9

これが私の日常の仕事の説明です：

2人の開発者が多くの小さな機能や修正に取り組んでいます。たとえば、開発者ごとに1日あたり3〜4人です。同僚が機能DとEに取り組んでいる間、私は機能A-B-Cに同時に取り組むことができる必要があります。

月曜日：機能Aは、クライアントレビューのためにステージングサーバーにプッシュされます。機能Bは、クライアントレビューのために同じステージングサーバーにプッシュされます。機能Dは、クライアントレビューのために同じステージングサーバーにプッシュされます。

火曜日：クライアントからAとDの承認を受けます（Bは承認されません）。そして、彼らはそれらの変更をすぐに実行する必要があります。

水曜日：機能Cは、クライアントレビューのために同じステージングサーバーにプッシュされます。ようやくBの承認を受けました。

木曜日：機能Bはすぐに本番環境にプッシュする必要があります。

金曜日：前回の製品リリースでエラーが発見されたため、前のバージョンにロールバックする必要があります。

機能をストーリーやスプリント計画にグループ化する可能性がないため、これをスクラムのようなプロセスとして扱うことはできません。これは、メンテナンスプロセスのようなものです（おそらくかんばん？）。

Gitを使用してこれをどのように処理するかの例を挙げていただけますか？現在、マスターブランチが1つしかない場合、ステージングまたは本番環境に何かをプッシュするときはいつでも、すべての変更（不要なものも含む）をライブで行うために「gitpull」する必要があります。特定のコミットを取得するためのgit"cherry-pick"はどうですか？機能が多すぎるため、機能ごとに1つのブランチは面倒に思えます。Gitコマンドとブランチの具体例を示すことができれば（主なアイデアを示すためだけに、100％正しい必要はありません）、それは素晴らしいことです。

ありがとう。

4

4 に答える 4

6

あなたが説明したことから、私はリリースブランチと多くのワーキングブランチの戦略を採用します。

staging意味：ステージングサーバーは、自分と同僚がすべて自分の機能ブランチ（A、B、C、場合によってはマスター）で作業しているときにのみ、ブランチからプルするように設定する必要があります。

変更を公開する必要がある場合は常に、機能をstagingブランチにマージしてサーバーにプッシュするだけです。ステージング環境は、そのブランチをプルしてデプロイします。

クライアントから承認を得たら、機能ブランチ（すでにstaging別のブランチ（多分stable）にマージされている）をプッシュして、それを本番環境にデプロイできます。

本番環境に入ると、機能ブランチを削除して最初からやり直すことができます。

TLDR： 各環境を、機能がそこに移動する必要がある場合にのみプッシュされるブランチとして扱います。そうすれば、そこに行くはずのないブランチ/環境からの変更を元に戻すことさえできます。

そして、私はかんばんのアプローチを採用します-より簡単で、あなたがしているように見えることにより適しています。

于 2011-12-16T18:09:31.410 に答える
3

私はついにこれを処理する次の方法を選択しました：

  • 1つのマスターリモートリポジトリ。

  • ステージングに関する1つのローカルブランチ。

  • 生産に関する1つのローカルブランチ。

    git checkout -b staging #on staging server
    git checkout -b production #on production server

プログラマーAは機能/パッチAに取り組む必要があります。

#local development box
git checkout master
git checkout -b issue-A
#work on the feature
git push origin issue-A
#log in to the staging server
git checkout staging
git pull origin issue-A #merge with the staging branch, changes are live on staging.

同じことが、機能Bに取り組んでいるプログラマーBにも当てはまります。

本番環境に移行する：

#log in to the production server.
git checkout production
git pull origin issue-A #merge with the production local branch, changes are live on production.

また、変更が有効で承認されたときに、ローカルの本番ブランチをマスターにプッシュできます。

git add <files>
git commit <commit info>
git push origin master

これは私たちの状況で最もうまくいったものです、それが誰かを助けることを願っています。

于 2012-02-22T20:37:52.413 に答える
1

私はこれにgit-flowを適応させました：https ：//plus.google.com/109096274754593704906/posts/R4qkeyRadLR

大きな違いは、スプリント/イテレーションのすべての機能を同じ開始から開始することです。

于 2011-12-16T18:05:36.883 に答える
1

このようなシナリオでは、gitflowを使用しました。

git flowを使用すると、複数の機能を作成し、必要な機能のみを開発ブランチとマスターブランチにプッシュできるため、要件にうまく対応できるはずです。

git-flowのリンクは次のとおりです。

https://github.com/nvie/gitflow/ http://yakiloo.com/getting-started-git-flow/

于 2011-12-16T17:21:20.590 に答える