work tree の外から git pull する - Sexually Knowing
バッチスクリプトなどで work tree の外から git pull を行いたい、ということはままあるシチュエーションであると思います。 git コマンドは --git-dir オプションでコマンドで操作する .git ディレクトリを指定できるので、これを指定すれば済むと思うかもしれませんが、これではうまくいきません: cd $HOME git --git-dir=$HOME/repos/@aereal/dotfiles/.git pull # Cannot pull with rebase: You have unstaged changes. # Please commit or stash them. work tree も指定する必要があります: git --git-dir=$HOME/repos/@aereal/dotfiles/.git --work-tree=$HOME/r
Post by @shyouhei · 1 image
Git には git blame というコマンドがあり(他のツールでも同様の機能は提供されている)、これを使うことでソースコードのどこを書いたのが誰か、という情報がline-by-lineで取得できる。この情報は行単位なので一次元の情報だけれど、適切な空間充填曲線に乗せることで二次元にマッピングできて、それに適当に作者ごとに色をつけるということをやってみると色々楽しい。そのスクリプトはひじょうにstraight-forwardな記述だとこういった感じになる。上の絵はruby 1.8.7に対する実行結果で、ChangeLogとかのあきらかに面白くないファイルは除外してあるからまあ、そのままの結果ではないけれど、これを見ると色々な思いが去来する。 Ruby 1.8.7 は多数の開発者が手を入れており、少数の支配的な貢献者といったような存在をみいだすことができないしかしながら、全体がのっぺりと灰
git reset --hard HEAD を安全にした - 永遠に未完成
昨日、git reset --hard HEAD してしまって大変なことになった話を書いた。私は普段これを cancel と言う名前に alias して使っている。 [alias] # 中略 cancel = reset --hard HEAD しかし前回のようなことがまたあってはたまらない。人間はミスするものだ。 alias があって実行しやすいのが問題なのだろうか? いや、割とよくする操作*1だし、alias しなくても使うだろう。 てことで、cancel が安全になるようにしてみた。 [alias] # 中略 cancel = !git commit -a -m 'Temporary commit for cancel' && git reset --hard HEAD~ 一旦コミットしてからそのコミットを消す。こうしておけば最悪 git reflog から元に戻せる。特にコミットす
Happy Git Commits
It’s a given: being happy makes us more productive. A few weeks ago while pairing, we decided that choirs should sing and crowds should cheer whenever we commit. I now have this in .git/hooks/post-commit for the projects that I work on most often: #!/bin/sh afplay ~/.git/happykids.wav > /dev/null 2>&1 & Here is the sound file it plays. I giggle every time I commit. It makes me want to start on the
[git][perl] rebase祭りを支援するツール「git-rebase-matsuri」というのを書いてみた | いわぶろ（ろてん）
はじめに どのブランチがどのブランチの上に乗っかるか，というルールが複数定義されたファイルを読んでひたすら git rebase を行うためのツール「git-rebase-matsuri」というのを書いてみたので，本エントリで軽く紹介します． issm/git-rebase-matsuri – GitHub ※ とあるコミットポイントにおいてちょっとした主要なコミットが発生したおかげで，そこから派生していたすべてのブランチに対して git rebaase する作業が発生することを，私は勝手に「rebase祭り」などと呼んでおります． 背景 「この機能の実装を進めて」「ちょっとあれを直してほしい」先方からそんな要求がくるたびに，その数だけトピックブランチを，公開状態のコミットポイントから生やして作業しています．で，こちらが作業を完了して報告，公開向けの準備の指示を仰ぐのですが，そこから返信が
A few git tips you didn't know about
Notice: some of these commands or flags require git version 1.7.2. On OS X, upgrade easily with Homebrew: brew install git Show branches, tags in git log 7466000 (HEAD, mislav/master, mislav) fix test that fails if current dir is not "hub" 494a414 fix cherry-pick of a commit URL 4277848 (origin/master, origin/HEAD, master) whoops d270fae bugfix: git init -g 9307af3 test deps 8ccc17e http://github.
git 1.7.8 changes for the everyday developer | John Kary
John Kary is a web application developer from Lawrence, KS using PHP, Symfony and jQuery.git 1.7.8 was released a little over a week ago. You can view the 1.7.8 release notes for a full list of changes. Most changes will probably not affect your every day use of git, but a few new features should be useful. git merge learned the --edit option to allow editing the merge commit log message If your d
Mac App Store - SourceTree (Git/Hg)
Mac App Store is the simplest way to find and download apps for your Mac.To download SourceTree (Git/Hg) from the Mac App Store, you need a Mac with Mac OS X 10.6.6 or later. Learn More. Description SourceTree is the easy to use GUI for Mercurial and Git, made for your Mac! ✓ One tool for Mercurial and Git repositories ✓ Collaborate with Subversion servers too ✓ See your GitHub, Bitbucket and Kiln
git/コミットログを修正する方法 - TOBY SOFT wiki
はじめに † gitでコミットログを修正したいです。 Redmineとかで、refs #10とかcloses #10とかつけるとコミットログにチケットを関連付けられますが、これがよく書き忘れるんですね…。 直前のコミットログを修正する方法あるみたいです。 直前のコミットログ以外も修正する方法はないのかな…。 (Subversionだとhookスクリプトで許可できますよね。分散型だとやっぱり無理？) ↑ 直前のコミットログを修正する方法 † 直前のコミットログの修正は"git commit --amend" でよいみたいです。 例えば、 $ git commit -m "fixed xxx bug" : # コミット完了! # あ！しまった！"refs #(チケット番号)"つけるの忘れてた！ # (私が使うプロジェクト管理ツールRedmineではrefs #13 のようにすると # コミット
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書かず、ブランチ戦略とリリース管理についてだけ述べよう。 以下では、
Tower Git Client - Tower — The most powerful Git client for Mac and Windows
Version 15.0.3 was released on December 19, 2025 Read Blog Post Version 10.1 was released on December 3, 2025 Read Blog Post Git Made Easy Drag and Drop • Undo everything • A unique Conflict Wizard • File history • Extensive documentation • Great customer support Learn More All of Git's Power (And None of the Pain) Pull Requests • Single-line staging • Interactive Rebase • Submodules • Git LFS • G
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - filhodanuvem/gitql: 💊 A git query language
More Git and GitHub Secrets
天下一gitconfig大会
GitHub - geelen/git-smart: Add some smarts to your git workflow
git push --delete
Accueil
Gitifier: Git commit notifier for MacOSX
GitHub - hatena/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントです。
github/gitignore at master - GitHub
