2

Git を使用して、複数の開発者が同時に使用するコード ベースを同期する最適なワークフローを見つけようとしています。チーム リーダーから提供されたスクリプトがあります。このスクリプトは、同期する必要があるほぼすべてのコード ファイルを追加し、バッチ ファイルやコンパイル済みファイルなどを除外しています。

一般に、私がすべきことは、問題に取り組み始める前に同期し、テストが終わったら同期することです。ただし、これは、リポジトリのコードをプルしてから公開するまでに長い時間がかかることを意味するのではないかと心配しています。これは、たとえば、自分の知らないうちに破損または修正された関数を使用する可能性があることや、その失効中に他の誰かが使用していたコードを不注意で壊してしまう可能性があることを意味します。また、「未完成」のコードを公開するのは悪い習慣かもしれませんが、よくわかりません。

同期を管理して、他のユーザーのコードへの干渉をできるだけ少なくし、長いターンアラウンド タイムを回避するにはどうすればよいですか? 任意の推奨事項を歓迎します。

4

2 に答える 2

2

この場合の私の戦略（他にもたくさんあります）は次のようになります。

1.）自分のリポジトリに自分用の2つのブランチを作成します。1つはリリースの準備ができている作業コード（YOURリリースブランチ）、もう1つは開発/バグ修正用（YOUR develブランチ）です。

2.）一般的に：develブランチは、sourceplusからreleaseブランチから最新のコードを取得します。そうすれば、ソースに変更があった場合でも、それをフェッチして最新の状態にすることができます。また、開発側からの変更がある場合は、それを取得できます。（たとえば、公開する準備はできていましたが、ソースAPIが変更されたことに気づきました。）最終的には、（安定した）変更とソースの変更に加えて、作業可能な（不安定な）修正を含む開発ブランチが作成されます。

3.）開発の準備ができたら、修正ブランチをリリースブランチにマージし、レビュー/統合のためにリリースブランチコードをリードに提供します。その間に何かが変更され、それを本当に修正する必要がある場合は、手順2に戻ります。）

アイデアは、リリースを常に手元に置いて、変更と修正を継続的に流し、安定して最新の状態に保つと同時に、すべてのソースからの最新コードを備えた不安定な開発ブランチを持つことです。

(project)           src-branch ----*----*---*-----*----------*------M
                                    \              \               /
(personal) devel/bugfix-branch ------M-*-*--*-------M-M---*--*----/--
                                             \       /         \ /
(personal)      release-branch ---------------M-*---*----*--*---M----

                               ------ time ----->

Legend: * commit, M merge

最後のステップでは、実際にgit-diffパッチを提供するか、プロジェクトソースへのレビュー/統合のために（ BAREリポジトリの）リリースブランチからリードにコントリビューションをフェッチさせます。

于 2012-09-17T17:29:01.353 に答える
1

ワークフロー情報を探している場合は、http://nvie.com/posts/a-successful-git-branching-model/で入手できる記事を確認してください。Git ワークフローの 1 つ (およびリポジトリ ブランチの管理に役立つ優れた Git プラグイン) について説明します。

于 2012-09-17T18:36:45.860 に答える