トランクベースの開発とGitフロー

高品質のソフトウェアを開発するには、すべての変更を追跡し、必要に応じて元に戻すことができる必要があります。 バージョン管理システムは、プロジェクトの履歴を追跡し、複数の人が行った変更をマージするのを支援することで、その役割を果たします。 それらは作業を大幅にスピードアップし、バグをより簡単に見つける能力を私たちに与えてくれます。

さらに、主にこれらのツールのおかげで、分散したチームでの作業が可能になります。 これにより、複数の人が同時にプロジェクトのさまざまな部分に取り組み、後で結果を1つの製品にまとめることができます。 バージョン管理システムを詳しく見て、トランクベースの開発とGitフローがどのように実現したかを説明しましょう。

バージョン管理システムが世界をどのように変えたか

バージョン管理システムが作成される前は、人々は以前のバージョンのプロジェクトを手動でバックアップすることに依存していました。 同じプロジェクトに複数の開発者の作業を組み込むために、変更されたファイルを手作業でコピーしていました。

それは多くの時間、ハードドライブのスペース、そしてお金がかかりました。

歴史を見ると、3世代のバージョン管理ソフトウェアを大まかに区別することができます。

それらを見てみましょう：

バージョン管理システムが成熟するにつれて、プロジェクトで並行して作業する能力が高まる傾向があることに気づきました。

最も画期的な変更の1つは、ファイルのロックから変更のマージへの移行でした。 これにより、プログラマーはより効率的に作業できるようになりました。

もう1つの大きな改善は、分散システムの導入でした。 Gitは、この哲学を取り入れた最初のツールの1つでした。 それは文字通りオープンソースの世界を繁栄させることを可能にしました。 Gitを使用すると、開発者は、フォークと呼ばれる操作でリポジトリ全体をコピーし、マージの競合を心配することなく、必要な変更を導入できます。

後で、変更を元のプロジェクトにマージするためにプルリクエストを開始できます。 最初の開発者が他のリポジトリからのこれらの変更を組み込むことに興味がない場合、彼らはそれらを独自に別々のプロジェクトに変えることができます。 中央ストレージの概念がないという事実のおかげで、それはすべて可能です。

開発スタイル

現在、最も人気のあるバージョン管理システムは間違いなくGitであり、2016年の市場シェアは約70％です。

Gitは、Linuxの台頭と一般的なオープンソースシーンで普及しました。 現在、パブリックプロジェクトで最も人気のあるオンラインストレージであるGitHubも、その普及に大きく貢献しました。 Gitへのプルリクエストの管理が簡単な導入のおかげです。

簡単に言うと、プルリクエストは、ソフトウェア開発者が作成した変更をメインプロジェクトと組み合わせるために作成したリクエストです。 これらの変更を確認するプロセスが含まれています。 レビュー担当者は、改善できると思われるすべてのビットにコメントを挿入したり、不要と見なしたりできます。

フィードバックを受け取った後、作成者はそれに応答してディスカッションを作成するか、単にそれに従ってコードを変更することができます。

Gitは単なるツールです。 さまざまな方法で使用できます。 現在、遭遇する可能性のある2つの最も人気のある開発スタイルは、Gitフローとトランクベースの開発です。 多くの場合、人々はそれらのスタイルの1つに精通しており、他のスタイルを無視する可能性があります。

両方を詳しく見て、いつどのように使用するかを学びましょう。

Gitフロー

Gitフロー開発モデルには、厳密にアクセスできる1つの主要な開発ブランチがあります。 多くの場合、 developブランチと呼ばれます。

開発者は、このメインブランチから機能ブランチを作成し、それらに取り組みます。 完了すると、プルリクエストが作成されます。 プルリクエストでは、他の開発者が変更についてコメントし、多くの場合非常に長い議論を行う場合があります。

変更の最終バージョンについて合意するには、しばらく時間がかかります。 合意されると、プルリクエストが受け入れられ、メインブランチにマージされます。 メインブランチがリリースされるのに十分な成熟度に達したと判断されると、最終バージョンを準備するために別のブランチが作成されます。 このブランチのアプリケーションはテストされ、最終ユーザーに公開する準備ができるまでバグ修正が適用されます。 それが完了したら、最終製品をmasterブランチにマージし、リリースバージョンでタグ付けします。 それまでの間、 developブランチで新しい機能を開発できます。

以下に、一般的なワークフローを示すGitフロー図を示します。

Gitフローの利点の1つは、厳密な制御です。 許可された開発者のみが、変更を注意深く見た後で変更を承認できます。 コードの品質を保証し、バグを早期に排除するのに役立ちます。

