Gitの用語とコマンドまとめ エンジニア転職に向けて勉強を開始したばかりですが、早速Gitの理解につまずきました。 自分のアウトプットと備忘録の為に、調べた内容をまとめました。 故に超初心者向けとなっております。 Gitとは何か ファイルのバージョンを管理するツール いつ、誰が、どのファイルを、どのように変更したかのか、という履歴を記録できる。 一つのシステムに対して一つのリポジトリという入れ物を作って、その中で作業をすることによって複数人で同時にシステムの開発をしていける。 Gitが用意したサーバーでファイルを共有する 複数人で共同開発する場合、このサーバーに対してファイルをアップロードやダウンロードすることでファイルの共有を行う。 このとき、サーバー側をリモートと予備、個人の作業用端末をローカルと呼ぶ。 GitHubでサーバーの中身を確認できる GitHubというツールを使うことで、サーバーの中身をウェブブラウザ上で見ることがGitとは別物なので混同しないように注意。必ずしもGitHubを使う必要はない。 Gitの基本用語 用語 意味 リポジトリ(Repository) 更新の履歴を管理場所場所 リモートリポジトリ(remote repository) サーバーにあるリポジトリ ローカルリポジトリ(local repository) 個人のPCにあるリポジトリ ステージング(staging) ファイルがGitの管理下にある状態(git Statusで緑色の状態) モディファイド(modified) git statusで表示される修正済みのファイル コミット(commit) 編集したファイルを保存すること オリジン(origin) リモートサーバーのこと プッシュ(push) ローカルからリモートにファイルをアップロードすること プル(pull) リモートにある最新のリポジトリ情報をダウンロードすること マスター(master) 正規の変更履歴 ブランチ(branch) gitの変更履歴を分岐機能 マージ(merge) 作業中のブランチに別のブランチを合流すること プルリクエスト GitHub上でブランチのマージを依頼することができる フェッチ(fetch) リモートの最新情報をダウンロードすること リベース(rebase) 異なるブランチの変更を反映させること。変更履歴が片方に集約される コンフリクト(CONFLICT) 同じブランチの同じ行を変更した場合に発生するエラー Gitのコマンド コマンド 実行される操作 git clone "リポジトリURL" 新規でリモートリポジトリからローカルリポジトリを作成する git status gitの状態を見る git add "ファイル名" ファイルをgitの管理下に置く(ステージング) git commit -m gitに保存を行う。コミットメッセージを付ける git log 何時何分に誰がコミットしたかの記録をみる git Push origin リモートにアップロードする git pull origin リモートのリポジトリ情報をダウンロードしてマージする git checkout -b "作成するブランチ名" origin/master 新しいブランチを切るコマンド git checkout "ブランチ名" 作業するブランチを切り替えるコマンド git branch ブランチの一覧をみるコマンド。緑色が現在のブランチ git branch -a リモート側も含めた全てのブランチを見る git merge "mergeしたいブランチ名" 指定したブランチを現在の作業ブランチに合流させるためのコマンド :wq viエディタに入力することでフェッチしたブランチをマージする git fetch origin リモートの最新情報をダウンロードする git rebase "A" "B" AのブランチにBのブランチを合流する git push -f リモートを無視して強引にプッシュする git reset --hard HEAD コミットする前の変更をリセットする git stash コミットしていない内容を全部消す git stash pop git stashコマンドで消した内容を元に戻す 最後に 他にも色々ありそうですが、今理解できそうなものはこんなところです。 実際使って慣れるしかないと思いますが、個人の開発であってもバージョンを管理することで 過去のデータを残すことができるのはとても便利だと思いました。 また今後エンジニアとしてやっていくにも操作方法はコマンドに慣れた方がいいと思いました。

ハッシュ値について コミットするたびに、 ハッシュ値が付けられている。 c773509683xxxxfb61bccxxxxe604e2ecd297c9c3c02 ↑ みたいなやつ。 ハッシュ値やリビジョン番号などと呼ぶ。 参考

