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

私は新しい開発者です-これが私の最初のプログラミング職です。 私の問題はこれです：私たちは使用しますgit-私はブランチからブランチを切り取り、develop割り当てられたマイナータスクの作業を開始します。私は経験が浅いので、とても遅いです。ブランチをdevelop他のブランチにマージする準備が整うまでに、多くの変更を行って競合を解決するのは圧倒的です（実際、作業を破棄してタスクをやり直すのは簡単なようですが、もちろん持続可能なソリューションではありません） ）。 どうすればこれを克服できますか？「コーディングが上手」以外の方法を使用できますか？私は来週、これを上司に報告するつもりです。

223 git  software  branching  merging 

プルリクエストを行うすべての深刻なGithubリポジトリが、コミットを1つのコミットにまとめるように要求するのはなぜですか？ gitログがあると思ったので、すべての履歴を調べて、どこでどのような変更が発生したかを正確に確認できますが、それを潰すと履歴から引き出され、すべてが1つのコミットにまとめられます。ポイントは？ これは「早期にコミットし、頻繁にコミットする」というマントラにも反するようです。

200 git  github  branching  pull-requests  etiquette 

現在、Pro Gitを読んでGitの使用方法を学んでいます。今、私は分岐とタグについて学んでいます。私の質問は、いつブランチを使用する必要があり、いつタグを使用する必要があるかです。 たとえば、プロジェクトのバージョン1.1のブランチを作成するとします。このバージョンを終了してリリースしたら、ブランチを残してリリースバージョンをマークする必要がありますか？または、タグを追加する必要がありますか？タグを追加する場合、バージョンブランチを削除する必要があります（マスターまたは他のブランチにマージされていると仮定します）。

141 programming-practices  version-control  git  branching 

現在、共有リポジトリにPHPアプリケーションのマスターブランチが1つあります。当社のソフトウェアの加入者であるクライアントは500人を超えており、そのほとんどが異なる目的のために、それぞれ個別のブランチにカスタマイズされています。カスタマイズは、異なるテキストフィールド名、まったく新しい機能またはモジュール、またはデータベース内の新しいテーブル/列にすることができます。 私たちが直面する課題は、これらの数百のカスタマイズされたブランチを維持し、クライアントに配布する際に、時々新しい機能を提供し、マスターブランチを更新し、更新するためにマスターブランチの変更をカスタムブランチにプッシュすることですそれらを最新バージョンに。 残念ながら、これによりカスタムコードで多くの競合が発生することが多く、すべての競合を解決するためにすべてのブランチを何時間も費やしています。これは非常に非効率的であり、これらの競合を解決する際に間違いは珍しくありません。 クライアントブランチをマスターブランチに合わせて最新の状態に保ち、マージ中の労力を軽減するより効率的な方法を探しています。

140 version-control  git  github  versioning  branching 

最初に、ソロ開発者としてのVCSについて多くの質問が寄せられていることを知っていますが、それらはあまりにも広範であることが多いです。これは分岐のみに関係しますが、依然として重複としてマークされています...想定される重複は、あまりにも広範で、特に分岐に関係しない別の質問の別の重複としてマークされています。それが私の質問のユニークな方法です。 ブランチを単独の開発者として使用する利点がある場合、それは何ですか？ソロ開発のコンテキストでも推奨されることがよくありますが、見る限りでは、開発に「マスター」トランクを使用し、作業用のリリース準備コードに分岐する以外に、どのように見えるのかわかりません開発プロセス全体を過度に複雑にすることなく、分岐の力を活用できます（たとえば、新しい機能を区分化するために）。

117 version-control  branching  solo-development 

最近まで、私の開発ワークフローは次のとおりでした。 製品所有者から機能を入手する ブランチを作成します（機能が1日以上の場合） ブランチに実装する メインブランチからブランチへの変更をマージします（後方マージ中の競合を減らすため） ブランチをメインブランチにマージする マージに問題があることもありましたが、一般的には気に入っています。 しかし、最近、継続的な統合や継続的な配信などを実践するのが難しくなるため、ブランチを作成しないというアイデアの信者が増えています。 Git、Mercurialなど 質問は、最近のブランチを使用する必要がありますか？

84 continuous-integration  branching  scm 

