rebase して FF マージすることによる一直線の履歴は本当にわかりやすいのか
Git でトピックブランチを統合ブランチにマージする直前、最新の統合ブランチの先端にrebaseしたうえで FF (Fast-forward)マージすることで、見かけ上の履歴は一直線になる。 このような一直線の履歴が「わかりやすい」と解説されていることが多いんだけど、これは本当だろうか？ 実は、このような見かけだけ「一直線」の履歴はむしろトピックの範囲が不明確になるのでわかりにくいんだ。 rebase && FF マージする理由としてよく挙げられるのが「マージコミットがあると log で見た時に履歴が入り乱れてわかりにくい」というものなんだけど、 これは明確な誤りだ。 マージコミットを含んだ統合ブランチにおいてファーストペアレントが常に統合ブランチ側になるようにマージしていれば[※]、 [※] これは「統合ブランチ側をcheckoutして git merge <topic> でトピックをマ
Gitでpush -fせずにmasterの間違いを修正する方法
そんなものはない (タイトルは釣りだ。ゴメン)。 でもよく聞く「ミスに気づいて、思わず master に push -f しちゃった」という話は、実はある運用方法で簡単に防ぐことができるんだ。 その運用方法とは・・・ 「使い捨て統合ブランチを作って、最初はそちらにmergeすること」 これだけ。 どのようなやり方なのか、具体的に見ていこう。 1. まず使い捨て統合ブランチを作る。 使い捨て統合ブランチの名前は何でもいいけど、pu (proposed update) がよく使われる。ここではとりあえず pu という名前を使うことにする。チェックアウトしたら push --set-upstream / -u で push しておこう。 % git checkout -b pu master % git push -u origin pu 2. 新しいトピックがあれば、まず pu にマージする。
Gitで今作ったコミットを以前のコミットに半自動的に融合させる(rebase autosquash)
よく「トピックブランチにおけるコミットは、トピックに関連した内容のみ、論理的単位で小さく作れ」といわれますが、実際にコードを書いているときは最初から完璧だと思える一連のコミットをつくり上げるのは非常に困難です。 たとえば、「あー、この変更はさっきのコミットに含めておくべきだったな」とか。 Gitの場合あとから rebase -i で表示されるTODOリストの順番を並べ替えたうえ、squashやfixupを指定すれば、前のコミットに融合できますが、コミットの時点でfixup先のコミットがわかっている場合、autosquashを使うと、その作業を半自動化できます。 たとえば % git log --oneline master.. 4ce35ee 新機能: ほげほげを追加 40a7ef4 ほげほげ機能追加のための準備 のように2つのコミットがあった場合、マージ前にレビューしたところ、40a7e
gitworkflowsの補足(0) - 補助的解説など
gitworkflows(7)日本語訳の補助記事です。 Gitのワークフローというと、git-flowやgithub flowが有名ですが、実はGitプロジェクト本家で使われているワークフローがGit付属のマニュアル gitworkflows(7) に記載されており、Gitとともに配布されています。 このワークフローはシンプルなルールで覚えやすく、かつ参加人数に対してスケーラブルで便利なのですが、日本語訳が存在しないからか、あまり話題に登ることが少ないように思います。そこで今回日本語に翻訳しました。(CopyrightはGit本体と同じです。) なお、gitworkflows(7)が他のワークフローよりも優れている、というわけではありません。このマニュアルの冒頭にも書かれていますが、プロジェクトごとに最適なワークフローは異なるので、自分のプロジェクトに使えるエッセンスを抽出して応用するのが
誰得UNIX
この4月で、Gitが誕生してからちょうど10年になるようだ。 10年前、つまり一番最初のGitはどのようなプログラムだったんだろう？ 当然だけど Git プロジェクトのリポジトリには10年前の最初の姿が e83c516 というコミットとして記録されている。 % git log --max-parents=0 commit e83c5163316f89bfbde7d9ab23ca2e25604af290 Author: Linus Torvalds <torvalds ppc970.osdl.org> Date: Thu Apr 7 15:13:13 2005 -0700 Initial revision of "git", the information manager from hell # --max-parents=0 は親のないコミット、つまりルートコミットを探す方法だ。 # もち
gitworkflows(7)を図解したスライドをアップしました
前回に引き続き、こちらも会社の読書会でGit関連本の番外編として実施したgitworkflows(7)の解説資料（の加筆修正版）です。 マニュアルからすると講義用にかなりつまみ食い的な内容になってます。 副読本的な位置づけでマニュアルを読むのも良いかなと思います。 Gitの布教などにお使いください。 講義した感触だと、やはり少しややこしいワークフローだと感じるようです。 確かにGitの動きにある程度慣れてないと理解しづらいですし、スライドでは最終的な機能リリース直後だけ見るとシンプルなコミットグラフなんですが、途中のnextが混じった図は結構カオスです。 ただ、「ステージング環境は便利そう」という感想もありました。 Q and Aに出てきていますが、プロジェクトの状態や開発スピードによっては master と pu (使い捨て統合ブランチ)だけ、とか、 master, master-pu,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-flowでもgithub flowでもない、Git本家推奨のワークフロー