2

GIT のヘルプが必要です。私たちは GIT を使い始めたばかりで、現在、社内に適切なセットアップが配置されていないため、すべてが混乱していると思います。私がやろうとしていることを皆さんがよりよく理解できるように、私の歴史を提供しました。 Git の歴史

Git の歴史 (続き)

だから今日、私は私たちのサポートとマスターサーバーに投稿しようとしています. 最初に Sup にポストし、次に Sup をライブ/マスター システムにマージします。

履歴を見て、サポートにマージしようとしているブランチ「130029」を見つけた場合、今日投稿する予定のすべてのブランチ/コミットを 1 つのパッケージに「押しつぶす」ことができるかどうかを確認したいと考えています。

リベースについて読んで、ブランチ「130029」で試しました。次のコードを実行しました

git checkout DEV.130029
git rebase SUPPORT -i

これにより、すべてのコミットが一覧表示されたリベース エディターに移動しましたが、それらのコミットは他のブランチであると予想していたので、それらを押しつぶしてサポートにマージすることができました。上記のコードよりも先に進むことはありませんでした。道に迷ったように見えたので中止しました。投稿する予定のすべてのブランチを選択して、それらすべてを 1 つのコミットとして Sup/master にマージできる他の方法はありますか?

前もって感謝します！

4

1 に答える 1

0

あなたの問題があるとすれば、それはワークフローだと思います。機能ブランチを使用する十分に複雑なプロジェクトは、乱雑なグラフになります。良い例が必要な場合は、git ソース自体である git.git を参照してください。これは文字通りgit ワークフローに関するドキュメントを書いたプロジェクトであり、現在のスナップショットmasterをgitkまたはtigにドロップすると、最初のパスではかなり混沌としているように見えます。

あなたのグラフについて懸念しているのは、それ自体が地下鉄の地図のように見えるということではありません。それは、上流の枝と下流の枝の明確な概念、または上流の枝から下流の枝への順序付けられた卒業を示していないことです。実際、SVN から git に移行したときに私の雇用主で使用していたワークフローに非常によく似ています。完全にアドホック。それも完全に間違っている可能性があります。いくつかの履歴スナップショットから会社のワークフロー ポリシーを推測するのは困難です。

簡単に説明できないと感じていて、その気持ちがチームで共有されている場合は、新しいワークフローの時期かもしれません。バージョン管理は、あなたの時間を無駄にするのではなく、あなたの生活を楽にするためにあります。多くの成功した git ワークフローが存在します。

少なくとも、利用可能な最も古い上流ブランチのバグを修正していない場合、下流の開発ブランチを上流の先祖への変更で最新の状態に保っていない場合、またはブランチ間で定期的にチェリーピッキングを行っている場合は、おつり。

最後に、ワークフローに関するその他の情報がない場合、たとえば、あるフィーチャー ブランチを 1 日中作業していて、そのSUPPORTブランチとマージして、最初に squash したい場合、これは多くの方法の 1 つです。

git checkout DEV.130029
git rebase -i --onto SUPPORT <branch_DEV_was_cut_from> DEV.130029 ;# squash what you want here
git checkout SUPPORT
git merge DEV.130029

つまり、グラフを単純に見せるためだけにリベースする場合は、代わりにワークフローに時間を費やしてください。

于 2012-07-26T21:42:47.100 に答える