web-dev-qa-db-ja.com

Gitワークフロー-初心者にアドバイス

初めてgitを使用するようになり、自分に合ったワークフローを考え出そうとしているので、いろいろと質問してみました。

現在、私はいくつかのプロジェクトに参加しており、私は唯一のプログラマーであり、実際にはOriginへの唯一の推進者です。

私は次のように作業しています。ここで、cはコミット、pはプッシュ、mはマージです。

              /feature2-c-c-c-c-m-c-c-c-c
             /                 /     \
master-----------------------m-p------m-p
        \                  /           \  
         \-feature1-c-c-c-c-c-c-c-c-c-c-m-c-c

今、私はリベースがそれらよりも「正しい」であることを集めましたmerge master私は機能ブランチで行っています、または少なくともそれはそれがどのように見えるかです..しかし、私はそれを正しく行っているかどうかわかりません。私が気付いたのは、masterを他のブランチにマージすることで、ブランチの履歴をいじって、関係のないすべての機能のコミットをブランチに追加することです。

たぶん、サブタスクによって、次のような3番目のレベルを追加してさらに分岐する必要があります。

                 ....................\
master---------------------------m-p--m-p-....
        \                       /         \
         \-feature1------------m-----------m.....
            \                 /             \  
             \-feature11-c-c-c          feature12-c-c-c..

これは、機能がブランチのあるべきものよりも大きい場合があるという事実には対処していません。

これまでのところ、これらは私の考えです。そのため、1人または2人のチームで最適なgitワークフローについての提案を非常に受け入れています。

図がわかりやすいことを願っています。

gitworkflows
5
Lacrymology

TL; DR：gitワークフローは実際には問題ではありません。問題は、トピックのブランチに配置する機能に対して、さらに小さな反復が必要になることです。これにより、これらの局所ブランチを最新の状態に保ち、アップストリームに統合する手間が軽減されます。

マージされていないブランチをアップストリームの変更に合わせて最新の状態に保つ必要があります。通常、これを行うにはリベースが正しい方法です。

「機能がブランチの本来のサイズよりも大きい場合がある」というコメントから、統合ブランチとの統合が難しい長期的なトピックブランチがあると思います。私の経験では、これが実際の痛みの根源です。

トピックブランチが数時間続き、その後統合ブランチにマージされた場合を想像してみてください。これらの一時的なブランチは、最新の状態に保つのは簡単で、統合ブランチにマージするのは簡単である可能性があります。一方、統合せずにソフトウェアの複数のリリースにまたがる長期実行のトピックブランチを想像してみてください。統合するのはかなり難しいでしょう。これにより、マスターに対して頻繁にリベースされる短期間のトピックブランチの方が操作しやすいと結論付けることができます。

それで、質問は「なぜブランチがどうあるべきかよりも機能が大きいのか」ということになります。これは、一度に多くのことを実行しようとしているためと考えられます。局所的な分岐を短命に保ち、統合を簡単にするための最良の方法は、市場性のある最小限の機能をその最低限の本質に無慈悲に切り詰め、その機能に関するさらなる作業を別々の増分で追加する反復的な方法で作業することです。

4
Rein Henrichs