いくつかの異なるエディションを持つ製品があります。違いはわずかです。異なる文字列があり、一方のロジックはほとんど追加されておらず、もう一方のロジックはほとんど違いがありません。ソフトウェアの開発中は、ほとんどの変更を各エディションに追加する必要があります。ただし、そうでないものと異なる必要があるものがいくつかあります。release-editionAおよびrelease-editionB（..etc）ブランチがある場合、ブランチの有効な使用ですか？落とし穴はありますか？良い習慣？ 更新：皆さんの洞察に感謝します。多くの良い答えがここにあります。一般的なコンセンサスは、この目的のためにブランチを使用することは悪い考えだと思われます。不思議に思う人にとって、この問題に対する私の最終的な解決策は、構成として文字列を外部化し、プラグインまたはスクリプトとして異なるロジックを外部化することです。

72 git  branching 

gitは以下のシナリオの処理にどのように役立ちますか？ タスクは、バックエンドタスクとフロントエンドタスクの2つの部分に分かれています。プルリクエストを作成してバックエンドの変更をマージし、マージされるのを待ちます（そしてフィードバックに対処します）。待っている間、フロントエンドの変更はバックエンドの変更に依存しており、マスターブランチではまだ利用できないため、フロントエンドの変更を実際に処理することはできません。 まだレビュー中に、バックエンドの変更ブランチからフロントエンドの変更ブランチに変更を取り込む最良の方法は何ですか？

65 git  branching 

開発者は、各スプリントのマスターブランチへのストーリーの統合について懸念を表明するレトロコールを終了しました。開発者はすべて自分のブランチ内のコードを作成し、スプリントの終わりに向かってすべて1つのマスターブランチにマージします。 次に、ある開発者（通常は同じ開発者）に、すべてが他の開発者のコ​​ードとうまく統合されていることを確認するタスクを残します（ほとんどの変更は同じページにあります。たとえば、データ表示ストーリー、データフィルターストーリー、 SLAインジケータ）。 この負担を軽減し、コードをより簡単にマージするにはどうすればよいですか？私の観点からすると、POまたはSMがストーリーをより効率的な方法で優先順位付けすることで、同じスプリントでこれらの種類の依存関係がなくなるため、いくつかの問題が解決する可能性があります。他のみんなはどのようにこれに取り組んでいますか？または、これはプロセスの一部ですか？

42 agile  scrum  branching  stories 

動作するコードのみをコミットすることを要求するのは良い考えですか？ このコミットでは、リポジトリを次のように動作状態のままにする必要はありません。 ...設計の初期段階にありますが、コードはまだ安定していません。 ...あなたはプロジェクトの唯一の開発者です。物事がうまくいかない理由を知っています。さらに、壊れたコードをコミットして誰かの作業を停止することはありません。 ...現在、コードは機能しません。これに大きな変更を加えます。物事がugくなる場合に戻るポイントを得るために、コミットしましょう。 ...チェーンが長く、壊れたコードがローカルブランチに存在する場合は問題ありません。すなわち ローカルファイル ステージングエリア ローカルブランチでコミット リモートの個人機能ブランチでのコミット リモートdevelopブランチとマージ リモートmasterブランチとマージ リモートreleaseブランチとマージ ...早くコミットし、頻繁にコミットします。 したがって、上記のリンクされた質問では、回答の大半は、コンパイルできないコードをコミットしても、ローカルおよび機能ブランチでは問題ないと述べています。どうして？壊れたコミットの価値は何ですか？ 追加：ローカルブランチでは、好きなことは何でもできると言っている、非常に投票されたコメントがいくつかあります。ただし、質問の技術的な側面には興味がありません。むしろ、ベストプラクティス-業界で長年働いてきた人々が最も生産性を高めてきた習慣-を学びたいと思います。 膨大な量の素晴らしい答えに驚いています！彼らは、コードを整理するためにブランチを使用するのが十分ではないという結論に至ります。

40 version-control  git  branching 

複数のブランチが開発されていると言う、AとBだけでなく、増分「バグ修正」ブランチC。 今Cはすでに「完成」しており、マスターにマージされています。AそしてB、まだ開発中であり、（おそらく）別のバグ修正ブランチがmasterにマージされる前に修正されません。 C新しい機能ブランチにできるだけ早くマージすることをお勧めしますか？新しい機能がmasterできるだけ近くにあるように？それとも、新しい機能を完成させてからマスターにマージするだけで、独自の「世界」で開発することをお勧めしますか？ とにかく競合が発生するため、それらの修正に時間を費やす必要があります。

