git/ワークフロー の履歴(No.5)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• git/ワークフロー へ行く。
  • 1 (2014-03-14 (金) 05:23:47)
  • 2 (2014-03-14 (金) 07:44:38)
  • 3 (2014-03-21 (金) 13:44:39)
  • 4 (2015-09-10 (木) 07:29:51)
  • 5 (2016-04-13 (水) 07:47:50)

Tag: git/ワークフロー

目次†

関連ページ†

参考情報†

共同開発時のワークフロー†

• Git のマージについて、自分的まとめ - tanaka51のブログ
• git merge --squash でブランチでの変更を1コミットにまとめてマージ - Qiita
• git rebase -i はやっぱりイケてる件【git】【rebase 】【iオプション】 - DRYな備忘録
• [Git] 使い分けできていますか？マージ（merge）&リベース（rebase）再入門 - The Powerful Code

基本的な考え†

• ローカル(リモート用=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ブランチでv1.0というタグを作成これをリリース。
  • masterブランチはv1.1の開発に進む。
  • v1.0の修正を行う必要がでてきた場合、v1.0のタグからrel1.0ブランチを作成。

    git checkout -b rel1.0 refs/tags/v1.0

  • 修正後v1.0aタグを作成してリリース。
• 修正は最初にmasterに反映し、各リリースブランチにcherry-pickする。
• リリースブランチは不要になったら削除。再修正が必要になった場合最新のリリースタグから再度ブランチを作成すれば良い。