1

私は C++ プロジェクトに git を使用しており、私は唯一の開発者です。コード履歴を維持することに加えて、新しい機能を元のコードに組み込む準備が整うまで、元のコードを変更せずに新しい機能をテストできるようにしたいので、git を使用しています。Github を使用していますが、開発者は私だけです。

だから、ここに私のコミット履歴がどのように見えるかを想像します（矢印は子コミットを示し、ブランチ間の矢印は暗示されています）：

         A1 ---> A2 ---> A3        B1 ---> B2
         /                \        /        \
X1 ---> X2  ----------->  X3 ---> X4 -----> X5 ---> (...)

上記の履歴で、AとBは私が行った機能 (または変更) を表します。この歴史の中で、私は最初に取り組みA、それを終えAてから始めましBた。もちろん、別々の新機能に並行して取り組んでいる場合もあるかもしれませんが、この架空の例では (そしておそらく私の実際の開発ではほとんどの場合)、機能は順番に取り組んでいます。

これに関連して、2 つの関連する質問があります。両方の質問を 1 つの SO 投稿にまとめるのが適切だと思います。

A(1)とB(および後続の新機能) の両方を開発するために使用される master と一緒に実行する「新機能」ブランチ (たとえば、テスト) を 1 つだけ作成することは理にかなっていますか? (そうであれば、マスターとテストを切り替え、テストをマスターにマージまたはリベースし、別の新機能に取り組むために再びテストに切り替えるというこのプロセスをどのように管理すればよいでしょうか?)

(2) 私が唯一の開発者であることを考えると、マスターに新しい機能を組み込むときに、マージまたはリベースする方が理にかなっていますか? 私はgitが初めてなので、理由を説明してください。答えが「場合による」の場合は、どちらかを決定する方法を説明してください。

4

2 に答える 2

3
  1. 機能ごとに新しいブランチを作成します。ブランチは、Git では非常に安価であり (文字通りファイルに 41 バイトを書き込むだけです)、管理も簡単です。

  2. それは依存しますが、あなたが考えるほどではありません。いずれにせよ、同じコードになってしまいます。問題は、履歴のグラフをどのように表示するかです。常にリベースすると、線形の履歴になります。それは簡単に推論できます。マージ コミットを使用したブランチでは、機能を開始した正確な時期と、他のブランチと比較してマージした時期に関する情報が保持されます。その情報は有用な場合もあれば、単なるノイズである場合もあります。ややこしいことに、デフォルトgit mergeではマージ コミットが時々しか作成されません (可能であれば、早送りマージが行われます)。

    上記のグラフのような履歴グラフが必要な場合は、両方を行う必要があります。

    git checkout feature/foo
git rebase master
git checkout master
git merge --no-ff feature/foo

    ここでの唯一の具体的なアドバイスは、他の人と共有した履歴を書き換える (リベースする) べきではないということです。

于 2013-05-19T17:17:20.813 に答える
2

私の職場ではこのモデルを使用していますが、うまく機能していると思います: http://nvie.com/posts/a-successful-git-branching-model/

したがって、そのリンクからのいくつかの仮定は次のとおりです。

マスターは常に 100% 安定しています。

開発が安定して終了すると、マスターは開発からマージを取得します。

機能ごとに、develop からブランチを作成します。

機能が安定したら、機能ブランチをマージして開発します。

開発に追加されたすべての機能をテストして、追加したすべての機能が、実行した他の各機能で安定していることを確認します。

それがすべて 100% になったら、master にマージします。

1: 「機能」A と B が大幅に重複している場合、または相互に大きく依存している場合は、両方を同じブランチで開発するのが賢明かもしれません。そうではなく、開発テストで問題が発生した場合は、診断の方法としてデバッグ中に機能をノックアウトできます。君に電話だ。ただし、主に他の人があなたの現在のブランチと競合する可能性のあるものをコミットしているため、他の誰かをそこに連れて行った場合、開発を機能ブランチにマージする必要があるかもしれません。

個人的には、ブランチごとに機能を用意するのが好きです。開発からブランチに戻すのはほんの少しの作業です。開発から変更を取得する必要があるため、少し手間がかかる場合があります。本当にトレードオフです。

1 つの機能を並行して実行する場合: 機能ブランチはいくつでも持つことができます。したがって、現在取り組んでいる機能に飽きたら、develop から新しいブランチを作成してそれに取り組んでください。master に移行する前に、develop でマージの問題に対処します。

2: ブランチを他の人と共有しているため、指定されたコンテキストではリベースを使用できません。マージを使用するだけなので、他の誰かをミックスに参加させても問題ありません。これも：

http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/

これがお役に立てば幸いです。

于 2013-05-19T17:24:55.020 に答える