web-dev-qa-db-ja.com

Web開発のためのGITワークフロー

ずっと前に、私が一緒に働くウェブ開発者の小さなチームが、ウェブ開発にgitを使い始めました。当時は、ステージングまたはマスターに直接コミットし、2つの間で頻繁にマージしていました。何もないよりはましでしたが、それもまた混乱でした。

少し前にgitflowワークフローを採​​用しました。それは前に来たカオスより確かに良いですが、やや面倒で過度にリリース/マイルストーン志向のようです。私の仲間の開発者は、それがどのように機能するのか、何をマージする必要があるのか​​、何をマージしてはならないのかを明確にするように頻繁に尋ねられます。一般に、コードを頻繁に展開し、リリースの特定のマイルストーンを追跡しないWeb開発作業には適さないようです。

友人の最近の提案で、私は GitHub Flow を見始めました。読む スコットチャコンの投稿はこちら これで問題点に完全にぶつかります：

それでは、なぜGitHubでgit-flowを使用しないのですか？さて、主な問題は、常に展開することです。 git-flowプロセスは、主に「リリース」を中心に設計されています。実稼働環境に毎日（多くの場合1日に数回）展開するため、実際には「リリース」はありません。

FWIW、私はまた、アトラシアンのサイトでワークフローのこの素晴らしいまとめを見てきました： https://www.atlassian.com/git/workflows#!workflow-feature-branch

ただし、それらはすべて、小規模なチームでのWeb開発の選択としては不十分であり、頻繁なリリースや毎日のリリースではなく、主要なアプリケーションリリースを対象としています。

これは、SEでのgit-flowとgithub-flowの比較を求める質問です https://stackoverflow.com/questions/18188492/what-are-the-pros-and-cons-of-git-flow -vs-github-flow

これは一般的には良い答えですが、以下のコメントで述べたように、meta.programmers.SEは一般的なワークフローのベストプラクティスに関する質問がここにあることを示しているようで、git-flowとgithubよりも幅広い回答のリストを望んでいました-フロー、Web開発に固有です。したがって、ここで新しい質問が必要になると思います。

これで、かなり継続的なデプロイメントを伴うプロジェクトに取り組んでいる小規模なWeb開発チームにとって、最も優れた/好ましいgitベースのワークフローは何だと思いますか？ github-flowか何かですか？

web-developmentgitgitflow
12
jb510

最初に、調査したさまざまなワークフローの概要を簡単に説明します。これは、現在取り組んでいる開発の種類には適していないと思います。

  • Centralized（ Source ）：SVNワークフローによく似ていますが、現在は分散環境にあります。すべての開発者がmasterの個人用コピーに取り組み、変更をOrigin/masterに直接またはプルリクエストを介してプッシュします。

  • 機能ブランチ（ ソース ）：ええ、それ。特定の機能に取り組むすべての開発者は、その機能専用の特定のブランチに取り組む必要があります。この機能ブランチは、masterまたは別の機能ブランチから作成する必要があります。最終的にはすべてがmasterにマージされます。

  • Gitflow（ Source ）：2つの主要なブランチがプロジェクト履歴を追跡します、developおよびmaster。 hotfix、release、およびfeatureと呼ばれる別の3つのブランチは、masterに直接加えられた変更を保持して、重大な製品のバグを修正し、バージョン番号やその他の詳細を変更してから、 Feature branchのように、特定の機能をリリースまたは処理します。

  • GitHubフロー（ ソース ）：開発者はfeatureからmasterブランチを作成します。変更はプルリクエストを介してプッシュされます。 masterに受け入れられた変更は、GitHubボットHubotによってすぐにデプロイされます。

質問の開発部分については、答えはチームの背景によって異なります。それらはSVN環境からのものですか？次に、SVNに最も似ているので、集中型のアプローチを使用する必要があります。彼らはGitでの作業に満足していますか？次に、チームのワークフローをそれらのワークフローに適応させようとせず、ニーズに合わせて作成された独自のワークフローを実装する必要があります。

後者の改善にも力を入れるべきだとも思います。 デプロイメントパイプライン はどのように構成されていますか？ 「 継続的デリバリー：ビルド、テスト、およびデプロイメントの自動化による信頼性の高いソフトウェアリリース 」では、開発者はまれなデプロイメントの考えられる原因を特定します。

  • 展開プロセスは自動化されていません。
  • テストには時間がかかります。
  • 人々はビルド/テスト/デプロイのプロセスを理解していません。
  • 開発者は、小さなインクリメンタルな変更を加えることでアプリケーションの動作を維持することについて規律を守っていないため、既存の機能を頻繁に壊す

それらの何かはあなたが改善できるもののように聞こえますか？おそらく、あなたとあなたのチームがプロジェクトのこの部分をどのように処理するかについてもう少し詳しく教えてください。

7
Hernán Erasmo