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

状況 8人のエンジニアからなる私のチームは、次の大きな仕事のために（Subversionから）Gitに移行しています。Gitを手に入れるのが非常に難しいと感じている「経験豊富な」エンジニアが少数います。ユーザーマニュアル、トレーニング活動、ホワイトボードセッションを提供したにもかかわらず、私は同じ些細な質問をしました。数日のうちにすべてを拾い上げた2人のジュニアコンサルタントがいましたが、それが問題を明らかにしました。これはGitに限定されたパターンではありませんが、結果として目に見えるようになりました。 質問 学べない/学べないエンジニア、特にここにいる年功序列レベルのスタッフには特に好意的ではありません。ただし、チームが成功し、優れた製品を構築することを望んでいます。中央集中型のGit Flowモデルを使用していますが、すべての新しい用語がそれらを困惑させているように感じます。 これらの従業員がGitを学ぶのを支援するためにできることはありますか？ Sourcetreeは、チーム全体で使用されているクライアントです。

68 git  gitflow 

最近、Webアプリの機能（自動サインアップ）が管理者によって延期されるという問題が発生しました。彼らは、開始が「冷たすぎる」と感じていたが、彼らが取り組んでいた他のすべての機能を公開したかったためです。 問題は、この機能が次のリリースでライブをプッシュする予定の他のすべての機能と一緒に終了したときに開発にマージされたため、通常のようにdev-> test-> masterをマージできないことです。 この問題をどのように回避できたでしょうか？

53 project-management  git  gitflow 

