前の関連記事：Git(18)EclipseでGitのチュートリアルビデオ:その2
Gitの基本構造を復習
ワークツリーとインデックス【Gitの基本】 | サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ
ワーキングツリー→インデックス→ローカルリポジトリ→リモートリポジトリ
ファイルを編集して、コミットして、プッシュするときはこの一連の要素を操作していることになります。
ワーキングツリーは実際にエディタで操作しているファイルマネージャで見えるファイル、インデックスはコミットするときにStaged Changesに入れているファイル、ローカルリポジトリはインデックスされてコミットされたファイルの内容が入っているところ、リモートリポジトリはGitHubなどのクラウド上のリポジトリ、となります。
誰得UNIX: ステージを理解して git をもっと便利に使う
インデックスとステージについてはこの解説がわかりやすかったです。
ワーキングツリーとインデックスとローカルリポジトリはこれまでは連動して変化していたので、違いをあまり意識してきませんでした。
しかし、resetとかrevertとかやりだすと、ワーキングツリーとインデックスとローカルリポジトリの内容がバラバラになってきてよくわからなくなってしまったので、とてもわかりやすい図がついたチュートリアルに沿って学習することにします。
チュートリアル１ ブランチの活用
0. 前準備【チュートリアル1 ブランチを使ってみよう】 | サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ
新しいブランチを作成して、それを元のブランチにマージするチュートリアルです。
前回の hellogitリポジトリを引き続き使うことにします。
新たなブランチissue1を作成する
GitパースペクティブのGitリポジトリビューでhellogitリポジトリのLocalのmasterブランチを右クリック→Create Branch。
新しいブランチ名をissue1にしました。
リモートリポジトリはいまは関係ないのでConfigure upstream for push and pullのチェックボックスは外しままにしておきます。
新たしいブランチで、すぐ編集できるようにCheckout new branchはチェックをつけたままにしておきます。
Finish。
Localにissue1という新たにブランチが作成され、チェックアウトしていることを示すレ点がついています。
Historyビューでみるとissue1というブランチ名が出現していることがわかります。
names = ["Bilbo","Frodo","Aragorn","Leglas","Gandalf","Boromir","Faramir"]
# print greetings to the fine folks in the Middle Earth
for name in names:
print("Hello, {}".format(name))
print("How are you doing today?")
# add 変更をインデックスに登録する
hellogit.pyの最後の6行目にコメントを追記して保存してコミットします。
Commit Messageはチュートリアルの通り「addの説明を追加。」にしてCommitボタンをクリック。
コミットId fbf31d9のコミットがHistoryビューに登場し、issue1とHEADタグがそこに移動しました。
issue1ブランチで行った変更をmasterブランチに取り込む
issue1ブランチで行った変更をmasterブランチに取り込むということは、つまりissue1ブランチをmasterブランチにマージします。
masterブランチに取り込むためにまずmasterブランチをチェックアウトします。
Gitリポジトリビューでmasterブランチをダブルクリックするだけでmasterブランチをチェックアウトできます。
HistoryビューでのHEADタグが現在のブランチの先頭のコミットに移動していることがわかります。
Gitリポジトリビューでmasterブランチを右クリック→Merge、とするとmasterブランチにマージするブランチの選択画面がでてきます。
この方法だとMerge optionとFast forward optionが選択できますが、まだよくわからないので、勝手にオプションを選んでくれる次の方法でやることにします。
Gitリポジトリビューでissue1ブランチを右クリック→Merge
これでissue1ブランチをmasterブランチにマージ完了です。
チュートリアルの説明通り、masterブランチとHEADタグがissue1ブランチのタグと同じコミットに移動しました。
masterブランチはissue1ブランチと同じコミット経路をたどっただけなのでコミットグラフに分岐はなく、Fast-forwardマージになっています。
このマージはmasterブランチに対してissue1ブランチと同じコミットを追加した操作と同じです。
なのでその取り消しはコミットの取り消しと同様にできます。
Hard Resetで取り消す(前のコミットの状態に戻したいとき)
この時点でマージを取り消したいときはリセットを使います。
Historyビューで、取り消したいコミットの前のコミットを選択します。
今回の場合はIdが11d9cf8のコミットです。
右クリック→Reset→Hard(Head, Index and Working Tree)。
これで全く前のコミットの状態に戻ります。
次のMixed Resetと比較するために再度先ほどと同様にして issue1ブランチをmasterブランチにマージしておきます。
Mixed Resetで取り消す(編集済みのコードは戻したくないとき)
今度は11d9cf8のコミットを右クリック→Reset→Mixed(Head and Index)。
HistoryビューをみるとHard Resetのときと同様にHEADとmasterのタグが元に戻っていることがわかります。
Indexが元に戻っていることはGit Stagingビューでわかります。
コミットするときにStaged Changesに移動させたhellogit.pyがUnstaged Changesに戻っています。
Hard ResetのときもMixed Resetと同様にIndexがリセットされているはずですが、Working Treeもリセットされて変化する前の状態に戻されているので、Hard ResetのときはUnstaged Changedにhellogit.pyは表示されていません。
Mixed ResetのときはHard Resetのときと違って、Working Treeが戻っておらず、hellogit.pyを編集して保存した状態ということです。
これはGitリポジトリビューで、Working Tree→hellogit→src→hellogit.pyとたどりhellogit.pyをダブルクリックしてエディタで中身をみるとissue1ブランチで編集して保存した状態と同じであることから確認できます。
Mixed Resetはコミットを戻したいけど、hellogit.pyの編集済みところだけは戻したくない時に使えます。
次のSoft Resetと比較するために最初と同様にマージを再現します。
まずhellogit.pyを編集する前の状態に戻せばいいわけですが、保存してしまったhellogit.pyを保存する前の状態に戻すコマンドがわかりませんでした。
なのでこれはissue1ブランチをチェックアウトして、masterブランチで行ったコミット前の作業すべてを消してしまうことにしました。
Gitリポジトリビューでissue1ブランチをダブルクリック。
issue1をチェックアウトするとhellogit.pyのコミット前の変更を失いますよ、と警告がでてきます。
失いたいのでResetボタンをクリックします。
これでmasterブランチが元の状態に戻りました。
(この方法は元に戻せるWorking Treeのローカルブランチがないとできないので、汎用的ではありません。次の投稿ではコミットしてから元のコミットでHard Resetして戻しました。)
次のSoft Resetと比較するために最初と同様にmasterブランチをチェックアウトして、issue1ブランチをmasterブランチにマージしました。
Soft Resetで取り消す(編集済みのコードとStaged Changedの選択は戻したくないとき)
今度は11d9cf8のコミットを右クリック→Reset→Soft(Head Only)。
HistoryビューをみるとHard ResetのときとMixed Resetのときと同様にHEADとmasterのタグが元に戻っていることがわかります。
Working Treeはリセットしていないので、Mixed Resetのときと同様にhellogit.pyはissue1ブランチで編集して保存した状態と同じです。
Soft ResetがMixed Resetと違う点は、Indexをリセットしていないので、Git Stagingビューを見ると、hellogit.pyがStaged Changesに移動した状態になっています。
これはコミットする直前の状態です。
なのでSoft Resetはコミットを戻したいけど、hellogit.pyの編集済みところとStaged Changedのファイルの選択は戻したくない時に使えます。
次に進むためにissue1をチェックアウトして、masterブランチの状態をリセットしました。
そして、最初と同様にまずmasterブランチをチェックアウトして、issue1ブランチをmasterブランチにマージしました。
issue1ブランチもGitHubにプッシュする
これまでの作業の続きをまるまる家でやるために、Issue1ブランチもGitHubにプッシュすることにします。
まずmasterブランチをチェックアウトした状態で、Gitリポジトリビューでhellogitリポジトリを右クリック→Push to Upstream。
Remote Trakingにはmastarブランチしか反映されていません。
issue1ブランチを右クリック→Push Branch。
リモートリポジトリにはissue1ブランチはないはずなので、Confgure upstream for push and pullもForce overwrite branch in remote if it exists and has divergedもチェックをはずしておきました。
Next。
Show dialog with result only when it is different from the confirmed result aboveにチェックをつけて、設定通りにならなかったときはダイアログを表示してもらうようにします。
(あとから考えるとこれはCancel push if result would be different than above because of changes on remoteにチェックをつけて、設定通りにならなかったらプッシュをキャンセルにしたほうがよいと思いました。)
Finish。
期待した通りorigin/issue1ブランチがリモートリポジトリに作成されました。
さて、続きは家に帰ってからやりますか。
参考にしたサイト
サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ
とてもわかりやすいGit入門。発展編のチュートリアルはCUI版のみです。
誰得UNIX: ステージを理解して git をもっと便利に使う
GitのIndexとStageについての解説。
0 件のコメント:
コメントを投稿