問題タブ [feature-branch]

Gitflowの分岐スタイルを見てみましょう。すべての機能に対して、「機能ブランチ」があります。機能を開発し、それが完了したら、それを「開発」ブランチにマージできます。

1. マージが完了したら、ブランチを削除するだけで、コミット ログ履歴に何も失われませんか?

2. 機能ブランチを削除していないと仮定します。"develop" にマージした後、誰かが変更をレビューし、小さな問題 (スペルミスやその他の小さな変更など) を見つけます。「機能ブランチ」で変更を行い、「開発」ブランチに再マージしても安全ですか? それとも、以前の「機能」で行われた作業にほとんど影響する些細なことであっても、常に新しい「機能ブランチ」を作成する方が適切ですか?

Bブランチから新しいブランチを作成Aし、単一のコミットを行うと、TeamCity は で複数のビルドをトリガーしますがB、単一のビルドだけを期待します。
「チェックインごとにビルドをトリガーする」をtrueに設定しましたが、新しいコミットが1つしかないため、ビルドは1つだけである必要があります。TeamCity は、当月内のコミットごとにビルドをトリガーするようです。ブランチのすべてのビルドがA終了し、同じビルド構成を使用してブランチAとB. (ブランチに関係なく) ビルドされていないコミットのためだけにビルドを作成するように TeamCity を構成できますか?

現在、TeamCity をセットアップして、チームのメインブランチではないすべてのブランチを構築しようとしています。これを機能させるのに問題があり、デフォルトのブランチでしか機能しませんでした。私たちのリポジトリには次のブランチがあります: master、Daily-build、Branch-Alex、および同様の名前を持つその他のブランチ。マスターを含まないプッシュでこのビルド構成を実行したいと思っています。ここに私の構成のいくつかの写真があります:

1. VCS ルート:

2. トリガー設定:

3. 現在のビルド構成:

TL:DR - チーム シティでフィーチャー ブランチ ビルディングをセットアップするためのより良いチュートリアルはありますか?

ボーナス ポイント - 名前を「ref/heads/Daily-build」ではなくブランチ名にする方法は?

職場では、すべての統合が最終的にブランチで終わる機能ブランチ モデルの上に開発を行っていmasterます。から分岐しmaster、 にマージしmasterます。これにより、非常に複雑な履歴グラフが作成され、開発ワークフローを簡素化する方法を検討しています。

これを行う 1 つの方法は、 mergeの代わりにリベースします。ただし、上書きアクセス許可が無効になっている内部 GitLab インスタンスがインストールされています (プロジェクトのみで有効になることはありません)。そのようなリベースは問題外です。

正直なところ、これを回避する方法はありません。しかし、私は Git の専門家ではないので、何か不足している可能性があります。

助言がありますか？

ここで説明されている機能分岐アプローチ: http://nvie.com/posts/a-successful-git-branching-model/は素晴らしいです。私たちはそれに従いたいと思っています。

本番環境、品質保証環境、ステージング環境、統合環境、およびローカル環境があります。私たちのプロジェクトは、API を公開する PHP バックエンドと、API を使用する AngularJS クライアントを備えた一種の標準的な Web サイトです。私たちのインフラストラクチャ アーキテクチャは、それほど単純ではありません。Varnish、Nginx、Apache2、memcache、プロキシ、いくつかのカスタム ミドルウェア、mysql、elasticsearch などがあります。リポジトリのコードはインフラストラクチャを変更しません。これは GitHub 内のアプリケーションのコードにすぎません。

私たちは通常、同時に 3 つ、4 つの機能ブランチに取り組んでいます。

すべての機能ブランチを 1 つの環境にデプロイし、Nginx/Apache2 vhost をもう 1 つ追加したり、db スキーマをもう 1 つ追加したり、同じサーバーに追加したりするのは良い方法ですか?

これらの機能ブランチ用に 3 つ、4 つの個別の環境を用意することもできますが、1 つの環境で動的に実行するための解決策を探しています。シェフ/パペットは、GitHub からのフックの後に機能ブランチにちなんで名付けられた新しいサーバー構成 (vhosts、db スキーマなど) をデプロイする必要がありますか?

他のアプローチはありますか？

私のチームは、git で機能ブランチ ワークフローを使用しています。

git pull upstream branchnameアップストリームのレポからa を常に に設定したいと思いますgit pull --ff-only upstream branchname。それは可能ですか？

また、プルupstreamのみを許可するようにリポジトリ全体を構成できれば幸いです。--ff-only

詳細

私たちのメインの統合ブランチはdevelop、メインのアップストリーム リポジトリにあります。個々の機能ブランチは開発から始まり、変更を加えてから、プル リクエストを上げて機能ブランチをマージして開発に戻します。

問題は、開発者の多くが本来あるべきほど git に精通しておらず、ローカル リポジトリの のコピーをめちゃくちゃにしてdevelop、アップストリームの のコピーから逸脱していることですdevelop。

彼らはこの相違に気づいていません。次に、borked から feature ブランチを作成し、developpull request を発行するまでそれに気づきません。これにより、突然大量のがらくたがもたらされます。運が良ければ、経験豊富なレビュアーから、プル リクエストをリベースしてクリーンアップするように指示されます。しかし、時々、めちゃくちゃなプル リクエストがマージされ、アップストリームの履歴がめちゃくちゃになります。

回避策

--ff-onlyこれらの初心者の git-folks への私の推奨は、アップストリームからプルするときに常にオプションを使用して、ローカルdevelopブランチをアップストリーム リポジトリの完全なコピーのままにすることです。

のローカル コピーがdevelopアップストリームから分岐し--ff-onlyた場合、次にプルしようとしたときに、オプションが彼らに怒鳴ります。この怒鳴り声は、彼らに本当の問題を解決させます。

しかし、それらは git-n00bs であるため、私が何を推奨しているのかさえ理解していないことが多く、混乱を招き続けています。

私はすべての適切なアメとムチの動機付けテクニックを試します (人間! 私は知っていますよね?) が、どうにかして彼らのローカル リポジトリを補助--ff-only輪で構成できれば、私のレビューの負担は軽減されます (そして、私の開発者は強制されます)。より良い git テクニックを学ぶため)。

私は (リモート) 機能ブランチに取り組んでおり、ブランチ履歴を変更した後、Gerrit に (強制プッシュで) プッシュしたいと考えています。

次のコマンドを試しました：

git push origin HEAD:refs/for/branch_name --force

ただし、ブランチ履歴を変更する代わりに、変更をブランチの上にプッシュしただけです。

私は何を間違っていますか？リモートブランチ履歴を強制プッシュまたは変更するにはどうすればよいですか? ありがとう。