Skip to main content

GitHub でのチームの共同作業

学習の目的

この単元を完了すると、次のことができるようになります。

  • GitHub ワークフローをチームの効率的なブランチ戦略に変換する。
  • GitHub のマージ競合を解決する。
  • 単一の作業単位を表すアトミックコミットを作成する。

GitHub のブランチ機能のイラスト。

機能するブランチ戦略

独自で作業する場合の GitHub の簡単なサンプルフローを実行しましたが、このワークフローがチームではどのように機能するのかを想像してみてましょう。ブランチ、コミット、およびプルリクエストの数が、チームの人数や進めている開発の数に応じて倍増します。現在までに多数のチームがこれを経験しており、成功パターンが蓄積されています。

一般にブランチは、1 つの機能を完成させる目的で短期的に使用され、マージ後に削除されます。ブランチを短期的に用いることで混乱を防ぎ、コードを最新の状態に保ち、開発者がプロジェクトを反復的な方法で改良できるようにします。

長期的なブランチは、慎重に使用しなければ問題が生じるおそれがあります。開発ブランチや、コードに複数の開発レベルが必要な状況などでは、長期的なブランチが適していることもあります。長期的なブランチの問題の大半は、開発者の各ブランチが最新バージョンでないため不必要なマージ競合や混乱、作業が生じることに起因します。ブランチワークフローを複雑にすれば問題が解消されるように思えるかもしれませんが、複雑になり過ぎることが少なくありません。GitHub フローはシンプルなほど効率的に機能します。

ブランチについてチームに以下のような質問をします。

  • どのブランチ戦略を採用するのか?
  • どのブランチをメインにするのか? リリース済みのコードであるブランチはどれか?
  • ブランチに命名規則を採用するのか?
  • ラベルと担当者をどのように使用するのか?
  • マイルストーンを使用するのか?
  • プロジェクトボード (プロジェクト) を使用するのか?
  • イシューまたはプルリクエストに必須テンプレート/要素を設定するのか (出荷チェックリストなど)?
  • プルリクエストにサインオフをどのように表示するのか?
  • プルリクエストを誰がマージするのか?

前述のとおり、ブランチの最大のメリットは、安全な場所で変更を行えること、そしてプルリクエストでレビューやテストを実施できることです。チームがブランチに何を期待しているのかを判断したら、できる限りコンパクトでわかりやすいものにします。コラボレーションを重視します。

マージ競合を処理する

チームで共同作業するときに (時として単独で作業するときにも)、マージ競合が生じることがあります。最初はマージ競合に怖じ気づくかもしれませんが、実際のところ、ごく簡単に解決できます。 

では、マージ競合を作り出して、どうなるかを見てみましょう。

コミットが競合する複数のブランチを作成する

ご存知のとおり、マージ競合が生じるのは、別々のブランチの同じファイルの同じセクションに複数のコミットが存在する場合です。そこで、競合の解決を練習するために、コマンドラインを使用して競合を設定してみましょう。2 つの異なるブランチを作成し、各ブランチの README.md ファイルに変更を行います。ローカルリポジトリは、メインブランチにあるはずです。

  1. 新しいブランチ (new-branch-1) を作成します。
    git checkout -b new-branch-1
  1. リポジトリの README.md ファイルに変更を加えます。どの行を変更したのかをメモしておきます。
  2. ステージングに変更を追加します。
    git add README.md
  1. 変更をコミットします。
    git commit -m "Changes to the README"
  1. GitHub Desktop で、[Publish branch (ブランチを公開)] をクリックします。
  2. GitHub を開いて、このコミットのプルリクエストを作成します。

次に、2 つ目のブランチを作成して、README.md ファイルを更新しましょう。まず、コマンドラインを使用してメインブランチに戻ります。

  1. もう一度メインにチェックアウトします。
    git checkout main
  1. 2 つ目のブランチ (new-branch-2) を作成します。
    git checkout -b new-branch-2
  1. README.md ファイルの同じ行に変更を加えます。
  2. ステージングに変更を追加します。
    git add README.md
  1. 変更をコミットします。
    git commit -m "More changes to the README"
  1. GitHub Desktop で、[Publish branch (ブランチを公開)] をクリックします。
  2. GitHub を開いて、このコミットのプルリクエストを作成します。

