コンフリクト、エラーに対応しよう！GitHub運用実践編

「変更の競合」を指します。複数人で同じファイルを編集し、同じ箇所を変更したり、編集者が記述の順番を大きく変えたりなど変更があったとき、変更をマージできなくなる現象です。

「GitHub Desktop」の場合、変更点をリモートリポジトリにCommitをpushするときに起こります。
具体的な操作方法は変更点を「Commit」し、「Sync」するときに発生します。
コンフリクトが発生すると、黄色で示されます。

この状態になったら、一度Commitを「undo」し操作を取り消し、もう一度「Sync」を押します。
そうすると、コンフリクトを起こしたファイルに以下のようなメッセージが入ります。

========の上に表示されているのが「リモートリポジトリ」の変更点で、
========の下に表示されているのが「ローカルリポジトリ」自分が行おうとしている変更点です。
「GitHub Desktop」のアプリケーションでは基本的に==の下が自分が行った変更点として表示されます。

これらは内容を確認し、手動で修正する必要があります。
リモートリポジトリに反映した作業者に確認が必要な場合は確認をしてから変更を行うようにしましょう。競合箇所を修正し、再度「Commit」、「Sync」することでコンフリクトを解消できます。

※コンフリクトが起こったファイルを修正せずに、そのままCommitしリモートリポジトリにpushしてしまうとエラーの文言が入った状態で「正しいデータ」として反映されてしまいます。
コンフリクトが起こった場合は必ずソースを確認し、手動で修正する必要があります。
Githubから出されるメッセージはよく確認しましょう。

長い期間編集していなかったり、他の編集者が変更を加えていた場合、変更をリモートリポジトリから取得せずに編集を続け「Commit」してしまうと高確率で起こります。
作業開始前には必ず「Sync」し、ローカルデータを最新化しましょう。

同じソースの同じ箇所を編集していると起こります。
共同作業者と連絡が取れる場合、自分がどこを編集するか伝えましょう。
編集箇所が競合する場合、作業のタイミングをずらしましょう。

リポジトリからデータを取得するのではなく、Webを公開しているサーバーなどからデータを取得して反映した場合に起こることがあります。
あまりこのような事を行うことはないと思いますが、サーバーOSによっては改行コードが変わってしまったり、見えないところでファイルの情報が変わってしまい、Githubのリポジトリデータとは全く同じデータではないかもしれません。

改行コードが変わると全行変更扱いになります。また、CRは基本的に認識されません。
（改行が反映されているはずなのにGithub上では全て1行に見える場合はこの状態になっている場合が多いです。）
改行コードはCRLF（Windows）、LF（Mac OSX、Linuxなど）が標準的です。

コンフリクト以外にデスクトップアプリケーションのエラーがあります。
運用していて比較的起こりやすいエラーについて以下にまとめてみました。

最近ではutf-8がほぼ定着しましたが、 Shift_JISで運用しているサイトもあると思います。「Github Desktop」では、Shift_JISだと文字化けを起こしたり、意図した動作にならない場合があります。

大きいサイズのファイル、または大量のファイルをリモートリポジトリに反映するとき、時間がかかったり、通信エラー、タイムアウトエラーが起きやすくなります。 通信環境に依存する部分でもありますが、GBを超えるデータを反映したり、数千のファイルを一気に反映するのはできる限り避けましょう。 ファイル数が多い場合、多少手間となりますが何回かに分けてCommitするとエラーを回避できます。

大きいファイルをCommitしようとして処理が終わらない、undoの反映前にアプリケーションで別の操作を行った、大きいファイルをリモートリポジトリから取得したときなど アプリケーションがエラーを起こしたり操作不能になる場合があります。

操作不能の場合、一度強制終了し、アプリケーションを再起動します。

アプリケーションを使用しているパソコンの再起動をしてみましょう。処理途中のものがキャンセルされることで復帰できる場合があります。

この場合はローカルリポジトリのデータを一度削除し、再びクローンする必要があります。
1.アプリケーションを終了
2.ローカルリポジトリファイルをゴミ箱に入れ消去
※削除するときはリポジトリをクローンしたフォルダごと削除（隠しファイルが残っている場合があるため）
※ゴミ箱に入れたファイルが使用中で消去できない、またはゴミ箱に入らない場合、パソコンを再起動
3.再起動後、残ったファイルを消去し、削除完了後、アプリケーションを起動し、再びリポジトリをクローン

いかがでしたでしょうか？
今回はGitHubの運用に関して実務的な面からアプローチしていきました。
これらの便利な仕組みも必ずエラーや予期しないことが起こります。
エラーが起きた際、どう対処するか、落ち着いて的確に行わなくてはなりません。
いざ起こったときに慌てないように、こういったパターンを想定しておけば落ち着いて適切な対処ができるはずです。
より円滑に、より快適に開発運用するためにはノウハウを蓄積していくことが大変重要です。
ノウハウを少しずつでもためていき、より良い運用が行えるようにしていきましょう！

参考： リモートリポジトリにプッシュする

参考：競合の解決

参考：コンフリクトの解消