web-dev-qa-db-ja.com

Git機能ブランチを削除する適切なタイミングはいつですか？

82個の機能ブランチがぶら下がっている になりたくないので、マスターにマージしたらすぐに機能ブランチを単純に削除することの潜在的な欠点は何か疑問に思っています。

ワークフロー：

git co -b feat-xyz
hack hack
git ci
hack some more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz

ここに問題はありますか？

gitversion-controlbranch
77
bstpierre

マージ後の削除は通常の方法です。これが理由です git branch -dは、ブランチが削除される前に完全にマージされていることを確認します。

ブランチを保持する理由として考えられるものがいくつかあります。実稼働環境にバグが戻ってきた場合に備えて保持したい場合や、履歴を記録したい場合があります。

どちらの場合でも、ブランチのヘッドを削除する前にタグ付けするオプションがあります。タグは、いくつかの小さな違いを除いて、コミットへのポインタであるという点でブランチのようなものです：1）ポーセリンは、通常、チェックアウトでgit show-branchやtab-auto completeなどの探索コマンドでタグを表示しません、2） 1つをチェックアウトすると、切り離された（非参照）HEAD 3）になります。 " tagging message "を残すことができます。これにより、タグがコミットのようなオブジェクトストア内のオブジェクト。

この方法で履歴を保存し、バグ修正が必要になった場合は、修正のためにマスターから新しいブランチを作成することをお勧めします。

52
masonk

マージ後に削除しますが、常にgit merge --no-ff、ブランチの履歴がグラフに表示されるように、高速転送を回避します。私は、機能ブランチが開発ブランチから離れた場所と、それが戻ってきた場所の歴史を持ちたいです：

Merging with or without fast-forwards

これは、Vincent Driessenによる 成功したGit分岐モデル から取られています。これは、ほとんどのプロジェクトに適用するgitで使用する非常に素晴らしいワークフローです。

87
lkraider

機能ブランチを少しの間維持したい理由は2つあります。

  • アップストリームによるさらなる作業のために、あなたに追い返される可能性があります。
  • 他のすべての開発者は、おそらく他のすべてをマスターに求めることなく、その機能を望んでいます。

実際には、ほとんどの場合、マージ後に削除するだけで十分です。

7
Karl Bielefeldt

典型的なワークフローは

 // Create new branch
 $ git checkout -b myfeature
 // and then do some changes and commit them

 // Switch to master branch
 $ git checkout master

 // Merge myfeature to master. --no-ff will always keep branch information.
 $ git merge --no-ff myfeature

 // Delete myfeature branch
 $ git branch -d myfeature

 // Push the changes
 $ git Push Origin master
6
Fizer Khan

私はそれが典型的なワークフローだと思います（マージ後に削除する）

編集だから、マージよりも、少なくとも短命のブランチについては、マスターにリベースすることだと思います。その後、線形の変更履歴になり、ブランチ全体がメイントランクの一部になります。この場合、すべての変更がそこにあるので、明らかにコピーは必要ありません。

1
second