それはバージョン管理システムになると、Gitは実際にアジャイル開発のレベルを表しています。強力なオープンソースのシステムとしてGitは、どのチームのワークフローを一致させるために必要な強力な柔軟性があります。そして、これは、集中型に比べ、分散、システムは、より優れた性能特性を与えることができ、そして、彼らは問題がないと思いますし、その後チームに放出ために自分自身を変更する場合、開発者は自由にローカルで試すことができます。
柔軟性および分散の効果に加えて、Gitのの主な機能は、アジャイル開発をサポートし、強化することです。Gitはモノリシックリリースと集中バージョン管理システムと比較して、すべての変更がより迅速に展開することができ、アジャイル開発の一部とみなされます。
専門家のヒント：
Gitは分散型バージョン管理システム（DVCS）です。CVSやSubversion（SVN）と異なるの他のツールと、Gitは、開発者は、メインコードベースと平行なストレージと、チーム・リポジトリ内の個々の分岐に特有作成することを可能にします。これらの手作りのコピーはフォークと呼ばれています。フォークの作業が完了した後、開発者は容易に、メインコードベースへの変更をアップロードすることができます。
方法の一つ：Gitリポジトリのブランチとみなさ開発タスク
製品の特徴は、洗練さと製品ロードマップに追加し、準備開始後も開発チームは、Gitは戦場に出ます。しかし、公式の開発チームは、クラッシュコースを開発するための迅速な機能を持っている必要があります前に：製品設計、品質保証（QA）、機能を開くために、研究開発は、特定の機能に開始します、プロジェクトのスコープと何に分類され、これらの機能の完了を確保するために、タスクの種類の用語は、コンセンサスに到達します。これらのタスクは、ユーザーストーリーの解体が完了したと呼ばれた後、タスクを各開発者に割り当てられます。Gitはまた、この時点で私たちのアジャイル開発プロセスに参加します。
Worktileで、我々はそれが新しい機能、バグの修理または既存のコードへの調整であるかどうかを、それぞれの新しいブランチのために別のタスクを作成し、すべてのコードの変更は新しいブランチ開発ブランチを作成し、私たち機能が完全に終了した後、それが私たちの安定した枝や他のブランチを開発するためにプル要求を提出される、管理者またはその他の権限のメンバーは、マージコードの後、コードレビューを合併しています。
中央のコードベースでのチームワークが簡単に可能にしながら、アプリケーションタスクの支店は、直感的になります。あなたは枝の開発を作成したら、それは彼らが実際に独立した中央のコードベースの個人的なコードライブラリがあることを意味します。
アジャイルチームを作成し、枝を対応する機能ユーザーストーリーに分割すると、開発チームのメンバーが一人で自分のタスクを処理できることを意味し、同じコードベースに基づいて、異なるストレージでの作業。開発者は、あまりにも多くの依存関係がありますので避けて、開発プロセスを遅らせるだろう別の小さなタスクにプライマリストレージに集中することができますので、開発努力は、増加していません。
専門家のヒント：
タスクのブランチの設定に加えて、あなたはまた、Gitのブランチの他のタイプを設定し、それらの間の共存と互換性がありますすることができます。例えば、我々はそれが将来のバージョンを開発するために他の開発者には影響しませんが、開発者はさらに発展し、特定のバージョンのための作業計画の安定性を強化できるようになるリリースブランチの単一のセットの異なるバージョンを提供することができます。
あなたはリリースのシングルブランチを作成した後、定期的および関連する機能は、将来のバージョンと互換性を持つことができると役割を果たしていることを確認するために、メインブランチタスクに融合の必要性。バックログを最小限に抑え、最高の計画リリース日に近いリリース枝の単一バージョンを作成するために。
方法2：多分岐の利点をフルに活用するには、個別にテストすることができます
テスト：枝が完了したとの可能なコードレビューとみなされると、Gitはアジャイル開発プロセスにおける他の重要な役割を果たし始めました。成功したアジャイルチームのコードレビューと自動テスト（継続的インテグレーション）。コードのレビューとテストを完了するために、開発者が直接、他のチームメンバーが分岐がプルリクエストを提出した後、完了している確認することができます通知することができます。簡単に言えば、要求は他の開発者は、あなたがブランチをメインブランチにマージテストすることができました良い仕事を行います依頼することです引き出します。
ツールが適切に使用されている場合は、継続的インテグレーションサーバでは、合併前に提出されたプルリクエストを作成して検出することができます。これは何の問題は、枝をマージしないことを保証します。様々な枝の間の差異がある場合、Gitのできる各支店とメインのコードベースの違いを区別するため、通常の状況下で、我々は、それが簡単にバグ修正と競合を再配置することができます。
専門家のヒント：
ブランチのメインブランチにマージ長時間実行していないが、アジャイルと反復チームの能力に影響を与える可能性があります。長時間実行支店がある場合は、コードベースの2つの異なるバージョンが実際に存在することを意味し、これは直接、より紛争やバグ修正の仕事につながります。最善の解決策は、短期的な分岐が小さなタスク、より詳細なスプリント計画にユーザーストーリーもと劣性（暗い部分）と、できるだけ早くこれらを達成するための他の方法として、コードをマージすることができます設定することです。
方法3：Gitはアジャイル開発の透明性と品質を確保
通常、効率、テスト、自動化と全体的な敏捷性と関連するのGit /敏捷性の物語。メインブランチに分岐後、アジャイルワークフローは完了です。同様に、コードをマージする提出プル要求した後、コード補完は、同時に、作業文書はすべてのチームメンバーが他の活動は、コードを停止し、すでに解放することができます持って、完了したことを意味します。これは、アジャイルチームが迅速かつ自信を持って頻繁にリリースを行なうことができる可能になります。これは、成功したアジャイルチームのサインです。
専門家のヒント：
定期的に問題がアジャイル開発の鍵となります。Gitのワークフローの俊敏性は、私たちが主枝が健康で滑らかされていることを確認する必要があり、適応するためにしてみましょう。これは、機能が整っていない場合は、あなたが再発の次のバージョンまで待つことができることを意味します。チームは毛周期の短いバージョンを試してみたい場合は、それも可能です。
技術とコラボレーションについて多くの質問を交換へようこそ。
記事のソースを明記してください。