ただし、これも大きなデメリットになる可能性があることを覚えておく必要があります。 それはソフトウェア開発を遅くする漏斗を作成します。 速度が主な関心事である場合、それは深刻な問題である可能性があります。 個別に開発された機能は、メインプロジェクトと組み合わせるのが難しいかもしれない長寿命のブランチを作成する可能性があります。

さらに、プルリクエストは新しいコードのみにコードレビューを集中させます。 コード全体を見てそのように改善するのではなく、新しく導入された変更のみをチェックします。 場合によっては、より高速に実行するために何かを実装することが常に可能であるため、時期尚早の最適化につながる可能性があります。

さらに、プルリクエストは、リード開発者が文字通りコードのすべての行を管理する広範なマイクロマネジメントにつながる可能性があります。 信頼できる経験豊富な開発者であれば、彼らはそれを処理できますが、あなたは彼らの時間とスキルを無駄にしているかもしれません。 また、開発者の意欲を大幅に低下させる可能性もあります。

大規模な組織では、プルリクエスト中の社内政治が別の懸念事項です。 プルリクエストを承認する人は、自分の立場を利用して、特定の開発者がコードベースに変更を加えることを意図的にブロックする可能性があると考えられます。 彼らは自信の欠如のためにこれを行うことができましたが、一部の人は個人的なスコアを解決するために彼らの立場を乱用する可能性があります。

GitFlowの長所と短所

ご覧のとおり、プルリクエストを実行することが常に最良の選択であるとは限りません。 それらは適切な場合にのみ使用する必要があります。

Gitフローが最適に機能するのはいつですか？

• オープンソースプロジェクトを実行するとき。
  このスタイルはオープンソースの世界から来ており、そこで最もよく機能します。 誰もが貢献できるので、すべての変更に非常に厳密にアクセスできるようにする必要があります。 率直に言って、貢献している人々を信頼することはできないため、コードのすべての行をチェックできるようにする必要があります。 通常、これらは商用プロジェクトではないため、開発速度は問題になりません。

• ジュニア開発者がたくさんいるとき。
  主にジュニア開発者と仕事をしている場合は、彼らの仕事を綿密にチェックする方法が必要です。 あなたは彼らに物事をより効率的に行う方法についての複数のヒントを与え、彼らが彼らのスキルをより速く向上させるのを助けることができます。 プルリクエストを受け入れる人は、繰り返し発生する変更を厳密に制御できるため、コード品質の低下を防ぐことができます。

  

• あなたが確立された製品を持っているとき。
  このスタイルは、すでに成功している製品がある場合にもうまく機能するようです。 このような場合、焦点は通常、アプリケーションのパフォーマンスとロード機能にあります。 この種の最適化には、非常に正確な変更が必要です。 通常、時間は制約ではないため、このスタイルはここでうまく機能します。 さらに、大企業はこのスタイルに最適です。 彼らは数百万ドルの投資を壊したくないので、すべての変更を綿密に管理する必要があります。

Gitフローはいつ問題を引き起こす可能性がありますか？

• 起動したばかりのとき。
  起動したばかりの場合、Gitフローは適していません。 最小限の実行可能な製品をすばやく作成したい場合があります。 プルリクエストを実行すると、チーム全体の速度が大幅に低下する大きなボトルネックが発生します。 あなたは単にそれを買う余裕がありません。 Gitフローの問題は、プルリクエストに多くの時間がかかる可能性があるという事実です。 そのように迅速な開発を提供することは不可能です。

• すばやく繰り返す必要がある場合。
  製品の最初のバージョンに到達したら、顧客のニーズを満たすために、おそらくそれを数回ピボットする必要があります。 繰り返しになりますが、複数のブランチとプルリクエストは開発速度を劇的に低下させるため、このような場合はお勧めしません。

• 主に上級開発者と仕事をするとき。
  チームが主に長期間互いに協力してきた上級開発者で構成されている場合は、前述のプルリクエストのマイクロマネジメントは実際には必要ありません。 あなたはあなたの開発者を信頼し、彼らが専門家であることを知っています。 彼らに仕事をさせて、すべてのGitフロー官僚機構で彼らを遅くしないでください。

トランクベースの開発ワークフロー

トランクベースの開発モデルでは、すべての開発者がオープンアクセスで単一のブランチに取り組んでいます。 多くの場合、それは単にmasterブランチです。 彼らはそれにコードをコミットして実行します。 とても簡単です。

場合によっては、短命の機能ブランチを作成します。 ブランチ上のコードがコンパイルされ、すべてのテストに合格すると、 masterに直接マージされます。 これにより、開発が真に継続的になり、開発者が解決が難しいマージの競合を作成するのを防ぐことができます。

トランクベースの開発ワークフローを見てみましょう。

