上野家のホームページ - 資料室バックアップ : 開発/バージョン管理システム/git/Gitの使い方のソース

[ 差分 | バックアップ | リロード ]
差分を表示
開発/バージョン管理システム/git/Gitの使い方へ行く。
* Gitの使い方 [#h058b63f]
Gitの基本的な使い方についての説明です。~

* 作業領域をgitで管理対象にする [#ifb5a1e6]
プログラムを作成する場所などを新規ディレクトリとして作成して，そのディレクトリを作業場所とします。~

作業場所をGitで管理するために，このディレクトリにローカルリポジトリを作成します。~

[[リモートリポジトリをコピー（clone）>../共有リポジトリの作成と運用#bd4804e3]]して作成する方法もあります。((リモートリポジトリには，すべてのリビジョンのファイルが入っている。))~

** 作業場所に新しいリポジトリを作成する [#ae964c9f]
hogehoheディレクトリ（任意の好きなディレクトリ）以下をgitで管理することにします。~
 > md hogehoge
 > cd hogehoge
 > git init

このようにするとhogehogeディレクトリに''.git''というディレクトリが新たに作られ，この.gitディレクトリがローカルリポジトリ((個人用のリポジトリ))になります。~

新規作成したディレクトリで，プログラムを作成したり文書を作成したりする作業を行うことになります。~

このローカルリポジトリを作成した直後だと，hogehogeにあるファイルはまだバージョン管理されていない状態になっている。~

''git status''コマンドでそれが確認できます。トラックしていないファイルって表示される。~
 > git status
 On branch master
 
 Initial commit
 
 nothing to commit (create/copy files and use "git add" to track)

試しにプログラムとかテキストファイルとかを作成してみます。~
その後，以下のコマンドを実行する。~
 > git add .

これで作成したファイルがGitで管理されるようになります。（トラックとかインデックスに入れると言っている。）~

''add''コマンドはいろいろな意味があって，新しいファイルのトラック開始・ファイル衝突時のマージなどのマーク付けなんかで使用しているみたい。~

Gitの場合はSubversionと異なり，''ステージング状態（インデックスに入れた後）が存在するのが特徴となる。''~
作業ディレクトリ上で何かファイルの編集を行ったら，編集したファイルをステージング状態にした後，ローカルレポジトリへコミットするという手順になる。~

''add''コマンドでファイルをステージング状態（インデックス）に入れたら，''commit''コマンドの''-m''オプションを使ってコメントメッセージを追加してコミットを行います。~

この時，''コミットされるのはaddコマンドを実行したファイルに対してのみ''になるのに注意。~
 > git commit -m "最初のコミット"

コミットすると，前回コミットした時の状態から現在の状態までの差分を記録したコミット（またはリビジョン）と呼ばれるものが作成される。~
コミットの実行時には，コミットメッセージの入力が必ず必要です。空のままで実行するとコミットが失敗します。~
#ref(commit.png,,70%)

実際には，いちいち''add''コマンドした後，さらに''commit''コマンドを使うのはちょっと面倒だなって思うこともあります。そんな時には，~
 > git commit -a -m "次のコミット"

と''commit''コマンドに''-aオプション付き''でコミットすると，add処理とcommit処理をやってくれます。~

コミットした場合，ファイルの内容から''重複のない英数字40桁の名前''が計算され，それをリビジョンとしてGit上で管理されるようになる。~
この名前を指定することで，''リポジトリの中から必要なコミット（リビジョン）を指定することが出来るようになっている。''

よくやるのは，コミットした後，早まったというか，変更するファイルがまだあった場合は，~
 > git commit -m '最初のコミット'
 > git add 忘れてたファイル
 > git commit --amend

とかすると，忘れてたファイルを''commit''コマンドで再度コミットする時，''--amend''オプションを使うって上書きのような状態にすることが出来ます。~

''add''コマンドでステージング状態（インデックスに入れた状態）にしたものを，コミットせずに全部それを取り消す場合は，~
 > git reset

とすれば，登録した内容を全て取り消すことが出来ます。作業ディレクトリにあるファイルには一切変更等の影響は無いです。~

* 普段の作業の流れ [#hddb2a26]
gitを使った作業の流れは，下記のような感じになリます。~
+ ファイルを編集，新規作成。~
+ git statusで変更状況を確認。~
+ git diffで変更箇所を確認。~
+ 編集作業が終わったらgit add ファイル名，またはgit add -uで変更ファイルを記録する指定をする。~
+ git commitでリポジトリに変更を登録。~
git commit -a "説明・・・"

変更したものがない場合は，''status''コマンドを使うと以下のような出力が返ってくる。~
 > git status
 # On branch master
 nothing to commit (working directory clean)

* ブランチ [#ea22f5c2]
ソフトウェアの開発なんかだと，一つのソフトウェアに対して複数のメンバーが同時に機能追加を行ったり，バグ修正を行ったりといったことがあります。~

また，複数のリリースバージョンが存在する状態で，それぞれを保守しなければならないといったこともあります。~

このような並行して行われる複数の機能追加やバージョン管理を支援するため，Gitにはブランチという機能がある。~

ブランチは分岐したりする履歴の流れを記録していくために使われる。~
分岐したブランチは他のブランチの影響を受けないようになるので，同じリポジトリ中で複数の変更を同時に管理できるようになる。~

分岐したブランチは他のブランチとマージすることで，一つのブランチにまとめ直すことも出来る。~

チームのメンバーでは他のメンバーの作業の影響を受けないように，メインのブランチから自分の作業専用のブランチを作成して作業していく。~
そして，作業が終わったら自分のブランチの変更をメインのブランチにまとめていく。~
このようにすると，他のメンバーの作業による影響を受けることなく，自分の作業に取り込むことができる。~

また，作業単位で履歴を残すことで，問題が発生した場合に原因となる変更箇所の調査や対策を行うことが容易になる。~
//#ref(ブランチ2.png)

** masterブランチ [#k4067461]
リポジトリに最初のコミットを行うと，Gitは''master''という名前のブランチを自動的に作成します。~

そのため，以後のコミットはブランチを切り替えるまで''master''ブランチに追加されていくことになる。~

** ブランチの運用 [#occ350d8]
Gitは，''branch''コマンドを使って，自由にブランチを作成することができる。~

しかし，ブランチを効果的に利用する場合には運用ルールを設けておいたほうが良い。~

よく使われる運用ルールで，''統合ブランチ''と''トピックブランチ''という2種類のブランチを使うほうほうがある。~
-''統合ブランチ''~
統合ブランチは，リリース版が何時でも作成可能なようしておくためのブランチ。~
また，トピックブランチの分岐元としても使用される。~
そのため，''安定した状態を保っておくことが重要''となる。~
何らかの変更を行う場合は，''トピックブランチを作成して作業を行う''ようにします。~
通常は，''master''ブランチが統合ブランチとして使用される。~
-''トピックブランチ''~
トピックブランチは，機能追加やバグ修正といった，ある課題に関する作業を行うために作成するブランチ。~
複数の課題に関する作業を同時に行う時は，その数だけトピックブランチが作成するようにする。~
トピックブランチは安定した統合ブランチから分岐する形で作成し，作業が完了したら統合ブランチに取り込むという使い方にする。~
//#ref(ブランチ3.png,,70%)

** ブランチの切り替え [#cc0dc967]
作業するブランチを切り替えるには，''checkout''コマンドを使う。~

''checkout''コマンドを行うと，まず移動先のブランチ内の最後のコミットの内容がワークディレクトリ（ワークツリー）に展開されます。~
また，''checkout''コマンド後に''commit''コマンドを行うと，移動後のブランチに対してコミットが追加されるようになる。~
#ref(ブランチ4.png,,70%)

-''HEAD''~
HEADは現在使用しているブランチの先頭を表す名前。~
デフォルトでは''master''の先頭を表している。~
HEADが移動することで，使用するブランチが変更される。~
コミットを指定するときに，~（チルダ）と^（キャレット）を使って，あるコミットからの相対位置を指定することが出来るようになっている。~
この時によく使われるのが''HEAD''です。~（チルダ）を後ろに付け加えることで，何世代前の親かを指定することが出来る。~
^（キャレット）はブランチのマージで親が複数ある場合に，何番目の親かを指定することが出来ます。~
#ref(ブランチ5.png,,70%)
-''stash''~
まだコミットしていない変更内容や新しく追加したファイルがワークディレクトリ（ワークツリー）やステージ（インデックス）に残ったままで他のブランチへのチェックアウトを行うと，その変更内容は元のブランチから移動先のブランチに対して移動します。~
ただし，移動先のブランチで同じファイルが既に何らかの変更が行われている場合は，チェックアウトに失敗します。~
このような場合は，変更内容を一度コミットするか，または''stash''コマンドを使って一時的に変更内容を退避させてから''checkout''コマンドを使う必要がある。~
''stash''とは，つまりはファイルの変更内容を一時的に記録しておく領域のこと。~
stashを使うことでワークディレクトリ（ワークツリー）とステージ（インデックス）中でまだコミットされていない変更を，一時的に退避させることが出来る。~
退避させた変更は後から取り出して，元のブランチや別のブランチに反映させることが出来る。~
#ref(ブランチ6.png,,70%)

** ブランチのマージ [#ra46fcc9]
作業が完了したトピックブランチは最終的に統合ブランチに統合（マージ）させる。~

ブランチの統合には，''merge''コマンドを使う方法と''rebase''コマンドを使う方法の2種類があります。~
どちらを使うかで統合後のブランチの履歴が異なってくる。~
- ''merge''~
''merge''コマンドを使用すると，複数の履歴の流れを合流させることが出来ます。~
~例えば，下の図のように''master''ブランチ''から分岐する''bugfix''というブランチがあったとします。~
#ref(ブランチ7.png,,70%)
この''bugfix''ブランチを''master''ブランチにマージする時，''master''ブランチの状態が以前から変更されていなければ，非常に簡単にマージを行うことが出来ます。''bugfix''ブランチの履歴は，''master''ブランチの履歴をすべて含んでいるため，''master''ブランチは単純に移動するだけで，''bugfix''ブランチの内容を取り込むことが出来ます。~
このようなマージを''fast-forward（早送り）マージ''と呼んでいる。~
#ref(ブランチ8.png,,70%)
しかし，''master''ブランチの履歴が''bugfix''ブランチを分岐した時より進んでしまっている場合もあります。この場合は，両方の''master''ブランチでの変更内容と''bugfix''ブランチでの変更内容を一つにまとめる必要があります。~
#ref(ブランチ9.png,,70%)
そのため，両方の変更を取り込んだマージコミットが作成されます。''master''ブランチの先頭は，そのコミットに移動します。~
#ref(ブランチ10.png)
- ''rebase''~
''merge''コマンドの時と同じく，図のように''master''ブランチから分岐する''bugfix''というブランチがあるとします。~
#ref(ブランチ9.png,,70%)
これに，''rebase''コマンドを使ってブランチの統合を行った場合には，次の図のような履歴になります。~
#ref(ブランチ11.png,,70%)
まず，''bugfix''ブランチを''master''ブランチに''rebase''コマンドすると，''bugfix''ブランチの履歴が''master''ブランチの後ろに付け替えられます。~
そのため，図のように履歴は一本化されます。~
~この時，移動するコミットXとYでは競合が発生する場合があります。その時は，それぞれのコミットで発生した競合箇所を修正していく必要があります。~
#ref(ブランチ12.png,,70%)
''rebase''しただけだと''master''の先頭の位置はそのままです。~
そのため，''master''ブランチから''bugfix''ブランチをマージして，''bugfix''の先頭まで移動します。~
#ref(ブランチ13.png,,70%)

''merge''コマンドと''rebase''コマンドは，共に履歴を統合しますが特徴が異なります。~
- ''merge''~
変更内容の履歴はそのまま残るが履歴が複雑になる。~
- ''rebase''~
履歴は単純になるが，元のコミットから変更内容が変更される。~
そのため，元のコミットを動かない状態にしてしまうことがある。~

''merge''コマンドと''rebase''コマンドは運用方針に応じて使い分けます。~
例えば，履歴を一本化するように運用をするのであれば，~
- トピックブランチに統合ブランチの最新のコードを取り込む場合は，''rebase''コマンドを使う~
- 統合ブランチにトピックブランチを取り込む場合は，まず''rebase''コマンドを使ってから''merge''コマンドでマージする。~

というように使い分けます。

** トピックブランチと統合ブランチでの運用例 [#ree14637]
機能の追加を行うトピックブランチで作業を行なっている途中に，バグの修正を行わなければならなくなったとします。~
#ref(ブランチ14.png,,70%)
このような場合でも，統合ブランチは機能追加をはじめる前の状態なので，ここから新たにバグ修正用のトピックブランチをつくることで，機能追加とは独立して作業を始めることが出来ます。~
#ref(ブランチ15.png,,70%)
完成したバグ修正の内容は，元の統合ブランチに取り込むことでリリース出来ます。~
#ref(ブランチ16.png,,70%)
元のブランチに戻って，機能追加の作業の続きを行うことが出来ます。~
#ref(ブランチ17.png,,70%)
しかし，作業の続きを行うには今のバグ修正，コミットXの内容が必要だったことに気づきました。ここで，コミットXの内容を取り込むには直接''merge''する方法と，コミットXを取り込んだ統合ブランチに''rebase''する方法があります。~
~統合ブランチに''rebase''する場合には，~
#ref(ブランチ18.png,,70%)
これで，コミットXの内容を取り込んだ状態で機能追加の続きを進めることが出来ます。~

このように，ブランチを上手く使うことで，異なる作業を並行して進めることが出来ます。~

** ブランチを使ってみる [#s393a8f9]
 > mkdir tutorial
 > cd tutorial
 > git init
 Initialized empty Git repository in D:/home/ueno/tutorial/.git/

tutorialディレクトリに，myfile.txtという名前でファイルを作成します。~
myfile.txtの内容は，~
 Gitのブランチを試してみる。

そして，コミットします。~
 > git add myfile.txt
 > git commit -m "最初のコミット"
 [master (root-commit) 8bd1e74] 最初のコミット
 1 file changed, 1 insertion(+)
 create mode 100644 myfile.txt

この時点での履歴はこのようになります。
#ref(b1.png,,70%)

- ブランチ作成~
ブランチを作成する場合は''branch''コマンドを使用します。
 > git branch <branchname>
例えば，''issu1''という名前でブランチを作成する場合は，~
 > git branch issue1
引数を指定せずに''branch''コマンドを実行すると，ブランチの一覧を表示することができます。~
頭に''*''のついているのが，現在のブランチになります。~
 > git branch
   issu1
 * master
#ref(b2.png,,70%)
 > git checkout issu1
 Switched to branch 'issu1'
この時点での履歴はこのようになります。
#ref(b3.png,,70%)
~
''checkout''コマンドに，''-b''オプションを指定して実行すると，実は，''ブランチの作成とチェックアウトをまとめて行う''ことが出来ちゃいます。~
 > git checkout -b <branch>
- issu1ブランチにコミットしてみる~
''issu1''ブランチをチェックアウトした状態でコミットを行うと，issu1ブランチに履歴が記録されていきます。~
myfile.txtに，addコマンドの説明を追加してからコミットしてみます。~
 Gitのブランチを試してみる。
 少し変更してみた。
のように編集して，
 > git add myfile.txt
 > git commit -m "ちょっと修正"
 [issu1 5b095cb] ちょっと修正
 1 file changed, 1 insertion(+)
この時点での履歴はこのようになります。~
#ref(b4.png,,70%)
- ブランチをマージしてみる~
issu1ブランチに行った変更を，masterブランチに統合してみます。~
ブランチのマージは，''merge''コマンドで行います。
 > git merge <commit>
 > git checkout master
 Switched to branch 'master'
 > cat myfile.txt
 Gitのブランチを試してみる。
 > git merge issu1
 Updating 8bd1e74..5b095cb
 Fast-forward
  myfile.txt | 1 +
  1 file changed, 1 insertion(+)
masterブランチの指すコミットが，issu1と同じ位置に移動しました。このマージは，fast-forward（早送り）マージです。~
#ref(b5.png,,70%)
myfile.txtファイルを開いて内容を確認してみます。
 > cat myfile.txt
 Gitのブランチを試してみる。
 少し変更してみた。
ちゃんとマージ出来ています。
- ブランチを削除する~
''issu1''ブランチの内容は''master''に無事統合されたので，削除します。~
ブランチを削除するには，branchコマンドに''-dオプション''を指定して実行します。
 > git branch -d issu1
 Deleted branch issu1 (was 5b095cb).
 > git branch
 * master
#ref(b6.png,,70%)
- 並行で作業する~
次に，ブランチを2つ作成して並行で作業してみます。~
まず，issu2ブランチとissu3ブランチを作成し，issu2ブランチをチェックアウトします。
 > git branch issu2
 > git branch issu3
 > git checkout issu2
 Switched to branch 'issu2'
 > git branch
 * issu2
   issu3
   master
#ref(b7.png,,70%)
issu2ブランチのmyfile.txtに，''commit''コマンドの説明を追加してコミットします。~
myfile.txtに追加
 Gitのブランチを試してみる。
 少し変更してみた。
 並行作業の確認
 > git add myfile.txt
 > git commit -m "並行作業の説明を追加"
 [issu2 1130b71] 並行作業の確認を追加
 1 file changed, 1 insertion(+)
#ref(b8.png,,70%)
 > git checkout issu3
 Switched to branch 'issu3'
 Gitのブランチを試してみる。
 少し変更してみた。
 Gitのブランチを試してみる。
 少し変更してみた。
 別の人の作業です。
 > git add myfile.txt
 > git commit -m "別の人の作業ですを追加"
 [issu3 f38fca6] 別の人の作業ですを追加
 1 file changed, 1 insertion(+)
#ref(b9.png,,70%)
issu2とissu3に別々の文を追加して，別の作業を行ったことを再現してみました。
 > git checkout master
 Switched to branch 'master'
 > git merge issu2
 Updating 5b095cb..1130b71
 Fast-forward
  myfile.txt | 1 +
  1 file changed, 1 insertion(+)
これは，fast-forward（早送り）マージが行われます。
#ref(b10.png,,70%)
 > git merge issu3
 Auto-merging myfile.txt
 CONFLICT (content): Merge conflict in myfile.txt
 Automatic merge failed; fix conflicts and then commit the result.
自動マージに失敗しました。同じ行を別の内容に変更していたため競合が発生したからです。~
この時，myfile.txtの内容は以下のようになっています。
 Gitのブランチを試してみる。
 少し変更してみた。
 <<<<<<< HEAD
 並行作業の確認
 =======
 別の人の作業です。
 >>>>>>> issu3
 Gitのブランチを試してみる。
 少し変更してみた。
 並行作業の確認
 別の人の作業です。
 > git add myfile.txt
 > git commit -m "issue3ブランチをマージ"
 [master ffa1ab3] issu3ブランチをマージ
履歴はこのようになります。
 今回のマージでは，競合箇所を修正したため，その変更を記録するマージコミットが新たに作成されました。
 そして，masterの先頭はそこに移動しています。このようなマージは，fast-forwardではないマージ，ということでnon fast-forwardマージと呼ばれます。
#ref(b11.png,,70%)
- rebaseでマージする~
''issu3''ブランチをマージするとき，issu3ブランチをあらかじめ''rebase''していれば履歴を一本にすることも出来ました。~
一旦，前で行ったマージを取り消してみます。
 > git reset --hard HEAD~
 HEAD is now at 1130b71 並行作業の確認を追加
#ref(b12.png,,70%)
 > git checkout issu3
 Switched to branch 'issu3'
 > git rebase master
 First, rewinding head to replay your work on top of it...
 Applying: 別の人の作業ですを追加
 Using index info to reconstruct a base tree...
 M       myfile.txt
 .git/rebase-apply/patch:8: trailing whitespace.
 95??l82?&igrave;8b?
 warning: 1 line adds whitespace errors.
 Falling back to patching base and 3-way merge...
 Auto-merging myfile.txt
 CONFLICT (content): Merge conflict in myfile.txt
 error: Failed to merge in the changes.
 Patch failed at 0001 別の人の作業ですを追加
 When you have resolved this problem run "git rebase --continue".
 If you would prefer to skip this patch, instead run "git rebase --skip".
 To check out the original branch and stop rebasing run "git rebase --abort".
 Gitのブランチを試してみる。
 少し変更してみた。
 並行作業の確認
 別の人の作業です。
 > git add myfile.txt
 > git rebase --continue
 Applying: 別の人の作業ですを追加
#ref(b13.png,,70%)
 > git checkout master
 Switched to branch 'master'
 > git merge issu3
 Updating 1130b71..a0259b9
 Fast-forward
  myfile.txt | 1 +
  1 file changed, 1 insertion(+)
myfile.txtの最終的な内容は，mergeと同じですが，履歴はこのようになります。
#ref(b14.png,,70%)

* コミットについて [#q917b767]

** コミットの位置 [#gac29fab]
- ''origin/master''~
リモートリポジトリ「origin」のブランチ「master」の位置を表しています。~
- ''origin/HEAD''~
リモートリポジトリ「origin」をクローンした時に，ダウンロードされるコミットの位置を表しています。~
通常は，「origin/master」と同じ位置を指します。~
- ''master''~
ローカルリポジトリのブランチ「master」の位置を表しています。~

** コミットの書き換え [#b9ab6612]

*** 直前のコミットを修正する [#ldcc9e67]
''amend''オプションを指定して''commit''コマンドを行うと，同じブランチの直前のコミットに対して内容を追加やコメントの修正をすることが出来ます。~
''主な利用シーン''~
- 直前のコミット漏れしたファイルを後から追加する~
- 直前のコミットコメントを修正する~

''例：''
以下のようなGitで管理されているディレクトリがあります。
#ref(amend1.png,,70%)
 > git log
 commit 326fc9f70d022afdd31b0072dbbae003783d77ed
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:17:56 2012 +0900
 
     addの説明を追加
 
 commit 48eec1ddf73a7fb508ef664efd6b3d873631742f
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:16:14 2012 +0900
 
     first commit
そのディレクトリのsample.txtに文を追加します。~
その後，addで変更をインデックスに登録する。commitでインデックスの状態を記録する。~
''--amend''オプションを追加してコミットしてみます。
 > git add sample.txt
 > git commit --amend -m "addとcommitの説明を追加"
''-m''を付けないと，直前のコミットのコミットメッセージがエディタで表示されます。この場合は，''addとcommitの説明を追加''にコメントを変更して，保存・終了します。~
''-m''でコメントを直接指定できます。~
これでコミットの内容を修正しました。logコマンドで履歴とコミットメッセージを確認します。
#ref(amend2.png,,70%)
 > git log
 commit e9d75a02e62814541ee0410d9c1d1bf47ab1c057
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:17:56 2012 +0900
 
     addとcommitの説明を追加
 
 commit 48eec1ddf73a7fb508ef664efd6b3d873631742f
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:16:14 2012 +0900
 
     first commit

*** 過去のコミットを打ち消す [#fe05c65a]
''revert''では，指定したコミットの内容を打ち消すコミットを作り出すことが出来ます。~
後述の''rebase -i''や''reset''コマンドによりコミットを削除することも出来ますが，そのコミットが既に公開済みであった場合は，勝手に削除出来ません。~
このような場合には，revertで内容を打ち消すコミットを作り出すことが出来ます。~
#ref(revert.png,,70%)
''主な利用シーン''~
- 過去に公開したコミットを安全に打ち消す~

''例：''
#ref(revert1.png,,70%)
 $ git log
 commit 0d4a808c26908cd5fe4b6294a00150342d1a58be
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:19:26 2012 +0900
 
     pullの説明を追加
 
 commit 9a54fd4dd22dbe22dd966581bc78e83f16cee1d7
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:19:01 2012 +0900
  
     commitの説明を追加
 
 commit 326fc9f70d022afdd31b0072dbbae003783d77ed
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:17:56 2012 +0900
 
     addの説明を追加
 
 commit 48eec1ddf73a7fb508ef664efd6b3d873631742f
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:16:14 2012 +0900
 
     first commit

sample.txtファイルを開いて，内容を確認します。~

''revert''を使って，pullの説明を追加しているコミットを取り消してみます。~
 $ git revert HEAD
 [master d47bb1d] Revert "pullの説明を追加"
  1 files changed, 1 insertions(+), 2 deletions(-)

sample.txtを開いてみると，pullの説明がなくなっています。~
#ref(revert2.png,,70%)
 $ git log
 commit 7bcf5e3b6fc47e875ec226ce2b13a53df73cf626
 Author: yourname <yourname@yourmail.com>
 Date:   Wed Jul 18 15:46:28 2012 +0900
 
     Revert "pullの説明を追加"
 
     This reverts commit 0d4a808c26908cd5fe4b6294a00150342d1a58be.
 
 commit 0d4a808c26908cd5fe4b6294a00150342d1a58be
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:19:26 2012 +0900
 
     pullの説明を追加
 
 commit 9a54fd4dd22dbe22dd966581bc78e83f16cee1d7
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:19:01 2012 +0900
 
     commitの説明を追加
 
 commit 326fc9f70d022afdd31b0072dbbae003783d77ed
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:17:56 2012 +0900
 
     addの説明を追加
 
 commit 48eec1ddf73a7fb508ef664efd6b3d873631742f
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:16:14 2012 +0900
 
     first commit

*** コミットを捨てる [#pb229172]
''reset''では，要らなくなったコミットを捨てることが出来ます。~
実行時に，影響範囲によって異なるモードを指定することで，インデックスやワークツリーの内容も戻すかどうか指定出来ます。~
#ref(reset.png,,70%)

モードには，デフォルトで使用される''mixed''の他，''soft''と''hard''があり，それぞれが影響を与える場所は，以下の表のようになっている。~
|モード名|HEADの位置|インデックス|ワークツリー|h
|soft    |変更する  |変更しない  |変更しない  |
|mixed   |変更する  |変更する    |変更しない  |
|hard    |変更する  |変更する    |変更する    |

''主な利用シーン''~
- 変更したインデックスの状態を元に戻す（mixed）~
- 最近のコミットを完全に無かったことにする（hard）~
- コミットだけを無かったことにする（soft）~

''例：''~
#ref(revert1.png,,70%)
 $ git log
 commit 0d4a808c26908cd5fe4b6294a00150342d1a58be
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:19:26 2012 +0900
 
     pullの説明を追加
 
 commit 9a54fd4dd22dbe22dd966581bc78e83f16cee1d7
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:19:01 2012 +0900
 
     commitの説明を追加
 
 commit 326fc9f70d022afdd31b0072dbbae003783d77ed
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:17:56 2012 +0900
 
     addの説明を追加
 
 commit 48eec1ddf73a7fb508ef664efd6b3d873631742f
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:16:14 2012 +0900
 
     first commit
sample.txtファイルを開いて，内容を確認します。~
''reset''を使って，コミットを削除します。~
#ref(reset2.png,,70%)
 $ git reset --hard HEAD~~
 HEAD is now at 326fc9f addの説明を追加
sample.txtを開くと，commitとpullの説明がなくなっています。~
logコマンドで履歴を確認します。
 $ git log
 commit 326fc9f70d022afdd31b0072dbbae003783d77ed
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:17:56 2012 +0900
 
     addの説明を追加
 
 commit 48eec1ddf73a7fb508ef664efd6b3d873631742f
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:16:14 2012 +0900
 
     first commit
''reset''前のコミットは，''ORIG_HEAD''という名前で参照することができます。~
間違えて''reset''したなどの場合は，''ORIG_HEAD''に''reset''すると''reset''前の状態に戻すことが出来ます。
 $ git reset --hard ORIG_HEAD
 HEAD is now at 0d4a808 pullの説明を追加

*** コミットを抜き取る [#u62c1ef4]
''cherry-pick''では，別のブランチから指定したコミットをコピーして，現在のブランチに取り込む事が出ます。~
#ref(cherrypick.png,,70%)
''主な利用シーン''~
- ブランチを間違えて追加したコミットを正しい場所に移す~
- 別ブランチのコミットを現在のブランチにも追加する~

''例：''
例として，以下の様なリポジトリの履歴がある場合。
#ref(cherrypick1.png,,70%)
ここでは，別のブランチで行った''commitの説明の追加''という変更だけを，''master''ブランチに取り込んでみます。
 $ git log
 commit 08084a5c58e9ca3672292c3883c44e623f817b72
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:22:17 2012 +0900
 
     pullの説明を追加
 
 commit 99daed25b45fcae2ce9d707a3434951cf69f253a
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:21:57 2012 +0900
 
     commitの説明を追加
 
 commit 48eec1ddf73a7fb508ef664efd6b3d873631742f
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:16:14 2012 +0900
 
     first commit
masterブランチに移動して，cherry-pickを使って，''commitの説明を追加''したコミットを取り出してmasterに追加してみます。
 $ git checkout master
 Switched to branch 'master'
 $ git cherry-pick 99daed25b45fcae2ce9d707a3434951cf69f253a
 error: could not apply 99daed2... commitの説明を追加
 hint: after resolving the conflicts, mark the corrected paths
 hint: with 'git add <paths>' or 'git rm <paths>'
 hint: and commit the result with 'git commit'
競合が発生しているんで，エラーが出ています。sample.txtを開いて，競合箇所を修正してから，コミットします。
 誰でもわかるGitコマンド
 <<<<<<< HEAD
 add 変更をインデックスに登録する
 =======
 commit インデックスの状態を記録する
 >>>>>>> 99daed2... commitの説明を追加
修正したら，
 $ git add sample.txt
 $ git commit

*** コミットの履歴を書き換える [#e7dbe167]
''rebase''に''i''オプションを指定すると，コミットの書き換え，入れ替え，削除，統合を行うことが出来ます。~
#ref(rebase_i.png,,70%)
''主な利用シーン''~
- pushする前にコミットコメントをきれいに書きなおす~
- 意味的に同じ内容のコミットをわかりやすいように一つにまとめる~
- コミット漏れしたファイルを後から追加する~

''例：''~
''rebase -i でコミットをまとめる''~
リポジトリの履歴が図の状態になっている場合。~
ここでは，''commitの説明を追加''と''pullの説明を追加''という変更を，ひとつのコミットにまとめてみます。~
#ref(rebase_i1.png,,70%)
過去のコミットをまとめるには，''rebase -i''を使います。~
 $ git rebase -i HEAD~~
テキストエディタが開いて，HEADからHEAD~~までのコミットが次のように表示されます。
 pick 9a54fd4 commitの説明を追加
 pick 0d4a808 pullの説明を追加
 
 # Rebase 326fc9f..0d4a808 onto d286baa
 #
 # Commands:
 #  p, pick = use commit
 #  r, reword = use commit, but edit the commit message
 #  e, edit = use commit, but stop for amending
 #  s, squash = use commit, but meld into previous commit
 #  f, fixup = like "squash", but discard this commit's log message
 #  x, exec = run command (the rest of the line) using shell
 #
 # If you remove a line here THAT COMMIT WILL BE LOST.
 # However, if you remove everything, the rebase will be aborted.
 #
二行目のpickの文字をsquashに変更して保存・終了します。~
すると，まとめた後のコミットに設定するコミットメッセージを編集するためのエディタが表示されるので，編集して保存・終了します。

これで，二つのコミットが一つのコミットにまとめられました。logコマンドで履歴を確認します。
 $ git log
 commit 623c2434b7ba1d28a61d1424b57082f81183872b
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:19:01 2012 +0900
 
     commitの説明を追加
     
     pullの説明を追加
 
 commit 326fc9f70d022afdd31b0072dbbae003783d77ed
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:17:56 2012 +0900
 
     addの説明を追加
 
 commit 48eec1ddf73a7fb508ef664efd6b3d873631742f
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:16:14 2012 +0900
 
     first commit
#ref(rebase_i2.png,,70%)

''rebase -i でコミットを修正する''~
リポジトリの履歴が図の状態になっている場合。~
ここでは，''commitの説明を追加''で行った変更内容を修正します。
#ref(rebase_i1.png)
rebase -iを使って，まず，修正するコミットを選択します。~
 $ git rebase -i HEAD~~
テキストエディタが開いて，HEADからHEAD~~までのコミットが次のように表示されます。~
 pick 9a54fd4 commitの説明を追加
 pick 0d4a808 pullの説明を追加
 
 # Rebase 326fc9f..0d4a808 onto d286baa
 #
 # Commands:
 #  p, pick = use commit
 #  r, reword = use commit, but edit the commit message
 #  e, edit = use commit, but stop for amending
 #  s, squash = use commit, but meld into previous commit
 #  f, fixup = like "squash", but discard this commit's log message
 #  x, exec = run command (the rest of the line) using shell
 #
 # If you remove a line here THAT COMMIT WILL BE LOST.
 # However, if you remove everything, the rebase will be aborted.
 #
1行目のpickの文字をeditに変更して保存・終了します。~
すると，次のような出力が表示されて，修正するコミットがチェックアウトされた状態になります。~
 Stopped at d286baa... commitの説明を追加
 You can amend the commit now, with
 
         git commit --amend
 
 Once you are satisfied with your changes, run
 
         git rebase --continue
sample.txtを開いて，commitの説明の所を適当に変更します。~
 誰でもわかるGitコマンド
 add 変更をインデックスに登録する
 commit インデックスの状態を記録する
 pull リモートリポジトリの内容を取得する
commit --amendで変更を保存します。~
 $ git add sample.txt
 $ git commit --amend
commitをしただけだとまだrebaseの作業は終わっていません。このコミットでの作業が終了したことを知らせるには，--continueオプションを指定して，rebaseを実行します。~
 $ git rebase --continue

この時，他のコミットで競合が発生することがあります。その時は，競合箇所を修正してからaddとrebase --continueを実行してください。このとき，コミットは必要ないので実行しないでください。~
もし，途中でrebaseの作業を中止したくなった場合はrebaseに--abortオプションを指定して実行すると，これまでのrebaseでの作業をなかった事にして，中止することが出来ます。

これで，コミットの修正が完了しました。もし，複数のコミットをeditに変更していた場合，次に修正するコミットがチェックアウトされるので，同じように変更を行います。~

実は，rebase前のコミットは，ORIG_HEADという名前で残っています。~
もし，rebaseした後で，元に戻したくなった場合は，
 git reset --hard ORIG_HEAD
で，rebase前の状態に戻せます。

*** ブランチ上のコミットを一つにまとめてマージする [#bdb63342]
少し特殊な''merge''として，''squash''オプションがあります。~
このオプションを指定してブランチをマージすると，そのブランチのコミット全てをまとめたコミットが追加されます。~
#ref(squash.png,,70%)
''主な利用シーン''
- トピックブランチ中のコミットを一つにまとめて，統合ブランチに統合する。~

''例：''~
''merge --squashを使ってみる''~
リポジトリの履歴が図の状態になっている場合。~
ここでは，issue1ブランチのすべてのコミットを，ひとつのコミットとしてまとめてmasterブランチに取り込んでみます。
#ref(mergesquash.png,,70%)
 $ git log
 commit 08084a5c58e9ca3672292c3883c44e623f817b72
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:22:17 2012 +0900
 
     pullの説明を追加
 
 commit 99daed25b45fcae2ce9d707a3434951cf69f253a
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:21:57 2012 +0900
 
     commitの説明を追加
 
 commit 48eec1ddf73a7fb508ef664efd6b3d873631742f
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:16:14 2012 +0900
 
     first commit
masterブランチに移動した後，--squashオプションを指定してmergeを実行します。~
 $ git checkout master
 Switched to branch 'master'
 $ git merge --squash issue1
 Auto-merging sample.txt
 CONFLICT (content): Merge conflict in sample.txt
 Squash commit -- not updating HEAD
 Automatic merge failed; fix conflicts and then commit the result.
競合が発生したので，sample.txtを開いて，競合箇所を修正してからコミットします。~
 $ git add sample.txt
 $ git commit -m "issue1からすべてマージ"
 [master 0d744a7] Conflicts:   sample.txt
  1 files changed, 4 insertions(+), 1 deletions(-)
これで，issue1ブランチ上のすべてのコミットを一つにまとめたものが，masterブランチに追加されました。logコマンドで履歴を確認してみます。
 $ git log
 commit 31b5bfc69fcd10c4a76368ce18df048aa55ca0ec
 Author: yourname <yourname@yourmail.com>
 Date:   Tue Oct 4 16:57:00 2016 +0900
 
     issue1からすべてマージ
 
 commit 326fc9f70d022afdd31b0072dbbae003783d77ed
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:17:56 2012 +0900
 
     addの説明を追加
 
 commit 48eec1ddf73a7fb508ef664efd6b3d873631742f
 Author: yourname <yourname@yourmail.com>
 Date:   Mon Jul 16 23:16:14 2012 +0900
 
     first commit

* タグ [#z5544b6f]
タグはコミットを参照しやすくするために，わかりやすい名前を付けるものです。~

Gitでは，軽量タグと注釈付きタグの2種類のタグが使用出来ます。~
-軽量タグ~
名前を付けられる。
-注釈付きタグ~
名前を付けられる。~
コメントを付けられる。~
署名を付けられる。~

また，一度付けたタグはブランチのように位置が移動することはなく固定になります。~

一般的には，リリースタグには注釈付きタグを使ってコメントや署名を追加します。~
軽量タグは，ローカルで一時的に使用する使い捨てなどで使用します。~
#ref(タグ1.png,,70%)

タグ名を指定して''checkout''したり''reset''を行うことで，簡単に過去の特定の状態に戻すことが出来ます。~

** タグを使ってみる [#m4b9a34c]
- 前準備~
まずは新しくディレクトリを作成し，そこに空のリポジトリを作成します。 ここでは，tutorial2というディレクトリを作成した。~
 $ mkdir tutorial2
 $ cd tutorial2
 $ git init
 Initialized empty Git repository in D:/home/ueno/tutorial2/.git/
tutorial2ディレクトリに，次のような''myfile.txt''という名前でファイルを作成します。~
 誰でもわかるGitコマンド
そして，コミットします。
 $ git add myfile.txt
 $ git commit -m "最初のコミット"
 [master (root-commit) fb15e6e] 最初のコミット
  1 file changed, 1 insertion(+)
  create mode 100644 myfile.txt
この時点での履歴はこのようになります。
#ref(b1.png)
- 軽量タグを追加する~
タグを追加するには，''tag''コマンドを使用します。<tagname>には，タグの名前を指定します。~
 $ git tag <tagname>
現在のHEADが指しているコミットに，appleというタグを付けるには，次のようにします。~
 $ git tag apple
パラメータなしで''tag''コマンドを実行すると，タグの一覧を表示出来ます。~
 $ git tag
 apple
また，logコマンドに''--decorate''オプションを付けて実行すると，タグ情報を含めて履歴を表示出来ます。~
 $ git log --decorate
 commit fb15e6eb361bc56b4698e259f655c4f93c859fe6 (HEAD -> master, tag: apple)
 Author: yourname <yourname@yourmail.com>
 Date:   Tue Oct 4 14:30:04 2016 +0900
 
     最初のコミット
#ref(タグ2.png,,70%)
- 注釈付きタグを追加する~
注釈付きタグを追加するには，''tag''コマンドに''-a''オプションを指定して実行します。実行するとエディタが起動するので，タグに設定するコメントを入力します。''-m''オプションを指定してコメントを与えることも出来ます。~
 $ git tag -a <tagname>
現在のHEADが指しているコミットに，bananaという注釈付きタグを付けるには，次のようにします。~
 $ git tag -am "誰でもわかるGit" banana
''-n''オプションを指定して''tag''コマンドを実行すると，タグの一覧とコメントを表示出来ます。~
 $ git tag -n
 apple           最初のコミット
 banana          誰でもわかるGit
#ref(タグ3.png,,70%)
- タグを削除する~
タグを削除するには，''tag''コマンドに''-d''オプションを指定して実行します。~
 $ git tag -d <tagname>
#ref(タグ4.png,,70%)

* gitに登録させたくないファイルを指定する方法 [#t4285e5b]

** .gitignoreで無視ファイルを指定する場合 [#x23eaaee]
全体的に指定したい場合は，ホームディレクトリ下に.gitignoreを，プロジェクト毎に指定したい場合は，そのプロジェクト下に.gitignoreで指定する。

''.gitignoreの書き方''~
 # ←で始めるとコメント行
 
 # サブディレクトリを含む hoge.mp3等のファイルを無視したい
 *.mp3
 
 # トップディレクトリの*.exeファイルのみを無視対象にしたくなった，
 # だけど，サブディレクトリは無視しない場合
 /*.exe
 
 # tmpディレクトリを，まるごと無視したい場合
 # ただし，gitはディレクトリを扱わないので取り出したときに
 # 多分，tmpが消えちゃう。それが問題なら，空のtmp/.gitignoreを作り
 #  git add tmp/.gitignore
 # してやればいいと思う。（もし文句言われたら -f をつける）
 tmp/
 
 # cacheディレクトリの中身は無視したいけど，
 # とにかく，.htaccessは無視したくない場合（"!"で除外設定）
 # cache/ だとなぜか上手く行かない？
 cache/*.*
 !.htaccess
 
 # *.oは，C言語なんかのコンパイル済みオブジェクトなのでいらない
 # だけど，zlib/以下の*.oは，いるなあ（除外指定）なんて時
 *.o
 !zlib/*.o

** .gitconfigで無視するファイルを記述するファイルで指定する方法 [#k959b6d7]
.gitconfigに以下のように追加します。
 [core]
     excludesfile = C:\\home\\ueno\\gitignore_global.txt
とかして，
gitignore_global.txtに，無視したいファイルを登録します。~
以下はVisual Studioでgitで管理されたくないファイルを指定する例。~
 #ignore thumbnails created by windows
 Thumbs.db
 #Ignore files build by Visual Studio
 *.obj
 *.exe
 *.pdb
 *.user
 *.aps
 *.pch
 *.vspscc
 *_i.c
 *_p.c
 *.ncb
 *.suo
 *.tlb
 *.tlh
 *.bak
 *.cache
 *.ilk
 *.log
 *.dll
 *.lib
 *.sbr

* gitに登録したファイルを削除 [#q1742fde]
単にrmでファイルを削除した場合は，リポジトリには登録されたままになる。この場合，
 $ git checkout -- filename
とかすると，削除したファイルを復活できます。リポジトリにファイルが残ってるからです。

gitリポジトリからファイルを削除する場合は，
 $ git rm filename
を実行すると，ファイルの削除が登録される。次にコミットすると，ファイルが削除される。
開発/バージョン管理システム/git/Gitの使い方のバックアップソース(No. All)
- 現: 2024-11-07 (木) 10:54:37 yuji
  - Deleted an attach file: rebase_i.png at 2024-11-07 (木) 12:17:15, Deleted an attach file: タグ3.png at 2024-11-07 (木) 12:33:30, Deleted an attach file: タグ2.png at 2024-11-07 (木) 12:33:33 at 2024-11-07 (木) 12:39:20