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

こんにちは。Webエンジニアの毛利です。


今回はGitHubについての話です。
GitHubではソースやファイルを管理するとき、複数の更新者が同時に更新しても変更点のみが蓄積されていくのでファイルをサーバーから直接ダウンロードしたり、そのためファイルの受け渡しや、最新版かどうかを確認したり、間違えて古いファイルを編集してしまった場合のリカバリーなどの必要がなくなるため、ファイル管理の手間が大きく減少します。

ただ、一方で問題も起こります。


よく発生する問題が「コンフリクト」です。

今回この「コンフリクト」がどの場合にどういう風に起こるのか、デスクトップアプリを運用してわかったことをまとめていきます。
また「コンフリクト」以外のトラブルに関しても「commit」、「syncできない！」「デスクトップアプリケーションが動かなくなった！」などといった問題を「Github Desktop」アプリケーションで運用する際、解決する際に、役立ちそうな方法をご紹介します。

コンフリクトとは？

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

どのような場面で起こるのか？

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

どうすれば解決できるのか？

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

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

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

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

コンフリクトを起こす「Github」運用4選

ローカルリポジトリから最新ファイルを取得しないで編集する

長い期間編集しておらず、他編集者が変更を加えていた場合、変更をリモートリポジトリから取得せずに編集を続け「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の反映前にアプリケーションで別の操作を行った、大きいファイルをリモートリポジトリから取得したときなど アプリケーションがエラーを起こしたり操作不能になる場合があります。

エラーの場合

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

アプリケーションを再起動しても復帰しない

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

パソコンの再起動をしても復帰しない

この場合はローカルリポジトリのデータを一度削除し、再びクローンする必要があります。

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

削除完了後、アプリケーションを起動し、再びリポジトリをクローンします。

まとめ

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