gitの基本的なcommandしか使ってないって人向けのtips集です。 エイリアスの設定 $ git config --global alias.co "checkout" とすると、 ~/.gitconfig に [alias] co = checkout のように追記されます。 このようにgit configを叩いてもいいですし、~/.gitconfigを直接編集しても大丈夫です。 とりあえず、 [alias] co = checkout # checkout長い… st = status -sb # シンプルなstatus pr = pull --rebase # pull するときにmergeコミットを作らない fo = fetch origin ro = rebase origin # branchでfoしてroすればmasterにrebaseできる rc = rebase -

Git をなかなか使いこなせずにいる私ですが、これはいい ! コンソールから使える git ブラウザ、tig が超便利 Vim に近い操作感で使えるのが Vim 使いには非常に嬉しいところです。以下で、インストール方法と基本操作について紹介します。 インストール インストールは、まずソースコードからやってみたのですが、パッケージが存在することに気づいたので、 aptitude で入れ直しました。 sudo aptitude install tig はい、簡単ですね。 起動する カレントディレクトリを Git のワークツリーに移動して、 tig コマンドを実行します。 $ cd /path/to/work-tree $ tig ヘルプを表示する: h 何はともあれ、わからないことがあればとりあえず h を押してヘルプを調べましょう。 カーソルの移動: j, k Vim ユーザなら、何の問題も

ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)

When working in git, you most commonly trace a repository’s history using commits’ SHA-1 hashes. To revert to a previous commit, you might write something like this: $ git revert 883c3dc85a49d98da649 The problem is, we tend not to think in hashes. Rather, we wonder what changes we made yesterday, or remember that a now-broken piece of code worked perfectly a week ago. Although we can use git log t

追記：たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自　己　責　任 追記２(2011/11/07)：commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ ｜ ├─　一人で使ってるよ ｜　　　｜ ｜　　　├─　手元に変更を取り戻したいよ(1)（そうだね、add忘れだね派） ｜　　　｜

なにがしたいのか 自分が会社のPCと、ノートPCの両方で開発したいだけなんですがね。 技術者なんか俺だけですので。 Heroku関連は過去記事参照のこと。 参考：WindowsでRubyでHerokuでGitでRailsやった - 常識という迷信 最初に、railsプロジェクトの作成とHerokuへのcommit 会社でプロジェクトを作成して、手元のgitにcommitする。 rails myapp cd myapp git init git add . git commit -m "first commit hogehoge" 次に、ディレクトリはそのままで、Heroku側にアプリを作成する。 heroku create myapp git remote add heroku git@heroku.com:myapp.git git push heroku master ここまでは、He

前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは？ HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは？ --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset

頻繁に使うわけではないけど便利なgitのtipsをいくつか紹介。というか自分が忘れるからメモ。 git stash 現在作業中のbranchでまだコミットはしたくないけど、trunkで直さないといけないバグとかが見つかったときに、今の変更を横にどけておくコマンド。 $ git stash で変更をいったん横にどけておいて、他のbranchに切り替えて作業後、今のbranchに戻ってきて $ git stash pop とすれば横にどけておいた変更が復活する。 git ignore プロジェクトの中で除外する必要があるファイルは.gitignoreに書くけど、自分の環境だけで除外したいファイルがある場合は.git/info/excludeに書くのがよいです。 自分の環境ではいつでも除外したいというときは $ git config --global core.excludesfile $HOM

「Git」使ってますか？ 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め

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だけを取り消すには別の方法もあります。ローカルは同期

ローカルで作成した branch は remote に push しないと他の人から見えない。remote から clone したリポジトリは何もしなければ master ブランチしか見えない(ように見える)。 remote に branch を push し、remote から clone したリポジトリの branch を変更して push するまでの操作。 ローカルにリポジトリを作成する $ mkdir sandbox $ cd sandbox/ $ git init Initialized empty Git repository in /repos/sandbox/.git/ $ touch README $ git add . $ git commit -m "first commit" [master (root-commit) d31404a] first commit 0

2012/12/13 追記 zsh 4.3.11 以降の新しい機能を使って改良しました。 -> 「zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita」 最近Gitを使い始めた。で、ブランチとか使うようになって、今どのブランチにいるのかをzshのプロンプトに表示したくなってきた。「そういやそんなブログのエントリ、よく見かけるな」と思ってちょっと調べてみた。 gitコマンドを呼び出してなんかやってる例が多いけど、manを読んでたらzsh自体にそういうのが組み込まれてたので紹介。vcs_info ってのを使うと解決する。 zshrcの例 いきなりだけど zshrc の書き方の例。 autoload -Uz vcs_info zstyle ':vcs_info:*' formats '(%s)-[%b]' zstyl