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

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

30 git  workflows  branching  gitflow 

通常、問題を回避するには注意するだけで十分ですが、時々、ランダムのソース管理パスをチェックして、作業中のブランチを再確認する必要があります（例：「うーん... devブランチにいますか？」）ファイル。 もっと簡単な方法を探して、それに応じてソリューションファイルに名前を付けることを考えました（例 MySolution_Dev.sln）が、各ブランチで異なるファイル名を使用して、ソリューションファイルをマージすることはできません。 大したことではありませんが、正しいブランチにいることをすばやく確認するために使用する方法や「小さなトリック」はありますか？TFS 2008でVisual Studio 2010を使用しています。

27 version-control  visual-studio  team-foundation-server  branching 

Gitでは「ブランチングは無料」とはどういう意味ですか？ 他のバージョン管理システムと比較してGitが言及されるたびに、これをよく耳にします。 他の人（SVNなど）に対処する機会がありません（？）。

27 version-control  git  branching 

新しいプロジェクトを開始するときはいつでも、「安定した」何かを得るまでマスターに直接コミットすることから始めて、ブランチで作業を開始するのが通常理にかなっています。 少なくとも、これは私が通常行う方法です。2番目のコミットからすぐにブランチを開始する方法はありますか？このようにするのは理にかなっていますか？明らかに、「初期コミット」は常にマスターになりますが、その後、いつ新しい機能のブランチを作成するのが適切なタイミングであるかがわかりますか？

26 version-control  git  branching 

gitブランチモデルに関する多くのアドバイスを見てきましたが、最も一般的な意見は、masterブランチで直接変更を加えることは悪い考えだと思われます。 同僚の1人がmasterブランチ上で直接変更を行うことを非常に喜んでおり、いくつかの会話にもかかわらず、彼らはこれを変更する可能性は低いようです。 現時点では、マスターに直接取り組むのは悪い習慣である同僚を納得させることはできませんが、私は彼の働き方と矛盾することを理解し、いつ再訪する必要があるかを知りたいですこの問題。

25 version-control  git  svn  branching 

私は同じソースコードを共有し、継続的に統合されている中規模のチームで働いていますが、私たち全員が同じブランチで作業しなければならないため、ビルドはほとんど常に壊れています。 また、壊れたビルドを軽減するために最近導入されたルールもあります。これは、ビルド中は誰もチェックインできないことを示しています。 そうは言っても、1日の間に誰もがチェックインできる10〜15分のウィンドウを持っています。 チームが成長するにつれて、チェックインの機会の窓はさらに小さくなります。そのため、開発者は変更をローカルに蓄積する必要があり、その結果、変更セットが大きくなり、変更が何も破壊しないことを保証するのがさらに難しくなります。悪循環を見ることができます。 このような環境で私が効果的に仕事を続けられるようにするために何をお勧めできますか。また、私はマネージャーではなく開発者であり、プロセスや他の人の行動をあまり変更できないことに注意してください。

25 version-control  teamwork  continuous-integration  builds  branching 

私は最近、自分のコードをバージョン管理下に置き始めました（私が働いているラボではSVNで、自分のコードはgithubで（明らかにgitで））。バージョン管理を使用する前に、私はこのようなことをしていました。バージョン番号の付いた多くのフォルダーの中に、ライブラリーの名前のフォルダーがありました。新しいバージョンで作業を開始するたびに、最後のバージョンのコピーを作成し、名前を新しいバージョンに変更して実装を開始します。 ただし、フォルダがバージョン管理下に置かれている場合、これはかなり冗長に思えます。冗長性は別として、誰かが最新バージョンを入手したい場合、彼import/ 彼女たちがちょうどあればすべてのバージョンをダウンロードするでしょうclone。 現在、バージョン管理を使用してこれを行う多くの方法を見ていますが、私はそれが初めてなので、どちらがより保守可能かはわかりません。 方法1：タグを使用する 私がタグを正しく理解していれば、メインブランチがあります。取得した変更をコミットし、バージョンでタグ付けします。次に、作業コピーを取得したい場合は、特定のタグが付いたコピーを取得します。（間違っている場合は修正してください） 方法2：分岐バージョン この方法では、メインブランチは開発ブランチになります。時々、安定したバージョンがv1.2.0作成されるとしましょう（たとえば）、そのバージョンのブランチを作成し、コミットしません。そうすれば、特定のバージョンをダウンロードする場合、そのブランチからコードを取得できます。私はあなたがそれにコミットすることは決してないと言ったが、バグ修正を行い、古いバージョンのブランチにコミットして古いバージョンを実行し続けることが可能かもしれない。現在のバージョンがある場合たとえばv2.0、しかし、使用したい人がいるv1.2、あなたはから別のブランチを取得することができv1.2、すなわち、v1.2.1およびバグ修正をコミット、またはちょうど同じバージョンを保持v1.2し、単にバグ修正をコミットします。 したがって、ブランチは次のようになります。 v1.2.1 v1.2.2 / / v1.0.0 v1.2.0--------- v2.0.0 / / / -------------------------------------- dev このようにして、マイナーバージョンアップデートごとにブランチを作成できます。（上のグラフでは、v1.2.1とv1.2.2、またはv2.0.0のリリース後に作成されたため、v1.2.0とv2.0.0の間の開発の一部ではないことに注意してください。古いバージョンのサポートと考えてください） 方法3：分岐開発 この方法は前の方法の反対です。メインブランチは最新の安定バージョンです。新しいバージョンで作業しているときは常に、（開発用の）ブランチを作成し、コードで作業し、安定しているときにメインブランチとマージします。 この場合、ブランチは次のようになります。 ________ ____ ________________ _____ dev / \/ \/ \/ ---------------------------------- latest_version おそらくこれはタグと組み合わせて行う必要がありますか？ 質問！ とにかく、私の質問はあなたの経験に基づいて、これらの方法のどれがより実用的であると証明しますか？そこに知られている最良の方法はありますか（おそらく私は自分自身を理解していなかった）？これらのことは一般的にどのように行われますか？

