1

コードリポジトリには git と github を使用しています。私の契約開発者の 1 人は Windows を使用していますが、残りはそうではありません。Windows 開発者は、プロジェクトを Windows で動作させるために、さまざまなファイルにいくつかの変更を加える必要がありました。これらの変更を master ブランチにマージしてはなりません。これらの変更以外に、彼はコミット (以前に Windows 固有のコミットを行った可能性のあるファイルへのコミットを含む) を行い、それを (私のレビューの後) マスター ブランチにマージして戻します。

これを解決しようとする私の最初の試みは失敗しています。彼のための特別なブランチ「windev」を作成し、origin に追加しました。彼は最初の Windows 固有のコミットを、リモート ブランチを追跡するローカルの windev ブランチに行い、その後、このブランチだけで作業を続け、プッシュしました。最初は、彼の Windows 固有のコミットを master ブランチにマージしたくないので、彼の関連するコミットだけを選んでみようと思いました。これは、マスター ブランチに適切なコミットを取得するためにうまく機能します。問題は、彼が master からの自分の windev ブランチを定期的に更新して、最新のコード ベースを保持する必要があることです。リベースを試すことから始めましたが、チェリーピックやウィンドウ固有のコミットをまったく処理できず、混乱を招くように見えました。だから、私は' コードを更新するたびに master ブランチからマージしてもらいましたが、問題は、私が選んだコミットごとに、ブランチに重複したコミットがあることです。また、これらの重複したコミットが不必要な競合や潜在的なコード損失につながっているのではないかと考えています。

私は彼とやり直す準備ができています. しかし、私はこの状況に最適なワークフローが何であるかを理解しようとしており、ちょっと混乱しています. 何か案は？(PS 彼は git を初めて使い、混乱しているので、彼のためにシンプルに保つようにしています。ワークフローの複雑な部分は自分で処理したいと思っています。)

4

2 に答える 2

3

Windows で動作させるために必要な変更のために永続的なブランチを構築windevし、彼が作成した機能ごとに (つまりmaster、ローカルで更新する必要があるたびに) 再構築するだけです。

これは実際よりも複雑に聞こえますが、Tomcat アプリ (つまりMETA-INF/context.xml、さまざまな運用環境用の複数のバージョン) で実行される同時実行の相互に排他的な構成変更のセットをうまく管理するために使用しました。

git checkout -B permanent master ;# check out a "permanent" branch
< make required windows changes and commit >
git checkout -B windev master ;# this is the branch he uses for new work
git merge permanent ;# merge 'permanent' into 'windev'

それで、彼はしばらくハッキングします。を使用しますcherry-pickが、これはあなたにとっては問題ありません。彼が にマージしmaster直す必要windevがあるとき、おそらく彼がある種の機能またはプロジェクトを完了し、あなたが彼の新しい仕事をチェリーピックしたときに発生すると思われますが、彼は単に発行します:

git rebase --onto master master permanent ;# rebase permanent onto newest master
git checkout -B windev master ;# reset 'windev' to 'master'
git merge permanent ;# and merge in the required changes

実際には、数日/数週間ごとに発行されるこれらの最後の 3 つのコマンドだけです。彼が非常に厄介で、ローカルに多くの WIP を保持している場合、または他のチーム メンバーの作業に大きく依存している場合は、十分ではない可能性があります。master彼がかなり孤立していて、論理的な作業ポイントでのみマージする必要がある場合、これは問題なく機能するはずです.

于 2012-08-10T18:55:05.220 に答える
0

作業ディレクトリを変更する前に変更を適用し、コミットする前に削除するために使用できるフックであるsmudge cleanに興味があるかもしれません。理想的には、これは単に Windows または Linux を示すフラグであり、アプリケーションは必要に応じてこのフラグを参照します。

私が見ることができる他のすべての可能性は非常に複雑に思えます: 彼は決してプッシュしないwindevブランチを持っており、これは永続的に/remotes/origin/masterに基づいてリベースされており、 masterブランチにコミットしていますが、変更を含むソフトを実行する前に常にwindevをチェックアウトする必要があります彼はwindevにしたので、あまり良くありません。

マスターでコミットするたびにマスターでwindevをリベースするフックなど、他のフックも価値があると思います。

于 2012-08-10T17:21:57.250 に答える