このようなアプローチでコードをレビューする唯一の方法は、完全なソースコードレビューを行うことです。 通常、長い議論は限られています。 ソースコードベースで変更される内容を厳密に制御できる人は誰もいません。そのため、強制可能なコードスタイルを設定することが重要です。 このようなスタイルで作業する開発者は、ソースコードの品質が低下しないことを理解できるように経験を積む必要があります。

このスタイルの作業は、経験豊富なソフトウェア開発者のチームと協力する場合に最適です。 それは彼らが不必要な官僚主義なしで迅速にそして新しい改善を導入することを可能にします。 また、 masterブランチに直接コードを導入できるため、信頼できることも示しています。 このワークフローの開発者は非常に自律的です。彼らは直接配信し、作業中の製品の最終結果をチェックします。 この方法では、マイクロマネジメントと社内政治の可能性は間違いなくはるかに少なくなります。

一方、経験豊富なチームがいない場合、または何らかの理由でチームを信頼していない場合は、この方法を使用しないでください。代わりにGitフローを選択する必要があります。 それはあなたに不必要な心配を救うでしょう。

トランクベースの開発の長所と短所

コストの両側、つまり最高のシナリオと最悪のシナリオを詳しく見てみましょう。

トランクベースの開発はいつ最適に機能しますか？

• 起動したばかりのとき。
  最小限の実行可能な製品に取り組んでいる場合は、このスタイルが最適です。 最小限の形式で最大の開発速度を提供します。 プルリクエストがないため、開発者は光の速さで新しい機能を提供できます。 経験豊富なプログラマーを雇うようにしてください。

• すばやく繰り返す必要がある場合。
  製品の最初のバージョンに到達し、顧客が何か違うものを望んでいることに気づいたら、考え直さずに、このスタイルを使用して新しい方向にピボットします。 あなたはまだ調査段階にあり、できるだけ早く製品を変更できる必要があります。

• 主に上級開発者と仕事をするとき。
  チームが主に上級開発者で構成されている場合は、彼らを信頼し、彼らに仕事を任せる必要があります。 このワークフローは、彼らに必要な自律性を与え、彼らが彼らの職業の習得を振るうことを可能にします。 彼らに目的（達成するためのタスク）を与えて、あなたの製品がどのように成長するかを見てください。

トランクベースの開発はいつ問題を引き起こす可能性がありますか？

• オープンソースプロジェクトを実行するとき。
  オープンソースプロジェクトを実行している場合は、Gitフローの方が適しています。 変更を非常に厳密に制御する必要があり、寄稿者を信頼することはできません。 結局のところ、誰でも貢献できます。 オンライントロールを含みます。

• ジュニア開発者がたくさんいるとき。
  主にジュニア開発者を雇う場合は、彼らが何をしているかを厳密に管理することをお勧めします。 厳密なプルリクエストは、スキルを向上させるのに役立ち、潜在的なバグをより迅速に見つけることができます。

• 製品を確立したとき、または大規模なチームを管理したとき。
  すでに繁栄している製品を持っているか、大企業で大規模なチームを管理している場合は、Gitフローの方が適している可能性があります。 数百万ドル相当の定評のある製品で何が起こっているかを厳密に管理したいと考えています。 おそらく、アプリケーションのパフォーマンスとロード機能が最も重要です。 この種の最適化には、非常に正確な変更が必要です。

適切な仕事に適切なツールを使用する

前に言ったように、Gitは単なるツールです。 他のすべてのツールと同様に、適切に使用する必要があります。

Gitフローは、プルリクエストを通じてすべての変更を管理します。 すべての変更に対する厳密なアクセス制御を提供します。 オープンソースプロジェクト、大企業、確立された製品を持つ企業、または経験の浅いジュニア開発者のチームに最適です。 ソースコードに何が導入されているかを安全に確認できます。 一方で、それは広範なマイクロマネジメント、社内政治を含む論争、そして著しく遅い開発につながる可能性があります。

トランクベースの開発は、プログラマーに完全な自律性を与え、プログラマーと彼らの判断へのより多くの信頼を表現します。 ソースコードへのアクセスは無料なので、チームを信頼できる必要があります。 優れたソフトウェア開発速度を提供し、プロセスを削減します。 これらの要素により、新製品を作成したり、既存のアプリケーションをまったく新しい方向にピボットしたりする場合に最適です。 あなたが主に経験豊富な開発者と仕事をしているのかどうかは不思議に思います。

それでも、ジュニアプログラマーや完全に信頼できない人々と仕事をしている場合は、Gitフローがはるかに優れた代替手段です。

この知識を身につければ、プロジェクトに完全に一致するワークフローを選択できるようになることを願っています。