24 version-control  git  svn  branching  release-management 

私の会社では、すべての開発（バグ修正と新機能）は別々のブランチで行われています。完了したら、QAに送信し、QAがそのブランチでテストします。QAが青信号を出したら、メインブランチにマージします。これには、1日から1年かかることがあります。 ブランチでリファクタリングを絞り込もうとすると、どれくらいの期間「アウト」されるかわからないので、マージして元に戻すと多くの競合が発生する可能性があります。 たとえば、作業中の機能がこの関数を頻繁に使用しているため、関数の名前を変更したいとします。名前が実際には目的に合わないことがわかりました（これも単なる例です）。そこで、この関数のすべての使用法を見つけて、それらをすべて新しい名前に変更すると、すべてが完全に機能するため、QAに送信します。 その間、新しい開発が行われており、名前が変更された関数は、メインから分岐されているブランチのいずれにも存在しません。私の問題が再び統合されると、それらはすべて壊れてしまいます。 これに対処する方法はありますか？ 経営陣がリファクタリングのみの問題を承認するようなことはないので、他の作業に絞り込まなければなりません。mainで直接開発することはできません。なぜなら、すべての変更はQAを通過する必要があり、mainを壊したジャークになりたくないので、彼は少しの非本質的なリファクタリングを行うことができるからです。

24 version-control  refactoring  branching 

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

23 testing  git  branching  qa  gitflow 

私と私のチームは機能ブランチを使用しています（gitを使用）。マスターにマージする前に、コードレビューの最適な戦略はどれかと思います。 マスターから新しいブランチをチェックアウトし、fb_＃1と呼びます 私は数回コミットし、それをマスターにマージしたい 私がマージする前に誰かがコードレビューをすることになっています 現在、2つの可能性があります。 1日 私はマージ＃1 FB_するマスターを（いない最新のできるだけそれを作るためにマスターにFB_＃1） チームメイトがマスターヘッドとfb_＃1ヘッド間の変更を確認します fb_＃1で問題なければ、fb_＃1をマスターにマージします 長所：廃止されたコードはレビューされていません 短所：他の誰かが「1」の間に何かをマージする場合 および「2.」彼の変更はレビューに表示されますが、別のレビューに属します。 2番目 チームメイトがチェックアウト（git merge-base master fb_＃1）とfb_＃1 headの間の変更をレビューします 長所：機能ブランチでの作業中に変更された内容を正確に把握できます 短所：一部の古いコードがレビューに表示される場合があります。 あなたはどちらの方が良いと思いますか、なぜですか？別のより適切なアプローチがありますか？

22 git  code-reviews  branching 

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

22 git  refactoring  branching  gitflow 

一般的に、製品ライフサイクル中に複数のリリースがあり、以前の製品のサポートが必要な長期プロジェクトの場合、製品バージョンとコードベースの分岐を処理する最良の方法は何ですか？ より具体的な意味では、適切な分散バージョン管理（例：git）があり、チームの規模は小規模から大規模であり、開発者は一度に複数のプロジェクトに取り組んでいると想定します。直面している主要な問題は、その時点で存在していた古いバージョンをサポートする契約上の義務があることです。つまり、新しい開発では古いコードにパッチを適用できません（Microsoft Office製品がその例です。所有している機能年）。 その結果、各主要製品には複数の依存関係があり、それぞれのバージョンは年間リリース間で変更される可能性があるため、現在の製品のバージョン管理は複雑です。同様に、各製品には独自のリポジトリがありますが、ほとんどの作業はメインソーストランクではなく、その年の製品リリースのブランチで行われ、製品がサポートされるように製品がリリースされるときに新しいブランチが作成されます。これは、バージョン管理を使用するときに考えられるように、製品のコードベースを取得することは単純な問題ではないことを意味します。

21 version-control  versioning  branching  product-management 

機能ブランチを使用してチームでgitを操作するとき、歴史上のブランチ構造を理解するのが難しいことがよくあります。 例： 機能ブランチfeature / make-coffeeがあり、機能のブランチと並行してmasterでバグ修正が続けられたとしましょう。 履歴は次のようになります。 * merge feature/make-coffee |\ | * small bugfix | | * | fix bug #1234 | | | * add milk and sugar | | * | improve comments | | * | fix bug #9434 | | | * make coffe (without milk …

20 git  branching 

私は、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 

機能がテスト用にステージングされるようになると、規模が大きくなるにつれて問題に遭遇し始めますが、すべてがテストされ、承認された新しい機能がテスト用にステージングされます。 これは、テスト済みの機能と未テストの機能の組み合わせがあるため、本番環境にほとんどプッシュできない環境を作成しています。これは一般的な問題であると確信していますが、まだ私たちにとって良いリソースが見つかりませんでした。 いくつかの詳細： BitBucketのGIT Azureへのスクリプト展開用のJenkins 私が望んでいるのは、機能が環境を移動するときに機能を分離し、準備ができているものだけをプッシュする方法です。

19 git  continuous-integration  branching  devops