ブランチをすばやく切り替えて何かを実行してから、以前に取り組んでいたものに戻りたいので、これは面倒です。スタッシュしてからスタッシュを取得できることはわかっていますが、毎回それらの行を入力する必要があります:/
これを回避する方法はありますか?
また、私は約 5 または 10 個のフィーチャー ブランチを保持していて、どれが取得する必要があるスタッシュを持ち、どれがそのまま作業を続けるのに適しているかを管理するのが難しくなるため、面倒です。
ブランチをすばやく切り替えて何かを実行してから、以前に取り組んでいたものに戻りたいので、これは面倒です。スタッシュしてからスタッシュを取得できることはわかっていますが、毎回それらの行を入力する必要があります:/
これを回避する方法はありますか?
また、私は約 5 または 10 個のフィーチャー ブランチを保持していて、どれが取得する必要があるスタッシュを持ち、どれがそのまま作業を続けるのに適しているかを管理するのが難しくなるため、面倒です。
git checkout
の--merge
( -m
) オプションを使用できます。
これを使用すると、ブランチを切り替えるときに 3 方向のマージが行われます。これらが発生した場合、マージの競合を解決する必要がある場合があります。
なぜこのようなことが起こるのかについては、マニュアルには次のように記載されています
ブランチを切り替えるときに、現在のブランチと切り替え先のブランチとの間で異なる 1 つ以上のファイルにローカルで変更を加えている場合、コマンドは変更をコンテキストに保持するためにブランチの切り替えを拒否します。
詳しくはgit checkout
マニュアルページをご覧ください
git stashを使用して変更を隠しておくことを回避できます。次に、ブランチを変更し、ブランチを復元して変更を元に戻すことができます。
$ git stash
$ git checkout other_branch
$ git checkout original_branch
$ git stash pop
私は毎日あなたと同じシナリオにいることに気づきます:
私は 5 つまたは 10 のフィーチャー ブランチを保持していますが、どのブランチに取得する必要があるスタッシュがあり、どれがそのまま作業を続けるのに適しているかを管理するのが難しくなります。
私にとって最も効果的な解決策は、最も単純なものでもあります(そして質問のタイトルでほのめかされています):
進行中の変更をコミットしてください!
私は常に実際のコミットを大文字で書きます (この一般的な標準に従います)。進行中のコミットはすべて小文字で始まるため、プッシュする前にインタラクティブなリベースが必要であることがすぐにわかります。したがって、誰かを助けるためにブランチを切り替える必要がある場合は、すべての変更をコミットし、次のようなコミット メッセージを使用します。
wip: 新しい CoolFeature API のラフ ドラフト
ところで、ブランチを変更するつもりがなくても、コーヒーを飲みに出かける場合は、同じコミットを行うこともあります。通常の一日を通して、私は次のようなメッセージを自分自身にコミットして書きます。
s into abcd123: First few words of that commit
f into bcde234: First few words of that commit
wip: rough draft of this thing
次回rebase -i
は自分の指示に従います (s=squash、f=fixup)。
読者のために熟考する質問:
答え:
1.「s」を使用する場合、それは、コミットに追加する変更に基づいて、コミットメッセージをスカッシュするだけでなく変更することを意味します。fixup の "f" は、コミット メッセージがそのままで十分であることを意味します。
2. 定期的にブランチのリベースを行い、ブランチを最新の状態に保ち、マージ先のターゲットに戻します。インタラクティブなリベースの前に最初にそれを行った場合、コミット ID は変更されますが、代わりにコミット タイトルと一致させることができます。
これは実際には問題の 1 つの解決策ですが、各 stash にメッセージを追加して、どの stash がどのブランチに属しているかを知ることができます。そうすることで、どのブランチに隠し場所があり、どのブランチにないかを常に簡単に知ることができます。
これを行うには、次のコマンドを使用します。
git stash save -u branch1
ここで、'branch1' は、stash に付けるメッセージまたは名前です