前回のブログでは、Git (バージョン管理システム) と Github (クラウドベースのホスティングサービス)、そして 4Dコードを他のデベロッパーと共有する方法について紹介しました。このブログ記事では、リモートリポジトリのクローン、コミット済みのファイルの無視、マージにともなう競合の解決など、開発者が遭遇する可能性のあるシナリオについてもう少し踏み込んで説明します。
前提条件
この先の内容は、プロジェクトデータベースを作成したり、バイナリデータベースをプロジェクトに変換したりする方法を知っていることを前提としています。Git がマシンにインストール済みで、Github にアカウントを持っていることは必須です。もしまだ持っていない場合は、このブログの記事を参考に進めてください。
リモートリポジトリをクローンする
前回例題として使ったアプリケーションの作業を再開しましょう。しかし、何らかの理由で、前回作業したプロジェクトがマシンにありません。どうすればいいのでしょう?
GitHub でリポジトリを作成したので (前回のブログ記事)、そのプロジェクトはリモートリポジトリとして存在します。今度は、このマシンにローカルコピーを作成し、リモートとローカル間で同期をとる必要があります。
- Github のアカウントに接続します。
- リポジトリのメインページに移動します。
- Clone or download ボタンをクリックし、クリップボードのアイコン (下の画像参照) をクリックします:
- ターミナルを開き、ディロクトリをクローンする場所を開きます。
- git clone と入力し、手順3 でコピーした URL を貼り付けます。
これで、マシンにローカルコピーが作成されました！
gitignore
特定のファイルやフォルダーを git に追跡させたくない
プロジェクトの中に、追跡されたくないファイルやディレクトリがある場合があります。そこで、.gitignoreファイルが役に立ちます。その名のとおりこのファイルは、リポジトリから無視すべきファイルやディレクトリ、パターンを Git に指示します。
この例では、Dataフォルダー (journal、.4ddを含む)、preferences、DerivedDataフォルダーを無視するように指示します。
- .gitignore を作成します:
- 無視するファイルやフォルダーを設定します:
.gitignore は、ファイル名の比較にグロビングパターンを使用します。さまざまな記号を使ってパターンを作成することができます。たとえばフォルダーを丸ごと無視するには、フォルダー名の末尾にスラッシュをつけます。.gitignore のパターンについては、こちらの記事を参照ください。
すでにリポジトリにコミットされているファイルを無視する
新しいリポジトリを作成するときには、無視したいファイルパターンについて .gitignoreファイルをあらかじめ作成しておくのがベストです。しかし、後になって無視したいファイルが紛れ込んでしまったときはどうすればよいでしょう。
大丈夫、慌てないでください！ いくつかの簡単なステップで、リポジトリをクリーンアップし、これらのアイテムを無視するようにすることができます:
- リポジトリからファイルを削除するためにステージしながら、ファイルはローカルに残すようにします: git rm -r –cache
- 作業ディレクトリ全体を確認して、新しいファイルや削除されたファイル、変更されたファイルを探し、インデックスに追加します: git add
- ステージングエリアにあるファイルをローカルリポジトリに送ります: git commit -m “Clean up ignored files”
- 変更をリモートリポジトリに送信します: git push
これで、リモートリポジトリではファイルが存在しなくなったことを確認できます！
重要な注記: あとから無視されたファイルはリポジトリの履歴に残ります。新しいリポジトリを作成する際に、無視したいファイルやフォルダー、パターンをすべて示す .gitignoreファイルをあらかじめ作成しておくべきなのは、このためです。あとから、特定のファイルを無視することにして、それを履歴にも残したくない場合、Github からリポジトリを削除して再度プッシュする必要があります。
マージコンフリクトを解決する方法
コンフリクトが発生した時は、まず第一に冷静になりましょう。
複数のデベロッパーが同じバージョン管理システムで作業している場合、コンフリクトの管理は日常茶飯事です。いくつかのオプションがあります。コンフリクトは、4Dエディターを使って簡単に解決できますが、すべてのファイルがテキストベースになったので、テキストエディターを使って解決することもできます。さらに、GIT に統合可能な多くのマージツールがあります。以下の例では、4Dエディターを使ってコンフリクトを解消しています。
4Dメソッドのコンフリクトの例を見てみましょう。これには、2人目のユーザーをシミュレートする 2つ目のローカルリポジトリが必要です。そのため、データベースフォルダーを複製して、プロジェクトメソッドを 1つ以上持つようにします。ここでは、my4DApplication と my4DApplication2 という 2つのデータベースフォルダーを用意しました。次に、両方のアプリケーションを開きます。
-
- 最初のアプリケーションでプロジェクトメソッドを開き、何らかのコンテンツ (たとえばコメント) を追加します。
- git status を実行すると、メソッドの変更が検出されます。新しい変更をコミットしてプッシュします。
- シナリオ: 他の誰かが同じメソッドを、同時に変更するケースをシミュレートしてみましょう。2つ目のアプリケーションで同じメソッドを開き、違うコメントを追加します。
- 新しい変更をコミットしてプッシュします。ご覧のとおり、プッシュは拒否され、代わりにプルが提案されます:
- 提案された git pull を実行しても、解決になりません:
- 最初のアプリケーションでプロジェクトメソッドを開き、何らかのコンテンツ (たとえばコメント) を追加します。
さてどうすればいいでしょう？
ここで、コンフリクトが発生しているメソッドを開いてみましょう。HEAD 側の行がローカルでの変更、そして赤の文字列 (別ユーザーが行ったコミットの番号) 側の行がコンフリクトを起こしているコミット済みの内容です。
コンフリクトを解決するのは簡単で、コードの正しい部分を選択して変更をプッシュするだけです。ここでは、両方の ALERT メッセージをそれぞれのコメントとともに残しています。
完了後、リモートリポジトリへ再度プッシュすれば、もう一人のユーザーも git pull を実行して新しい変更を取得することができます。これで、どちらのユーザーもメソッドを同じ内容で確認することができます。
そもそもコンフリクトを避けるために
常にコンフリクトを回避できる確実な方法はありませんが、git fetch を実行すればマージの手間を省くことができます。これは、リモートリポジトリに新しいコミットがあるかどうかをチェックするものです。プッシュする前にこれを行わなかったために、[Rejected] というエラーが発生したのです。
おわりに
この記事では、開発者が Git を使っているときに遭遇しそうなさまざまなシナリオについて説明しました。次回の記事では、コマンドラインから離れ、GUI クライアントを使用して Git を操作する方法を紹介します。