集中型バージョンコントロールシステムから Git に切り替えることで、開発チームのソフトウェア作成方法が変わります。ミッションクリティカルなアプリケーションでソフトウェアに依存している企業であれば、開発ワークフローの変更は、ビジネス全体に影響を与えます。

組織開発

ほとんどの組織は、開発チームからマーケティング、およびその間にあるすべての部門を含め、組織のあらゆる側面で Git がどれほど有益かについて説明します。この記事の最後には、Git がアジャイルソフトウェア開発のためだけではなく、アジャイルビジネスのためのソフトウェアであるということが明らかになります。

開発者向け Git

フィーチャー ブランチ ワークフロー

Git の最大のメリットの 1 つが、ブランチング機能です。集中型バージョンコントロールシステムとは異なり、Git ブランチは安価で、マージが簡単です。これにより、多くの Git ユーザーに人気の機能ブランチワークフローを促します。

フィーチャー ブランチ ワークフロー

フィーチャーブランチは、コードベースに対するすべての変更用に隔離環境を提供します。開発者が作業を開始したい場合、その規模の大小に関係なく、新しいブランチを作成することになります。これにより、マスターブランチが常に本番品質のコードが含まれるようにします。

Using feature branches is not only more reliable than directly editing production code, but it also provides organizational benefits. They let you represent development work at the same granularity as the your agile backlog. For example, you might implement a policy where each Jira ticket is addressed in its own feature branch.

分散型環境

SVN では、各開発者は、単一の中央リポジトリを示す作業コピーを取得します。ただし、Git は、分散型バージョン管理システムです。作業コピーの代わりに、各開発者は、コミットの完全な履歴が含まれた、ローカルのリポジトリを取得します。

分散型開発

コミットを作成し、ファイルの以前のバージョンを調べたり、コミット間の差分を実行するために、ネットワークへ接続しなくて済むため、完全なローカル履歴を持つことで Git が高速化します。

また、分散型開発により、エンジニアリングチームの拡張も簡単になります。誰かによって SVN の生産ブランチを壊された場合、それが修正されるまで、他の開発者は変更を確認することはできません。Git では、このようなブロックは存在しません。全員が自分のローカルリポジトリで自分の作業を継続できます。

ブランチと同様、分散型開発はより信頼性の高い環境を作り出します。開発者が自分のリポジトリを抹消する場合であっても、単純に他の人物のものを複製して新しく始めることができます。

プルリクエスト

Bitbucket のような多くのソースコード管理ツールは、プルリクエストを使用してコア Git 機能を強化します。プルリクエストは、他の開発者に、自分のブランチの 1 つを彼らのリポジトリへマージしてもらうよう依頼する手段です。これにより、プロジェクトが簡単に変更を追跡できるだけでなく、開発者がコードベースの残りの部分に自分の作業を統合する前に、自分の仕事に関する議論を開始することができますだけではなく。

プルリクエスト

それらは基本的にフィーチャーブランチに接続されたコメントスレッドのため、プルリクエストは非常に汎用性があります。開発者は困難な問題に立ち往生したら、プルリクエストを開き、チームの残りのメンバーに助けをお止めることができます。あるいは、若い開発者はプルリクエストを正式なコードレビューとして処理することで、自分たちがプロジェクト全体を壊すことはないと自信を持つことができます。

コミュニティ

多くのサークルは、Git は新しいプロジェクトに期待されるバージョン管理システムになってきました。チームが Git を使用している場合、彼らはすでに分散開発に精通しているため、ワークフローで新入社員を訓練する必要がない可能性が高くなります。

Git コミュニティ

さらに、Git は非常に人気のあるオープンソースプロジェクトです。つまり、サードパーティのライブラリを活用し、独自のオープンソースコードを分岐するよう他のメンバーに奨励するのが容易です。

リリースサイクルの短縮

フィーチャーブランチ、分散開発、プルリクエスト、および安定したコミュニティの究極の結果は、リリースサイクルの短縮です。これらの機能により、開発者はより頻繁に小さな変更を共有することが奨励されているアジャイルワークフローを促進します。その結果、変更は、集中バージョン管理システムに共通する画一的なリリースよりも短期間で、展開パイプラインを押し下げることができます。

リリースサイクルの短縮

ご想像のとおり、Git は継続的インテグレーションと継続的デリバリー環境で非常にうまく機能します。Git フックでは、リポジトリ内部で特定のイベントが発生した場合スクリプトを実行できるため、あなたが考えているコンテンツへの展開を自動化できます。特定のブランチから別のサーバーへコードをビルドまたは展開することもできます。

例えば、誰かがプルリクエストをマージするたびに、開発ブランチからテストサーバーへの最新のコミットを展開するよう Git を構成することもできます。このようなビルドの自動化をピアレビューと組み合わせることで、開発から本番へのステージングへ移行する際、コードに最大限の自信を持つことができます。

マーケティング向け Git

Git への切り替えが貴社のマーケティング活動にどのように影響するかを理解するため、貴社の開発チームに、今後数週間で完成予定の3つの明確な変更点があると想像してください。

  • チーム全体が、6 か月間取り組んでいる確信的なを仕上げようとしています。
  • メリーは既存の顧客にのみ影響する、小さい、無関係の機能を実装します。
  • リックは、ユーザーインターフェイスへいくつかの重要な更新を加えます。

