私は私のチームに機能主導型の開発を導入しようとしています。私たちはgitで作業しており、私たちは仕事のためにトピックブランチを作成し始めました。私が理解しているところでは、すべての機能やバグに対してトピックブランチを作成し、ブランチは「短命」であると考えられます。小チェンジセットのgitのトピック分岐？
私たちのワークフローでは、発見した各バグ（そして、今のところ紹介したい機能だが）の問題を作成し、マスターから派生するブランチを作成して変更を加え、 &をコミットして、コードレビュー後にプル要求をマージします。
これまでのところうまくいきましたが、バグ修正が数行（2-3など）であった場合は2つありました。私は開発者にブランチを作成するように指示しましたが、これは過剰なもの、つまり数行のコードと1つのコミットのブランチを作成するようなものです...
このような場合には、マスターブランチでブランチを作成するのではなく、少し変更するだけでマスターブランチで作業する方が良いでしょうか？
Gitの支店は非常に安いです。エクストラを作成することはめったにありません。人々はそれらを作る義務を感じるべきではありませんが、それはデフォルトでなければならず、自明ではないと判明したものを作ったために愚かではありません。
コミットをブランチに「移動」することは可能ですが、発行していない（他の人がそれをフェッチできるようにしている）限り、可能です。たとえば、最初にこれを持っているとします。
次に、最初にブランチを作成せずに何かを修正します。あなたはDをコミット新しいます
...--A--B--C <-- origin/master
\
D <-- HEAD -> master
が、その後、あなたはこれが十分でない、または間違った修正で、これはブランチfix-xxxあるべきかを決定発見します。
...--A--B--C <-- HEAD -> master, origin/master
\
D <-- fix-xxx
を：ちょうど与えて、（あなたが今masterに残っているので、例えば、git reset --hard HEAD~1を使用して）Cをコミットするために戻って指すようにmasterを設定し、その後、（例えば、branch fix-xxx masterを使用して）Dを指し示す新しいブランチラベルを追加今、あなたはgit checkout fix-xxx置くために戻って作業ツリー内とfix-xxxを指すようにHEADを設定Dをコミットすることができます：あなたはを作成したかのように
...--A--B--C <-- master, origin/master
\
D <-- HEAD -> fix-xxx
、それすべてが見えます最初にを呼び出し、コミットをDにしました。
つまり、これは両方とも両方の方法で動作します。可能な限りフリーに近いブランチを自由に作成できますが、それらを作成せずにコミットを移動することができます。ちょうど周りの枝ラベルをシャッフルしただけです！）。プログラマーは、彼らのために何でもできます。
最初の分岐を作り、その後、後でそれを必要としないの大きな利点は、これが最初の分岐を作り、その後、後でそれを必要としないより少ない仕事であるということです。また、git reset --hardの手順は大変危険です（最初に作業ツリーがきれいであることを確認する必要があります）。
あなたはこれらのリンク私の側に
に見ることができ、私はマスターや開発ブランチにバグをコミットすることをお勧めしてからプッシュする前にリベースでしょう。分離されたブランチとそれに続くマージは、新機能またはマイナーリリースでのみ使用する必要があります。私はそれが多くのマージする必要がある歴史を壊すと思う。
例
(master) Init --- Bug1 --- Bug2-- merge -- HEAD
(featureA) \--- 1 --- 2 -------/
私はそれがあなたのチームの設定に依存しますね。ローカルのコンピュータに1つの中央リポジトリをクローンしている場合、コードレビューとバックアップの目的で、自分の機能に分岐する必要があります。すべてが独自の中央クローン（github forksのようなもの）を持っていれば、コードレビューを行う独自の中央リポジトリにすべてを押し入れることができるので、大きなメリットはありません。 –