GITワークフロー - それを正しくするために必要なヘルプ/アドバイス

Question

gitプロジェクト（すべてのウェブサイト）で適切なワークフローを実現するのに苦労しています。

私たちは5つの開発者（フロントエンド&バックエンド）が一度に30以上のプロジェクト（ライブサイト&ベータサイト）で作業しています。複数の開発者が複数のタスクを実行しています。フロントエンド&バックエンドの間で前後）

私たちの現在のワークフローがこれです：

pull dev branch 
work on task 
commit to dev branch 
push dev 
deploy dev branch to staging site 
repeat ad infinitum 

すると最終的には、クライアントによって承認されたベータサイトの機能：

cherry pick commit/commits in to master (We can not merge development branch in to master as there will be mulitple pieces of code in the development branch that are not ready for live.) 
push master 
deploy master to live 
Pray. 

これらのコミットのいくつかは、クライアントから承認される前に開発ブランチに数週間（数か月間も）置くことができます。この時点で、マスターブランチは大規模に変更されており、 "ライブになる"承認が与えられたとき、開発者は指定されたタスクに関連するコミットを覚えていません！また、それまでに紛争などの額が圧倒されています。

また、一般に「実行」タスクは1 devに与えられますが、具体的なタスクのコミットはわかりません。

機能の大部分にブランチを使用していますが、うまく機能しているようですが、ブランチが作成されないように、小さな変更が時間の経過とともに大きな機能に発展することがよくあります。

私たちは、誰もリポジトリを信頼しないためFTP上で直接修正される傾向があるライブサイトでエラーに終わります。失われたり上書きされたりすることもあります。

質問

GITは、右の私たちのためですか？

別のものを使用する必要がありますか？

または、プロセスを正しく取得するだけですか？

Answer 1

stagingブランチを維持する必要があります。 masterのクイックフィックスの場合は、masterからブランチを作成する必要があります。このコードをstagingに統合し、クライアントテスト用にstagingをデプロイします。 承認後にstagingをmasterにマージします。

それは簡単な修正でないなら、あなたはdevからtask-branchを作成し、それを終えた後stagingでそれをマージする必要があります。クライアントのテスト用に展開し、go live承認後にmasterにマージします。

Answer 2

あなたのために適切ですが、あなたのワークフローを最適化することができます。

使いやすく構成が簡単なGitLab CIを使用してください。

子ブランチからの変更をマージするブランチデベロッパーが必要です。

だからスキーマがあるように：

のDevをステージング

• マスター/製品版
• • 機能してい

あなたの開発者のためのあなたの子供のブランチ開発するUser-Product-Wishlistと呼ばれる機能を使用すると、最新のDevブランチから派生したブランチuser_product_wishlistが作成されます。彼がやって来ると、彼はブランチからDevブランチへのプル/マージ要求を作成します。少し後で見ることにします。

開発者がタスクを終了するまで、彼は確かにブランチにいくつかのコミットをプッシュしました。
サーバへの最後のプッシュの前に、ブランチを1つだけにしてコミットをコミットするためにブランチをリベースする必要があります。
彼は彼がしたコミットとのgitコマンドを実行するの量（xはコミットの量である）チェック：

git rebase -i HEAD~X 

一つだけが彼がしたすべての変更をコミットするようになります、素敵はそれではないでしょうか？

今私達の機能のコミットの歴史は、彼がリモートブランチ上で作業をプッシュすることができますきれいです。

git push origin user-product-wishlist -f 

--force（-f）オプションは、それが変化するため、常にリベース後に使用使用されていますタイムスタンプ履歴をコミットして、サーバー上の以前のバージョンを上書きする必要があります。

チームがコードレビューを行った後にプル/マージ要求を受け入れる時間、またはあなたが処理できる他のチェックがあります。あなたはプル/競合を持つ要求をマージ表示された場合、他のdevのは、彼らがDEVに特徴合併しているため、あなたはそう、リモートDevのブランチであなたの現在のブランチをリベースする必要があります。

git rebase origin/dev 

解決の競合をあなたが、もしいない場合サーバー上で更新するには、あなたのブランチをプッシュすることができます。

git push origin user-product-wishlist -f 

今、あなたは/プルを受け入れ、要求をマージし、DEVブランチにマージすることができます。あなたが容易になりますあなたのコミットの歴史を見ている特定のバージョンにロールバックする必要がある場合は

あなたは...クリーンさえなど、マージされた分岐後、Devのブランチにコミット履歴

を維持します！

今あなたがテストするために、複数の機能を持っている場合、あなたは/別のプルを作成し、サーバー上の要求のチェックアウトにこのブランチをマージすることができます

ステージングまたは生産を展開するときに、そのアップが選択すると、それが試験されるとし、あなたがマージすることができます確認した。