プロジェクトのバージョン管理ツールとしてGitを使用するときの私の戦略
私はGitを使用してすべての開発を追跡し、常にこの戦略に従います。
戦略はに触発されています成功したGit分岐モデル。
私には2つの恒久的なブランチがあります:マスターと開発です。
これらは私が日常生活で従う規則です:
私が新しい問題に取り組むとき、または機能を組み込むことにしたとき、2つの主要な道があります:
機能は簡単です、または私が行う後続のコミットはコードを壊しません(または少なくとも私はそう願っています):私は開発にコミットするか、クイック機能ブランチ、次にそれをマージして開発します。
機能が完了するまでに複数のコミットが必要です。機能が終了して再び安定するまでに数日かかる場合があります。機能ブランチを行います、次にマージして開発します。
私たちに何かがあれば本番サーバーには早急な対応が必要、バグ修正のように、できるだけ早く解決する必要があります。短い修正プログラムブランチ、問題を修正し、ブランチをローカルおよびテストマシンでテストしてから、マスターにマージして開発します。
必要な場合クイック機能/編集本番サーバーにプッシュするために、開発ブランチには不安定なコードが含まれています。その機能をできるだけ早く編集したいのですが、できます。開発ブランチをスキップし、クイック機能ブランチを実行して、マスターと開発の両方にマージします、機能/編集が高速で些細なものである限り。将来的にもっと複雑なことが判明した場合は、開発ブランチでコードを待って安定させることをお勧めします。
ザ・開発ブランチは常に流動的な状態になります、それがそれが 'に置かれるべきである理由です氷結'リリースを準備するとき。コードがテストされ、すべてのワークフローがチェックされてコードの品質が検証され、マスターへのマージの準備が整います。
開発または別のホットフィックスブランチがマスターにマージされるたびに、タグを付けますバージョン番号が付いているので、問題が発生した場合に前の状態に簡単に戻すことができます。
その他のgitチュートリアル:
- Gitチートシート
- 複数のブランチでの作業を管理するためのGitワークフロー
- Gitサブリポジトリを処理する簡単な方法
- 優れたGitチュートリアルの不完全なリスト
- 開発者によるGitHubの紹介
- 完全なGitガイド
- gitbisectを使用してバグを発見する方法
- GitHubで最初のプルリクエストを行う方法
- 別のブランチからGitブランチを更新する方法
- パスワード/ APIキーをGitHubに投稿しました
- Gitを押しつぶすコミット
- Gitリモートを削除する方法