ある文字列を変更したときのログを表示 $ git log -S"文字列" ログをgrep $ git log grep 検索する単語 ブランチのログをグラフィカルに表示 $ git log --graph リモートブランチとの差分を見る $ git diff origin/ブランチ名..コミットID ..の左側(origin/ブランチ名)から右側(コミットID)での差分を見ることができる。 コミット内容を詳細に表示 $ git show コミットID

GITとは？ 難しい言い方をすれば「分散型バージョン管理システム」です。 と言ってもややこしいので、一旦言葉だけでも頭の片隅に置いておき、もっとわかりやすく解説します。 簡単な言い方に変えると、「ファイルのバージョン管理が簡単にできるツール」です。 バージョンとは、ファイル（htmlファイルやcssファイルjsファイル etc...）を編集して、更新した履歴だと思ってください。 ポイント ・ GIT = ファイルのバージョン管理が簡単にできるツール ・ バージョン管理 = 履歴の管理のこと 誰が、どのファイルに、何を書き込んだのか、何を削除したのか、編集前とどう変わったのかをバージョン（履歴）として残しておき、それをずっと残しておき、いつでも確認し、必要であればそのバージョンまで戻すことも可能です。 つまり、バックアップなどを取る必要もなくなります。 Gitで何ができるのか？ Gitを導入することで得られるメリットは多くありますが、わかりやすい例でいうと以下になります。 メリット ・以前のバージョンにファイルを戻せる = いつでもバックアップに復元できる ・複数人で同じファイルを編集して、それを統合できる = 同じファイルを触っても上書きにならない ・履歴を複数人で共有できる = 誰が、いつ、どのファイルに、どんな編集をしたかが管理できる Gitの概念 Gitの管理構造は下記の図のようになっています。 リポジトリについて Gitを知る上で必ず覚えておく必要があるのが、「リポジトリ」という言葉です。 リポジトリとは、ファイルや履歴を保存するためのストレージのことで、簡単に言うと保管庫のようなものです。 Gitにはこのリポジトリが２種類あります。 ・リモートリポジトリ（webサーバー上に存在） ・ローカルリポジトリ（ローカルのPC上に存在） リモートリポジトリはWeb上に置かれており、一つのGitシステムに一つ設置して、各ユーザー共通で使用します。 ローカルリポジトリは各ユーザーがPC上に持っています。 ポイント ・ リポジトリ = ファイルや履歴を保存するための保管庫のこと。 ・ Gitにはリモートリポジトリとローカルリポジトリが存在する。 ・ リモートリポジトリはWebサーバーに置かれており、共有で使用する。 ・ ローカルリポジトリは各PCの中に置かれており、各ユーザーごとに使用する。 基本の4つのアクションを覚えよう（add・commit・pull・push） 「add」「commit」「pull」「push」 GITを扱う上で、この4つのアクションとその意味を覚えておけば、GITの基礎は60%くらい理解したことになります。 なので、この3つの言葉の意味について説明します。 add addとは上の図にあるように、コミットを行う前の準備みたいなもので、ファイルを編集したことをインデックスに登録する作業です。 簡単に言うと履歴を残す前の仮登録のようなものです。 ツールを使ってGitを操作する場合は、このaddの作業は自動で勝手にやってくれる事がほとんどです。 まあ、履歴を残す前の準備みたいに捉えてください。 commit commitは、addを行ったと後に、自分のローカルリポジトリに作業内容の履歴を保存する作業のことです。 コミットを実行するとファイルを編集した内容・日時・作業者を記録したファイルが生成されて保存されます。 pull pullは、共有しているリモートリポジトリに保存されているファイルの中で、自分のローカルリポジトリに存在しないファイルや、他のユーザーが更新したファイルのみをダウンロードする機能です。 つまり他の人の作業した履歴を自分のローカルリポジトリのファイルに反映させる作業です。 push pushは、自分のローカルリポジトリにあるファイルをリモートリポジトリにアップして保存する作業です。 自分のローカルリポジトリにある内容を、リモートリポジトリにアップ・反映させる感じです。 自分がpushして、更新したリモートリポジトリを、他のユーザーがpullして落としてくるといった形で、リモートリポジトリを共有しています。 「add・commit・pull・push」の流れ 【1】自分の手元でファイルを編集する。 【2】編集したファイルをaddでインデックスに登録。 【3】インデックスに登録した内容をcommitして、履歴として、ローカルリポジトリに保存する。 【4】ローカルリポジトリをリモートリポジトリに登録する時に、他のユーザーがリモートリポジトリを更新していた場合、一旦pullでリモートリポジトリの内容を、ローカルリポジトリに落としてくる。 ※リモートリポジトリが更新されていない場合は、pullは不要です。 【5】リモートリポジトリの内容をローカルリポジトリに取り込んだ後で、ローカルリポジトリの内容を、リモートリポジトリにpushして保存する。 すでにGit管理されているところに参加する方法 すでにGit管理されているところに自分も参加するときには、上記のアクションの前に行うことがあります。 それはcloneというアクションです。 clone cloneとは、簡単に言うとダウンロードのことです。 リモートリポジトリですでに保存されているファイルや、変更履歴を自分のローカルリポジトリとしてダウンロードしてくることです。 cloneをすることで、今までの履歴を自分のローカルに取り込み、管理することができます。 Gitを更に使いこなすためには ここまではGitの基本機能のバージョン管理について説明してきました。 ここからはGitを更に使いこなすために、もう一歩進んで説明していこうと思います。 「branch」「merge」「fetch」というアクションについてです。 branch まずはbranchです。branchはGitを使う上でとても大切な概念になります。 しっかり理解しておきましょう。 branchとはファイルを編集した履歴を分岐させて記録していく機能のことです。 WEBサイト作成やWEBサービスなどを行う上で、バグの修正や、機能・ページの追加などのファイル編集作業は複数のユーザーが同時に行うことが多くあると思います。 同時に並行して行われる作業を正確に管理するためにbranchを使用します。 branchは大きく分けると２つに分類できます。（もっと細かく分けることもできます） マスターブランチは、メインのブランチのことで、本体だと思ってください。 このマスターブランチから、その他のブランチを作成することを、ブランチを切ると言います。 ※実際にはマスターブランチからブランチを切って、さらにそのブランチからブランチを切ることもあります。 ブランチとは現在のバージョンをコピーして、別の作業空間を作るイメージです。 ちょっとややこしいかもしれないですが、世界に例えて説明します。 ここはわかりにくければ、無視してください！！！ マスターブランチ = 現実の世界 その他のブランチ = パラレルワールド マスターブランチから、その時点をベースに別のパラレルワールドを作成して、並行して作業を行うことができます。 その他のブランチで行っている作業は、マスターブランチには全く影響を与えません。 例えば、マスターブランチから、その他のブランチを一つ切って、そのブランチでファイルを全部削除してしまうとします。 削除されたブランチではファイルは全てなくなってしまってますが、マスターブランチではファイルは消されず残っています。 このようにお互い干渉しない、別のコピーを作って、別々の世界として作業を行うことができます。 これがブランチを切るということです。 merge branchがわかったところで、次はmergeについてです。 mergeとは切られたブランチで作業を行い、それを他のブランチに統合する作業のことです。 図ではマスターブランチからその他のブランチを切って、マスターブランチに再度統合しています。 この時に、同じファイルの同じ箇所を編集していた場合は、競合エラーというのが起こり、どっちの編集を残すかを選んでから、mergeすることができます。 fetch 最後にfetchについてです。 リモートリポジトリからファイルの最新情報を取得してきて、リモートリポジトリが更新されていないかを確認する作業のことでです。 ちょっと似ていてややこしいかもしれませんが、プルとは違い、ローカルのファイルを更新されることはありません。 本当は違うのですが、わかりやすくするためにあえて例えると、自分が見ているリモートリポジトリのキャッシュクリアみたいなものです。 プルは、このフェッチとマージを同時に行う機能といえます。 まとめ 以上がGitの基本概念の説明となります。 複数人で作業するときにはすごく便利で、今やどこの現場でも必須レベルのツールだと思います。 実際にGitを使うには概念だけでは扱えず、使い方や、Gitを操作するツールのことも学ぶ必要があります。 それはまた別の記事で説明しようと思います。

