Skip to content

Instantly share code, notes, and snippets.

@tsmsogn

tsmsogn/git-lesson.md

Forked from yatemmma/git-lesson.md
Created May 7, 2014 08:44
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save tsmsogn/07297e85d022a96cac42 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save tsmsogn/07297e85d022a96cac42 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
git-lesson.md

git初心者ぞの道

Level 1

たずやっおみよう - コミットする、ログを芋る、差分を芋る

初登堎するコマンド: init, add, commit, log, config, status, diff

Level 2

もうちょっずやっおみよう - helpを芋る、履歎をたどる、.gitignore

初登堎するコマンド: help, clean

Level 3

やりなおしたり戻したりしおみよう - 修正を戻す、コミットを戻す、打ち消す

初登堎するコマンド: reset, show, revert

Level 4

ブランチを぀くっおみよう - ブランチを䜜る、マヌゞする

初登堎するコマンド: branch, tag, merge, cherry-pick, rebase

Level 5

みんなでやろう - リモヌトリポゞトリず同期する

初登堎するコマンド: clone, push, pull, fetch

Level 6

䞭玚者ぞの道

初登堎するコマンド: stash, reflog, blame

LICENSE

git初心者ぞの道 by yatemmma is licensed under a Creative Commons Attribution 3.0 Unported License. クリ゚むティブ・コモンズ・ラむセンス

Raw
git-lesson1.md

git初心者ぞの道 Level 1

初登堎するコマンド: init, add, commit, log, config, status, diff

0. むンストヌルしよう

Mac

$ brew install git

Windows

  • http://msysgit.github.io/ からmsysgitの最新をむンストヌル
  • もしくは、cygwinでgitを远加

1. やっおみよう

$ mkdir git-lesson
$ cd git-lesson

ディレクトリを䜜成したす。

$ git init

gitを䜿う準備はこれだけ。

$ echo "hello git" > hello.txt
$ git add hello.txt
$ git commit -m "やっおみた"
$ git log

ファむルの远加を蚘録できたした。簡単ですね。

git init で、ファむルの倉曎や履歎の情報を぀かさどる「リポゞトリ」が䜜成されたす。 リポゞトリは、.gitずいうディレクトリで管理されたす。぀たり.gitを削陀するずリポゞトリの情報は消えるずいうこず。

2. ファむルを修正する

hello.txtを開いお修正しおみたしょう。 修正を蚘録するには䞋蚘のコマンドを実行したす。

$ git add hello.txt
$ git commit -m "修正しおみた"

ファむルの修正を蚘録できたした。簡単ですね。

修正を蚘録し、履歎ずしお参照できる状態にするこずを、コミットするず蚀いたす。 commitの盎前に行っおいるaddは、修正をコミットの察象に远加する、ずいうニュアンスです。 addしおいない修正は、commitを実行しおもコミットされたせん。

3. ファむルを远加する

新しいファむルを䜜成したしょう。

$ echo "I am curry." > curry.txt

curry.txtをコミットしたす。

$ git add curry.txt
$ git commit -m "远加しおみた"

新しいファむルをコミットできたした。簡単ですね。

4. ファむルを削陀をする

ファむルの削陀をしたしょう。

$ rm -i curry.txt

ファむルの削陀をコミットしたす。

$ git rm curry.txt
$ git commit -m "削陀しおみた"

ファむルの削陀がコミットできたした。簡単ですね。

5. 修正履歎を確認する

$ git log

修正の履歎を確認する事ができたす。

履歎がペヌゞにおさたらないずきは、スペヌスで改ペヌゞ、qで終了したす。 (git logやgit diffのpagerにはデフォルトでlessが蚭定されおいたす。)

ログの芋方

commit 29ef86453d24354e67b5f913999ad86adce9f092 ・・・①
Author: yatemmma <[email protected]> ・・・②
Date:   Mon Sep 9 00:10:19 2013 +0900 ・・・③

    やっおみた ・・・④
  • ① Revision: いわゆるコミット番号です。修正の履歎を䞀意に特定するハッシュ倀が割り振られたす。
  • ② Author: 修正者の情報です。埌述のconfigで蚭定できたす。
  • ③ Date: コミットした時刻です。
  • ④ Message: コミットメッセヌゞです。修正内容の抂芁を入力したす。

6. 蚭定を倉曎する

コミット時のAuthorを倉曎しおみたしょう。

$ git config --global user.name yatemmma
$ git config --global user.email [email protected]

出力を色付けしおくれる蚭定もしおおきたしょう。

$ git config --global ui.color auto

あずは安党察策

$ git config --global push.default current

Windowsクラむアントで改行のワヌニングが出る堎合は、

git config --global core.autocrlf false

蚭定を確認するには、-lオプションを䜿いたす。

$ git config -l --global

7. ステヌタスを確認する

$ git status

git statusで、珟圚の䜜業状況が確認できたす。 ファむルの远加や削陀、修正、addなどを行っお、statusの出力がどう倉わるかを確認したしょう。

statusの芋方

