Help us understand the problem. What is going on with this article?

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

More than 1 year has passed since last update.

はじめに

どうも、「サルでも分かる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. コメントでご指摘いただいた表現を使わせていただいております。ありがとうございます! 

nh321
せやかて工藤、このアカウントが発信するんは全て個人的な意見で、現在所属する会社の公式見解では無い、ゆーとるやろが。
tis
創業40年超のSIerです。
https://www.tis.co.jp/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした