GitやGitHubを用いる上でのトラブルシューティング
ブランチを作成せず、masterブランチ上でコードを書いてしまった
新たにブランチを作成し、これまで書いたコードを新しいブランチに移す。
コードを書いている途中にブランチを作成する際は、書いているコードを作成したブランチに引き継ぐか、0からコードを書き直すかを選択できる。
以下は、masterブランチから新ブランチを作成しようとしている。この時、masterブランチ上でコードを編集しているとする。
ブランチを作成。
すると、以下のような選択肢が出てくる。
選択肢について。
Leave my changes on master
元のブランチで書いていたコードを全て捨て、新しいブランチで0からコードを書く選択。
Bring my changes to (新しいブランチ名)
元のブランチで書いていたコードを新しいブランチに引き継ぐ選択です。
もしブランチを作成することを忘れてコードを書き進めてしまった場合、ブランチを作成したらBring my changes to (新しいブランチ名)を選択するようにする。
間違えてLeave my changes on masterを押してしまった場合は、以下の手順で捨てたコードを復旧できる。
まず、一度元のブランチに戻る。
すると、左下にStashed Changesという記述が増えている。ここをクリック。
ここで、上部にあるRestoreというボタンを押すと、コードを復旧することができる。
再度ブランチを作成し直し、選択肢を間違えずにBring my changes to (新しいブランチ名)を選択するようにする。
同じファイルを別の人が既に修正していてマージができない
ブランチをマージしようとしたら、自分がファイルを編集している間に、他の人が同じファイルを編集してmasterブランチに反映していた場合。
変更修正を上書きしてしまうことになり、マージができない。このような事象をコンフリクト（競合）と言う。
コンフリクトは開発を進める上で、常に直面する問題である。
コンフリクトについて
コンフリクトとは、あるファイルにおいてブランチごとに情報が異なり辻褄が合わない状況のことを言う。例えば、トピックブランチをマージしようとする際に、masterブランチとファイル内の情報が合致しない場合である。
以下のような状況を想定してみる。
チーム開発をしているAさんとBさんは、互いに作業内容の確認がとれておらず、二人とも同一のファイルに対して作業をしてしまった。これがコンフリクトである。
コンフリクトが生じていると、Bさんはマージをしようとしてもできない。コンフリクトを解消した上で、マージをする必要がある。
コンフリクトを解消する
先ほどまで使用していたgit-appを用いる。
Aさんにおける作業を実施
まず、Aさんが作業するブランチを作成する。conflict-Aというブランチとする。
article.rbに以下のようなバリデーションを付与する。
app/models/article.rb
1 2 3 |
class Article < ApplicationRecord
validates :title, presence: true
end
|
以下の様にコミット、プッシュしておく。
⌘+Rでプルリクエストを作成。
今回はコンフリクトの練習なので、Why/Whatは記述必要ない。
現時点では下図の作業が完了している。
Bさんにおける作業
では次にBさん側の作業をしていく。先程と同様にconflict-Bというブランチをmasterから作成。
article.rbに以下のようなバリデーションを付与する。バリデーションの意図はAさんと同じですが、記述方法が異なる。
app/models/article.rb
1 2 3 |
class Article < ApplicationRecord
validates_presence_of(:title)
end
|
先程と同様にコミット、プッシュして、プルリクエストを作成する。
現時点では下図の作業が完了している。
Aさんのプルリクエストをmasterにマージする
下図で示した部分の作業を実施。
通常どおり、プルリクエストをマージ。
またその後、GitHub Desktopにおけるmasterブランチで、忘れずにプルする。
Bさんのプルリクエストを確認
下図で示した部分の作業をしたい。
しかし、上記のAさんのプルリクエストをマージした段階で、Bさんのブランチにおけるarticle.rbの変更修正の記述と、masterブランチにおけるAさんが行ったarticle.rbの変更修正記述が被っている。このまま無理やりマージしたとしたら、Bさんの変更修正のみ反映され、Aさんの記述は上書きされて消えてしまう。
しかしGitHubはコンフリクトが生じた際は丁寧に教えてくれる。
Bさんのプルリクエストを確認してみると以下のように、コンフリクトのためにマージできない旨の表示がされている。
ではこのコンフリクトを解決していく。
コンフリクトを解決
コンフリクトを解決する手順は以下。
- コンフリクト箇所をconflict-Bのブランチに反映
- コンフリクト箇所を修正
- コンフリクト解決をコミット
- conflict-Bのブランチをマージ
①. コンフリクト箇所をconflict-Bのブランチに反映
GitHub Desktop conflict-Bのブランチに戻る。
GitHub Desktopで[History]タブの「Select Branch to Compare...」というプレースホルダーが書かれたボックスをクリックすると、現在のブランチとそれ以外のブランチの比較を確認することができる。
ここで、表示されているmasterブランチをクリックすると、 具体的にどのように異なるのかが確認できる。
ここのBehindとAheadは、Gitにおいて大切な考え方になる。
Behindは、現在のブランチよりも比較するブランチが進んでいる変更履歴を意味し、 Aheadは、現在のブランチが進めた変更履歴を意味する。
現在それぞれのタブでは、 Behindには、conflict-Aの変更と、それをmasterにマージした変更履歴、Aheadには、conflict-Bで編集した変更履歴がそれぞれコミット単位で確認できる。
現在このBehindとAheadに同じファイル編集のコミットが存在しているため、 画面左下に「There will be 1confilicted file when merging master into conflict-B 」という表示がある。これは、もしmasterブランチをconflict-Bブランチにマージした時は、コンフリクトが発生するファイルが1つあります。という意味。
[Merge into conflict-B]というボタンをクリックし、実際にマージして競合を解決していく。
このマージによってBehindで表示されていた分のコミットがconflict-Bに追加され、Aheadにあるarticle.rbと競合が発生する。GitHub Desktopでは以下のような画面が表示されるはず。下図の通りにクリックすると、テキストエディタが自動起動しarticle.rbを開く（画像ではAtomになっているが、実際の環境ではVisual Studio Codeになっているはず）。
テキストエディタで開かれたarticle.rbは、以下のようになっている。
app/models/article.rb
1 2 3 4 5 6 7 |
class Article < ApplicationRecord
<<<<<<< HEAD
validates_presence_of(:title)
=======
validates :title, presence: true
>>>>>>> master
end
|
<<<<<<< HEADと>>>>>>> masterという記述が、=======で区切られて追記されている。HEADとは現在のコミットを指していまる。つまり、conflict-Bのブランチで追記した内容。masterというのはリモートリポジトリのmasterブランチを指している。=======で区切られた上と下の記述が競合しているという意味になる。
②コンフリクト箇所を修正
競合を解決するために競合箇所を修正する。競合の解決方法は以下の2つ。
- 不要な方の記述を削除する
- 両方とも残す
どちらの方法を選択するかは、状況によって異なる。該当箇所を編集した人に確認するなどして、適切な方法で競合を解決する。今回はBさんの修正を削除したい。なぜならば、Bさんのバリデーションの記述は、古いRailsのバージョンのみに対応したものだからである。
以下のようにarticle.rbを編集し、保存する（残したい箇所以外を消去）。
app/models/article.rb
1 2 3 |
class Article < ApplicationRecord
validates :title, presence: true
end
|
競合解決の際に、<<<<<<< HEADと>>>>>>> masterと=======の記述は必ず消す。
③コンフリクト解決をコミット
競合を解決できたので、マージできた結果をコミットする。GitHub Desktopを確認すると先程とは表示が変わり、競合が解決できていることと、[Commit merge]というボタンがクリックできる状態になっていることが分かる。
そのまま[Commit merge]ボタンをクリックしコミットする。 競合解決の場合は自動的にコミットされる 。忘れずにプッシュしてリモートリポジトリに競合解決をした変更を反映させる。
④conflict-Bのブランチをマージ
プッシュした後に、GitHubでプルリクエストを確認。競合を解決したのでマージできるようになっている。そのまま、conflict-Bをマージする。
マージしたら、ローカルリポジトリのmasterブランチに忘れずにプルしておく。以上でコンフリクトの解決は終了。
作業するブランチを誤ってしまった
「ブランチを切り替え忘れて作業してしまった！」という事態は誰しもが通る道である。今回もgit-appを用いる。
ブランチを作成し忘れて作業してしまった時の対処法
「edit-readmeブランチで作業すべきだったのに、そのブランチを作成し忘れて、masterで作業してしまった」 というシチュエーションを想定する。ブランチを間違えてしまうと一時は絶望的な気持ちになるかもしれないが、実はトラブルシューティングは非常に簡単。GitHub Desktopを用いた対処法を覚えておく。
変更修正を本来あるべきブランチに移動
まず、masterにいることを確認して、以下のようにREADME.mdを修正。
README.md
1 2 |
# README
## how to use GitHub Desktop
|
GitHub Desktopで確認。masterブランチに変更修正が記載されてしまっている。
本当はこの変更修正はedit-readmeブランチで実施したかったもの。
そこで以下のように無理やり、新しいブランチの作成を試みる。
edit-readmeというブランチを作成。
すると、2つの選択肢を求められる。
[上側] 今ある変更修正を一度放置して、ブランチを移動する
[下側] 今ある変更修正を携えて、ブランチを移動する
今回は下側を選択。
すると、先程の修正変更ごと新しいブランチへ移動できている。簡単！
新しいブランチに移動させない変更修正はコミット
「この変更修正はこのブランチで、一方この変更修正は新しいブランチで」といった場合には、前者はコミットしておく。ブランチを移動してもコミット済みの変更修正は移動しない
コミット済みの変更修正を移動したい場合はundoする
コミット済みの変更修正を別ブランチに移動したい場合は、undo ボタンをクリックする。すると、コミット前のインデックスに登録されただけの段階まで戻すことができる。この状態でブランチを移動すれば、変更修正も一緒に移動できる。
誤った情報をプッシュしてしまった
gitにおいて、プッシュした情報をローカルリポジトリに戻すことはできない。したがって、プッシュする前に作業をしているブランチは正しいのかどうか、必ず確認するようにする。
それでも間違ってプッシュしてしまうことがある。ローカルリポジトリにその情報は戻せないものの、リモートリポジトリにある誤ったコミット情報は打ち消す必要がある。なぜならば、十分に内容が精査されていない情報がデプロイされてしまい、本番環境で思わぬバグを引き起こす可能性があるから。
そんな時に有用なのが、git revert。
git revertについて
git revert
コミットを打ち消すコミットを生成する操作が行なえる。プッシュ済みのコミットを消す方法もあるが、git revertでは誤りであるコミットを打ち消したコミットの記録が残る。
git revertを実行
まずはmasterブランチで以下のような修正をする。
README.md
1 2 3 |
# README
## how to use GitHub Desktop
## how to use git revert
|
コミットしてプッシュする。するとリモートリポジトリでmasterにコミットが記録されてしまっている。masterのREADME.mdを確認すると先程の追加が反映されてしまっている。
先程のコミットを打ち消すには、コミットIDが必要となるため、git logコマンドでコミットの履歴を確認。
ターミナル
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ git log # logの結果は各環境で異なります。
commit 4c695e4565c5718558c260c20d7e6eb57f3ee6c1 (HEAD -> master, origin/master)
Author: user <user@user.com>
Date: Wed Jun 26 10:44:26 2019 +0900
Update README.md
commit 0cb4947de8ef140a34d1d7bbdcc0b5afc7956acd (stash-test)
Author: user <user@user.com>
Date: Wed Jun 26 10:04:51 2019 +0900
Update README.md
（以下省略）
|
最上部のlogが最新のコミットを表す。対象となるコミットは4c695e4565c5718558c260c20d7e6eb57f3ee6c1となる。
以下のようにgit revertコマンドを実行。
ターミナル
1 |
$ git revert 4c695e4565c5718558c260c20d7e6eb57f3ee6c1
|
するとターミナル画面が編集できなくなる表示になるが、:qと入力すると脱出できる。
GitHub Desktopを確認。
git revertで生成したコミットが確認できる。こちらをpushする。するとリモートリポジトリでは以下のように先程の変更修正が打ち消されていることが確認できる。
これがrevertコマンドの基本的な使い方である。
git revert後にやること
git revert実行後、revertしたコミットの内容はローカルからも消えている。つまり、同じような記述を再度commit&pushしたい場合は、もう一度最初から当該コミットのコードを書きなおす必要がある。push前の状態に戻されるわけではない。ゆえに、リモートへのpushは慎重に行う。
GitHubトラブルシューティングの際の心得
GitHubには上記で紹介した以外にも、様々なコマンド、様々なオプションが存在する。何か操作に誤りがあった場合に、パニックになって様々なコマンドを試してしまうことがあるが、場合によっては取り返しのつかない状況になる（貴重なコードが消えるなど）こともあるので、十分注意する。一方で、トラブルシューティングを経験することで、GitやGitHubの概念を早く身につけることが可能である。もし何か試してみたいことがあった場合は、git-appのようにミニアプリを用意して試してみるのが良い。
