Git の diff を美しく表示するために必要なたった 1 つの設定 #git - 詩と創作・思索のひろば
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 に書いてあ
gitのコミットを後から分割 - cakephperの日記(CakePHP, Laravel, PHP)
最近関わってる http://tipshare.info というサイトで簡単なTipsを書いてます。 皆さんも是非使ってみてください。 この週末に [twitter:@monsat]さんがtipshareの記事をブログに貼り付けられる機能を作ってくれたので、gitのコミットを後から分割する方法を貼り付けます。 gitでコミットしたものを後から複数のコミットに分割する方法@cakephper2011-10-08 16:40:49 ※ただしリモートリポジトリにpushした後は実行してはいけない git rebase -i HEAD^ 下記のようなコミットメッセージが表示されるので、pickをeditに変更 pick 310154e 修正1と修正2 ↓ edit 310154e 修正1と修正2 git reset HEAD^ git add前の状態になるので、必要な単位でgit addとcomm
git commit --amend を省力化する方法
Git で最後のコミットを修正するときには git commit --amend を使うんだけども、いままでは git add . git commit --amend エディターが立ち上がって、前回のコミット メッセージが表示される エディターを終了させる としていた。 この作業は何度も繰り返すと面倒だったので、man を調べてみると --no-edit なるステキなオプションを発見した。 --no-edit を使う --no-edit を指定すると、上の手順はこうなる。 git add . git commit --amend --no-edit コミット メッセージはそのままに、コミットの中身だけを書き換えられる。エディターが立ち上がらないので楽チン。 -a でさらに省力化 さらに git add . も省力化できて とすればよい。 コマンド一発になった。超楽チン。 注意点は次の 2
git pullの詳細な挙動を追ってみる - hokaccha memo
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
git rebase fatal: Needed a single revision
I have a branch of a public repository and I am trying to update my branch with the current commits from the original repository: $ git fetch <remote> remote: Counting objects: 24, done. remote: Compressing objects: 100% (20/20), done. remote: Total 20 (delta 12), reused 0 (delta 0) Unpacking objects: 100% (20/20), done. From git://github.com/path_to/repo 9b70165..22127d0 master -> $/master $ git
Git submodule の基礎 - Qiita
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
vimプラグインをgitのsubmoduleで管理 - rochefort's blog
2011/07/06追記 今はsubmoduleでなく、vundleを使ってます。 vundleでvimのプラグインを管理 - うんたらかんたら日記 git submodule 参考 git 1.6.0.2 submoduleを使おう！その1：add, status - satoko's blog - s21g git 1.6.0.2 submoduleを使おう！その2 - satoko's blog - s21g こんな感じで使うと。 $ git submodule add git://github.com/dchelimsky/rspec.git vendor/plugins/rspec $ git submodule status -fd553b85af3da59a35cf8366319fb244fc4172b5 sub/rspec $ git submodule update --
gitの各種オプションの使用頻度を可視化 - 西尾泰和のはてなダイアリー
ソースコードはこちら https://gist.github.com/2651961 引数にzshのhistoryファイルを指定して実行すると下のような解析結果が表示されます。bashとかで動くかは未確認。 残念ながら僕はzshに乗り換えたばっかりで500行しか履歴が溜まってなかったんだけどそれでも割と面白かった。できればもっと履歴の溜まっている人の解析結果が見たいな。すごく量が多くなってしまうって場合はif count < 2: breakの行を編集するといいかと。 僕のgitに関するコマンドの使用頻度(2回以上出現したもの) add: 55 -p: 14 -u: 3 js/main.js: 2 commit: 45 -m: 41 "add: 10 ←こういうシンプルなメッセージの時にcommit -mを使っているっぽい "fix: 4 "clean: 2 "make: 2 checko
Gitのベストプラクティクスっぽいもの - Sexually Knowing
tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
Germán Laullón Padilla on about.me
Germán Laullón PadillaSoftware Engineer in Madrid, Spain I am a software engineer currently living in Madrid, Spain. My interests range from photography to technology. I am also interested in programming, innovation, and video games. You can click the button above to view my portfolio. If you’d like to get in touch, feel free to say hello through any of the social links below.
人様の git リポジトリを milkode で簡単に管理するインタフェース「gitomb」を作った - tomykaira makes love with codes
tomykaira/gitomb Milkode は数万のファイルでも軽々動く、ソースコード検索エンジンです(製作者は id:tuto0621 さんです）。 しかし、数万ファイルもあるリポジトリなんて管理しますか?普通。 ソースコードを検索する回数がもっとも多いのは、既存のライブラリの使い方がよくわからないときに、ドキュメントに乗っているメソッド名を手掛かりに検索して、望みの機能を発掘していくような時のはずです。いままで、ライブラリのコード検索をしようとおもったら、 ライブラリを落としてくる そのディレクトリに移動する git grep かなんか ヒットしたファイルをエディタで開いて、まわりを見回す 見付かるまで検索をくりかえす みたいなことをやっていました。milkode web を使うと、次のようになります。 ライブラリを落としてくる そのディレクトリに移動する milkode
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Gitリポジトリに蓄積された歴史を可視化、グラフ化する·GitStats MOONGIFT
GitStatsはGitリポジトリを解析して静的なHTMLファイルとグラフを出力するソフトウェアです。 Gitにaddしてcommit、addしてcommit…そんな日々の努力の結果をビジュアル化してくれるソフトウェアがGitStatsです。社内プロジェクトで使ってみても面白そうです。 supybotのGitリポジトリから作られたHTMLです。 アクティビティです。コミット数などをグラフ化しています。 時間数が出たりするのも面白いです。 コミット数を見ればプロジェクトの栄枯盛衰が分かります。 タイムゾーンごとのコミット数もユニークです。 開発者の一覧です。 ファイル数のカウントです。 拡張子ごとというのも面白いです。 コードの行数です。 タグ一覧です。 GitStatsはアクティビティ、ファイル数、コード数、タグ、開発者と言ったデータをリポジトリから抽出してグラフ化します。静的なHTMLで
githubを会社で導入してみて感じたこと - モノノフ日記
会社で利用するソースコードのバージョン管理システムをgithubに移行しつつあります。 gitは以前から個人で利用していたのでブランチ管理のメリットや気の利いたマージなどはもう知っていたのですが githubで同時に複数人で開発をする、という状況は初めてだったので感じたことを残しておきます。 導入 まず当然なのですが開発スピードは上がってます。 これはgithubというよりgitの分散リポジトリの仕組みが大きいです。svnでsvk使うと効率が良いのと同じことです。 そこで問題になるのが各開発者のリポジトリ間をどうやってマージさせていくのか、って所なんですが masterからリリース用のブランチを切ってそこにpull requestを投げて他の開発者に確認してもらってからマージする、という流れで今は運用しています。 投げられた側が確認してマージをコミットするので責任は一蓮托生としてます。 人
git-flow によるブランチの管理
今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か
githubにpushしたcommitの取り消し - 七誌の開発日記
githubにpushしてからcommitが間違っていたことに気付きました。以下のようにすると取り消すことができます。 【注意】commitだけでなく変更も失われます。ローカルのソースツリーは残された最後のcommitに戻されます。変更を保存したい場合は使わないでください。コミットログの修正には git commit --amend を使用してください。 git rebase -i HEAD~2 ← エディタが開くので二行目を削除して保存する git push origin +master以下を参考にしました。 How can I remove a commit on github? id:okmount:20091021 古いコミットを書き換える： 歴史修正主義者のための git rebase -i 入門 githubだけ githubだけを取り消すには別の方法もあります。ローカルは同期
古いコミットを書き換える： 歴史修正主義者のための git rebase -i 入門 - 学習する機械、学習しない人間
直前のコミットをやり直したいときは、git commit --amend を使うと可能だ。そして、さらに昔のコミットをやり直す(書き換える)ときは、git rebase -i を使う。 git rebase -i を使うと、引数にとったコミット以降のコミット系列に対して、コミットの書き換え、削除、統合を行うことができる。 次の課題をこなすことを目標としながら、git rebase -i の動作を追っていこう。 課題「最新のものから古いほうへ3つ分のコミット(HEAD, HEAD~1, HEAD~2)のログメッセージを書き換えたい」 git rebase -i の起動 まず、変更したいコミットで一番古いものより一つ古いものを引数にして、git rebase -i を実行する。この場合は HEAD~3 である。 $ git rebase -i HEAD~3 すると、エディタが rebase コ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitでMerge CommitをRevertする方法 - Qiita
こわくない Git
Gmane Loom