Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
はじめましてこんにちは、今年新卒でKRAYに入社しました亀井と申します。 会社のみなさんからは「あさちゅん」と呼ばれております。どうぞよろしくお願いします。 突然ですが、みなさん使ってますか？ Git。 KRAYではバリバリ活躍してるGitですが、 「よくわからない……」と頭を抱えてる方も多いですね。 わたしも抱えてます。 正直、KRAYに入社するまでターミナルを使ったことすらなく、 Gitも入社してから使いだしたので初心者もいいところです。 そんなわたしが1日約200回×3ヶ月ターミナルでGitコマンドを打ち続けて やっとわかってきた、Gitの「これなんで？」を解説します。 主にGit初心者、Gitについて理解を深めたい人向けです。 もくじ なんでcommitする前にaddしなきゃいけないの？ ブランチってなんのために分けるの？ HEADってなんなの？ 消したファイルもコミットしなきゃい
あるファイルに大量のコンフリクトが発生し解決が面倒なとき、パッチを使ってファイルに1コミットずつ変更を適用する方法を示す。この方法のメリットは： ファイルへの変更を1コミットずつ適用・コンフリクト解決することができる それぞれのコミットを適用する前に、コミットをパッチファイルの形で編集できる 注目するファイル以外への変更をいったん無視し、そのファイルに関係する変更に集中できる の3点である。複数コミットの変更が混ざった大量のコンフリクトマーカーを手作業で消すような状況に陥ったとき、この方法を使えばいくぶんかは楽にマージ作業を進められる。 概要 マージ中に特定のファイルに大量のコンフリクトが起きたら、マージを中止する。一時作業用ブランチを作り、そのファイルに1コミットずつパッチを当てて編集する。パッチを当て終わったらマージをやり直し、コンフリクト解決作業中に、コンフリクトしたファイルを一時作
思い浮かんだGitのTipsを列挙してみました。 gitのコマンドをで補完する git-completion.bash を入れると、でコマンドの補完が効くようになります。 また、PS1の設定を行うと現在のブランチ名が常にbash上に表示されるようになります。 （Windowsの場合、msysgit は標準で入ってます） contrib/completion/git-completion.bash - GitHub インストール方法（引用） # To use these routines: # # 1) Copy this file to somewhere (e.g. ~/.git-completion.sh). # 2) Add the following line to your .bashrc/.zshrc: # source ~/.git-completion.sh # # 3)
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
GitHub がオープンソースの場として魅力的な理由は、Git という優れた分散・協調型リビジョン管理システムのリポジトリー・ザーバーとして誰でも利用できるということはもちろん、README などのドキュメント生成機能やコメンティング機能、問題のトラッキング機能など、Git を補助し、オープンな分散・協調開発を支えるサブシステムが充実している点が挙げられるでしょう。無料でもかなりのことができるのに、ビジネスとしてもちゃんと成立している理由はこんなところにあるように思います。 ただ、同種サービスの Google Code や Bitbucket と決定的に異なり、GitHub の最大の魅力となっているのは、GitHub Pages という1種のホスティング・サービスではないかと思います。成果物をただずらずらと味気ないページに並べるのではなく、趣向を凝らした紹介ページを自由に作り、プロジェクト
gitによるバージョン管理 バージョン管理システムはつかってますか？ 僕は前に自分の作成したコードを元に、後輩にプログラムを作らせようとしてまずは僕のコードをコピペしろと指示したところ、コピペしかしてない(と言い張る)割にはコピペしたコードは動かず、さらに何故かコピペ元の僕のコードが滅茶苦茶に荒らされて当然のごとく動かなくなるという、なんかもう幽霊の存在を認めない限り説明がつかないような怪奇現象に遭遇したことがあります。しかもそのときはcpコマンドによるバックアップに頼っていて運悪くバックアップを忘れたために僕の貴重な１日が消え去ってしまった訳でして、それから僕はバージョン管理システムに頼ることを固く心に決めました。また僕はその目を覆いたくなるような残虐な事件以来、建設業界に見習って、IT業界でもプロジェクトキックオフ時にお祓いはすべきだと訴え続けています。 まぁそれはいいとして、いやまだ
序 言うまでもないことだが、タイトルはジョークである。 そもそもバージョン管理は本来我々がしたい事ではない（一部の人を除く）。別に作りたいものがあり、そこでの作業を円滑に進めるためにバージョン管理するのだから、所詮はヤクの毛刈りである。さらに、Gitクライアントのへっぽこさも相まってなかなかに時間を食われる。この文書はそのような人々が、より円滑にGitを使えることを祈って書かれた。 なお、バージョン管理というのはとても複雑なシステムであるため、バージョン管理自体が目的な人には楽しい世界である。そのような人々はぜひGitやその他のバージョン管理システムのマニュアルやソースコードを読んでいただきたい。きっとその奥深い世界を堪能できることだろう。 Git概説 Gitはこれまでの旧来のバージョン管理システムとは一風違った設計で作られている。また、Git特有の概念も多い。なので、まずGitの概観を説
README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。 GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 （マークアップ） されて表示されていることはご存知でしょう。 マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown （略して GFM） という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 （もちろん GitHub 初心者です！） の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ （レンダリング） を気にして
ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが（ただのコミットマシーン状態）、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。 前提 まず始めに、現在のプロジェクトの状況は下記のようになっています。 開発は 1 人のメインコミッタ（私）と数人のサポートコミッタ（アルバイト等）で行われる メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態 サポートコミッタに対しては、基本的に 1 機能（1 チケット）を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあ
Git の 1.7.11 から git difftool コマンドに --dir-diff というオプションが追加されたのですが、これがライフ チェンジングだと思ったので紹介します。 --dir-diff 登場以前の git difftool は「ファイルごとに順番に差分を表示していく」ことしかできず、使い勝手はいまいちでした。それが、--dir-diff オプションの登場で状況が一変したわけです。 こんな感じの使い心地だよ ある Git レポジトリーで dir1/a.txt と dir2/c.txt を編集したとしましょう。 この状態で git difftool --dir-diff または git difftool -d を実行してみると・・・。 はい、差分のあるファイルが一覧で表示されました。 (difftool に WinMerge を設定して、メニューから [ツリー表示] を有効
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
※本稿は「PowerShell Advent Calendar 2012」に向けての記事です。 バージョン管理システムとのつきあい仕事上、自分の立場は基本的にはデベロッパー。 C#, SQL, JavaScript, HTML, CSS を書く ASP.NET プログラマである。 当然、作成したソースコードは、なんらかのバージョン管理システムに保管、開発メンバと共有している。 使用バージョン管理システムとしては、ウン十年前は RCS使ってたような記憶がうっすらとある。 その後、今の勤め先に移籍して Visual Source Safe (ちなみにほとんど保管庫状態だが今も活きている)、Subversion と変遷。 最近は Git を本格的に使い始めたところだ。 使用OS は Windows OS なので、msysGit と TortoiseGit をインストールして使っている。 Git
Gitもいろいろ増えているんだと改めた@HIROCASTERでございませう。 過去のGitのバージョンでは、設定できないと言われていたことについて、最近のGitでは設定できるようになっています。（と、言っても何ヶ月も前に追加されている内容ですが…） そのなかでも「これが欲しかったんだ！」と思われる2点について取り上げます。 git merge –no-ff git mergeをおこなう際には –no-ff をつけることによって、トピックブランチでおこなわれたコミットが明確にわかるようにするかと思います。 以下の図だと、Topic-bは別ブランチでコミットされましたが、masterへマージする際に ff だったために履歴を見ると別ブランチでコミットされたかどうかが判断できません。 一方、Topic-CはTopic-B同様に別ブランチでコミットされましたが、masterへmergeされる際に
先日（※1）、「.gitconfigの書き方や、gitのTipsについてワイワイ情報交換しましょう！」という趣旨で社内勉強会が開催されました。題して「天下一.gitconfig大会」。ここに我こそはと、5名の強者がネタをエントリしました。 業務後の時間にもかかわらず、いろんな部署から20人以上が参加。社内で最も大きな会議室が、ほぼいっぱいに。 「さいきょうの.gitconfig」（天野 祐介） 「jenkins先生にライブラリの更新をお願いする」（田中 裕一） 「おれさまの.gitconfigでぎっとぎとにしてやんよ」（佐藤 鉄平） 「git のよくある誤解 No.1 rebase について」（山本 泰宇） 「rebase すべき時とその作法」（星野 喬） 天野が、.gitconfigのベストプラクティスを探求していたら、いつの間にかシェルのベスト環境を構築していた……というオチで笑いを取
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！ こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？ A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
