Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GitHubよちよち会#3

 GitHubよちよち会#3

社内勉強会で使った資料(3回目/全3回)

はない

March 02, 2016
Tweet

More Decks by はない

Other Decks in Technology

Transcript

  1. A.local R.local 前回のおさらい GitHub.com bugfix add_function bugfix # 忘れ物追加 てへぺろ(・ω<)

    $ git push origin bugfix # 最新ソースの取得 $ git fetch $ git merge origin/bugfix $ git merge bugfix # conflictを直接編集して修正
  2. rreebbaassee iiss…� rreebbaasseeの挙動をおさらいしよう! first release bugfix bugfix master commit 2

    commit 1 commit 2 commit 1 $ git rebase master bugfix modify message 変更パッチ として適用 bugfix bbuuggffiixxブランチの差分コミットが、 mmaasstteerrブランチのHHEEAADDの後ろに追加されたよ。
  3. rreebbaassee iiss…� first release commit 2 commit 1 modify message

    bugfix 差分コミットがmmaasstteerrの後ろに着いたので、 FFaasstt--FFoorrwwaarrddできるようになった! first release commit 2 commit 1 modify message bugfix master $ git checkout master $ git merge bugfix master
  4. local wwhheenn yyoouu “ppuullll”…� ppuullllの挙動を確認だ! $ git pull $ git

    pull --rebase $ git fetch $ git merge origin/branch_name $ git fetch $ git rebase origin/branch_name clone branch_name origin/branch_name clone mod merge local branch_name origin/branch_name add clone clone mod add add add
  5. local GitHub.com rreebbaasseeこわい first release commit 2 commit 1 master

    もうちょっと複雑な場合を考えよう。 merge commit merge modify master
  6. local GitHub.com rreebbaasseeこわい first release commit 2 commit 1 master

    mmeerrggeeコミットが残っちゃた。。。 履歴をきれいにするためにrreebbaasseeしたよー! merge modify merge modify rebase modify master 分岐元がなくなっちゃった。。。
  7. local GitHub.com rreebbaasseeこわい first release commit 2 commit 1 master

    mmeerrggeeするために、リモートをppuullllすると・・・ merge modify merge modify rebase modify master merge commit merge commit 消したかった履歴が    戻っちゃう。。。
  8. local GitHub.com rreebbaasseeこわい first release commit 2 commit 1 master

    mmeerrggeeするために、リモートをppuullll ----rreebbaassee すると・・・ merge modify merge modify rebase modify master 差分 patch ・ローカルにしかない ・mmeerrggeeコミット以外 を選んでppaattcchhにするよ
  9. local GitHub.com rreebbaasseeこわい first release commit 1 master ただし・・・ merge

    modify merge modify rebase modify master 差分 patch commit 2 差分が多いとうまくできないよ
  10. あなたは[[コミットの歴史]]を どうとらえますか? rreebbaassee VVSS mmeerrggee ~pull-requestがconflictしているとき~ グリーンにするための主な選択肢は、二種類あります。 ひとつは、自 分のブランチを、プルリクエストの対象ブランチ (普通は、フォーク元の

    リポジトリの master) の先端にリベースすること。 もうひとつは、その対 象ブランチを自分のブランチにマージすることです。 GitHub 上の開発者の多くは、後者を選んでいるようです。その理由 は、先述したとおりです。 重要なのは、そこにいたるまでの歴史と、最 終的にマージしたという事実だと考えているのでしょう。 リベースをす ると、歴史がすっきりするという以外の利点はありません。そして、リベ ースはマージに比べて ずっと 難しいし、間違いを起こしやすいもので す。 「Pro Git」 p228 https://progit-ja.github.io/
  11. ggiitt--ffllooww ・developブランチ 開発を行うためのブランチ。開発者は、主にこのブランチ上で作業を行う。次に紹介する featureブランチなど、他のブランチで行った作業は、ここにマージされる ・featureブランチ 主要な機能を実装するためのブランチ。機能の実装やバグフィックスなど、タスクごとにfeature ブランチを作成し、作業を行う ・releaseブランチ リリースの準備を行うためのブランチ。プロダクトをリリースする前に、このブランチを作成し、微 調整を行う。releaseブランチを作成することで、リリース準備と次のバージョンに向けた開発の

    コードを分けることができる ・masterブランチ リリースしたソースコードを管理するためのブランチ。リリース作業を行うと、releaseブランチは masterブランチへマージされて、リリースタグが打たれる。開発者は、このブランチへのコミット は行わない ・hotfixブランチ リリースされたソフトウェアに緊急の修正を行うためのブランチ。このブランチでの修正内容は、 すぐにリリースされるので、hotfixブランチはリリースを管理するmasterブランチへマージされる いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識 http://www.atmarkit.co.jp/ait/articles/1311/18/news017_2.html
  12. Q.