小さなチームのためのGit開発戦略

Question

私たちは小さなデジタルチーム（3人のデザイナー、3人の開発者）を抱えており、Gitを私たちのシステムに統合しようとしています。

現時点では、ほとんどのサイトでステージングサイト（dev.example.com）と本番サイト（example.com）が用意されています。私たちの開発者は、通常、ローカルバージョンへのコード変更を行い、その変更をステージングサイトに移し、承認されると、それらの変更は実際に移動されます。一方、私たちのデザイナーは、開発者があまりにも忙しいときにステージングサイトに直接小さな編集を加えて、承認されたライブをプッシュします。また、場合によってはステージングサイトがなく、編集内容が本番サイトに直接プッシュされます。

さまざまなワークフローが理想的ではないが、Gitを現在のシステムに統合し、ワークフローをかなり単純に（デザイナーのために）維持するにはどうすればよいだろうか？ Gitを組み込む前に私たちの現在のワークフローを標準化するべきです（ステージングサイトは必須で、デザイナはステージングに進む前にローカルで開発しなければなりません）か、そのまま動作するようにGit柔軟性がありますか？

私はGitにかなり新しいですが、プッシュは裸のリポジトリにのみ行うべきだと読んでいます。これは必要ですか？もしそうなら、これはステージングサイトですか？または、それが独自のエンティティ（example.localのような社内サーバー）であるべきかどうか

良いワークフローは次のような次のようになります。

1. ユーザーが取得し、ローカルリポジトリに裸のリポジトリをマージします。
2. ユーザーはローカルで開発し、ローカルリポジトリへの変更をコミットします。
3. ユーザーがexample.local（または類似したもの）
4. ユーザーが承認された場合は、リポジトリdev.example.com
5. のステージングに裸のリポジトリから変更をプルで裸のリポジトリに変更をプッシュし、ユーザーが生産リポジトリへの裸のリポジトリから変更をプルexample.com

このワークフローで私の唯一の問題は、裸のリポジトリが不要なように見えることです...いいえ？そして最後に、私はローカルリポジトリに何が記録されるのかを理解しています（ユーザーは変更、コミットなど）。しかし、私は裸のリポジトリに何が記録されるのか（プッシュ後）、ステージングは）と生産（プル後）。上記のすべての手順を追跡して簡単に記録できますか？

ありがとうございました！ここ

Answer 1

は1つのinterestionのGitのワークフローです：http://nvie.com/posts/a-successful-git-branching-model/

あなたの開発者やデザイナーは、コマンド・ライン・相間に精通していない場合は、GUIのgitのラッパーを使用して、いくつかあります。gitx、gitbox、git towerは、単にそれらをグーグル自分のサイトを取得します。あなたのチームが快適なツールを見つけることができます。

ベストワークフローは、チームのニーズを満たすものであり、時間とともに変化する可能性があります。

Answer 2

はそのままの状態で動作する柔軟性がありますか？

非常にそうです。

私がそれをやり遂げたやり方は、デザイナーがdesignというブランチや同様の名前で作業し、常にプッシュする単一のコマンドがあるようにしましょう。

開発者は、サーバーを更新するたびにデザインブランチからコンテンツをマージします。実際、自動展開スクリプトでは、マージがコマンドになります。

デザインの変更のみを行い、変更はできません。ステージングのブランチをデザインブランチに切り替えることができます。このために、デザイナに最新の変更をプッシュするデプロイスクリプトを提供し、デザインブランチに切り替えます。

これは、デザイナーがgitをゆっくりと徐々に使用するよう奨励しています。まず、それらをstashコマンドにフックします。そして引っ張ってください。次に、異なるブランチを作成するように依頼します。

裸のレポジトリは、すべての人を同期させる標準的な方法であり、その1つを余分にする技術的な理由はありません。ほとんどの人がgithubや通信や調整のための優れたWeb UIを備えた同等のリモートバックアップサービスを使用している点を除いて、デファクトは中央の裸のリポジトリになります。

Answer 3

ベアリポジトリを使用する理由もわかりません。私は簡単な開発者プロセスに関する短い記事を書いた： A simple developer process with Git

これはあなたのケースではありませんが、より一般的な解決策です。フィーチャーブランチを使用するという考え方は、誰もが変更をメインリポジトリにプッシュし、誰もがelsesの仕事を台無しにすることなく、他の人の変更をマージすることを容易にすることです。

私はこれをしなかった場合は、これは私がどうなるのかです：

1. はGitoriousをインストールします。必要はありませんが、物事を追跡するのに役立ちます。
2. Gitoriousでプロダクションリポジトリを作成します。
3. 更新を受け取ったプロダクションリポジトリにポストフックを追加すると、プロダクションサーバーが自動的に更新されます（翌夜に遅れて、最適なもの）。
4. Gitoriousで開発リポジトリを作成します。
5. 開発サーバーを更新する開発リポジトリに同様のポストフックを追加します。

このセットアップには多くの利点があります。

• 開発者は、サイトの更新を心配する必要はありません。彼らがする必要があるのは、dev repoにプッシュすることだけです。
• テストの合格後に本番サーバーを更新するのは非常に簡単です。単なるプッシュで十分です（本番リポジトリは開発サーバー以外では更新されません）。ポストフックにセクションを追加することもできます。このセクションは、タグが押された場合にこれを行います。したがって、タグを使用してリリース番号にバージョン番号を付けることができ、これにより本番サーバーが自動的に更新されます。
• 誰かが何かを混乱させる可能性のある点はずっと少なくなっています（「おっと！私はデベロッパーに押しつけようと思っていましたが、代わりに押し寄せる」と言いました）。