フィーチャーブランチの作業中に何をすればいいのですか？マスターをフィーチャーブランチに引っ張ったりマージしたりせずにプロジェクトをコンパイルできませんか？ C＃プロジェクトのリポジトリに

Question

、

• 私はmasterブランチからの機能ブランチを作成し、その後、機能ブランチにいくつかの仕事をしてくれました。その時点で、私はgit addまたはgit commit私の仕事はまだありません。

• 変更を加えたC＃プロジェクトをコンパイルできるかどうかを確認しようとしましたが、できませんでした。私はその後、いくつかの同僚がマスターブランチを変更したので、マスターブランチをチェックしてgit pullを実行してマスターを私のフィーチャーブランチにマージしました。そこで私はマージ競合を手動で解決しました。その後、C＃プロジェクトをコンパイルすることができました。この時点で、ステージングされていない変更は、マージの競合を解決するために自分の作業と私の手動による変更で構成されていました。

• 次に、フィーチャーブランチの作業を続けました。私が終了した後、私はgit addとgit commitを実行して、機能ブランチに関するすべての作業とマージの競合を解決するための変更からなる新しいコミットを作成しました。そして私のフィーチャーブランチをGitHubにプッシュし、それをGitHub上のマスターにマージするプルリクエストを作成し、プルリクエストをレビューする共同編集者を割り当てました。

Now I realize it is bad for the reviewer to distinguish my work on the feature branch from my changes to resolve the merge conflict in the single commit, and it is better to create different commits to separate the changes for merge conflict and my work on the feature branch.

私は再び機能ブランチで作業の途中で同様のケース（つまりが発生した場合は、私がマスターを引き出し、それをマージすることなく、私のプロジェクトをコンパイルすることができないことがわかりますフィーチャーブランチ）、私はマージの変更と私の仕事の変更を別のコミットに分ける方法がわかりません。 私は何をするでしょうか？

ありがとうございました。

Answer 1

この回答には2つの部分があります：1.手元の状況を修正する方法、2.今後同じ問題を回避する方法。これらの2つの部分は全く異なるアプローチを必要とします。

---

手元の状況を修正してください。

問題は、すでに他のコミットに含まれていた変更を含むコミットが公開されていることです。後でマージの競合が発生するため、これは悪いことです。

状況を修正するには、右の基本コミットからフィーチャーブランチを再作成する必要があります。あなたは、次のコマンドでこれを行うことができます。このシーケンスでは

git checkout feature-broken 
# git status to ensure that the working directory and index are clean 
git reset --mixed <the-commit-you-actually-want-to-base-your-work-on> 
# git status and git diff, to see what changes your feature branch actually wanted to introduce 
git checkout -b feature-repaired 
git add ... 
git commit ... 

を、あなたはあなたの壊れた機能ブランチはそれを置くとして、作業ディレクトリの状態を取り、別のを作成し、まったく同じ内容とが異なるとコミット親コミット。それはあなたが必要とするすべての修正です（もちろん、feature-brokenを引っ込めることは別として）。

私は確かではありませんが、あなたが実際に使用したいと思っています。あなたの質問は、あなたが壊れている機能ブランチにコミットしたことがないように思えます。その場合、使用する基本コミットはmasterになります。壊れた機能ブランチで既にコミット済みの作業を行っている場合は、変更をマージしてコンフリクトを解決するマージコミットが作成されます。その場合は、先にコミットされた変更に対してクリーンマージコミットを作成してから、その新しいコミットに基づいてgit reset --mixedをベースにする必要があります。

---

今後これを回避する方法。

答えはgit stashです。アップストリームの変更を取り込む前に、git stashを発行して、ローカルな変更を取り除くだけです。作業の基盤となる正しいコミットが完了したら、git stash popを実行して、ローカルの変更を元に戻します（遭遇したマージの競合を修正します）。