集中 VCS に依存している従来の開発ワークフローを使用している場合、これらの変更のすべてのは、おそらくシングルリリースにロールアップされることになります。マーケティングは、革新的な機能に焦点を当てる 1 件のみを発表することができ、他の 2 つの更新プログラムのマーケティングの可能性は事実上無視されます。

Git によって開発サイクルの短縮を促すことで、これらを個別リリースへと分割しやすくなります。これにより、マーケティング担当者はより頻繁に、より多くの話題を得ることができます。上記のシナリオでは、マーケティングはそれぞれの機能を中心に 3 つのキャンペーンを構築して、非常に限られた市場セグメントをターゲットにすることができます。

マーケティング向け Git

例えば、革新的な機能に対する大規模な宣伝、マリーの機能に対する企業ブログの投稿やニュースレターの推薦、外部デザインブログへ送信するための、リックの基本的な UX 理論に関する一部のゲストの投稿などを準備する場合があります。これらの活動はすべて、別のリリースと同期させることができます。

製品管理向け Git

製品管理に Git を使用するメリットは、マーケティングの場合とほぼ同じです。リリースが頻繁ということは、顧客フィードバックがより頻繁になり、そのフィードバックに対する更新も短時間で行われるということです。今から 8 週間後の新しいリリースを待つのではなく、開発者がコードを記述するとすぐに顧客にソリューションをプッシュすることができます。

優先度管理 Git のワークフロー

機能ブランチワークフローは、優先順位が変更されたときにも柔軟性を発揮します。たとえば、リリースサイクルの途中で、別の期限が厳しい機能を延長したい場合も、問題ありません。エンジニアリングに確認する時間ができるまで、初期機能は独自のブランチに残すことができます。

この同じ機能により、革新的なプロジェクト、ベータテスト、迅速なプロトタイプを独立したコードベースとして管理しやすくなります。

設計者向け Git

フィーチャーブランチは、急速なプロトタイピングに向いています。UX / UI デザイナーが完全に新しいユーザフローを実装するか、単純にいくつかのアイコンを置き換えるかに関係なく、新しいブランチをチェックアウトすると共に作業できるサンドボックス環境を提供します。これにより、デザイナーは既存の機能が壊れることを心配せずに、製品の実際の作業コピーで変更がどのように見えるかを確認できます。

Git の非破壊バージョン管理

このようなユーザーインターフェースの変更をカプセル化する他の利害関係者への更新を提示しやすくなります。たとえば、エンジニアリングのディレクターが設計チームの作業内容を確認したい場合、彼らのすべきことは対応するブランチを確認するようディレクターに伝えるだけです。

プルリクエストはこのさらに一歩先に進み、関心を持つ人物が新しいインターフェイスについて議論するできる正式な場所を提供します。設計者は、必要な変更を加えることができ、そして得られたコミットは、プルリクエストに表示されます。これにより、反復プロセスに参加するよう全員を招待します。

おそらく、ブランチを使用するプロトタイピングで最も優れている点は、生産に変更を加えるのが、削除する場合と同じ用に簡単だということです。どちらを行う場合もプレッシャーはありません。これにより、デザイナーや UI 開発者に実験を奨励し、同時に最高のアイデアのみを顧客に提供するようにします。

カスタマーサポート向け Git

カスタマサポートと顧客の成功は、製品のマネージャーとは異なる見方を持っている場合がよくあります。顧客が彼らを呼び出した場合、彼らは通常、ある種の問題を経験しています。問題の原因が会社のソフトウェアの場合、できるだけ早くバグ修正をプッシュする必要があります。

Git の合理化された開発サイクルは、次回のモノリシックリリースまでバグ修正が延期されるのを防ぎます。開発者は問題をパッチを作成し、直接生産にプッシュすることができます。修正を早く行うことで、顧客を満足させ、サポートチケットが繰り返し発行されるのを防ぐことができます。立ち往生して「申し訳ありません。現在対応中です」と答える代わりに、カスタマーサポートチームは「すでに修正済みです!」と答えることができます。

人事向け Git

ある程度まで、ソフトウェア開発ワークフローによって誰を雇用するかが決まります。貴社の技術やワークフローに精通しているエンジニアを雇うことは常に役立ちますが、Git を使用することによっても他の利点が得られます。

従業員は、キャリアの成長の機会を提供する企業に惹かれるため、大きな組織と小さな組織の両方で Git を活用する方法を理解しておくことは、すべてのプログラマーにとって利益となります。バージョン管理システムとして Git リポジトリを選択することで、将来を見据えた開発者を惹きつける決断を行います。

予算管理担当者向け Git

効率性は Git のすべてです。開発者にとって、ネットワーク接続を介してコミットを渡すために無駄に使われた時間から、集中バージョン管理システムの変更を統合するために必要な工数までのすべてを排除します。さらに、作業できる安全な環境を与えることで、経験の浅い開発者を活用することもできます。これらはすべて、エンジニアリング部門の収益に影響します。

Git 分散チーム

ただし、これらの効率性は開発チーム以外にも広がります。マーケティングが、人気のない機能の販促用品にエネルギーを注ぐのを防ぎます。デザイナーはわずかなオーバーヘッドで実際の製品上の新しいインターフェイスをテストできます。顧客の苦情に即座に対応することもできます。

迅速であるということは、何が機能するかをできるだけ早く見つけ、成功する作業を強調し、成功しないものを排除することです。Git は、すべての部門が自分たちの仕事をより効率的に行っていることを確認することによって、すべてのビジネス活動の増幅器として機能します。

Git を学習する準備はできていますか?

この対話式チュートリアルを利用しましょう。

今すぐ始める