40 version-control  branching  merging 

現在、アプリケーションに新しい機能を追加するたびに新しいブランチを作成していました。 機能が完成して機能するようになったら、それをmasterブランチにマージします。 しかし、後で、この機能を更新する必要がある場合（改善など）、新しいブランチを作成する方が良いですか、マスターで以前のものをリベースする必要がありますか？更新してから再度マージしますか？ たとえば、Ruby on Railsアプリケーションにmodeling-memberというブランチがあります。後で、メンバーモデル（このブランチで作成された）にいくつかの属性を追加する必要があります。私は何をすべきか？このブランチをマスターでリベースし、モデルを更新して再度マージするか、単に新しいブランチを作成しますか？

36 git  branching 

10人のアジャイル開発者のチームがあるとします。毎日、彼らはボードからタスクを選び、そのタスクに対していくつかの変更をコミットします（1日の終わりまでに）。すべての開発者は、トランクに対して直接チェックインします（Googleスタイル、すべてのコミットはリリース候補であり、機能の切り替えなどを使用します）。 SVNのような集中型CVSを使用している場合、1人がコミットするたびに、ビルドサーバーは変更を統合し、他の9人の開発者の作業に対してテストします。ビルドサーバーはほぼ1日中継続的に実行されます。 しかし、gitのようなDCVSを使用している場合、開発者はタスクを完了するまで待ってから、ローカルコミットをすべて中央リポジトリにプッシュすることができます。それらの変更は、一日の終わりまで統合されません。 このシナリオでは、SVNチームはより頻繁に継続的に統合し、gitチームよりもはるかに迅速に統合の問題を発見しています。 これは、DVCSが従来の集中型ツールよりも継続的なチームに適していないということですか？この遅延プッシュの問題をどのように回避しますか？

34 git  svn  continuous-integration  dvcs  branching 

以前はgitを使用していましたが、Pythonに貢献したいので、今では水銀を学ぶ必要があり、非常にイライラします。 そこで、私はいくつかの小さなパッチを作成し、それらをローカルのMercurialリポジトリでコミットとして追跡したいと考えました。どうやら水銀の分岐を処理する4つの方法があります。1と4は完全にばかげているように見え、名前付きブランチはヘビーウェイトのようで、1コミットの迅速な修正のためにそれらを使用することになっていないので、ブックマークを使用しました。 今、私のパッチは拒否され、ブックマークブランチの1つをリポジトリから削除したいと思います。OK、gitではブランチを強制削除して忘れてしまうので、ブックマークを削除すると次の問題が発生します。 TortoiseHGは、hg logコミットとdefaultブランチに2つのヘッドがあることを示しています。そして、私が正しく理解していれば、追加のプラグインなしでhgのコミットを削除することはできません。 Mercurialにはハッシュだけでなく、リビジョン番号もあります。いくつかのコミットを追加したので、それ以降にプルされたすべてのコミットには、メインの中央リポジトリとは異なるリビジョン番号が付けられています。 ブックマークをhg update引っ張ってmaster最新のコミットに自動的に移動した後、実行しますが、TortoiseHGでそれを行う方法が見つかりませんでした。 何が間違っていますか？これは正常で予想されるもので、これらの問題を無視する必要がありますか？または、ブランチでどのように作業するのですか？

32 git  mercurial  dvcs  branching 

まず、いくつかの背景として、すべてのプロジェクトチームをgitの使用に移行し、特定のブランチを継続的に統合して監視できるようにリポジトリを編成する方法のガイドラインを策定しています。テストサーバーへの自動展開。現在、開発中の2つのモデルがあります。 最も安定したコードを表すmasterブランチ、最先端のコードの開発ブランチ、およびQAテストの準備ができたコードの統合ブランチでの成功したブランチングに関するnvie.comの記事の影響を大きく受けています。 マスターブランチが最先端の開発コード、QAテストの準備ができているコードの統合ブランチ、および展開の準備ができている安定したコードの本番ブランチを表す代替モデル。 この時点で、masterブランチが何を表すかに関しては部分的にはセマンティクスの問題ですが、masterブランチで積極的な開発を行っているのは実際には良い習慣ですか、それとも実際にはそれほど関係ないのでしょうか？

32 git  branching