解決すべき問題 一年前のこと、Subversionを長く使ってきた開発チームにGitを教えようとした。わたしはGitのブランチをちゃんと説明したかった。というのもSubversionにもブランチという用語があるが、GitのブランチはSubversionとは似て非なるものだからだ。"Git"と"Subversion"と"ブランチ"をキーにネットを検索すると解説記事がたくさんみつかった。だがわたしが同僚諸君に説明するのに使えるようなひと目で理解できる記事が見当たらなかった。 いま自分の手元にあるプロジェクトの.gitディレクトリのなかにあるGitレポジトリの実物を読み出して図にしてくれる、そういうツールがほしい。 解決方法 Pythonでツール kazurayam/visualize_git_repository.py を開発した。これを使えばいま自分の手元にあるプロジェクトの .git ディレクトリのなかにあるオブジェクト群の実物を読み出し、Graphvizでグラフを生成してPNG画像ファイルを出力することができる。 説明 デモ用にディレクトリを作りGitレポジトリを作ろう。masterブランチとdevelopブランチでファイルを追加・変更などして、developをmasterにマージしよう。Gitレポジトリのなかがどんなふうに形を変化させていくか、図を示しつつ、説明しよう。 ステップ1 最初のコミット 新しいGitレポジトリを作ろう。いくつかファイルを作ってコミットしよう。 作業用ディレクトリを作った git initした ファイルを３つ作った。README.md、.gitignore、src/greeting.plを。 git add .した git commit -m "initial commit'した この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop まだ無い このグラフから次のことが読みとれる。 git initするとmasterという参照名が自動的に作られる。 Gitにおいてブランチとはひとつのcommitオブジェクトを指す別名にすぎない。上記の図で参照名 master は initial commit というコメントを含むひとつのcommitオブジェクトを指す別名にすぎない。 Gitには HEAD という名前の参照名が組み込みで定義されている。HEADもやはりひとつのcommitオブジェクトを指す。上記の図でHEADは参照名masterを指しているが、masterがcommitオブジェクトを指すので、けっきょくHEADもmasterを介して間接的にひとつのcommitオブジェクトを指すと解釈することができる。 HEADは特殊な参照名だ。さまざまのgit xxxコマンドを実行した副作用としてHEADが指すモノが切り替わる。 参照名HEADが参照名masterを指しているという状態を「カレント・ブランチがmasterである」と表現することもある。この言い方のほうが日本語としてすなおなので多用するだろう。以下で「カレント・ブランチが...」という文がでてきたら、参照名HEADから伸びた矢印 → が何を指しているかを思い浮かべてほしい。 ステップ2 developブランチを作る 新しいブランチ develop を追加しよう。 カレント・ブランチがmasterである状態で git branch developコマンドを実行した この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop 前と同じ このグラフから次のことが読みとれる。 新しい参照名 develop が作られた。 参照名 develop はinitial commitというコメントを含む commitオブジェクト すなわち master が指していたのと同じcommitオブジェクトを指している。 参照名HEADが参照名developを指すかたちに変更された。別の言い方をすると カレント・ブランチがmasterからdevelopに切り替えられた。 カレント・ブランチがdevelopに切り替えられた後でも参照名masterはGitレポジトリのなかに存続している。上の図ではmasterの図を省略したがそれは図をシンプルにして見やすくするためであって、消えてなくなったわけではない。 ステップ3 developでコミットする developブランチで新しいファイルを追加してコミットしよう。 ワーキングツリーで新しいファイル doc/TODO.txt を追加した カレント・ブランチがdevelopであることをたしかめて git add .を実行した git commit -m "add doc/TXT.txt"を実行した この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop 前と同じ このグラフから次のことが読みとれる。 新しいcommitオブジェクトができた。新しいcommitオブジェクトが親commitにリンクする形になり、commitオブジェクトの鎖がひとつ伸びた。新しいcommitオブジェクトはルートディレクトリ / を指すtreeオブジェクトにリンクしている。treeのなかには doc/TODO.txt ファイルのblobオブジェクトがある。つまり追加したファイルがちゃんと認識されている。 参照名developすなわちdevelopブランチがどのcommitオブジェクトを指しているか？を見ると自動的に更新されたのがわかる。ブランチ名はcommitオブジェクトの鎖の端っこ(ゴーヤの蔓の成長点のようなところ)を指すようにgitによって自動的に更新されるのだ。 ステップ4 masterブランチに戻る ファイル README.md を修正してコミットする前に、masterブランチに戻ろう。 git checkout master を実行した この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop 前と同じ このグラフから次のことが読みとれる。 参照名 HEAD が参照名 master を指すように更新された。すなわちカレント・ブランチがmasterに切り替わった。 masterブランチの中身は1回目のcommitをした時のままで変わっていない。 カレント・ブランチがmasterに切り替えられた後でも参照名developはGitレポジトリのなかに存続している。上の図ではdevelopの図を省略したがそれは図をシンプルにして見やすくするためであって、消えてなくなったわけではない。 ステップ5 masterでコミットする masterブランチで既存のREADME.mdファイルを変更してコミットしよう。 git branch --show-currentとやってカレント・ブランチがmasterであることを確かめた echo "#Read me carefully" > README.mdとやってファイルを更新した git add .した git commit -m "modified README.md"とやった この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop 前と同じ このグラフから次のことが読みとれる。 新しいcommitオブジェクトができた。新しいcommitオブジェクトが指すtreeのなかにあるREADME.mdファイルのblobをみるとhash値が変わっている。つまり変更されたREADME.mdファイルのために新しいblobオブジェクトがひとつ生成されて、そのhash値をcommitが参照している。これこそが「変更後のREADME.mdファイルがレポジトリにコミットされた」という表現の意味するところだ。 参照名 master が新しいcommitオブジェクトを指すように更新された。 ステップ6 developをmasterにマージする developブランチをmasterブランチにマージしよう。すなわちdevelopブランチで行ったファイルの追加・変更・削除をmasterブランチにとり込もう。 git branch --show-currentとやってカレント・ブランチがmasterであることを確かめた git merge developとやった この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop 前と同じ このグラフから次のことが読みとれる。 マージする前にmasterブランチにはcommitオブジェクトが2個あった。マージした後にmasterブランチにcommitオブジェクトが4個ある。2個増えた。 増えた2個のcommitオブジェクトうちひとつはdevelopブランチで作られたものだ。add doc/TODO.txtというコミットメッセージをもっている。developブランチだけで見えていたcommitオブジェクトがgit merge developコマンドによってmasterブランチでも見えるようになった。 増えた2個のcommitオブジェクトのうち残るひとつは新しくmasterブランチに追加されたものだ。このcommitオブジェクトは親(parent)コミットを2つ持っている点が特徴的だ。これをマージコミットともいう。 マージコミットの親コミット2つとはカレント・ブランチの先端にあったcommitオブジェクトと、マージされたブランチの先端にあったcommitオブジェクトである。マージコミットによってコミットの履歴2本が合流する。マージコミットより古い履歴は2本のまま残されて、マージコミットからあとは1本の履歴が始まる。 参照名 master はマージコミットを指すように自動的に更新された。 マージコミットは普通のcommitオブジェクトと同様にルートディレクトリ / に対応するtreeオブジェクトへの参照をもっている。そのtreeオブジェクトを起点としてすべてのファイルのblobオブジェクトを参照することができる。それらblobはmasterブランチとdevelopブランチにおいてこれまでに追加・変更・削除されたファイルの最新状態が反映されている。 上の図ではマージコミットが指しているtreeオブジェクトだけを描き、時系列的に古いcommitオブジェクトが指しているtreeオブジェクトを省略した。これは図を簡素化するためだ。treeオブジェクトがGitレポジトリから消えて無くなったわけではない。 ツールについて 本稿で示したPNG画像は自作のツール visualize_git_repository で描画した。このツールはPython言語で開発した。ソースコードは下記のGitHubレポジトリにある。 https://github.com/kazurayam/visualizing-git-repository このツールは下記2つのライブラリを利用している。 pytest python graphviz PNG画像を生成するにはコマンドラインで下記の操作をする。 $ cd $visualize_git_repository $ pytest -s kazurayam/visualize_git_repository.py::test_2_branch_and_mearge 上記の例を作るのにどういうgitコマンドを実行したのかを知りたいならプログラムのソースコードを読み解いてください。下記を入り口として解読してください。 kazurayam/visualize_git_repository.py まとめ 一年前の同僚諸君に本稿を読んでもらいたいなあ。これならGitのブランチとマージが理解できるだろうと思うのだが、どうだろうか？ author: kazurayam date: June, 2021 連作の目次 第1回 commitとtreeとblob 第2回 ブランチとマージ 第3回 タグ

