私たちの会社は git を使用してドキュメント/コードの変更を追跡しており、複数の人が変更を加えて中央リポジトリにプッシュしています。彼らのほとんどは、一般的に git やコマンド ライン ツールに関しては初心者です。彼らのために、変更を行った後にローカル リポジトリを更新または公開するためのスクリプトがあります。
git の経験が豊富な人が解決しなければならないマージ競合の発生を最小限に抑えるために、このような状況でよりうまく機能するワークフローはありますか?
質問する
3566 次
4 に答える
6
マージの競合の最大の理由は、各マージ間の時間です。
各マージの間の待ち時間が長ければ長いほど、マージの競合をより確実に確認できます。
機能ごとのブランチを提唱し、タスクの分離を促進するマージ ワークフロー(たとえば、 git フローなど) を選択することで、それを最小限に抑えることができます。
しかし、 (2 つの異なる開発で)共通のファイル セットが関係している限り、マージの競合が発生することになります。
したがって、分散型VCS では、定期的に発行 (プッシュ/プル) することを学び、マージする前にリベースすることを学びます。
これにより競合の数が減るだけでなく、セマンティックな競合の数も減ります。これらは自動的に (競合がないように見える)マージですが、誤ったコードを生成します。「 「セマンティック コンフリクト」のより良い、より単純な例は?
」
を参照してください。
于 2012-11-19T06:50:11.263 に答える
6
Git は、適切な開発プラクティスに代わるものではありません。それはあなたにとってより良いコーディングにはなりません。
2 人の開発者がまったく同じコードに触れている場合、git には彼らの仕事を簡単にする方法はありません。
短期的な解決策: 適切なローカル ブランチとリモート ブランチを使用して、さまざまな機能の作業をカプセル化します。ブランチ差分 (または github プル リクエスト) を使用して、機能セットを確認し、差分や競合を調べてください。
長期的には、コードを修正し、それをチームに適応させ、その逆も同様に行い、適切な開発プラクティスを使用します。
于 2012-11-18T21:15:06.107 に答える
2
魔法のようなものは何もありません。主に規律。
人々がプル リクエストのようなことをしなければならない場合や、「メイン」リポジトリやブランチとマージされる前にコミットがレビューされるのを待つ必要がある場合は、レビューの時間をできるだけ短くするようにしてください。
おそらくブランチの有効期間を短くするように努めるべきですが、それは実際に取り組んでいるプロジェクトの種類によって異なります。
すべてのコミットはできるだけ小さくする必要があるというルールを作ります。コミットは 1 つのことだけを変更しなければならないというルールにします。表面的な変更 (空白など) と機能上の変更および大幅なリファクタリングを混在させないことを原則としてください。(空白の変更を完全に禁止するのではなく、他の変更から切り離してください。)
バージョン管理自体を超えて、同じ週に同じコードを変更する可能性を減らす方法で、コーダーにタスクを割り当てるようにしてください。
于 2012-11-18T21:48:37.280 に答える
-1
よりよく理解するのに役立つ記事「A success Git branching model」がここに書かれています。次のようなさまざまなタイプのブランチを分離する必要があると述べています。
- 主人
- ホットフィックス
- リリースブランチ
- 発展させる
- フィーチャー ブランチ
于 2012-11-18T21:54:17.537 に答える