2017-06-03 27 views
1

私は最初のソフトウェアエンジニアリングクラスに入っています。 私たちの誰もがチームで働いて、gitとgithubを使ったのは初めてです。 クラスでは、先生は、通常、マスターから分岐して、新しいフィーチャーを完成した後、マスターに戻してマージする必要があることを教えてくれました。 これは私がやってきたことです。 しかし私のグループの他のメンバーは分岐していません。 githubのマスターからローカルマシンにプルし、編集を行い、ローカルのマスターでその機能を終了し、githubのマスターにプッシュします。本当にGitにブランチする必要はありますか?

私は彼らに枝分かれを納得させようとしていますが、今私はそれについて考えると、私はもっと混乱していると感じます。 私は、ブランチの目的はコードのコピーを作成することであり、誤って実行不能なコードを置くことによってマスターを台無しにする心配はないと言われました。

ローカルマスターはブランチ自体とまったく同じではありませんか?彼らは編集を行っているので、githubのマスターを変更していないので、他の人は自由にgithubから作業コードを引き出すことができます。その後、ブランチと同様にマージされます。

私は混乱しています。なぜ彼らがやっていることが働いていると思われる場合、私たちは分岐するべきですか?

ありがとうございます!

+0

実際のプロジェクトでは、人々は機能について協力し、チームメンバーは他の人のコードをマージする前にレビューし、人々は異なる機能や修正を同時に行い、機能は長時間続くことがあります。開発者のマシンなどこのすべてはギブスにブランチとプッシュブランチで可能になります。 –

答えて

1

しかし、地元のマスターは実際にブランチのようなものではありませんか?

はい!

私は混乱しています。彼らがしていることが機能していると思われる場合、どうして私たちは分岐するべきですか?

これはワークフローによって異なります。

アリスはmasterを追跡し、ボブはまたmasterを追跡bobブランチを作るブランチaliceを作る:あなたが記述しているように見えることは、このワークフローです。アリスは常にaliceにコミットし、ボブは常にbobにコミットします。そして、彼らが変更に満足すれば、masterに合併します。

もちろん、ローカルのmasterブランチで働いているアリスとボブとの違いはほとんどありません。

同じ人物が同時に複数の機能を操作しているときに問題が発生することがよくあります。たとえば、

アリスはFeature Aで作業しており、ボブはFeature Bで作業しています。アリスはFeature Aで途中で完了し、aliceでコミットしました。しかし、Feature Aは実装するのが非常に難しいので、アリスは彼女がむしろFeature Cで作業すべきであると判断し、aliceにコミットします。ボブはFeature Bを完成させ、彼はFeature Aに取り組みたいと判断し、alicebobに引きます。

ボブが完了した後Feature Abobmasterにマージします。ただし、bobは現在Feature A,Feature BおよびFeature Cの部分を含んでいますが、Feature Cはマージする準備ができていません。このようなワークフローが混乱を招くコンフリクトを混乱させることは容易にわかります。

トリックは、個人的なブランチを持つ代わりにフィーチャーブランチを持つ必要があります。アリスはFeature AFeature Cのブランチを持ち、ボブはFeature BFeature Aのブランチを持つ必要があります。そうすれば、彼らはお互いのつま先をめちゃくちゃにすることなく、両方の機能を別の機能で動作させることができます。

+0

ありがとう!私は自分のグループが一度に一つの機能に取り組むことを計画していると思います。しかし、今では、他のメンバーとのコラボレーションで一度に複数の機能を作業する場合、分岐が本当に重要であることがわかります。 – seal308

+0

フィーチャーブランチを作成することは過度に思えるかもしれませんが、予期せぬ問題のために多くの人が同じフィーチャーで作業しなければならない場合や、開発者は他の問題に取り組んでいきたいと考えています。 – Moyamo

0

考えられるのは、コードが安定してマージされているマスターブランチがあるということです。

ウェブサイトをスクラップするアプリケーションがあるとします。

私は、develop/pulldataという新しいブランチを作成します。このブランチでは、私はデータを引き出す作業をします。私のチームメンバーの1人は、データにいくつかのロジックを適用することで作業できるので、彼自身のブランチ開発/アプリケーションロジックを作成することができます。

コミットが少なく、コードが安定したら、コードをマスターにマージするプルリクエストを開きます。これをgithub UIで表示して、変更したコードを確認してマージしたい場合、または変更が必要な場合

しばらくすると、コードが完了し、私はマスターにプルリクエストを開き、同僚が自分のコードを表示して変更を承認または提案できるようになります。見やすく、チーム内のすべての人がmasterブランチが安定していることを知っています。しかし、他の支店はそうである必要はありません。彼らはマスターに合併されたときでなければなりません。

0

もっと短くしてください。あなたがあなたのマシンに持っているものは、ローカルマスターです。すべての変更をorigin/masterサーバーにプッシュします。

masterブランチで作業することをお勧めしない主な理由は、複数の人がプロジェクトで作業し、1つのブランチがブランチを作成したすべての人の共通基盤である必要があるということです。例えば


、あなたはあなたがマスターにそれをマージしたとき、あなたはマスターから分岐add_blueetoothを作成し、それにBluetoothモジュールを追加したい製品を持っています。別の男がwifiで仕事をしていて、自分の支店をマスターに合併することができます。これは、一般的なCVSワークフローで、ブランチを作成すると並列処理が行われます。


クローンすると本当に何が起こりますか?

実際には、git cloneはすべてのリモートブランチをフェッチし、ローカルブランチを作成します。これはmasterです。ただ、このコマンドgit branch -a

git branch -a 
* master 
    remotes/origin/HEAD 

彼らはあなたがグラムit branch -rを使用してリモートブランチを見ることができる他のコマンドであるを入力します。

ローカルブランチによって作成された参照を、この場所に移動して確認することができます。 refs/remotes/origin

関連する問題