これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情

ファイル編集がコンフリクトした場合 下記はよくある（忌々しい）コンフリクト画面ですね。 皆さんはコンフリクトのmergeはどんな方法でやっていますでしょうか？ vimやemacsで直接編集している方が多いイメージですが、実際開いてみると、下記のように差分が表示されていると思います。 この画面を見ただけではどのようにmergeすればよいのかわかりません。（Objective-CのARC/MRC双方の開発経験がある人は目をつぶってください・・） gitにはこのようなコンフリクトのmergeを支援するgit mergetoolコマンドが搭載されています。 このままEnterキーを押すと下記のような画面が立ち上がります。 画面幅の都合でフォントが小さいのですが、ここで「mergeしたい差分が作られる直前の状態」と「mergeしたい差分」に注目してみます。 この2つを見比べると、@propertyの

After I open something with emacsclient, when I kill that buffer (C-x k) I get a confirmation dialog: Buffer `blah' still has clients; kill it? (yes or no) But when I kill buffers opened directly from Emacs I don't. Is there a way not to get them when emacsclient opened them?

チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G

gitでは様々な方法でコミットログを書き換えることができます。 その一例として誤ったブランチに対して行った変更を正しいブランチへ移す方法を紹介します。 問題 これまで「新機能Xを追加する」という設定で以下のトピックについて解説していました: gitでコミットの順序を入れ替えるgitで複数のコミットを1つにまとめるgitで1つのコミットを複数のコミットに分割する これにはまず としてこの作業用のトピックブランチを作成してそちらで作業を行うのが普通です。 しかし git branch を実行したところで安心してしまい、 git checkout を忘れて全く違うブランチで作業を行ってしまう というミスは時々やってしまいます (git checkout -b という方法もありますがここではそれも忘れていたとしましょう)。 例えば以下のような状況だったとしましょう: $ git branch ma

ファイルの変更を取り消そうと思って $ git reset --hard fileとしたら fatal: Cannot do hard reset with paths.と怒られた。 $ git reset --hard HEAD fileとか $ git reset --hard HEAD -- fileとか試してもやっぱり怒られる。 じゃあどうすればファイルの変更を取り消せるのかというと $ git checkout fileとすれば良いみたい。 なんで reset では取り消せないのか調べてみたところ、 git reset [-q] [] [--] … git reset [--patch|-p] [] [--] […] git reset [--soft | --mixed | --hard | --merge | --keep] [-q] [] git-reset（1） とあった

これはGit Advent Calendar / Jun. - Qiita.16日目の記事です． 私はエイリアスが好きなのでgitまわりのエイリアスについて書いてみます． 間違ってたらすみません，指摘してくださると嬉しいです． 設定方法 いろんなスコープにエイリアスを設定できます． 例としてgit stでgit statusを実行できるようにしてみましょう． 設定ファイルに書き込む方法と，git configコマンドで設定する方法があります． 設定ファイルに書く場合は以下のようにaliasセクションに短縮形 = 展開形の書式で書きます． どの設定ファイルに書くかで適用される範囲が変わります． また，コマンドで設定する場合は，git config [option] alias.短縮形 展開形を実行します． マシン全体に反映させる場合 $(prefix)/etc/gitconfigに書くか，以

Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書

はじめに ※ 以前git rebase -i して何か失敗して痛い目にあったりした ※ これ。git rebase master に失敗した模様のとき【git】 ※ でも最近ちゃんとgitを理解し出したので再挑戦したらgit rebase -i がやっぱりイケてる 前提 ※ .zshrc (.bash_profile?) にて、gitのデフォルトエディタを設定しときます .zshrc export GIT_EDITOR=vim ※ あと、念のためローカルbranchは新しく切って試します % git branch * develop master % git branch rebase_test % git branch rebase_test * develop master % git checkout rebase_test ※ ぜんぜん関係無いけど、tigあるとちょっと幸せかも そ