9
私は単独のプロジェクトにのみGitを使用しました。今私は他の2人の開発者とプロジェクトを続けたいと思っています。開発者ごとにブランチを作成することは理にかなっていますか？
開発者が変更をコミットしたいが、他の開発者が別のコミットを作成した場合、問題が発生するでしょうか？したがって、私たちひとりひとりに一つの支店を作るのは意味がありますか？
A
答えて
17
Gitは、ほとんどのバージョン管理システムと同様に、複数の開発者が使用するのに適しています。実際、バージョン管理システムの主なポイントの1つです。
ユーザーごとにブランチを作成する必要はありません。私はそれが逆効果であると言っています。同じ機能を使って作業している場合は、引き出したりマージしたりして、お互いの変更を得たいと思うかもしれません。ユーザーあたりのブランチを作成することは冗長であり、不必要に物事が複雑になります。
あなたが記述したコミット状況に問題はありません。別のユーザーがあなたと同じブランチで新しいコミットを作成した場合は、pushを実行すると停止します。代わりに、最初にpullに他のユーザーのコミットをダウンさせ、それらの変更を作業にマージ（またはリベース）する必要があります。これはgit pullの標準動作です。
通常は、機能を中心にブランチを作成します。分岐に関するガイダンスが必要な場合は、this is a popular strategy。
+0
あなたの仕事がどのように分かれているかによって異なります。私が働いた場所では、同時に2人の人が同じ機能をコーディングすることはありません。あなたが同じ機能を持っている複数の開発者を持っている場合でも、私は完全にあなたに同意します。 – Renan
+1
あなたはまだ人ごとに別々のブランチ*を作成するべきではありません。ブランチの作成を促進する機能でなければなりません。それぞれの人は、能動的な開発の特徴を持つように、多くの支店を持つべきです。 – meagar
+0
私の意見では、この答えは間違っています。あなたは同じブランチに2人の開発者を持つべきではありません。誰かがたくさんのコミットを押しつぶして強制的にプッシュするとどうなりますか？フィーチャーが2人の開発者を保証する場合は、各開発者がどの範囲に取り組んでいるかを正確に把握し、各フィーチャーのブランチを作成する必要があります。次に、マスター（またはマイルストーンなど）から別のブランチを作成し、それらのブランチをマージすることができます。これにより、マージ競合の解消と統合ブランチの適切なテストがマスターにマージされ、デプロイプロセスを経ることができます。 –
4
私は以前、私が働いていた場所でそれをしていました。私たちのそれぞれには、少なくとも1つの個人支店がありました。
完了したら、メインブランチにプルリクエストを行います。誰かがあなたの変更と矛盾するメインブランチコードに合併した場合、他のソース管理プラットフォーム（Tortoise、Mercurialなど）と同じように競合解消を行う必要がありますが、開発者が知っている限り大きな問題はありません彼らがやっていること。
これは、チームで開発を行うための最善の方法です。自分の個人的な環境でいつでもテストし、必要に応じて各支店のコードをすばやくスウィングすることができます。プルリクエストシステムは、皆さんが協力してgithub diffページの関連する行に直接コメントを書くことができるので、ピアレビューを非常に簡単にします。
同じマシンで作業している場合を除いて、1人のブランチが1人ずつ用意されています。あなたのレポをクローンすると、自分の*ブランチのセットが得られます。ブランチのセットは他のブランチと同じ名前になりますが、まだ自分のブランチ*です。 – meagar
@meagar面白いですね、これを詳しく教えてください。 – danijar
リポジトリのクローンされたすべてのインスタンスは、完全に自己完結したものです。あなたはあなたのブランチであなたがしたいことを自由にすることができます*あなたが押してみるまで他の誰の足指にも乗りません。プッシュ＆プルすると、ローカルブランチとリモートブランチのマージ（またはその逆）を「トラッキング」ブランチとして実行しています。これは、ローカルマシン上の任意の2つのブランチをマージすることと同じです。実際、 'git pull'は本当に単なるフェッチであり、続いてマージされます。簡潔にするために、 'git push'は、リモートコンフリクトを効果的に解決できないので、マージを早送りマージに制限します。 – meagar