6

私の大学のプロジェクトの1つでは、Webアプリケーションを最初から開発することを任務とする4人の開発者のグループに属しています。私たちは皆、Gitについて非常に基本的な知識を持っており、コードベースのコラボレーションに使用することにしました。リポジトリが設定されており、全員がGitHubのコラボレーターです。

ここ数か月間、マスターブランチへのクローン作成とマスターブランチからのコミットを行ってきましたが、これは問題なく機能しました。ただし、最近では、一度に2人以上の人がコードベースで作業している場合があり、コミットが遅れてコミットする前にリポジトリのクローンを作成しなければならない場合があります。失った。

今日、グループメンバーの1人が「開発」ブランチを持つことについて話しました。これは、私たち全員が複製してコミットし、各スプリントの最後にマスターブランチにマージします。これを試しましたが、すべて同じコードベースで作業しているため、実際には改善が見られませんでした。そのため、以前と同じ問題が発生します。

他の誰かがメインリポジトリをフォークして(これは私にとっては新しいことです)、それに取り組んでからプルリクエストをメインリポジトリに送信するというアイデアを持っていました。メインリポジトリはマージできます。これは実際には良い計画のように聞こえます。コードが壊れた場合は、変更を確認して修正することができます。とにかく、それが私がそれを理解する方法です。

しかし、私が言ったように、私たちは皆Gitにかなり慣れておらず、全体のアイデアについて非常に基本的な理解を持っています。Gitリポジトリに取り組んでいる4人の開発者のチームを編成する標準的な方法は何ですか?いくつかのGitドキュメントを調べましたが、マスターブランチのクローンを作成してコミットする方法を本当に知っているだけの人にとってはかなり混乱します。

助けてくれてありがとう!

4

2 に答える 2

3

Gitワークフローや分岐モデルを調べる必要があります。たくさんあります、そしてここに始めるための1つがあります:

成功したgit分岐モデル

リリース、ステージング、プロダクションなどの概念は簡単に表現できるため、考える必要があります。基本的には組織がすべてです。

于 2013-03-25T22:15:43.750 に答える
0

開発方法論で「標準」であると話すことは、そのようなことはほとんどないので危険です。開発者のグループは、自分たちのために機能する方法で(または、管理者が自分たちを整理するように指示する方法で)自分自身を整理する傾向があります。

あなたが特定したすべてのアプローチは、分散バージョン管理システムを使用する有効な方法です。同じ地理的位置にあり、同じ言語を話し、同じような能力を持ち、結果がどうあるべきかについての同様に明確な考え。それらのいずれかが当てはまらない場合、Gitは輝く傾向があります。

一人がプロジェクトの正規バージョンのゲートキーパーとして機能することを本当に望んでいる分散プロジェクトの場合、プルリクエストは非常にうまく機能します。全員に実質的に平等なコミットアクセスを持たせたい場合は、開発ブランチが優れたソリューションです。人々は開発ブランチを使用する傾向があるので、人々が使用できるように常に機能するバージョンをぶらぶらさせることができます。現在、ユーザーがいないと思います。そのため、このアプローチから多くのメリットが得られる可能性はほとんどありません。

お互いに話し合って、チームとして何かがうまくいかないと判断しない限り、基本的にはそのまま続けます。その場合、他の働き方のいずれかがあなたにとってより良いかどうかを判断できます。

于 2013-03-25T22:16:44.240 に答える