Gitで今作ったコミットを以前のコミットに半自動的に融合させる(rebase autosquash)
よく「トピックブランチにおけるコミットは、トピックに関連した内容のみ、論理的単位で小さく作れ」といわれますが、実際にコードを書いているときは最初から完璧だと思える一連のコミットをつくり上げるのは非常に困難です。 たとえば、「あー、この変更はさっきのコミットに含めておくべきだったな」とか。 Gitの場合あとから rebase -i で表示されるTODOリストの順番を並べ替えたうえ、squashやfixupを指定すれば、前のコミットに融合できますが、コミットの時点でfixup先のコミットがわかっている場合、autosquashを使うと、その作業を半自動化できます。 たとえば % git log --oneline master.. 4ce35ee 新機能: ほげほげを追加 40a7ef4 ほげほげ機能追加のための準備 のように2つのコミットがあった場合、マージ前にレビューしたところ、40a7e
レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
SIerからWeb系に転職して半年。転職前にやっといてよかったなぁと思ったこと - suusan2号の戯れ
SIerから自社Webサービスをやってる会社に転職して半年たったのでまとめる。本当は試用期間が終わったころに書こうと思っていたのに、すっかり忘れてました。。。 SIerでは仮想化のインフラエンジニアっぽいことしてました。いまはRubyの会社でRails触ったりReact触ったりしています。 以下は、これをやっておくと転職のときに有利…とかいうものではなく、転職後になってやっておいてよかったなと思ったことですので注意。 やっておいてよかったなと思ったこと Gitの使い方を覚えておく Gitは普通に使いますし、Gitが全く使えないと開発に参加するところから大変です。 当然、仮想化のインフラエンジニアなんてやってたのでGitなんて全然仕事では触ってませんでしたが、趣味の自分一人の開発でも更新はGitHubでプルリクエストを送りセルフマージする感じにして慣れるようにしてました。 以下の本では、なん
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git rebase -i のための rebase.autosquash オプション - Qiita
こわくない Git
Git入門：Git初学習者のための効率的な学習方法を考えてみた
μ’sと学ぶバージョン管理システム入門 – ラブライブ！で学ぶソフトウェア開発入門