タグ付けされた質問 「gitflow」

一般的に呼ばれる、Git-flowモデルの修正プログラムは、特定のhotfix-*ブランチに導入され、リリースの直前に小さな統合修正がrelease-*ブランチに導入されます。前のバージョンからの一般的なバグ修正には場所がないようです。 どこに表示されますか？彼らbug-*はdevelop（ちょうどfeatureブランチのように）分岐する独自のブランチにあるべきですか？

14 git  gitflow 

ずっと前に、私が仕事をしている小さなWeb開発者チームは、Web開発にgitを使い始めました。当時は、ステージングまたはマスターに直接コミットし、2つの間で頻繁にマージしていました。それは何もないよりはましでしたが、混乱でもありました。 少し前に、gitflowワークフローを採​​用しました。それは確かに前に来た混乱よりも優れていますが、やや面倒で過度にリリース/マイルストーン指向です。私の仲間の開発者は、それがどのように機能するのか、何をマージすべきか、何をマージすべきでないのかを明確にするように頻繁に頼まれます。一般的に、リリースの特定のマイルストーンを追跡せずにコードを頻繁にデプロイするWeb開発作業には適さないようです。 友達の最近の提案で、GitHub Flowを見始めました。ここでスコットチャコンの投稿を読むと、これで問題が完全に解決されます。 それでは、なぜGitHubでgit-flowを使用しないのでしょうか？まあ、主な問題は、常に展開することです。git-flowプロセスは、主に「リリース」を中心に設計されています。運用環境に毎日（多くの場合1日に数回）展開するため、実際には「リリース」はありません。 FWIW、私はアトラシアンのサイトでこの素敵なワークフローのまとめを見ました：https ://www.atlassian.com/git/workflows#!workflow- feature-branch しかし、それらはすべて、小さなチームでのWeb開発には不適切な選択肢のように見え、頻繁な/毎日のリリースではなく、主要なアプリケーションリリースを対象としています。 これは、git-flowとgithub-flowを比較するよう求めるSEに関する質問です /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -フロー それは一般的に良い答えですが、下のコメントで言及したように、meta.programmers.SEは一般的なワークフローのベストプラクティスに関する質問がここにあることを示しているようで、単なるgit-flowやgithubよりも幅広い回答のリストを期待していました-ウェブ開発に固有のフロー。したがって、ここで新しい質問が必要だと思います。 それで、かなり継続的な展開を伴うプロジェクトに取り組んでいる小規模なWeb開発チームにとって、最適/推奨のgitベースのワークフローは何ですか？それはgithub-flowか何かですか？

12 web-development  git  gitflow 

私はジュニアチームメンバー（生協）にgitを紹介しています。 追加、コミット、プッシュ、プルの基本的な操作に慣れています。 次に、プルリクエストとブランチにそれらを紹介したいと思います。 ブランチでプルリクエストを実行し始めた場合、進行中の作業にも同じことをする必要がありますか？ プルリクエストをマージするのは私です。ブランチで作業するのが最も理にかなっているかどうかはわかりませんでした（通常、私は知っている良い習慣ですが、2人の開発者が1人のジュニアといるこの特定の状況に興味があります）そしてもしそうなら、私は自分のブランチをマスターにマージするだけだということを意味します。とにかく自分の仕事/ブランチのプルリクエストを行うこともできますか？通常、これらの変更には基本的なgithub機能分岐ワークフローを使用します：https : //www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow 私が唯一の開発者である場合、自分のリポジトリでプルリクエストを使用する目的はありますか？便利ですが、それほど具体的ではありません。 プロジェクトに2人での作業の流れはいただきました！また、より一般的なようです そして 公式リポジトリまたは私のフォークのブランチからプルリクエストを開く必要がありますか？フォークについてのようです。

11 git  github  gitflow  pull-requests 

私の職場のチームは、VCSとしてSubversionを使用して新しいプロジェクトを開始しています（この質問の目的のために、これは固いものと考えることができます）。私たちはまだプロジェクトの初期段階にあり、分岐モデルについて合意しようとしています。以前のプロジェクトは非標準バージョンモデルに基づいていたため、既存のリリースのホットフィックスとパッチを管理するときに問題が発生しました。 さまざまな分岐モデルがかなり複雑であることがわかりましたが、私がかなり明確に理解しているモデルの1つはgit flowです。Subversionでこれのバリエーションを実装するのがどれほど難しい/望ましくないか知りたいです。明らかに、ブランチで協力している人々の点でいくつかの違いがあります。機能ブランチはローカルリポジトリに限定するのではなく一元化する必要がありますが、モデルの他の概念は、私が理解しているようにSubversionで再現可能でなければなりません。 このアプローチの欠点または課題は何でしょうか。私が聞いたのは、SVNではGitに比べて「マージは高価です」ということです。しかし、これが実際に何を意味するのか、それがブランチモデルのようなgitフローを使用する能力にどのように影響するのかについては、完全には明らかではありません。 このアプローチの最大の懸念は何でしょう。Subversionでより自然な同様の明確なアプローチはありますか？

