Git
新人プログラマ応援
OriginalTISDay 5

サル以下の存在がまとめた「Git用語」図解

はじめに

どうも、「サルでも分かるGit入門」が分からなかった、サル以下の存在です。

正確には、各ページの言わんとしていることは分かるし、言われた通り操作もできる。
だけど、各操作が具体的に、何を対象にしているのかが分からない。。。

初めての人に教える機会もあるので、ついでにまとめてみました。

基本操作

image.png
※寒色:頻度の少ない操作(比較的)
※暖色:頻度の多い操作

操作 説明
fork リモート上でのリポジトリのコピー
fork時点の資源/ブランチ構成がコピーされる。fork以前の履歴情報はコピーされない。
clone ローカルへブランチのコピー(ブランチは指定する)
「clone元となるリモートリポジトリおよびリモートブランチ」と「cloneしたものを格納するローカルディレクトリ(≒working-tree)」を指定する。
merge 後で補足します。
fetch リモートブランチの状態を、リモート追跡ブランチに反映する。
マージはしないので、差分チェックしたい時は、いきなりpullするよりは、一度fetchした方が良い。
fetchを自動で行ってくれるツールもある(SourceTreeなど)。
pull fetch + merge。リモートブランチの内容を差分を確認せずに一気にmergeしたい時に行う。
add/stage 修正したファイルをcommit対象にする場合、この操作をする。
この操作がされていないファイルは、commitされない。
なお、add/stageした後に、同一ファイルに対して変更を加えても、その変更はcommitされない。
commit add/stageされた物を対象として、ローカルブランチに変更を反映する。
push ローカルブランチの内容をリモートブランチに反映する。
stash(stash save) indexとworking-treeにある変更をstashという領域に退避する。
この操作を行うと、indexとworking-treeは、local-branchと同じ状態(変更を加える前の状態)になる。
stash操作をしたタイミング毎に保持される。(過去退避したものが上書きされたり、過去分にマージされたりはしない。)
stashの後のsaveは省略できるらしい。
なお「ファイルの追加」に関しては、working-treeからの直接stashできず、一度add/stageしてindexにある状態だとstashできる。(「ファイルの削除」はstashできた。)
stash apply 指定した退避状態を、working-treeに反映させる。
競合が発生していると失敗するので、stashはあまり溜めすぎないようにしたい。
「ファイルの追加」に関してだけは、working-treeだけじゃなく、indexにも反映される。
英語 日本語 説明
remote-repository リモートリポジトリ サーバにあるリポジトリ。
githubだと「Create new file」などで直接変更することもできるが、基本的に直接操作しない類のもの。
local-repository ローカルリポジトリ PCにcloneして来たリポジトリ。基本的に直接操作するのはココ。
remote-branch リモートブランチ サーバにあるブランチ。「リポジトリじゃなくて、ブランチやで!」って伝えたい時に主に使われる。
local-branch ローカルブランチ 図示されている通り。
index インデックス ココに入れた時点のファイル状態がコミット対象になる。
working-tree / working-copy 作業コピー / ワーキングツリー など 実際のディレクトリに格納されているファイル。cloneする際に指定したディレクトリを指す。
stash スタッシュ 一時退避したものが格納されている領域。

自分が正しく理解できていなかったこと

ブランチとは

「この線がブランチなのだな」と理解していたのが、適切じゃなかった。
概念的には「線」に近いのだが、実際の挙動としては「点(コミット)」が中心に据えられている。

概念としてのブランチ
image.png

実際のブランチが指し示しているもの
image.png
ここらへんは下のマージについての説明で補足します。

マージ操作におけるブランチ

merge操作についてもここで合わせて説明します。

概念としてのマージ
image.png

実際のマージ
以下の図では、developブランチを起点(checkoutした状態)として、merge対象にfeatureを指定しています。コマンドライクに言うならgit merge feature
developブランチでgit merge featureを実行したときに行われる操作は、「developとfeatureの2つを親としたマージコミットが作成され、それが新たなdevelopになる」というもの1
featureブランチが指すコミットは変化しない。
image.png

ブランチとタグの違い

似たような概念で、「タグ」がいますが、以下のような違いがあります。

  • タグは静止点なので、他にcommit/mergeがどれだけ発生しても、指し示すcommitは変動しない。
  • ブランチは、概念としては「線」の扱いなので、commit/merge等で指し示すcommitが変動する。
    • 該当のブランチであると認識される「最新のcommit」を常に指し示す。

最後に

色々調べたつもりですが、間違ってたら教えてください・・・

なお、弊社のアドベントカレンダーは、こんなサル以下な記事とは違って、良記事ばっかりなので、ぜひ見てみて下さい。

こんな記事あげて大丈夫かな・・・と小一時間悩みましたが、「へーきへーき!フレンズによって得意な事違うから!」の精神で頑張ります。
きっと、これでハードルが下がるはず・・・あとは頼みましたよ、承太郎・・・

参考資料

基本的な知識

  • A successful Git branching model:英語 / 日本語翻訳 : Git使うなら必ずと言って良いほど話題に上がるもの

初学者向け情報

もう少し詳しく理解したい人向け

ここで説明しきれなかった操作


追記
2017/12/27 簡易説明用に使う記事をまとめました → Gitについて説明する時に使う資料



  1. コメントでご指摘いただいた表現を使わせていただいております。ありがとうございます!