解決すべき問題 一年前のこと、Subversionを長く使ってきた開発チームにGitを教えようとした。わたしはGitのブランチをちゃんと説明したかった。というのもSubversionにもブランチという用語があるが、GitのブランチはSubversionとは似て非なるものだからだ。"Git"と"Subversion"と"ブランチ"をキーにネットを検索すると解説記事がたくさんみつかった。だがわたしが同僚諸君に説明するのに使えるようなひと目で理解できる記事が見当たらなかった。 いま自分の手元にあるプロジェクトの.gitディレクトリのなかにあるGitレポジトリの実物を読み出して図にしてくれる、そういうツールがほしい。 解決方法 Pythonでツール kazurayam/visualize_git_repository.py を開発した。これを使えばいま自分の手元にあるプロジェクトの .git ディレクトリのなかにあるオブジェクト群の実物を読み出し、Graphvizでグラフを生成してPNG画像ファイルを出力することができる。 説明 デモ用にディレクトリを作りGitレポジトリを作ろう。masterブランチとdevelopブランチでファイルを追加・変更などして、developをmasterにマージしよう。Gitレポジトリのなかがどんなふうに形を変化させていくか、図を示しつつ、説明しよう。 ステップ1 最初のコミット 新しいGitレポジトリを作ろう。いくつかファイルを作ってコミットしよう。 作業用ディレクトリを作った git initした ファイルを３つ作った。README.md、.gitignore、src/greeting.plを。 git add .した git commit -m "initial commit'した この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop まだ無い このグラフから次のことが読みとれる。 git initするとmasterという参照名が自動的に作られる。 Gitにおいてブランチとはひとつのcommitオブジェクトを指す別名にすぎない。上記の図で参照名 master は initial commit というコメントを含むひとつのcommitオブジェクトを指す別名にすぎない。 Gitには HEAD という名前の参照名が組み込みで定義されている。HEADもやはりひとつのcommitオブジェクトを指す。上記の図でHEADは参照名masterを指しているが、masterがcommitオブジェクトを指すので、けっきょくHEADもmasterを介して間接的にひとつのcommitオブジェクトを指すと解釈することができる。 HEADは特殊な参照名だ。さまざまのgit xxxコマンドを実行した副作用としてHEADが指すモノが切り替わる。 参照名HEADが参照名masterを指しているという状態を「カレント・ブランチがmasterである」と表現することもある。この言い方のほうが日本語としてすなおなので多用するだろう。以下で「カレント・ブランチが...」という文がでてきたら、参照名HEADから伸びた矢印 → が何を指しているかを思い浮かべてほしい。 ステップ2 developブランチを作る 新しいブランチ develop を追加しよう。 カレント・ブランチがmasterである状態で git branch developコマンドを実行した この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop 前と同じ このグラフから次のことが読みとれる。 新しい参照名 develop が作られた。 参照名 develop はinitial commitというコメントを含む commitオブジェクト すなわち master が指していたのと同じcommitオブジェクトを指している。 参照名HEADが参照名developを指すかたちに変更された。別の言い方をすると カレント・ブランチがmasterからdevelopに切り替えられた。 カレント・ブランチがdevelopに切り替えられた後でも参照名masterはGitレポジトリのなかに存続している。上の図ではmasterの図を省略したがそれは図をシンプルにして見やすくするためであって、消えてなくなったわけではない。 ステップ3 developでコミットする developブランチで新しいファイルを追加してコミットしよう。 ワーキングツリーで新しいファイル doc/TODO.txt を追加した カレント・ブランチがdevelopであることをたしかめて git add .を実行した git commit -m "add doc/TXT.txt"を実行した この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop 前と同じ このグラフから次のことが読みとれる。 新しいcommitオブジェクトができた。新しいcommitオブジェクトが親commitにリンクする形になり、commitオブジェクトの鎖がひとつ伸びた。新しいcommitオブジェクトはルートディレクトリ / を指すtreeオブジェクトにリンクしている。treeのなかには doc/TODO.txt ファイルのblobオブジェクトがある。つまり追加したファイルがちゃんと認識されている。 参照名developすなわちdevelopブランチがどのcommitオブジェクトを指しているか？を見ると自動的に更新されたのがわかる。ブランチ名はcommitオブジェクトの鎖の端っこ(ゴーヤの蔓の成長点のようなところ)を指すようにgitによって自動的に更新されるのだ。 ステップ4 masterブランチに戻る ファイル README.md を修正してコミットする前に、masterブランチに戻ろう。 git checkout master を実行した この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop 前と同じ このグラフから次のことが読みとれる。 参照名 HEAD が参照名 master を指すように更新された。すなわちカレント・ブランチがmasterに切り替わった。 masterブランチの中身は1回目のcommitをした時のままで変わっていない。 カレント・ブランチがmasterに切り替えられた後でも参照名developはGitレポジトリのなかに存続している。上の図ではdevelopの図を省略したがそれは図をシンプルにして見やすくするためであって、消えてなくなったわけではない。 ステップ5 masterでコミットする masterブランチで既存のREADME.mdファイルを変更してコミットしよう。 git branch --show-currentとやってカレント・ブランチがmasterであることを確かめた echo "#Read me carefully" > README.mdとやってファイルを更新した git add .した git commit -m "modified README.md"とやった この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop 前と同じ このグラフから次のことが読みとれる。 新しいcommitオブジェクトができた。新しいcommitオブジェクトが指すtreeのなかにあるREADME.mdファイルのblobをみるとhash値が変わっている。つまり変更されたREADME.mdファイルのために新しいblobオブジェクトがひとつ生成されて、そのhash値をcommitが参照している。これこそが「変更後のREADME.mdファイルがレポジトリにコミットされた」という表現の意味するところだ。 参照名 master が新しいcommitオブジェクトを指すように更新された。 ステップ6 developをmasterにマージする developブランチをmasterブランチにマージしよう。すなわちdevelopブランチで行ったファイルの追加・変更・削除をmasterブランチにとり込もう。 git branch --show-currentとやってカレント・ブランチがmasterであることを確かめた git merge developとやった この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。 master develop 前と同じ このグラフから次のことが読みとれる。 マージする前にmasterブランチにはcommitオブジェクトが2個あった。マージした後にmasterブランチにcommitオブジェクトが4個ある。2個増えた。 増えた2個のcommitオブジェクトうちひとつはdevelopブランチで作られたものだ。add doc/TODO.txtというコミットメッセージをもっている。developブランチだけで見えていたcommitオブジェクトがgit merge developコマンドによってmasterブランチでも見えるようになった。 増えた2個のcommitオブジェクトのうち残るひとつは新しくmasterブランチに追加されたものだ。このcommitオブジェクトは親(parent)コミットを2つ持っている点が特徴的だ。これをマージコミットともいう。 マージコミットの親コミット2つとはカレント・ブランチの先端にあったcommitオブジェクトと、マージされたブランチの先端にあったcommitオブジェクトである。マージコミットによってコミットの履歴2本が合流する。マージコミットより古い履歴は2本のまま残されて、マージコミットからあとは1本の履歴が始まる。 参照名 master はマージコミットを指すように自動的に更新された。 マージコミットは普通のcommitオブジェクトと同様にルートディレクトリ / に対応するtreeオブジェクトへの参照をもっている。そのtreeオブジェクトを起点としてすべてのファイルのblobオブジェクトを参照することができる。それらblobはmasterブランチとdevelopブランチにおいてこれまでに追加・変更・削除されたファイルの最新状態が反映されている。 上の図ではマージコミットが指しているtreeオブジェクトだけを描き、時系列的に古いcommitオブジェクトが指しているtreeオブジェクトを省略した。これは図を簡素化するためだ。treeオブジェクトがGitレポジトリから消えて無くなったわけではない。 ツールについて 本稿で示したPNG画像は自作のツール visualize_git_repository で描画した。このツールはPython言語で開発した。ソースコードは下記のGitHubレポジトリにある。 https://github.com/kazurayam/visualizing-git-repository このツールは下記2つのライブラリを利用している。 pytest python graphviz PNG画像を生成するにはコマンドラインで下記の操作をする。 $ cd $visualize_git_repository $ pytest -s kazurayam/visualize_git_repository.py::test_2_branch_and_mearge 上記の例を作るのにどういうgitコマンドを実行したのかを知りたいならプログラムのソースコードを読み解いてください。下記を入り口として解読してください。 kazurayam/visualize_git_repository.py まとめ 一年前の同僚諸君に本稿を読んでもらいたいなあ。これならGitのブランチとマージが理解できるだろうと思うのだが、どうだろうか？ author: kazurayam date: June, 2021 連作の目次 第1回 commitとtreeとblob 第2回 ブランチとマージ 第3回 タグ 第4回 ワークツリーとインデックスとblob