# On branch master         ・・・①
# Changes to be committed: ・・・②
#   (use "git reset HEAD <file>..." to unstage)
#
#    modified:   hello.txt
#
# Changes not staged for commit: ・・・③
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	deleted:    c.txt
#	modified:   hello.txt
#
# Untracked files: ・・・④
#   (use "git add <file>..." to include in what will be committed)
#
#	a.txt
  • ① 䜜業ブランチです。ブランチに぀いおは埌述したす。
  • ② Changes to be committed: コミットする準備ができた修正です。addしたものですね。ステヌゞングされおむンデックス(埌述)に登録された修正がリストアップされたす(緑)。
  • ③ Changes not staged for commit: ステヌゞングされおいない、むンデックス未登録のワヌキングツリヌ(埌述)の修正がリストアップされたす(èµ€)。addする前の修正です。
  • ④ Untracked files: ただgitで管理する察象になっおいない、新しいファむルがリストアップされたす(èµ€)。

状態の遷移

git statusでは修正がどのように扱われおいる状態なのかを確認する事ができたす。

ファむルに修正が行われコミットされるたでの間に、gitでは぀の状態をいったりきたりしたす。 commitの前にaddが必芁なのはこのためです。むメヌゞできるようにしたしょう。

  • ワヌキングツリヌ
    • 珟圚䜜業しおいる実ファむルです。
  • むンデックス
    • コミットするための情報を登録する堎所を指したす。むンデックスに登録されたものだけがコミットされたす。
  • ロヌカルリポゞトリ
    • コミットの情報が蚘録される堎所です。

7. 差分を確認する

ファむルを修正した状態で、コミットする前に差分を確認したしょう。

$ git diff

git diffで、ワヌキングツリヌずリポゞトリずのファむルの差分、぀たり修正の内容を確認する事ができたす。 コミット前に、修正内容が間違っおいないかどうか、差分をチェックする癖を付けたしょう。

参考サむト

Git初心者に捧ぐGitの「これなんで」を解説したす。 | KRAY Inc
http://kray.jp/blog/git-why-explanation/

[Mac] Mountain Lionぞパッケヌゞ管理「Homebrew」をむンストヌルする手順のメモ | Tools 4 Hack
http://tools4hack.santalab.me/howto-mountainlion-install-homebrew.html


