私は単独のプロジェクトにのみ Git を使用しました。今、私は他の 2 人の開発者と一緒にプロジェクトに取り組みたいと思っています。
ある開発者が変更をコミットしたいが、別の開発者によって別のコミットが作成された場合、問題が発生しますか? したがって、私たち一人一人に 1 つのブランチを作成することは理にかなっていますか?
私は単独のプロジェクトにのみ Git を使用しました。今、私は他の 2 人の開発者と一緒にプロジェクトに取り組みたいと思っています。
ある開発者が変更をコミットしたいが、別の開発者によって別のコミットが作成された場合、問題が発生しますか? したがって、私たち一人一人に 1 つのブランチを作成することは理にかなっていますか?
Git は、ほとんどのバージョン管理システムと同様に、複数の開発者による使用に非常に適しています。実際、これはバージョン管理システムの要点の 1 つです。
ユーザーごとにブランチを作成する必要はありません。逆効果だと言っても過言ではありません。同じ機能に取り組んでいる場合は、おそらくプルとマージによって、互いの変更を取得したいと思うでしょう。ユーザーごとにブランチを作成するのは冗長であり、必要以上に複雑になります。
あなたが説明するコミット状況は問題ありません。別のユーザーがあなたと同じブランチで新しいコミットを作成した場合、あなたがしようとすると停止しますpush
。代わりに、最初にpull
他のユーザーのコミットを停止し、それらの変更で作業をマージ (またはリベース) する必要があります。これは の標準的な動作ですgit pull
。
通常のプラクティスは、主に機能に基づいてブランチを作成することです。分岐に関するガイダンスが必要な場合、これは一般的な戦略です。
私が働いていた場所では、それを行っていました。私たちはそれぞれ、少なくとも 1 つの個人用ブランチを持っていました。実際、私は、実行しなければならないすべてのタスクに対してブランチを作成しました。
完了したら、メイン ブランチへのプル リクエストを行います。あなたの変更と競合するメイン ブランチ コードに誰かがマージした場合、他のソース管理プラットフォーム (Tortoise、Mercurial など) と同じように競合解決を行う必要がありますが、開発者が知っていれば大したことではありません。彼らがしていること。
IMO これは、チームで開発を行うための最良の方法です。必要に応じて各ブランチからコードをすばやく切り替えて、いつでも独自の個人環境でテストできます。また、プル リクエスト システムにより、ピア レビューが非常に簡単になります。誰もが協力して、github diff ページの関連する行に直接コメントを書き込むことができるからです。