Githubトークン作成方法 Githubにログイン -> Settings -> Developer settings -> Personal access tokens -> Generate new token -> Note: 名前、　 -> Select scope↓ admin：repo_hook　にもチェック！ -> VCS -> Import into Version Control -> share project on github -> token入力してログイン

はじめに git mergeと違ってリベースをしたときのコンフリクトは各コミットごとに起こるため若干厄介です。 その対処法を見様見真似でやってみたので、こちらでまとめます 準備 まずは準備です。 ブランチを用意して、それぞれで作業していきます terminal % git br * master % git br test % git br * master test index.html <p>master側の処理です</p> terminal % git add index.html % git commit -m "masterでの処理" index.html <p>test側の処理です</p> terminal % git add index.html % git commit -m "testでの処理" リベースしていく さっそくリベースしていきます。まずtestブランチで以下を叩きます terminal git rebase master すると以下のような表示が出ます。 Auto-merging index.html CONFLICT (content): Merge conflict in index.html error: could not apply c2657f6... test側での処理 Resolve all conflicts manually, mark them as resolved with "git add/rm <conflicted_files>", then run "git rebase --continue". You can instead skip this commit: run "git rebase --skip". To abort and get back to the state before "git rebase", run "git rebase --abort". Could not apply c2657f6... test側での処理 コンフリクトですね。さっそく手元のコードを見てやります。 index.html <<<<<<< HEAD <p>masterでの処理です</p> ======= <p>test側での処理</p> >>>>>>> c2657f6 (test側での処理) 今回はあえて次のように処理してやります。 index.html <p>喧嘩両成敗！！</p> そして、コミットします。 terminal git add index.html git commit -m "リベースのコンフリクト解消1" git statusして状態を見てやリましょう terminal interactive rebase in progress; onto 6d9705c Last command done (1 command done): pick c2657f6 test側での処理 No commands remaining. You are currently editing a commit while rebasing branch 'test' on '6d9705c'. (use "git commit --amend" to amend the current commit) (use "git rebase --continue" once you are satisfied with your changes) nothing to commit, working tree clean ご丁寧に次にないすべきか書いてあります。 今回はコンフリクトを解消したので、続行させます。 terminal % git rebase --continue Successfully rebased and updated refs/heads/test. よし！！成功！ 次にmasterブランチに行きます。 masterブランチでマージしてやります terminal git merge test おわり コンフリクトは怖いですが絶対にわけわからん！ということはないはずなので落ち着いて対応しましょう！