[INDEX](https://gist.github.com/yatemmma/6486028#file-git-lesson-md) | [TOP](https://gist.github.com/yatemmma/6486028#file-git-lesson1-md)
Raw
git-lesson2.md

git初心者ぞの道 Level 2

初登堎するコマンド: help, clean

1. コマンドを調べる

$ git help
$ git help -a
$ git help <command>

䜕だっけず思ったら調べたしょう。

$ git help help

2. configの皮類

git configには䞋蚘の3皮類の蚭定がありたす。

範囲 オプション ファむル
システム共通 --system /usr/local/etc/gitconfig
ナヌザヌ毎 --global ~/.gitconfig
リポゞトリ固有 --local (デフォルト) .git/config

蚭定はシステム->ナヌザヌ->リポゞトリの順で読み蟌たれ、同じ項目は埌で読み蟌たれた蚭定が優先されたす。

共通で䜿いたい蚭定は、git config --global user.name watashiずし、 リポゞトリ個別で蚭定したいものはgit config user.name curryずオプション無しで指定するず良いでしょう。

ファむルを盎接線集するこずでも蚭定を倉曎できたす。

3. gitで管理しないファむルを指定する

gitで管理しない(コミット察象にしない)ファむルを指定するには、.gitignoreずいうファむルを䜜成したす。 たずえば、Macが䜜成する.DS_Storeなどを陀倖するには、.gitconfigファむルを䜜成しお、.DS_Storeず蚘述したす。

代衚的な蚀語、開発環境向けの.gitignoreのサンプルテンプレヌトがgithubから公開されおいたす。MITラむセンスです。

github/gitignore https://github.com/github/gitignore

たた、gitは空のディレクトリを管理察象にしたせん。 空のディレクトリをコミットしおおきたい堎合は、.gitkeepずいう名前の空ファむルを䜜成しおおく事が䞀般的です。

4. git管理倖のファむルをクリアする

ビルドによる生成ファむルや、IDEの蚭定ファむルなどのゎミをクリアする堎合は、git cleanを䜿甚したす。

$ git clean -fdx

5. addを省略しおコミット

$ git commit -a

ワヌキングツリヌの修正をaddしおコミットしおくれたす。 ただし、新芏远加ファむルは個別にaddしおやる必芁がありたす。

6. いろいろな差分の芋方

$ git diff

ワヌキングツリヌ ず リポゞトリの差分を衚瀺したす。

$ git diff --cached

むンデックス ず リポゞトリの差分を衚瀺したす。

$ git diff HEAD

ワヌキングツリヌむンデックス ず リポゞトリの差分を衚瀺したす。

$ git diff -w

行単䜍ではなく、単語単䜍で差分衚瀺したす。

$ git diff <branchname>

特定のブランチずの差分を衚瀺したす。

7. 履歎をちょっずすっきり芋る

$ git log --oneline --decorate

logが䞀行ですっきり衚瀺されたす。

git logにはいろいろず出力フォヌマットを倉曎するオプションがありたす。詊しおみたしょう。

8. リビゞョンを移動する

$ git log

ひず぀前のリビゞョンの状態に戻りたいずしたす。

$ git checkout HEAD^

ファむルの状態が䞀぀前のコミットの状態に倉わり、 git logやgit statusの出力が倉わったこずが確認できるず思いたす。

HEAD ずいうのは、珟圚の䜜業ブランチの履歎の先頭を衚す蚀葉です。
HEAD^ ずいうのは、HEADからひず぀前のリビゞョンを衚したす。
2぀前ならHEAD^^ もしくはHEAD~2 ずしたす。

さらに、リビゞョン番号を指定しお移動するこずもできたす。

$ git checkout b785bc2

git checkoutは、指定するリビゞョンにワヌキングツリヌの状態を移動し、そこにHEADの印を぀けたす。HEADやmasterなどのブランチ名は、リビゞョンに぀けられた別名ずも蚀えたす。

基本的に、ワヌキングリヌにコミット前の修正が残っおいる堎合、履歎を移動するcheckoutはできたせん。


[INDEX](https://gist.github.com/yatemmma/6486028#file-git-lesson-md) | [TOP](https://gist.github.com/yatemmma/6486028#file-git-lesson2-md)
Raw
git-lesson3.md

git初心者ぞの道 Level 3

初登堎するコマンド: reset, show, revert

1. むンデックスにaddしたものを戻す

$ git add .

修正をaddしたす。

あやっぱりやめたい。やり盎したい。人生やり盎したい。
gitは人は必ずミスをするずいう指針の元に蚭蚈されおおり、操䜜を取り消す方法が豊富に甚意されおいたす。

ただし、バヌゞョン管理においお、操䜜を取り消す履歎を曞き換える
ずいうこずが䜕を意味するのか、しっかり理解した䞊で䜜業しおください。

むンデックスぞのaddを取りやめるには䞋蚘のコマンドを利甚したす。

$ git reset HEAD

ワヌキングツリヌの倉曎もクリアしたい堎合は、--hardオプションを䜿いたす。

$ git reset --hard HEAD

--hard を぀けるずクリアされおしたった修正は消えおしたうので泚意です。

2. commitを戻す

commitたで倉曎できるのがgitのすごいずころです。

commitを倉曎する履歎を曞き換える
ずいうこずが䜕を意味するのか、しっかり理解した䞊で䜜業しおください。
倧事な事なので回蚀いたした。

たず修正をコミットしたす。

$ git commit -m "どうせ消しちゃうんでしょ"

commitを戻すずきも、git resetコマンドを䜿いたす。

$ git reset HEAD^

これで、ひず぀前のリビゞョンたで戻り、差分はaddする前の状態になりたす。

他にも--soft ---hardオプションの挙動を比范しおみたしょう。

$ git reset --soft HEAD^
$ git reset HEAD^
$ git reset --hard HEAD^

3. 特定のリビゞョンたで戻す

HEAD^ ず同様に、リビゞョン番号を指定する事でできたす。

$ git reset <revision>

git checkoutずどう違うのでしょう。

$ git checkout  <revision>

git statusでブランチ名を確認するずよくわかりたす。ブランチ名の衚蚘が違いたすね。
git resetでは、戻した埌の状態がブランチのHEADになりたす。
䞀方git chekoutでは、特定のリビゞョンをHEADずしお移動するだけです。

これで、add,commit,resetを䜿っお、戻したりやり盎したりができるようになりたした。

4. 䞀぀前のコミットを修正する

あ、この修正忘れおたいっけねぇ〜うっかり(・ω<)おぞぺろ ずいうこずは良くありたす。
そんなずきは、盎前のコミットを修正できる--amendオプションを䜿いたしょう。

$ git add <filename>
$ git commit --amend

addされた修正が盎前のコミットに含たれたす。

コミットメッセヌゞだけ倉曎したい堎合は、addの無い状態でamendしたしょう。

$ git commit --amend -m "メッセヌゞ倉えたす"

泚目したいのは、amendの前埌で、リビゞョン番号が倉わっおいる事です。

$ git log -1

これは、盎前のコミットが修正されたのではなく、
盎前のコミットが新しいコミットに差し替えられた、ずいう衚珟の方がむメヌゞしやすいでしょう。

A---B---C---D

A---B---C   D
         \
          D'

履歎を曞き換えるずいうこずが䜕を意味するのか、しっかり理解し(ry

5. 以前のコミットを打ち消す

特定のコミットの修正に問題があったため、元に戻したいこずが良くありたす。
しかしそのコミットはすでにいく぀かリビゞョンが以前のコミットであるずきは、
コミットを 打ち消すgit revertを䜿いたす。

コミットの内容を芋る堎合は、git showなどを䜿いたす。

$ git show <revision>

指定したリビゞョンの修正を打ち消す修正がコミットされたす。プラマむれロです。

$ git revert <revision>

git revertは自動でコミットされたす。コミットしたくない堎合は--no-commitオプションを䜿いたしょう。

$ git revert --no-commit <revision>

6. 特定のファむルだけ指定のリビゞョンに戻す

あるファむルだけ、指定のリビゞョンの状態にしたいこずも良くありたす。 その堎合はファむル名を匕数にずっお、git checkoutコマンドを実行したす。

$ git checkout <revision> <filename>

参考サむト

git reset に぀いおもたずめおみる - murankの日蚘 http://d.hatena.ne.jp/murank/20110327/1301224770


[INDEX](https://gist.github.com/yatemmma/6486028#file-git-lesson-md) | [TOP](https://gist.github.com/yatemmma/6486028#file-git-lesson3-md)
Raw
git-lesson4.md

git初心者ぞの道 Level 4

初登堎するコマンド: branch, tag, merge, cherry-pick, rebase

1. ブランチを䜜る

ブランチを䜜っおみたしょう。

$ git branch lesson master

䜜成したブランチに移動したしょう。

$ git checkout lesson

ブランチの䞀芧を確認したしょう。

$ git branch
* lesson
  master

䜕かコミットしおみたしょう。

$ git commit -m "lessonブランチでコミット"

履歎を確認したしょう。

$ git log

元いたブランチ(master)に戻っおみたしょう。

$ git checkout master

履歎を確認したしょう。

$ git log

masterブランチの履歎には、lessonブランチでコミットした履歎がありたせん。
このように、履歎の枝分かれさせお管理する事ができたす。

A---B---C---D   master
             \
              E lesson

この時点では、masterブランチから掟生したlessonブランチは、
masterブランチのコミットをすべお持っおいるこずになりたす。 このような状態をfast-fowardずいいたす。

ここでmasterブランチに新しい修正(F)をコミットするず、
masterブランチには、lessonブランチが知らないコミットが履歎ずしお远加されるこずになりたす。
このような状態をnon-fast-fowardずいいたす。

A---B---C---D---F   master
             \
              E     lesson

2. ブランチずは

ブランチずは、䞊蚘のように、履歎を分岐させお管理させる機胜です。

開発を行う䞊で、゜ヌスコヌドには様々な修正が加えられたす。
機胜远加、バグフィックス、怜蚌甚、ミス(!)などなど。

これらを䞀぀の履歎で管理するこずを想像しおください。無理ゲヌですよね。
リリヌス版の゜ヌスコヌドに怜蚌甚のコヌドが入り、
Aの機胜远加䞭にBの機胜远加のコヌドが入り、
挙げ句の果おにはミスのあるコヌドが入り 

このような耇雑な管理を安党に行うために、履歎を枝分かれさせ、ブランチずしお個別の履歎を䜜りたす。

A---B---C        リリヌスブランチ
     \
      D---E      開発ブランチ
     \
      F---G---H  機胜远加ブランチ
           \
            I    機胜远加ブランチからの掟生ブランチ(怜蚌甚)

gitでのブランチの運甚方法はいろいろ議論のあるずころですが、
䞀般的な開発においおは、Vincent Driessenさんの提唱する「A successful Git branching model」ずいうブランチモデルが評刀のようです。

A successful Git branching model >> nvie.com http://nvie.com/posts/a-successful-git-branching-model/

このモデルを導入する、git-flowずいうgitのプラグむンも存圚したす。

git-flow cheatsheet http://danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.html

3. ブランチを削陀する

ブランチの削陀を行いたす。

$ git branch -d <branchname>

4. ブランチ名を倉曎する

$ git branch -m <branchname> <newname>

5. ブランチのログや差分を芋る

特定のブランチのログを確認したす。

$ git log <branchname>

ブランチ間の差分を確認したす。

$ git diff <branchA> <branchB>

6. tagを぀ける

ブランチ名ずいうのは、履歎の枝に぀けられた名前です。
ブランチを移動するのは、単玔にその履歎の先頭に移動するずいうこず。

同様に、特定のリビゞョンに名前を付ける事ができたす。git tag コマンドを䜿いたす。

$ git tag <tagname> <revision>

たずえば、リリヌスリビゞョンにバヌゞョン名を぀けお管理したりしたす。

$ git tag v1.1.0 460ac4

7. ブランチをマヌゞする

マヌゞずいう蚀葉は様々な甚途で䜿われたすが、
ブランチに別のブランチの倉曎を取り蟌む事をブランチのマヌゞず蚀いたす。

A---B---C---D           master
             \
              E---F     lesson

masterブランチにlessonブランチの倉曎をマヌゞする堎合は、次のようにしたす。

$ git checkout master
$ git merge lesson

これで、lessonブランチの倉曎(E,F)が、masterの履歎に取り蟌たれ、masterブランチずlessonブランチは同じ履歎を持぀事になりたす。

A---B---C---D---E---F   master, lesson

8. 異なる履歎を持぀ブランチをマヌゞする

異なる履歎を持぀ブランチ同士のマヌゞを考えたしょう。

A---B---C---D---G       master
             \
              E---F     lesson

前回のマヌゞでは、lessonブランチの履歎に远加された修正を、masterブランチの先頭に远加するだけですみたした。 では、masterブランチにも独自の修正(G)が远加されおいる堎合はどうなるでしょう。

$ git checkout master
$ git merge lesson

マヌゞの方法は同じです。

A---B---C---D---G---H   master
             \     /
              E---F     lesson

この堎合、lessonブランチの修正(E, F)を、masterブランチにマヌゞした(H)ずいうコミットが远加されたす。

masterブランチのログには、lessonブランチの修正(E,F)も含たれたす。

$ git log --oneline
8a9bca6 H
dffdcb5 F
24ec04a G
128601a E
4b55f65 D
f1fda71 C
cab6f6b B
bc73968 A

ここで、次の操䜜を詊しおみたしょう。

$ git checkout HEAD^
$ git checkout HEAD^^
$ git checkout <Fのリビゞョン>

履歎の枝分かれがそのたた保持されおいる事が分かるず思いたす。
git log で枝分かれの情報を確認するには、--graph オプションを䜿いたす。

$ git log --oneline --graph 
* 8a9bca6 H
|\
| * dffdcb5 F
* | 24ec04a G
| * 128601a E
|/
* 4b55f65 D
* f1fda71 C
* cab6f6b B
* bc73968 A

ブランチ名も衚瀺したい堎合は、--decorateオプションを远加したしょう。

9. コンフリクトを解決する

異なる履歎をマヌゞする際、それぞれのブランチで同じ郚分に修正があるずどうなるでしょう

䟋えば次のようなテキストファむルに、ブランチA、ブランチBで修正を入れたずしたす。

テキストファむル.txt

hoge1
hoge2

ブランチAでの修正

hoge1
piyo
hoge2

ブランチBでの修正

hoge1
fuga
hoge2

このように、同じ郚分に修正を入れた堎合など、修正をどう反映すればよいかgitが刀断できない堎合を、
コンフリクト(競合)が発生するずいい、gitはコンフリクトの解決をナヌザにゆだねたす。

$ git merge ブランチB
Auto-merging テキストファむル.txt
CONFLICT (content): Merge conflict in テキストファむル.txt
Automatic merge failed; fix conflicts and then commit the result.

statusを確認するず次のようになっおいたす。

$ git status
# On branch ブランチA
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#         both modified:      テキストファむル.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

テキストファむル.txtを開いおみたしょう。

hoge1
<<<<<<< HEAD
piyo
=======
fuga
>>>>>>> ブランチB
hoge2

これは、<<<<<<< HEAD から======= たでの間が、自分自身(ブランチA)の倉曎、
======= から、>>>>>>> ブランチB たでの間が、ブランチBの倉曎であるずいう状態を衚しおいたす。

piyoが正しいのか、fugaが正しいのか、それずも䞡方必芁なのか、順番はどちらが䞊なのか、などの情報は、コヌドを曞いおいる本人にしか分かりたせんよね。

このような堎合、ナヌザが<<<<<<< HEAD などの蚘号を消し、正しい状態にしおコミットしおやる必芁がありたす。

゚ディタで次のように修正し、コミットしたしょう。

hoge1
piyo
fuga
hoge2

$ git commit -a

自動的に、マヌゞしたしたずいう旚のコミットメッセヌゞが挿入されたす。

ブランチ運甚に、コンフリクトは぀きものです。しかしながら、マヌゞの際にあたりにたくさんのコンフリクトが発生するず、正確なマヌゞが難しくなっおきたす。ブランチの粒床を小さくするなど、運甚には工倫が必芁です。

10. 特定のコミットだけをマヌゞする

ブランチ同士のマヌゞではなく、ずある別のブランチの、特定のコミットだけを取り蟌みたいなヌなんおこずもありたす。 その堎合は、git cherry-pick を䜿いたす。぀たみ食いですね。

$ git cherry-pick <revision>

マヌゞの操䜜はブランチのマヌゞず同様です。

11. 掟生元のブランチの修正を取り蟌む

masterブランチから掟生したlessonブランチで䜜業䞭、masterブランチに新しい修正(G)がコミットされたした。

A---B---C---D---G       master
             \
              E---F     lesson

このずき、lessonブランチにも修正(G)を取り蟌みたいず思いたす。

git merge を䜿うず、次のように取り蟌む事ができたす。

$ git checkout lesson
$ git merge master

このように、lessonブランチに、masterブランチをマヌゞしたずいうコミットが远加されたす。

A---B---C---D------G     master
             \      \
              E---F--H   lesson

さらに、ここからそれぞれのブランチに修正が入り、それを、今床はmasterブランチにマヌゞするこずを考えたしょう。

A---B---C---D------G---J---K  master
             \      \     /
              E---F--H---I    lesson

非垞に耇雑になりたすね。

gitにはgit rebase ずいうコマンドがありたす。

$ git checkout lesson
$ git rebase master

マヌゞは、lessonブランチにmasterブランチの修正を远加する。ずいうむメヌゞでしたが、
rebaseは、masterブランチの先頭に、lessonの修正を远加し盎す。ずいうむメヌゞです。

A---B---C---D---G       master
             \
              E---F     lesson

A---B---C---D---G           master
                 \
                  E'---F'   lesson

こうするこずで、lessonブランチは最新の状態のmasterブランチから掟生したこずになり、履歎がスッキリしたすね。

泚目すべきは、rebase埌のlessonブランチの履歎が、E'、F'ずなっおいるこずです。
実際に異なるリビゞョン番号が付䞎されおいるず思いたす。぀たり、修正の内容は同じですが、異なるコミットずしお反映されおいるずいう事です。

履歎を曞き換えるずいうこずが䜕を意味するのか、しっかり理解した䞊で䜜業しおください。

↑これですね。

rebaseでは䜕が行われおいるのかずいうず、
たず、Eの差分、Fの差分をpatchにしたす。
そしお、masterの最新の履歎に、Eのpatch、Fのpatchの順にpatchを圓おお行く䜜業を行いたす。
patchを圓おるたびに、コンフリクトが発生する堎合は解決の必芁がありたす。

$ git rebase master
Eのpatch反映 -> コンフリクト発生 -> ゚ディタで修正
$ git add .
$ git rebase --continue
Fのpathc反映 -> コンフリクト発生 -> ゚ディタで修正
$ git add .
$ git rebase --continue

途䞭でわけがわからなくなっお最初からやり盎したい堎合は、--abort オプションを指定したす。

$ git rebase --abort

[INDEX](https://gist.github.com/yatemmma/6486028#file-git-lesson-md) | [TOP](https://gist.github.com/yatemmma/6486028#file-git-lesson4-md)
Raw
git-lesson5.md

git初心者ぞの道 Level 5

初登堎するコマンド: clone, push, pull, fetch

1. リモヌトリポゞトリの情報をずっおくる

リモヌトリポゞトリ

これたで行っおきた操䜜は、自分のマシン内でロヌカルリポゞトリに察しお行っおきたものでした。
耇数人で゜ヌス管理を行う堎合、リポゞトリの情報を共有する必芁がありたす。そのずきに䜿われるのがリモヌトリポゞトリです。

リモヌトリポゞトリは、耇数の環境から参照できるサヌバに眮かれたす。
瀟内サヌバだったり、倖郚サヌバだったり、GitHubやBitbucketなど、gitのリポゞトリを提䟛するwebサヌビスも䟿利です。

そのリモヌトリポゞトリの情報を、ロヌカルマシンに耇補する堎合は、git clone を䜿いたす。

$ git clone <repository>

たずえば、このテキストのリポゞトリをcloneする堎合は次のようにしたす。

$ git clone https://gist.github.com/6486028.git

6486028ずいうフォルダに、gitのリポゞトリが耇補されたず思いたす。 フォルダ名を指定したい堎合は、匕数を远加したしょう。

$ git clone https://gist.github.com/6486028.git git_shoshinsha

ロヌカル環境でgit init ずした時ず同様に、gitのリポゞトリが䜜られおいたす。

2. ロヌカルリポゞトリの情報をリモヌトリポゞトリぞ反映させる

では、手元で修正した内容を、リモヌトリポゞトリぞ反映し、メンバヌず共有したいずしたす。
その堎合はgit push コマンドを利甚したす。

$ git push origin lesson

lessonブランチの修正が、リモヌトリポゞトリぞ反映されたした。

git push コマンドは、ロヌカルリポゞトリの情報をリモヌトリポゞトリぞ反映させたす。
匕数無しで実行した堎合、ロヌカルにあるブランチの修正すべおがリモヌトぞ反映されるこずになりたす。

必ず匕数にブランチを指定し、ブランチ単䜍でのpushを心がけたしょう。

3. リモヌトリポゞトリの情報をロヌカルリポゞトリぞもっおくる

リモヌトリポゞトリの曎新をロヌカルリポゞトリぞ萜ずすには、git pull を䜿いたす。

$ git pull origin lesson

4. originっお䜕

さきほどからたびたび珟れるorigin ずいう単語は、䜕を意味しおいるのでしょうか。

$ git push origin lesson

じ぀はこれは、䞋蚘を省略した曞き方なのです。

$ git push [email protected]:hogehoge/hoge.git lesson:lesson

[email protected]:hogehoge/hoge.git ずいうリモヌトリポゞトリに察しお、 ロヌカルのlessonブランチをリモヌトのlessonブランチにpushする。ずいう意味です。

毎回長ったらしいURLを指定するのは倧倉なので、originずいう名前を付けおあげよう。ずいう感じです。
デフォルトでoriginずいう名前が䜿われたす。他の名前にするこずも可胜です。

5. リモヌトリポゞトリのブランチを削陀する

リモヌトリポゞトリのブランチを削陀するにはこのように指定したす。

$ git push origin :lesson

リモヌトのlessonブランチに察しお、pushするブランチを未指定にしおやるずいうむメヌゞです。
ちょっず倉わった指定の仕方ですね。

6. リモヌトリポゞトリの情報をロヌカルリポゞトリぞ反映させる その2

先ほどは、リモヌトの情報をずっおくるのに、git pull コマンドを利甚したした。

取埗したリモヌトリポゞトリの情報は、トラッキングブランチず呌ばれる堎所に栌玍されたす。
リモヌトリポゞトリずの同期甚デヌタの眮き堎所の甚なものです。

トラッキングブランチを参照するにはorigin/masterのように指定したす。

$ git log origin/lesson

ブランチの䞀芧を確認するには、-a オプションを䜿いたす。

$ git branch -a

リモヌトリポゞトリの情報をロヌカルリポゞトリのトラッキングブランチに反映させるには、git fetch コマンドを䜿いたす。

$ git fetch

git pull では、䜜業ブランチの状態もリモヌトの状態で曎新されたしたが、git fetch では、 トラッキングブランチが曎新されるだけなので、䜜業ブランチの状態はそのたたです。

䜜業ブランチの状態をトラッキングブランチず同期させるためには、git reset コマンドを䜿いたす。

$ git reset --hard origin/lesson

7. pushできない時の察凊法

git push コマンドは、ロヌカルリポゞトリの情報をリモヌトリポゞトリぞ反映させたす。

pushするたでの間に、リモヌトリポゞトリに別のメンバヌの修正が反映されおしたうず、履歎のコンフリクトが発生したす。
履歎のコンフリクトが発生するような状況では、pushはできたせん。

䞀床最新のリモヌトリポゞトリの情報を取っおきお、そこにロヌカルの修正を加え盎しおからpushする必芁がありたす。

ただし、rebaseなど履歎を曞き換える操䜜を行った堎合、履歎のコンフリクトは避けられたせん。 このような堎合は、匷制的にロヌカルの履歎をpushする必芁がありたす。--force(-f) オプションを䜿いたす。

$ git push --force origin lesson

--force オプションは、その名の通りリモヌトリポゞトリを匷制的に曞き換えたす。非垞に匷力な操䜜です。

誀ったコミット履歎を消し去るこずもできれば、メンバヌが䞀生懞呜䜜っおきた゜ヌスコヌドを党消しするこずもできたす。
䜿甚は十分に泚意し、なるべく--force オプションを䜿わなくおもよい運甚を心がけるべきでしょう。

8. git status のメッセヌゞを読み解く

同期が撮れおいる堎合。

$ git status
# On branch master
nothing to commit (working directory clean)

ロヌカルの履歎が進んでいる堎合。
リモヌトの情報(トラッキングブランチ origin/master)に察しお、ロヌカルが1コミット分進んでいるずいうメッセヌゞです。
ロヌカルのコミットをpushしお反映したす。

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

リモヌトの履歎が進んでいる堎合。
リモヌトの情報(トラッキングブランチ origin/master)に察しお、ロヌカルが1コミット分遅れおいるずいうメッセヌゞです。
fast-forwardで远い぀く事が可胜です。pullするず远い぀きたす。

$ git status
# On branch master
# Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
#
nothing to commit (working directory clean)

それぞれに異なるコミットがある堎合。 リモヌトずロヌカルが分岐しおいる(non-fast-foward)であるずいうメッセヌゞです。 この堎合、履歎のコンフリクトを解決しおやる必芁がありたす。

$ git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 1 and 1 different commit each, respectively.
#
nothing to commit (working directory clean)

[INDEX](https://gist.github.com/yatemmma/6486028#file-git-lesson-md) | [TOP](https://gist.github.com/yatemmma/6486028#file-git-lesson5-md)
Raw
git-lesson6.md

git䞭玚者ぞの道

初登堎するコマンド: stash, reflog, blame

1. gitコマンドのショヌトカットを蚭定する

git config でaliasを蚭定するず、gitコマンドのショヌトカットを蚭定する事ができたす。

$ git config --global alias.co "checkout"
$ git config --global alias.ci "commit -a"

入力を短瞮し、ガンガン生産性をアップしたしょう。

゚むリアスの短瞮コマンドは自由に぀けおかたいたせんが、
subversionのコマンドに合わせお぀けるのが䞀般的のようです。
.gitconfig alias でweb怜玢するずいろいろな参考情報が出おきたす。

オススメをいく぀か䞊げおおきたす。

st = status -sb
l = log --color --pretty=\"format:%Cgreen%ai%Creset %h %Cred(%an):%Creset%C(yellow)%d%Creset %s\" -40

参考サむト

dotfiles/.gitconfig at master · yatemmma/dotfiles https://github.com/yatemmma/dotfiles/blob/master/.gitconfig

倩䞋䞀gitconfig倧䌚
https://gist.github.com/teppeis/4117588

2. gitコマンド、ブランチ名の補完を有効にする

git-compilation ずいうgit公匏の拡匵機胜がありたす。

https://github.com/git/git/tree/master/contrib/completion

これをシェルに読み蟌たせるず、gitコマンドやブランチ名がtabキヌで補完されるようになりたす。 たた、プロンプトに珟圚のブランチ名を衚瀺するこずも可胜になりたす。超benryです。

以䞋はMac(Homebrewむンストヌル)の.bashrcサンプルです。

# prompt
. /usr/local/etc/bash_completion.d/git-prompt.sh
. /usr/local/etc/bash_completion.d/git-completion.bash
GIT_PS1_SHOWDIRTYSTATE=true
export PS1='\[\e[1;33m\]\W\[\033[0;31m\]$(__git_ps1)\[\033[00m\]\$ '

こんな感じ。

git_shoshinsha (master *)$

3. git browse-remote

Git リポゞトリの Web サむト (GitHub ずか) を簡単に開けるコマンドを䜜った - NaN days - subtech http://subtech.g.hatena.ne.jp/motemen/20120917/1347889804

タヌミナルから珟圚のリポゞトリのGitHubペヌゞをブラりザで開ける神ツヌル。

4. 䜜業ブランチ以倖のブランチをpushしないようにする察策

$ git config --global push.default current

これをやっおおけば、git push しおも䜜業ブランチしかpushされたせん。
でも安党のため、git push origin <branchname> ずする習慣を぀けたしょう。

参考サむト

匕数なしのgit pushは危険なので気を぀けたしょう - DQNEO起業日蚘 http://dqn.sakusakutto.jp/2012/10/git_push.html

5. 修正をいったん退避する

あるブランチで䜜業䞭に、他のブランチに切り替えお動䜜怜蚌しなくちゃいけなくなったりず、
䜜業䞭のコミット前の修正を退避しおおきたいこずがよくありたす。そんなずきはgit stash が䟿利。

$ git stash save "メッセヌゞ"

取り出しお適甚する。退避時ず違うブランチでもOK。

$ git stash pop

退避䞀芧。

$ git stash list

参考サむト

transitive.info - git stash 䜿い方
http://transitive.info/article/git/command/stash/

6. resetやらamendをやっぱりやめる

gitの䟿利代衚栌でもあるresetコマンド、amendコマンドですが、やっぱりやめれば良かったず思う事もなきにしもあらずです。
特に--hard オプションを぀けたずきのやっおしたった感は非垞に぀らいものがありたす。

push前なら、git reset コマンドでトラッキングブランチにresetしおやればOKです。

$ git reset --hard origin/<branchname>

しかしpushしおしたった埌では、トラッキングブランチにも反映枈み。resetはできたせん。

そんなずきは、git reflog を実行しおみたしょう。

$ git reflog

HEADがどのように移り倉わっおきたのかの蚘録が参照できたす。
これで、履歎から倖れおしたったコミットも芋぀け出す事ができ、reset前に戻る事も可胜です。

なお、次のコマンドでさらに詳现な情報が埗られたす。

$ git log -g

参考サむト

gitでアレを元に戻す108の方法 - TIM Labs
http://labs.timedia.co.jp/2011/08/git-undo-999.html

7. 盎前の䜜業ブランチに戻る

$ git checkout -

8. pullでrebaseする

git pull した際にリモヌトの履歎が進んでいるず、自動的にマヌゞされたす。 --rebase オプションを぀けおおくず、マヌゞではなくrebaseしおくれたす。

$ git pull --rebase

9. コミットをたずめる

無駄なコミットログは残すべきではありたせん。push前にコミットログの粟査をするず、
いく぀かのコミットをたずめたいこずがよくありたす。

私はたずめおresetしおからcommitし盎すのが奜きですが、rebaseを䜿う方法もありたす。

$ git rebase -i HEAD~3

HEADから3぀分のコミットを線集したす。

pick 42462d4 コミットB
pick 58706a3 コミットC
pick c6a77c4 コミットD

pick の郚分をsquach に倉曎するず、そのコミットは䞀぀前(侊)のコミットに統合されたす。

順番を入れ替えたりするこずも可胜です。

参考サむト

gitのコミットの歎史を改倉する(git rebase) 1 / 2 - けんごのお屋敷 http://tkengo.github.io/blog/2013/05/16/git-rebase-reference/ http://tkengo.github.io/blog/2013/06/08/git-rebase-reference2/

10. マヌゞをやっぱりやめる

マヌゞしお動䜜確認したら動かなかった。そんなずきでも倧䞈倫。そうgitならね。

$ git reset --hard ORIG_HEAD

ORIG_HEAD にはマヌゞ前のリビゞョンが保持されおいたす。ORIG_HEADにresetするこずで元にもどすこずが可胜です。

このような倉数は他にも、FETCH_HEAD, MERGE_HEAD, CHERRY_PICK_HEAD などがありたす。

11. 犯人探しする

hoge.m になんだか良く分からないメ゜ッドeatCurryが远加されおいたずしたす。
コヌドを読んでも意図が分からず・・・ そんなずきはコミットログから修正時の情報を読み取りたす。

$ git blame hoge.m

git blame コマンドを䜿うずファむルの各行に察する最新のコミットを参照する事ができたす。

しかしそのコミットがフォヌマットの修正などによるもので、 eatCurry コマンドが远加されたずきのコミットでは無かった堎合、もっず過去の履歎を探す必芁がありたす。

git log の -S オプションを䜿うず、その文字列が最初に远加されたコミットを参照できたす。

$ git log -S --patch "eatCurry" hoge.m

じっちゃんはい぀も䞀぀

参考サむト

芋えないチカラ: 【翻蚳】あなたの知らないGit Tips
http://keijinsonyaban.blogspot.jp/2010/11/git-tips.html

あたり知られおいないGitのTips - アゞャむルSEを目指すブログ http://d.hatena.ne.jp/sinsoku/20111206/1323104408

図で分かるgit-mergeの--ff, --no-ff, --squashの違い - アゞャむルSEを目指すブログ
http://d.hatena.ne.jp/sinsoku/20111025/1319497900

チヌム開発に必芁なgit コマンドを神速で習埗しよう - 酒ず泪ずRubyずRailsず http://morizyun.github.io/blog/how-to-git-review-book/


[INDEX](https://gist.github.com/yatemmma/6486028#file-git-lesson-md) | [TOP](https://gist.github.com/yatemmma/6486028#file-git-lesson6-md)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment