ローカルのgitワークフローはどのように機能する必要がありますか？
自宅には、いくつかのソフトウェアを実行しているサーバーがあります（LAMPスタック上にありますが、内部でのみアクセス可能です）。私は別のマシンとラップトップを持っており、両方ともそのソフトウェアの開発に使用しています。私にとって最良のワークフローは何ですか？
ローカルサーバーにリポジトリがある場合は、ライブブランチ、ステージングブランチ、開発ブランチを作成し、ラップトップ/開発PCから開発ブランチをチェックアウトして作業し、完了したらコミットしてから、開発ブランチをマージします。ライブブランチにさらにマージする前に、テスト用のステージングブランチを使用しますか？
サーバー上の/ www/var /への本番ブランチをチェックアウトするだけでいいですか？
それとも私はこれについてすべて間違っていると考えていますか？
ありがとう。
プロダクションブランチをチェックアウトしないでください
または、より具体的には、本番ブランチで作業しないでください（テストやパッチ適用のためにチェックアウトしても問題ありません）。そして、これが理由です。すでに何か他のものを開発しているときに、いつ、または別の要件/修正に取り組むように求められるかどうかはわかりません。本番ブランチは、公開されようとしているコードのテストまたは迅速な修正（本番ブランチへの2回のチェックイン間の平均タイムスパンよりも開発サイクルがはるかに短い修正）にのみ使用する必要があります。
あなたが言及した最初のアプローチは、私がエンタープライズ環境で最も一般的に観察したものです。利点は次のとおりです。
- さまざまな機能に必要な数のさまざまなブランチを作成できます。
- タスクを一時的に中止したり、しばらくの間別のタスクに取り組む必要がある場合でも、作業を失う必要はありません。
- 多くの開発者は、バックアップをとるためにブランチに変更をコミットする習慣があります（そして、「どうやって...ここにたどり着いたのか」と自分自身に答える習慣があります。本番ブランチでは明らかにこのアプローチを取ることはできません。 Perforceシステムを使用すると（そうではないとおっしゃっていましたが）、シェルフ機能を使用したくなるかもしれませんが、それでも、＃1と＃2で説明した状況から抜け出すことはできません。
開発を維持する方法に関するいくつかのトピック外のアドバイス。枝
プロダクションブランチを開発者に定期的にマージすることは良い習慣だと思います。ブランチを作成して、変更を本番ブランチにマージする場合に大規模なマージタスクを実行する必要がないようにします。この方法のもう1つの利点は、本番ブランチへの変更に対する競合する変更を誰かがチェックインした場合、開発サイクル自体でそれを見つけることができることです（開発中に定期的にテストすることを前提としています）。
本番ブランチを台無しにしないために従うことができるもう1つの方法は、本番ブランチを最後にもう一度開発者とマージすることです。ブランチ、開発者をテストします。完全に分岐して競合（ラインの違いとして発生するものだけでなく、設計レベルの競合として発生する可能性のあるもの）を解決/発見してから、ブランチを本番環境にマージします。
さらに別の良い習慣は、開発者にラベルを付けることです。その開発者の所有者だけでなく、その開発タスクの特定の目標を特定するもので分岐します。ブランチ（したがって、dev_notificationEnhancementではなくdev_monstertruck）。