最初にマスターを別のブランチにマージし、その後それをマスターにマージし直すのは間違いではないかと思っています。
それぞれ別のコミットを持つ次のブランチを作成するとします。
mkdir git_merging
cd git_merging/
git init
touch on_master
git add .
git commit -m "Initial commit on master"
git checkout -b x
touch on_branch_x
git add .
git commit -m "Initial commit on branch x"
git checkout master
touch on_master_again
git add .
git commit -m "Commit on master after branching"
ここでマージします。通常は、まずマスターを x にマージし、次に x をマスターにマージします。
git checkout x
git merge -m "Merge master into x" master
echo "test results"
git checkout master
git merge x
こうすることで、マスターにマージする前にテストすることができ、常に機能するマスター ブランチがあることが保証されます。私の知る限り、x をマスターに直接マージする場合と比べて機能上の違いはありません。
git merge -m "Merge x into master" x
git checkout x
git merge master
しかし実際には、マスターに排他的にマージバックするリポジトリによく遭遇します。私のアプローチには欠点がありますか? これを行わないほうがよい理由はありますか?
ベストアンサー1
これはかなり主観的な質問ですが、かなり客観的な答えが思いつくと思うので、無視します。
それは素晴らしいマージする前に、マスターを自分のブランチにマージし直す練習をしてください。もし誰かがコミットして、あなたが実装した機能を壊してしまったらどうしますか（あなたが指摘したように）？ あるいは、誰かがあなたと同じコードを変更して、マージの競合を引き起こしてしまったらどうしますか？ 私は実際に、マスターを自分のブランチにマージし直すことをお勧めします。非常に頻繁にこれにより、マージの競合を解決するために 1 日半を費やす必要がなくなるだけでなく (ただし、これはブランチが大きすぎることを示している可能性がありますが、それは別の話です)、プロジェクトの変更や進化に合わせて対応できるようになります。
こう言う人もいるかもしれないリベースコミットをマスターの上に置きます。簡単に言うと、機能が完了していなくても、開発プロセスの非常に早い段階でプル リクエストを開くことをお勧めします。つまり、コードをリモート サーバー (GitHub など) にプッシュすることになります。コミットをリベースするには、書き換えた git 履歴でプッシュし、強制プッシュする必要があります。強制プッシュはワークフローの決定としては不適切であり、コミット履歴に (ほぼ) 永久的な損傷を与える可能性があるため、避けるべきです。
ですので、マージする直前にマスターからマージし、それ以外の場合はできるだけ頻繁にマージしてください。GitHubを使用している場合は、新しい保護されたブランチ機能を使用して強制するマージする前にマスターでブランチを更新します。
