Tag: git/ワークフロー
関連ページ†
参考情報†
共同開発時のワークフロー†
基本的な考え†
- ローカル(リモート用=masterとか) /ローカル(自分用=devとか)を保守する。
- masterではgit pull する(masterで直接変更しちゃった場合は、git pull --rebaseが良いかもしれない)。
- 開発はトピックブランチで行い、masterにmergeする。
- mergeは--squash(複数のコミットをまとめる)、通常、--no-ff(必ずマージコミットを作る)など使い分けることができる。
- merge後はトピックブランチは削除する。ただしブランチを削除した場合分岐していたという分岐履歴は残るがブランチ名は残らない。
- ブランチ名を残したい場合、how to get git log display name of (deleted) branchesによると、自動で作られるマージコミットのコメントを参照するか、ブランチ削除する前にtagをつけておくなどの対策をとらないといけないらしい。
リリース戦略†
2015/12/09のベストプラクティス†
- 複数リリースを同時にメンテナンスする必要がある場合GitHubフローは使いづらい(アプリ・デスクトップソフト・受託開発など)。
- GitLab Flow | GitLabにある「Release branches with GitLab flow」が参考になる。2-3-stable, 2-4-stableのように安定版ごとにブランチを作ってリリースするというもの。
- 各バージョンをリリースするごとにブランチを作るのはめんどくさいので必要ない場合はリリースブランチを作らないことにして、以下のような方法をとることにした。
- 修正は最初にmasterに反映し、各リリースブランチにcherry-pickする。
- リリースブランチは不要になったら削除。再修正が必要になった場合最新のリリースタグ(例えば先ほどのv1.0a)から再度ブランチを作成すれば良い。できるかどうか要確認!
Last-modified: 2022-04-11 (月) 15:28:20