10 svn  branching  gitflow 

プロジェクトでgitflowの使用を開始しましたが、未処理の機能ブランチと新しく作成した修正プログラムがあります。gitflowワークフローに従って、ホットフィックスはマスターブランチと開発ブランチの両方に適用されますが、現存する機能ブランチについては何も言われておらず、行われていません。 それでも、修正プログラムの変更を機能ブランチに組み込みたいと思います。これは、できる限り3つのオプションを残します。 変更を組み込まないでください。機能ブランチに変更が必要な場合、それは機能ブランチの一部であるはずです。 マージ開発機能ブランチに戻ります。これはgitflowワークフローに最もよく従うようですが、順不同のコミットを引き起こします。 機能ブランチを開発にリベースします。これはコミットの順序を保持しますが、リベースは一般的なgitflowワークフローには完全に存在しないようです。 ここでのベストプラクティスは何ですか？

10 git  gitflow 

gitflowを使用すると、release-1.0.0ブランチを作成してそれを両方masterとにマージするとdevelop、両方のブランチでコミットが失われます。 masterrelease-1.0.0マージ先のコミットはありませんdevelop developrelease-1.0.0マージ先のコミットはありませんmaster 代わりに、後にhotfix-1.0.1作成され、にマージmasterマージされているとき、develop、マージにコミットコミットどこ以前に含まれますrelease-1.0.0にマージされましたmaster。したがって、次のようになります。 User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'. * merge release-1.0.0 to master * merge release-1.1.0 to master * Fix shopping cart critical bug この音が混乱した場合、あなたは簡単にあなたが見るこのeverytieが気づくことができdevelop、通常の背後にあるコミットのカップルであるmaster（たとえ開発し、理論的には、必要があるだけで、それはメインブランチだから先になる。これらのコミットからマージされるrelease-x.x.xまでmaster）。 クリーンな履歴を維持するには、これをどのように処理する必要がありますか？

9 git  gitflow 

アプリとgitflowのA / Bテストを処理するためにどのような戦略を使用していますか。 概要： 私たちは、大きなアプリを開発して維持する6人のプログラマーのチームです。これまでのところ、私たちはgitflowに取り組んでおり、数年前から完全にうまく機能していたプロセスにいくつかのアドオンを追加しました。簡単に言うと、次のように使用します。 マスターブランチ（公開バージョンのコードのみ） 最終的な冗長性テストの後にマスターにマージするリリースブランチ 極端な場合にのみmasterブランチと対話する修正プログラム 開発とモジュールの完成とテストが完了した時点で蓄積され、最終的にリリースにマージされます。 / featureは、開発から分岐し、それらが完了してテストのさまざまな段階を通過すると、機能を追加する開発にマージして戻る機能のグループです。 / fix_developは、以前のバージョンで発生したバグの修正を含む機能のグループであり、ホットフィックスを開始するのに緊急ではないものです。 アプリが進化するにつれ、UXチームや他の利害関係者チームとともに、新しいリリースに2つのバージョンがあり、ユーザーがいずれかのバージョンを好むかどうかに基づいて、より強力なA / Bテスト戦略を採用しています。ユーザーにとって意味のあるバージョンである必要があります。 それを説明したら、問題は次のとおりです。gitflow でA / Bテストバージョンのコードを管理するために、どのような戦略を使用または推奨しましたか？ 私が検討したオプションは、どういうわけか一貫性がありません。たとえば、AブランチとBブランチをマスターからブランチしてから、リリースブランチをどちらかに結合します。リリースブランチに含まれるコードを機能に分離する方法を知りません。枝。別のオプションは、リリースAとBのブランチを作成し、AとBのブランチを開発することです。これは、ブランチが多すぎてチームメイトにとって混乱のように思えます。 あなたの意見を聞いて、ありがとう！ 更新： 開発するアプリはAndroidアプリであり、A / Bテスト用にPlayStoreプラットフォームを使用してA / Bテストを実装しています。これには、2つのAPKを作成し、そのうちの1つをロールアウト％でアップロードする必要があります。また、物事をよりシンプルに保つため、またボタンの位置よりも変更が大きい場合があるため、1つのAPKにAおよびBテスト用の独自のスイッチを追加しないことにしました。

8 acceptance-testing  gitflow  development 

私のプロジェクトはGit Flow分岐モデルに従っています。開発はで行われdevelop、masterリリースにマージされ、タグが付けられます。修正プログラムは、現在のブランチから分岐しmasterます。 ただし、現在の開発では修正プログラムも必要なので、各修正プログラムのブランチもマージさdevelopれます。 これにより、非常に見苦しいリビジョングラフが作成されます。特に、開発/ホットフィックスは、短い時間枠で頻繁にマージされます。 これは一般にGit-Flowで発生する問題ですか？簡単な修正はありますか？

8 git  gitflow