1 つのプルリクエストをマージする

この時点では、まだどちらのブランチにもマージ競合が表示されていません。GitHub で、(new-branch-1) の 1 つ目のプルリクエスト “Changes to the README” をマージして、メインブランチを更新します。

ほかのブランチの競合を解決する

new-branch-1 のプルリクエストをマージしたら、new-branch-2 のプルリクエスト “More changes to the README” に移動します。 

GitHub のマージ競合を示すスクリーンショット。

マージ競合が生じていることがわかりますね。焦ることはありません。解決できます。マージ競合がどのくらい複雑なのかによって、GitHub のブラウザーで解決可能な場合もあれば、ローカルで解決する必要がある場合もあります。

ローカルで解決するには、メインをブランチにマージして、競合を解決してからマージを完了します。

  1. 競合の存在が示されていれば OK です! git status と入力して、どのファイルに競合があるのかを確認します。Unmerged Paths の下に、競合のあるファイルがリストされます。
  2. テキストエディターで該当するファイルを開き、マージ競合のマーカー。(<<<<<<<, =======, >>>>>>>)
    “”
  1. ブランチの両方のバージョンのコードが表示されています。残すコードを選び、もう一方を削除します。Git によって作成されたマージ競合のマーカーを削除して、変更を保存します。
    “”
  1. マージ競合を解決するために保存された変更を追加してコミットします。
    次のコマンドを入力します。
    git addREADME.md

    Enter command:
    git commit -m “Commit to resolve merge conflict”
  1. GitHub Desktop で、[Publish branch (ブランチを公開)] をクリックします。
  2. GitHub のプルリクエストに戻ります。この時点でプルリクエストに競合はありません。競合のないブランチのスクリーンショット。
  1. プルリクエストをマージします。

上記のブランチを処理したら、GitHub の該当するブランチを削除し、git checkout main と git pull コマンドを使用してローカルリポジトリを同期させます。

アトミックコミットを作成する

参照可能で有益なプロジェクトの履歴を作成するにあたって、重要な要素となるのが、アトミックコミットの作成です。

理想とするのは、履歴の内容を確認したり変更したりする必要がない世界です。残念ながら、そんな理想的な世界は望めないため、必要に応じてバージョン管理によって変更履歴を確認できるようになっています。コミットはそれぞれ、小規模で論理的な変更単位であり、リポジトリのストーリーを伝えるものです。

では、アトミックコミットの作成に役立つ git add --patch というコマンド (短縮形は git add -p) の使い方を練習してみましょう。このコマンドは、ファイルの各部をステージングエリアに追加することができ、真に論理的な変更単位をコミットする場合に役立ちます。

  1. bigFile.md をコンピューターにダウンロードします (場合によっては、右クリックして [対象をファイルに保存] を選択する必要があります)。
  2. GitHub で、bigFile.md を best-repo-ever リポジトリのメインブランチにアップロードします。
    1. [Upload files (ファイルをアップロード)] をクリックします。
    2. コンピューターで bigFile.md を選択します。
    3. [Commit directly to the main branch (メインブランチに直接コミット)] を選択します。
    4. [Commit changes (変更をコミット)] をクリックします。
  3. ローカルのメインリポジトリが最新の状態であることを確認します。
    次のコマンドを入力します。
    git checkout main

    次のコマンドを入力します。
    git pull
  1. Git で追跡している内容を確認します。
    git status

    コミットするものが何も存在しないことがわかります。
  2. bigFile.md の 1 行目と 100 行目に変更を加えます。(変更内容は何でも構いません)。
  3. --patch フラグを使用して、いくつかのファイルの一部をステージングエリアに移動します。
    git add -p
  1. [y] を押してハンクをステージングします。これは変更単位に対する Git 言語です。

ハンクにどのようなオプションがあるのか気になる場合は、? を使用すると、ハンクの上にオプションリストが表示されます。

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む