通常のgitとgithubを使用して、マスターブランチに取り組んでいる機能ブランチのプルリクエストを作成するだけで、コードレビューを行うことができます。git-flowでコードレビューを行うにはどうすればよいですか？「git flow feature finish`」のようなワークフローでは、コードレビューが実際に行われる場所と、git-flowまたはgitがそのレビューを容易にする方法について混乱しています。

43 code-quality  git  code-reviews  github  gitflow 

私の会社はGitを使用しており、独特の分岐スキームを使用しています-作業はマスターで行われ、分岐はリリース用に予約されています。これは、反復で行われたすべての作業がブランチに行われる限り正常に機能しますが、重大な生産上の問題が発生した場合、作業が何らかの方法で両方のブランチに行われるようにする必要があります。 最近、私たちはそれらのブランチで「楽しい」ことをしてきました。これは管理上の頭痛の種であり、すべての作業がすべてのブランチに反映され、1つのブランチで修正された一部のバグは、誰かが指摘するまでマスターになりません。 しばらく前にGit Flowに出会いましたが、それが私たちの問題の解決策だと感じています-コードがリリースまで浸透していないか、ずっと下に浸透していません。唯一の問題は、私のリードがこの種の開発はアンチパターンであると述べていることです。つまり、2週間にわたって猛烈に開発し、マージの競合を解決するために3を費やしました。 同意するかどうかは定かではありませんが、それを育ててから、仕事は通常のように再開しました。ごく最近になって、これに関していくつかの大きな問題がありました。 私は知りたい-なぜこの種の開発スキームはアンチパターンと見なされるのですか？ で、それは本当にアンチパターン？

30 git  workflows  branching  gitflow 

ここに取引があります。私は新しい会社に入社し、ほとんど一年間触れられていないブランチの仕事を終えるように頼まれました。一方、マスターブランチは安定したペースで成長しています。masterブランチからのすべての変更をfeatureブランチにマージして、そこから作業を継続したいのが理想ですが、どのようにこれにアプローチするのかはよくわかりません。 ブランチの両側で重要な変更を保持しながら、このマージを安全に実行するにはどうすればよいですか？

25 version-control  git  gitflow 

私たちは、同じgitリポジトリで複数のプロジェクトに取り組んでいる大きなチーム（10〜12人の開発者と4人のqa）です。そのスプリングブートベースのバックエンドWebサービス。優れたgit分岐および展開戦略を探しています。また、機能が期待どおりに機能することを保証するqaチームもあります（ある程度のバグはありません）。 いくつかの記事を読んだ後、Gitflowモデルは私たちにとってうまく機能するだろうと感じました。ここに私の質問が来ます。 QAチームはどこで機能をテストする必要がありますか？ 彼らが機能ブランチでテストすれば、彼らはバグを発生させ、開発者はそれを修正し、それがQAテストに合格したら、開発のためにマージします。また、QAは開発ブランチで整数化テストを再度行います。 すべての機能をマージして（ユニットテストと開発者による基本的なテストの後）ブランチを開発し、そこからqaテストを行います。修正とテストもすべて開発中に行われます。 他の人にとってどのアプローチがうまくいったのか知りたいです。

23 testing  git  branching  qa  gitflow 

私たちはプロジェクトでGitHub Flowを使用し、ほとんどの場合、masterから新しい機能ブランチを開き、そこで作業を行い、PRを開き、コードを確認してmasterにマージします。 しかし、私の現在の仕事はで取り組んでいる別の問題に依存していfeature-branch-Aます。他のブランチからブランチを作成するのはコーシャーですか、それともGitHub Flowの精神に反するものですか？ 別の方法は、私のブランチをマスターに基づいて、feature-branch-A（頻繁に）変更をマージすることです。 GitHubフローではどのオプションが推奨されますか？

22 git  github  gitflow 

私は最近、bitbucketで実装されたGitFlowモデルの使用を開始しました。そして、私には完全に明確ではないことが一つあります。 リファクタリングタスクをバックログ、計画、および実装することにより、技術的な負債に定期的に対処しようとしています。そのようなリファクタリングブランチは、でマージされたプルリクエストで終わりますdevelop。私の質問は、リファクタリングブランチはGitFlowのどこに属しますか？ featureプレフィックスを使用することは最も論理的ですが、リファクタリングによって新しい機能が追加されることはないため、完全に正しいとは限りません。 しかしbugfix、実際のバグリファクタリングの修正がないため、プレフィックスの使用は適切ではないようです。 一方で、カスタムプレフィックスを作成することは、物事を過剰に設計しない限り複雑化するように思えます。 そのような状況はありましたか？これに対処するためにどのプラクティスを使用しますか？理由を説明してください。

22 git  refactoring  branching  gitflow 

私は非常に頻繁にプロジェクトのいくつかの機能に取り組んでおり、コミットするのに十分である前に休憩を取る必要があります。しかし、私は毎日2台の異なるコンピューターを使用してコーディングしています（ラップトップと研究室のデスクトップ）。例：自宅で機能の作業をしているときに、停止してラボに移動します。 クラウドの同期（Dropboxなど）とGitHubリモートトラッキングを混在させたくありません。 作業を続行するために他のコンピューターにコードを引っ張る目的でのみ、以前にコードの未完成（および乱雑な）状態をコミット（およびプッシュ）しました。これは悪い習慣だと確信しています。 しかし、今日は、git stashグーグルで少し見つけました。それは私が必要なものに対する完璧な解決策のようです。 ただし、ドキュメントに、変更をプッシュした後にgithubに移動するかどうかは記載されていません。それに加えて、必要なモビリティを達成するためのより効率的な方法があるかどうかを知りたいです。 前もって感謝します！

20 git  github  gitflow 

私は、nvieのgit-flowのモデルにほぼ従うgit分岐モデルを持つプロジェクトを持っています。 リリースブランチは、SemVer形式で名前が付けられます。たとえば、v1.5.2 リリースブランチに本番環境の青信号が与えられたら、マスターにマージしてタグを適用し、ブランチを削除してブランチを閉じます。 リリースブランチをすぐに削除するので、ブランチのタグ付けに同じ識別子を使用しました。例えば v1.5.2 リリースブランチを閉じるために使用するコマンドは次のとおりです。 $ git checkout master $ git merge v1.5.2 $ git tag -a v1.5.2 -m "Version 1.5.2 - foo bar, baz, etc" $ git branch -d v1.5.2 $ git branch -dr origin/v1.5.2 $ git push origin :v1.5.2 $ git push $ git push --tags これは大部分のケースで機能するようですが、gitリポジトリの別のインスタンス（別の開発マシン、ステージング環境など）がv1.5.2ブランチのローカルチェックアウトを持つシナリオで問題を引き起こしています。 …

20 version-control  git  branching  gitflow 

私たちは約200人の開発者で構成される組織であり、特定の日にリリースされる予定の1つの製品（リビジョン管理Gitを使用）で継続的に作業しています。 開発者が非常に多いため、各チームに約10人の開発者がいる「クロスファンクショナル」チームを作成しようとしています。その結果、組織内に約20の開発チームができます。 メインリポジトリ内の製品の継続的な「高水準」（開発者がプルするとき、製品が少なくともコンパイル可能であることなど）を維持したいので、何らかの品質ゲートを使用したいと思います。 質問の言い方が少しわかりませんが、単一の製品に取り組んでいるこのような大規模な開発者グループの開発方法論に関するアドバイスを得ることができるかどうか疑問に思っています。 私たちの意見では、スペクトルの一端は各開発者がメインリポジトリに直接コミットできるようにすることですが、開発者/コミットの数が多いため、「メインリポジトリ」が常に壊れた段階にある可能性があることを恐れていますコミットごとに厳しい「品質ゲート」を持つことはできません。 スペクトルのもう一方の端は、（メインリポジトリ）に3つのプルソースのみがあり、これら3つに少数の信頼できるプルソースのみがあるツリーまたはピラミッド構造のようなものです（Linus Torvalds / Linuxが行うと思います）しかし、そのような構造では、変更が「メインリポジトリ」に入るために登るには長いチェーンがあると感じています。さらに、マージの競合が発生した場合、「元の開発者」以外の別の開発者に問題が発生します。 この背景情報と意見をすべて述べた上で、非常に多くの開発者に推奨される開発方法論をどのように学び、読むことができますか？大規模な組織（Microsoft、Facebook、Ubuntuなど）はどのように開発を構成していますか？

19 agile  workflows  software  development-methodologies  gitflow 

私は自分のプロジェクトに取り組んでいる初心者プログラマーとしてあなたに来ます（これは順調に進んでいます）。私の共同創立者はプログラミングの方法も学んでおり、おそらくいくつかの問題を修正し、何らかの問題を起こせるようになりました。 彼は非常に良い質問をしました。それは「この仕事はどうするのか」でした。私は他の誰かとプログラムしたことがないので、私が理論化するだけの何か。最適なワークフローを教えてください。gitを使用します。 システムの特定の部分を所有する必要がありますか？コードをチェックインしていますか？コードレビュー？ > 1開発者とどのように連携しますか？

18 git  github  gitflow 

私はいくつかのプロジェクトをgit flowワークフローに移行しましたが、それが大好きです。ただし、一度に複数のメジャーバージョンが維持されているプロジェクトで作業する場合、物事をスムーズに進めるベストプラクティスは見つかりませんでした。 具体的には、「無料版」や「有料版」などのパラレルモデルを維持していません。バージョン1がリリースされ、マイナーバージョン（1.1、1.2などでサポートされているプロジェクト）について話しているのです。 。）バージョン3がリリースされるまで、その時点で2と3が維持され、4がリリースされるまで... gitflowワークフローでプロジェクトの2つ以上のサポートされているバージョンを一度にどのように維持しますか？

18 git  workflows  gitflow 

私たちのチームは、FogBugz＆Kiln / MercurialからJira＆Stash / Gitに切り替えました。ブランチにはGit Flowモデルを使用し、機能ブランチからサブタスクブランチを追加しています（Jira機能のJiraサブタスクに関連）。プルリクエストを作成して親ブランチにマージするときにStashを使用してレビュアーを割り当てます（通常は開発しますが、サブタスクは機能ブランチに戻ります）。 私たちが見つけている問題は、複数の開発者が同じ機能、たとえばフロントエンドとバックエンドで相互に依存しているコードで作業している場合、機能ケースの最適な計画と内訳でもです。別のブランチでは、1人の開発者が他の開発者をブロックします。 開発中に、お互いのブランチ間をプルしようとしました。また、各開発者が複数のブランチからプルして、開発時に統合をテストできるローカル統合ブランチを作成しようとしました。最後に、これはこれまでのところ私たちにとっておそらく最もうまく機能しているようですが、もう少しオーバーヘッドがありますが、機能ブランチからすぐに統合ブランチを作成しようとしました。サブタスクブランチ（機能ブランチ外）がプルリクエストとコードレビューの準備ができたら、これらの変更セットをこの機能統合ブランチに手動でマージします。その後、関心のあるすべての開発者は、その統合ブランチから他の依存サブタスクブランチにプルできます。これにより、コードレビューに合格するために依存しているブランチを誰も待つことができなくなります。 これは必ずしもGitの問題ではないことを知っています。これは、独自の作業プロセスと文化が混在する、複数のブランチで相互依存するコードを操作することに関係しています。開発（厳密な統合ブランチ）のための厳格なコードレビューポリシーがない場合、開発者1は、開発者2が引き出せるように開発にマージできます。もう1つの複雑な点は、QAに機能を渡す前に、コードレビュープロセスの一部としていくつかの予備テストを行う必要があることです。バックエンド開発者2が終了し、プルリクエストがコードレビューに1週間座っている場合、フロントエンド開発者2はコードレビューアができないため、技術的にプルリクエスト/コードレビューを作成できませんバックエンド開発者2 'のためのテスト 結論として、これらのインスタンスでは、どのルートに行くかに応じて、パラレルではなくはるかにシリアルなアプローチで自分自身を見つけており、これを回避するために使用するプロセスを見つけたいと考えています。 最後に言及することは、コードのレビューとファイナライズが完了していないブランチ間でコードを共有することで実現していますが、本質的には他のベータコードを使用しています。ある程度まではそれを避けることはできないと思いますし、ある程度それを受け入れるつもりです。

17 git  workflows  branching  jira  gitflow 

この問題は次のことを示しています。 私の理解では、マージする前にリリースブランチに（マスターブランチではなく）タグを配置するのが正しいので、実際にはgit describe --devsブランチからタグを見つけることができます。＃374を参照 一方、別の投稿： 今日、誤って0.4.2-preバージョンをhomebrew経由でインストールしましたが、そのバージョンでのタグ付けの仕組みに混乱しました。以前（バージョン0.4.1）は、リリースブランチがマージされた後、マスターブランチでタグが作成されました。今では、リリースブランチの最後のコミットでタグが作成されているようですが、これは私にとっては良い考えではないようです。特に、gitタグに依存し、HEADがタグ付きコミットの場合はリリースバージョンを作成し、次のいずれかのコミットの場合は開発バージョンを作成するビルドシステムがある場合。誰かがこの変更の背後にある論理を私に説明できますか？また、セマンティックバージョニングに関しては、これがパッチレベルのバージョンバンプであるとは考えません。 私たちのチームでは、これについて複数の議論を行いました。タグをmasterブランチから作成する必要があることを示すものもあれば、releaseブランチを好むものもあります。gitflow画像によると： タグがマスターに配置されているように見えます。

16 gitflow