Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こんにちは、Watanabe Jin(@Sicut_study)です。 今回は記事1本で初心者が必要な知識を全て学べるGitチュートリアルを紹介していきます。 世の中にはたくさんのGitに関する教材があります。しかし、真に良いと思える教材はありません。 もちろん私も4年前はGitという言葉を知らない状態から、書籍などで学習をしました。 しかし、書籍で知識を得たとしても実際にコマンドを使って実践的に学んだわけではなかったのでほとんど身になりませんでした。 私が思う世の中にあるGitの教材のイケてない点は2つです。 結局ほとんどの
中級Git操作
今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」（Gitがわかっているとでも思っているか？）発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"（記録ずみ解決方法を再利用）の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
「仕事でWordをめちゃくちゃ使うんだけど、Gitみたいなソース管理、バージョン管理できないかな」やりたいのは差分比較→有識者から様々な提案が寄せられる
もくだいさん🇯🇵 365おじさん @mokudai 仕事でWordをめちゃくちゃ使うんだけど、Gitみたいなソース管理、バージョン管理できないかなぁ やりたいのは差分比較なんだよなぁ Wordなので文章の追加削除だけじゃなく、スタイルの適用、セクションの変更など全部比較したい。 。。。世の中には無さそうだなぁ もしあればだれか教えて！ #m365jp もくだいさん🇯🇵 365おじさん @mokudai セクションのスタイルを正しく使うと、「特定のセクション（中表紙とか）にはページ番号付けない」とか設定できるんですけど、さぼって白いオブジェクトで隠すやつがいるので、こういうのも駆逐したい。 pic.x.com/yotudzzdn0
1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ
本稿は当初チーム開発時のメンバー向けにまとめたものです。 ある程度、端折っていた背景などを記載しました。 git初心者同士でのチーム開発において、git操作を詳しく知らないメンバーも含め安全に行う必要がありました。しかし、開発期間はごくわずか...この状況を回避するために、下記の対応をとりました。 Gitコマンドの基礎的な内容を理解する（私） 各種操作をGUI上で完結させる拡張機能を色々と導入する シンプルな開発フロー(Github flow)を採用し、コマンド実行に相当する操作を限定する 各操作をGUI上での操作に置き換え、チームメンバーに教える 本稿はその際の、コマンドやGUI操作に関するメモをまとめたものになります。 こういった取り組みのおかげか、チームの開発をすんなりフローに乗せることができました。 ■ 前提条件 対象とする動き Github flowを回すうえで、 cloneする
物理情報工学ソフトウェア開発演習
え？まだgit checkoutしてるの？
公式ドキュメントには以下のように書かれています。 THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. 和訳：このコマンドは実験的です。動作が変更される可能性があります。 この記事の内容と違う場合があるので、ご注意ください。 この記事は2024年2月28日時点の情報です。 え？まだgit checkoutしてるの？ git checkoutといえば、ブランチを切り替えたり、git addしたファイルを元に戻したりするコマンドですが、それはもう古いです。 実は2019年8月リリースのgit 2.23からgit switchとgit restoreが追加されました。 知らなかった人も多いのではないでしょうか？(恥ずかしながら私は知らなかった...) 「先輩、checkoutってなんすか？」と後輩に聞かれる前に、この記事を読んでgit sw
VScodeだけでGit操作を完結させるのだ～～ッ!!
VScodeだけでGit操作を完結させる方法について書くのだ。 👀その前に！ この記事は、以下の2つの拡張機能がインストールされている前提で進めるのだ。 Git Graph - Visual Studio Marketplace GitLens — Git supercharged - Visual Studio Marketplace インストールしておいてほしいのだ。 ✅ステージング(git add ◯） 以下のようにするのだ。 ＋ボタンをクリック：ステージングする ーボタンをクリック：ステージングを解除する ▲ステージング→解除 ✅コミット名を自動でつける 右にある✨ボタンを押すと、コミット名を自動で決めてくれるのだ👇 ▲この例だと、変更内容が意味不明すぎて変なコミット名になってるし、現状英語だけみたい？ これは、GitHub Copilotの機能なのだ。 ✅コミット(git c
GitはLinuxカーネルのソースコード管理に用いるために開発された分散型バージョン管理システムで、GitリポジトリをホスティングするGitHubのユーザー数は1億人を超えます。一方、軽量データベースのSQLiteの開発においてはGitではなくFossilというバージョン管理システムが利用されており、SQLiteの開発陣が「なぜGitを使用しないのか」という理由を公式サイトで説明しています。 Why SQLite Does Not Use Git https://sqlite.org/whynotgit.html なお、Fossilがどんな機能をもつバージョン管理システムなのかについては下記の記事を読むと分かります。 GitとGitHubの機能をひとつのバイナリに詰め込んだ「Fossil」レビュー - GIGAZINE 1：Gitは適切な状況認識を提供しない SQLiteにどんな変更が加え
今やバージョン管理ツールとして圧倒的な人気を集める「Git」ですが、Linuxカーネル開発のために作られたという経緯もあり、使いこなすにはかりの経験値が必要となります。 この問題を解決するために、Googleのソフトウェアエンジニアによって、新しいバージョン管理システム「Jujutsu」の開発が進められています。 Jujutsuの素晴らしさを紹介する記事「jj init 」によると、Jujutsuは過去のバージョン管理システムの問題点やメリットを分析して作られていて、Googleの既存のバージョン管理システムを置き換える勢いがあるとのこと。 JujutsuはmacOSでは、brew install jjを実行するだけで使用することができ、バックエンドとしてGitを使用しているため、採用にコストがかからないというメリットもあるそうです。 公式サイトでは、Jujutsuの特徴がリストアップされ
こんにちは！ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか？ Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f
Hello! I always wish that command line tools came with data about how popular their various options are, like: “basically nobody uses this one” “80% of people use this, probably take a look” “this one has 6 possible values but people only really use these 2 in practice” So I asked about people’s favourite git config options on Mastodon: what are your favourite git config options to set? Right now
設計ドキュメント腐る問題、 Git管理で運用してみた 本当のところ 2023.12.5 真野隼記 ドキュメント管理を制する 陳腐化を防ぐための実践事例 Lunch LT
Gitのブランチ戦略にはいくつかあります。 Gitフロー GitHubフロー GitLabフロー チームの戦略を考えるときにどれかを参考にしつつカスタマイズするときにいろいろ不都合が生じてしてきて複雑になってしまうことってありますよね？ 社内でブランチの管理の議論をする中で、ブランチの役割を明確にした上で、どのブランチがどのような役割を持っているのかを明確にした方が混乱が少なくなるのではないか？ というのを考えていました。 特に、プロジェクトごとに同じ名前でも役割が違うなー、というのとかもあり、ブランチ名＝役割ではなく、ブランチの上位概念として役割を考えて、それを実際のブランチとの対応づけを行う必要があるのではないかな、と。 CI/CDと組み合わされることで、releaseブランチ==ステージング環境となってしまい、ステージング環境を使いたいリリース前のブランチと、ホットフィックスの検証の
はじめに こんにちは、kenです。みなさんコンフリクト解消してますか！ チーム開発をしているとコンフリクトとは嫌でも向き合うことになりますが、コンフリクト解消って緊張感のある作業なのでやりたくないですよね。 そんなコンフリクト解消をちょっぴり楽にする(かもしれない)コマンドを最近知ったので今回はそれを紹介します、その名もgit rerereです。 git rerereとは Gitの公式ドキュメント（日本語版）には次のように記載されています。 git rerere コマンドはベールに包まれた機能といってもいいでしょう。これは “reuse recorded resolution” の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。 そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。 ここに書かれているように、git
Gitを学びたての人へ Gitを学びたての皆さん、こんにちは！今年の4月よりエンジニアとして新卒入社した k_uki512です！🎉 会社の新人研修や、プログラミングスクールでGitを初めて触り始めた方もいらっしゃるのではないでしょうか。そんな方が「分からない」という状態に陥りやすいのが "Git" のコマンドだと思います。 分からない理由を分析してみた Gitのコマンドが分かりづらい理由として以下のような原因があると考えました。 データをコマンドでやり取りすることがなかった 用語いっぱい。違いが分からない、、（add,commit…） データ（変更履歴）の流れが見えづらい つまり変更履歴という概念が抽象的かつ、pushまでのステップが多いことが原因だと考えました。 そこで、この記事ではGitの一連の流れを、わかりやすく電車に例えて解説していきます！ この記事を通じてGitの流れを学び、会
gitでrebaseしまくるzaruです、こんにちは。rebaseする時、編集途中のファイルがあるとstashしてくれと怒られますよね。本当に面倒くさいのですが、これを一発でstashしなくて済む方法を紹介します。
より良いコミットメッセージを残すことは Git を使った開発をする上で重要なことです。優れたコミットメッセージは、それを読んだ人がコードを理解するのに大いに役立ちます。 では、どのようなメッセージが良いもので、どのようなメッセージが悪いものなのでしょうか？ それについて掘り下げていきたいと思います。 基本的な Git Commit Message の書き方 詳しいところは、以下の3サイトを参照してください。特に「How to Write a Git Commit Message」には基本がすべて書かれています。 How to Write a Git Commit Message https://cbea.ms/git-commit/ Gitのコミットメッセージをうまく作成する7つのルール （「How to Write a Git Commit Message」の和訳記事） https://
ChatGPTにgitのリポジトリ渡すと全ソースコード.txtをダウンロードさせてくれるやつ〜〜〜〜（AIに食わせるコード一覧が欲しい時用）
クレデンシャル含むソースコードをChatGPT等のクラウドLLMサービスにアップロードしないでください。 今回のプロンプトはオープンなリポジトリのみを対象としており、シェルスクリプトが実行される環境もChatGPT側のクラウド上のサンドボックス内のみを想定しています。 ローカル環境では以下のシェルスクリプトをそのまま実行せずに、ご自身が作成したシェルスクリプトを利用してください。 以下はソースコードのプロジェクトルートで実行することで、ソースコードのダンプを.txt形式でダンプするシェルスクリプトです。 \`\`\` #!/bin/bash # バイナリファイルかどうかを判定する関数 is_binary_file() { local file="$1" local file_output file_output=$(file "$file") if [[ "$file_output" ==
混乱を引き起こしがちなGitの用語まとめ
分散型バージョン管理システムのGitは2005年の登場以降シェアを伸ばし続け、2022年の調査では約94％のユーザーに利用されるほど一般的なツールとなっています。Gitにはさまざまな機能が搭載されていますが、その中で特に混乱を引き起こしがちな用語について、Gitを15年近く使用してきたというジュリア・エヴァンスさんが解説しています。 Confusing git terminology https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ ◆HEADと「heads」 HEADは現在チェックアウト中のブランチやコミットを指しており、「.git/HEAD」に保存されています。一方「.git/refs/heads」に保存されているのはブランチで、「heads」は「branches」と読み替えればOKとのこと。 ◆detached HE
Gitは、バージョン管理に強力なツールで、開発者がコード変更を追跡し、プロジェクトで協力し、作業履歴を維持することを可能にします。Gitは複雑なプロジェクトを管理するための堅牢なフレームワークを提供しますが、同時にプラットフォームの初心者にとっては習得の曲線があり、一般的なミスにつながる可能性があります。これらのエラーは、些細な面倒から、プロジェクトのワークフローに重大な混乱をもたらすまでさまざまです。 これらの落とし穴を理解し、回避することは、プロジェクトの整合性と安定性を維持するだけでなく、チームメンバー間の効果的な協力関係を育むためにも不可欠です。このブログでは、Gitを使用する際にユーザーが直面する最も一般的な課題について掘り下げます。メインブランチへの直接コミット、ブランチの非効率的な使用、不適切なコミットの処理、マージコンフリクトの解決など、さまざまな問題を探ります。 一般的な
発端 Pull Request で force push されると差分がわからなくなるから困るんだけどみんなどうしてますか？— codehex.bsky（へっくす） (@codehex) 2024年2月25日 ポストの前提がちょっとわかりませんが、レビュー後にforce pushされると、どこに修正を入れたのかわからないケースだと仮定します。プルリクエストがまだドラフト状態でのforce pushやrebaseで困るケースはそんなにないと思うからです。 git commit --fixup このケースではgit commit --fixupが便利です。レビューで指摘が入ったコミットに対して--fixupをかけておき、レビュワーはfixupコミットの内容を確認します。レビュワーが確認してOKが出た段階で、git rebase -i --autosquashなどを使ってfixupコミットを元コ
第8回は、前回の続きとして、GitHubとの連携機能、連携を強化するGit History、Git Graph、GitLensといった拡張機能を紹介し、GitHub上でワンストロークでオンライン版VSCodeを呼び出せるGitHub Codespacesについても紹介します。 はじめに Microsoftの提供するVisual Studio Code（VSCode）は、2015年の最初のリリースから、今では開発用エディタの定番の座を占めるまでになりました。これには、無償で使えることも大きいですが、何よりエディタとしての使いやすさ、そしてさまざまな拡張機能によっていくらでも使い勝手を向上させたり、利用の領域を拡げたりすることも大きいでしょう。本連載では、このVSCodeにフォーカスし、基本的な使い方から拡張機能の活用、そして本格的な開発現場での利用を想定した高度な機能までを紹介していくことで
はじめに Microsoftの提供するVisual Studio Code（VSCode）は、2015年の最初のリリースから、今では開発用エディタの定番の座を占めるまでになりました。これには、無償で使えることも大きいですが、何よりエディタとしての使いやすさ、そしてさまざまな拡張機能によっていくらでも使い勝手を向上させたり、利用の領域を拡げられたりすることも大きいでしょう。本連載では、このVSCodeにフォーカスし、基本的な使い方から拡張機能の活用、そして本格的な開発現場での利用を想定した高度な機能までを紹介していくことで、読者がVSCodeマスターになるお手伝いをします。 対象読者 テキストエディタメインで開発してきた方 Visual Studioより軽い環境が欲しいと考えている方 Visual Sudio Codeをもっと使いこなしたい方 必要な環境 本記事の内容は、以下の環境で動作を確
はじめに Git Graphという拡張機能を使います。 Git GraphとGitLensという拡張機能を使います。[1] また、gitから開かれるエディタをvscodeにしておきます。 コミットのまとめかた（1分未満でできるよ） ステータスバーのGit Graphのボタンをクリックして、Git Graphの画面を開きます。 まとめたいコミットの一つ前のコミット（今回だとinit）を右クリックして、「Rebase current branch on this Commit...」を選択します。 「Launch Interactive Rebase in new Terminal」にチェックを入れて「Yes, rebase」をクリックします。 こんな画面が開きます。 まとめたいコミットを上から順にpickからsquashに変更します。最後の一つはpickのままにしておきます。そして「STAR
git-replay というコマンドが追加されたみたいなので触ってみた。とは言っても、自分はあんまり凝ったことはやらないので、細かいところまでは踏み込まずに最低限の使い方ができたらいいなってくらいの気持ちで触った。 github.blog この記事には、こんな風に書いてある↓ git replay exists to address these challenges. It offers an alternative to git rebase that, in addition to being far more performant: Can operate in bare repositories. Can rebase branches other than the currently checked-out one (in non-bare repositories). Can
git worktreeを使ってプルリクレビューを効率化した話 - freee Developers Hub
共通マスタ基盤チームにおけるソフトウェアエンジニアのyugoです。 共通マスタ基盤チームは、従業員、商品、取引先といった製品横断で利用できるマスタデータを一元管理し、ユーザーにfreeeプロダクトにおける統合体験を提供できる基盤開発をミッションとしております。 そんな共通マスタ基盤チームチームですが、製品横断で利用されるとだけあり、日々の開発フローでPRレビューの割り込みが多いです。そんな中で、開発フローにgit worktreeを導入してみて、個人的にはPRレビューの割り込み作業時に割と使いやすかったので紹介します。 git worktreeを使うに至る背景 実はfreeeで働く以前、前職で先輩シニアエンジニアが「レビューするときにgitのstagingにあげていない自分の変更を、stashしたり、テキトーにcommitしてからrebaseするなりするの嫌だったら、worktree使った
VS Code でコミットするときに GitHub Copilot を使っていると コミットメッセージを生成してくれたりします。 図 1 コミットメッセージを Copilot で生成 英語苦手な自分からすると「マジうれしいんですけど」という感じなのですが、コミットメッセージはできればエディターで記述したいと考えてしまいます。 そこで今回は「コミットメッセージをエディターで編集する利便性」を維持しつつ、「GitHub Copilot による生成機能もできるだけ利用しよう」という内容のメモになります。 VS Code のエディターでコミットメッセージを記述するとは VS Code でコミットメッセージを記述する方法としてはソース管理タブの利用が一般的かと思われます。 図 1-1 ソース管理タブのフィールドから普通に入力 一方で上記とは別に、コミット用のコマンドを実行しエディターの中で記述する方
開発者が知っておくべき Git コマンド12選
Author Kedasha Kerr 初心者のためのGitHub入門の最新版では、Gitを使いこなせるようになるために欠かせないGitコマンドを紹介します。 GitHub for Beginners へようこそ。このシリーズでは、初心者向けにリポジトリからプルリクエストまで、あらゆるものの基本を学べるようになっています。(これらが何なのかまだわからない？大丈夫です、そのために私たちはここにいるのですから！) 前回の記事ではGitの基礎について説明しましたが、今日はさらに一歩進んで、開発者なら知っておくべき最も重要なGitコマンドについて説明します。 毎日使うことになる Git コマンドのトップ 12 を紹介しましょう。 Git の設定 マシンにGitをインストールしたら、まず最初にすべきことは、Gitがあなたが誰であるかを理解できるようにGitを設定することです。git config コ
git stashをもっと便利に扱いたいと思い、fzfを使って使いやすくしてみた。以下のURLに載っているものを参考にして自分にとって使いやすいように改変した。 fzfでGUI選択したファイルをgit stashするシェルスクリプト git-stash-explore できたこと 今の変更ファイルをfzfを使って選択して、選択したものだけをstash (git-stash-select) stash一覧の中から中身をpreviewしながら選び、apply or deleteする (git-stashes) 現在の変更ファイルから一部を選んでgit stashするコマンド fzfでGUI選択したファイルをgit stashするシェルスクリプト を参考に、git-stash-selectというコマンドを作った。 #!/usr/bin/env bash # Get the root direct
はじめに データサイエンティストのasanoです。 Gitコマンドを学んだあと「Gitブランチ戦略」や「綺麗なコミット」や「プルリクの出し方」など、チームでGitのコード管理を円滑に運用するためのノウハウは実務を通して学ぶことが多いと思います。 実際の業務ではそういった暗黙知になっている部分を認識合わせするために、本記事のようなガイドラインを利用しています。 ※ これを読んでスキルが一朝一夕で身に着くわけではなく少ない時間でも毎日Gitを触る中で身につけるものだと思いますが、学習の一助になれば幸いです。 円滑に運用するために 次の3つをチーム全員で取り組む必要があります。 ①Git運用モデルを取り入れる ②綺麗なコミットを心がける ③適切なプルリクを出す、受ける ①Git運用モデルを取り入れる まずはA successful git branch model (git-flow)を学びまし
AWS 構成図を S3 にアップするだけで Terraform のコードを git push / pull request から terraform plan まで自動で動作するシステム
2024/10/25 社内 LT 会 ■GitHub ・Lambda https://github.com/hiyanger/diagram-to-terraform-cicd-lambda ・生成コード https://github.com/hiyanger/diagram-to-t…
こんにちは。メルカリのBackendエンジニアの@osari.kです。 この記事は、Mercari Advent Calendar 2023 の9日目の記事です。 一般に大きなプルリクエストはレビューが大変で、マージまでに時間がかかります。一方で複数の小さいプルリクエストに分割するとコードレビュー待ちの間、関連する開発がブロックされることがあります。今回は機能の開発時間を短くするために、チームで試したGitのブランチ戦略の1つであるStacking手法をケーススタディを交えて紹介します。 大きなプルリクエストがもたらす問題点 大きなプルリクエストがもたらす問題とは何でしょうか？ コードレビューで読むサイズが増える コードレビュー中の修正回数が増える（可能性が増える） コードレビューで必要な知識の範囲が広がる（可能性が増える） 変更箇所が多いのでリリースのリスクが増加する プルリクエストが大
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【図解解説】これ1本でGitをマスターできるチュートリアル！【完全版】 - Qiita
2024年Gitワークフロー再考 | フューチャー技術ブログ
結局 Git のブランチ戦略ってどうすればいいの？ - Qiita
Git不慣れ勢を束ねて安全なチーム開発をするメモ - Qiita
Gitの仕組みと用語 / GitHub Term
SQLiteがバージョン管理システムとしてGitを採用しない理由
Gitを置き換えるバージョン管理システム「Jujutsu」 | ソフトアンテナ
Git の Squash マージをやめた話 - Mobile Factory Tech Blog
Popular git config options
20231206_設計ドキュメント腐る問題、Git管理で運用してみた本当のところ
Gitのブランチの役割を考える | フューチャー技術ブログ
【Git】同じコンフリクト解消を繰り返している人に教えたい「git rerere」 - Qiita
初めてのGitは電車で例えて学ぼう！初学者向け基本Gitコマンド入門 - Qiita
gitでstashが面倒なあなたにautostash
「エクスプローラー」に「Git」を統合 ～アプリ開発者のためのWindowsシェル改善／ファイル右クリックメニューからのTAR/7z圧縮、「Sudo for Windows」なども
より良い Git コミットメッセージを書こう - Qiita
Git の一般的な落とし穴を回避します: ベスト プラクティスと回復手順。 | DevelopersIO
git commit --fixupを使いましょう - Don't Repeat Yourself
VSCodeのGit連携をさらに便利に！ 拡張機能Git History、Git Graph、GitLensを解説
VSCodeのソース管理をはじめよう！ Gitの連携機能について解説
VSCodeでGitのコミットを楽に整理して、レビュワーに「コイツできる」と思わせよう。
git-replay を最低限の使い方で触ってみた - Mitsuyuki.Shiiba
VS Code + GitHub Copilot 環境でも git commit しちゃうんだな、これが
fzfを使ってgit stashを便利に扱えるように - $shibayu36->blog;
Gitでコード管理する際の運用ガイドライン - Qiita
Gitブランチ戦略 Stacking手法のケーススタディ | メルカリエンジニアリング