問題タブ [git-workflow]

これは、現在従うワークフローです。

1. develop機能を完成させてブランチにマージする
2. release開発からブランチを作成する
3. releaseブランチでビルド スクリプトを実行する
4. releaseブランチをマージするプル リクエストを作成します。master
5. releaseブランチのプル リクエストを受け入れてマージする
6. masterその後、デプロイ コマンドを実行して、ブランチをライブ サーバーにデプロイできます。

これはすべてうまく機能しますが、私の Git リポジトリでは、ブランチを にマージするプル リクエストから発生したマージ コミットがないため、ブランチが同期されていませmasterん。しかし、ブランチを取得するためのプル リクエストからのマージ コミットが含まれるようになったため、先を行っています。developreleasedevelopmasterdevelopreleasemaster

Bit Bucket で同期をクリックしてすべてのブランチを最新の状態にできますが、これは奇妙なプロセスのように感じられるので、ブランチを自動的に同期させた方がよいでしょう。

または、それらが同期していなくても問題ないのでしょうか?

慣れていない場合に備えて、Git Flow プロセスへのリンクを次に示します: http://nvie.com/posts/a-successful-git-branching-model/

ありがとう。

私のチームでのワークフローは次のとおりです。

• いつでも複数のアクティブなブランチがあります。v4開発は、アプリケーションの 2 つの異なるバージョン (たとえば、まもなくリリースされるバージョンとv5、遠い将来にリリースされる予定のバージョン) に対して、2 つ以上のブランチに並行して着地します。私たちは定期的に にマージv4しv5ます。
• v4またはで直接作業する人はいません。私たちはフォーク内のフィーチャー ブランチで作業し、アップストリームまたは(Atlassian Stash を使用) をv5指すプル リクエストを作成します。v4v5

私が新しい開発を作成するとしましょう。新しいブランチを作成します。

git checkout -b SOMETHING_FOR_V4 v4

今、私はにいSOMETHING_FOR_V4ます。私はコミットしてプッシュします：

git push -u origin SOMETHING_FOR_V4

リモート追跡ブランチを設定した-uので、次に何かを更新するときは、git pushブランチを指定せずに実行でき、Git はプッシュ先を認識します。

しかし、時間が経ち、リベースしたいと思っています。

はっきりと伝える必要がありますgit rebase origin/v4

逆に、origin/v4ブランチの作成時にトラッキング ブランチを設定することもできますが、プッシュするgit push origin SOMETHING_FOR_V4たびに毎回言わなければなりません。

私が望んでいるのは、Git がリベースする必要があることを十分に認識できるようにすることです。git rebaseを行った後に言ったらgit push -u、プッシュ時に指定したリモート追跡ブランチが必要になりますが、これは私が望んでいるものではありません。

基本的には、別の追跡ブランチ(最初にプッシュするもの)と別の追跡ブランチgit push(最初にリベースするか、開始した [1] に依存するもの) を使用したいと考えています。git rebasev4v5

この種の動作を取得することは可能ですか?

または、自分が「近い」か、v4またはv5(エイリアスでフェッチとリベースを自動化することを考えています)かどうかを確認するには、どのコマンドを使用しますか?

v4[1]このシナリオでは、たとえば、またはそのリモートから始めたものの上にリベースできますorigin/v4。自分で同期を維持できるv4としましょう。origin/v4

チームに参加する新しいジュニア開発者がいて、プロジェクトに貢献したいと考えています。問題は、経験不足のために大量のガベージ コミットが予想されることと、最初にすべてのコミットでコード レビューを行う必要があることです。

この場合、適切な git ワークフローは何でしょうか? 彼のガベージ ヒストリーによってマスター ブランチが汚染されることは望ましくありません。

私は GIT ワークフローをよく理解しています。ブランチを持っていて、masterブランチをチェックアウトしdevelopます。その後、featureブランチをチェックアウトします。featureブランチでファイルを編集しました。developブランチに戻ってチェックアウトするとき。ファイルが編集されているのを見ました。ブランチ上のファイルで何かを行うと、両方のブランチをマージするまで、別のブランチの同じファイルには影響しないと思ったので、理解できなくなりました。developブランチでそのファイルを編集したときに、ブランチの同じファイルに影響を与えた理由を誰かが説明できますかfeature? ありがとう！

私が理解している限り、GIT ワークフローは次のように記述されています: http://nvie.com/posts/a-successful-git-branching-model/

このワークフローの古いブランチのバグ修正に関する質問があります。

多くの古いリリース ブランチがマスター ブランチにマージされていることを考えると、私たちの最後のリリースは、たとえば 2.6 のリリースでした。古いリリース ブランチ (1.5 など) で見つかったバグを修正する必要があります。リリース 1.5 に関連するマスター ブランチ状態からブランチを作成し、修正してデプロイすればOKです。しかし、ここで疑問が残ります。この変更をすべての新しいリリースに保存して伝達するにはどうすればよいでしょうか?

この修正をマスターにマージすることはできません。たとえば、修正していたクラスがリリース 2.3 で削除される可能性があるためです。master ブランチの HEAD に存在しない可能性があります。

マスターの履歴にマージできるかどうかわかりません。すべてのコミットをどのように変更する必要があるか想像できません。

そのため、ホットフィックスの後、すべてのマスター ブランチの次のコミットが古くなり、使用できなくなります。1.9 リリースに何らかのバグがある場合、1.9 のブランチを master からコミットし、何らかの方法で 1.5 のホットフィックスとマージしてから続行するしかありません。

私の理解は正しいですか？

季節（夏/ワインダー）によってデザインが切り替わるウェブサイトを持っているクライアントがいます。なので基本的には同じ機能なのですが、テンプレート関連のファイル(css、JS、imagesなど)を2バージョン。各デザインに 1 つずつ、2 つのブランチが必要だと思いますが、他のファイルを同じに保つにはどうすればよいですか? サブモジュールを作成する必要がありますか? そうでない場合、何かを変更し、その変更を両方のブランチにコミットする必要があるときに、両方のブランチの小さなファイルを一度に編集する方法は?