2

最近、リポジトリとユーザー（グループ内）とともに、Gitolite Ubuntuサーバーをセットアップしました。実際に機能するものについては、すべてが順調に進んでいます。

私の Git 調査で、私たちが望む方法で動作する特定のGit モデルを見つけました。現在の開発バージョンを台無しにすることなく、現在のソースにホットフィックスを適用する方法が切実に必要でした。「nvie」のこのモデルは、私たちのすべてのニーズに応えます。

問題は、このモデルを使用したリモート ホスティングを実際に説明していないことです。そして、いくつかのことを理解できません。

現在、完成した新しいブランチを追加するたびにfeature-*、同じ名前でリモート ブランチにプッシュすることを考えています。しかし、これは、後日、私たちの 1 人が手動でそれらをプルし、競合がないようにする必要があることを意味します。

「nvie」モデルをチームベースのワークフローで使用するにはどうすればよいですか?

より明確にするために編集します：

チームの誰も、たとえば 2 人が独自の機能を開発する方法を理解していません。最初の人は自分の機能を終了し、 にマージしdevelopます。2番目の人は何をしますか？変更をスタッシュしてブランチにプルダウンし、スタッシュをdevelop適用しますか?

お互いに新しい変更を上書きすることなく、同時に開発を進める方法などはわかりません。

4

3 に答える 3

1

トピックスより引用

フィーチャー ブランチの本質は、フィーチャーが開発中の間は存在するが、最終的には開発にマージされる (次のリリースに新しいフィーチャーを確実に追加するため) か、破棄される (期待外れの実験の場合) ことです。

通常、フィーチャー ブランチは開発者リポジトリにのみ存在し、オリジンには存在しません。

すべての水晶をきれいにしなければなりません。後のコードは同じスタイルを示します

完成した機能は開発ブランチにマージされる可能性があり、次のリリースに確実に追加されます。

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

機能ブランチではなく、プッシュされたブランチ、開発に注意してください。必要なだけマージ|プッシュするだけです

于 2011-10-21T09:03:52.487 に答える
1

これは大きな論争の的となっています。機能ごとのブランチは、Git などの最新のツールによって可能になります。以前は、粒度のレベルが不可能である、または行うのが難しすぎるため、眉をひそめられていました。

QAの承認を得られない可能性があることに基づいてリセットできるブランチを追加することを検討します-統合後のUAC。これは私と他の人にとってうまくいきました。これは非常に詳細な説明であり、その後の良い議論です。私はそれが役立つことを願っています:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

于 2011-10-21T09:48:06.807 に答える