git log --pretty='format:%C(yellow)%h %C(green)%cd %C(reset)%s %C(red)%d %C(cyan)[%an]' --date=iso とすると、 という表示に出来ます。 毎回このパラメータを指定するのも面倒なので、~/.gitconfigに登録しておきましょう。 ~/.gitconfig ファイルの[alias]セクションに以下を追加します。
この前gccでコンパイルした実行ファイルを無視するために,拡張子がないファイルだけをgitの管理対象から外したいと思ってやり方を調べたのでメモする. How do I add files without dots in them (all extension-less files) to the gitignore file? にあるStackoverflowの回答によると,以下のように.gitignoreなどのファイルに記述すれば (or 変数に値を入れれば) 実現できると書いてあった. ただし,上の記述は先頭に加えないと動作しない (後勝ちなのでこのルールで前のルールが全て無効になってしまう). また,2行目は!/**/と書いてもOK. このルールは, 1行目の*で全てのファイル,ディレクトリを管理対象から外し, 2行目の!*/で全てのディレクトリを管理対象にre-includeして,
以前調べたネタですが、ここにメモしておきます。 (最近ブログの更新が滞っていたため) gitには普通のリポジトリとbareリポジトリがあります。普通のリポジトリは、チェックアウトされたファイルを含むリポジトリで、bareリポジトリは.gitディレクトリの中身のみを含むリポジトリです。 bareリポジトリは、 % git init --bare hoge のように作ります。サーバにbareリポジトリを作って、そこにみんなでpushするような使い方は一般的でしょう。ちなみに、push先がbareリポジトリではなかったりすると、ワーニングがでたりします。 さて、例えば2つのチームがそれぞれ別々のリモートサーバを使って別のbareリポジトリにpushしていたとします。その2つのbareリポジトリを同期したいとします。bareリポジトリにはチェックアウトという概念がないので、git mergeは使え
今のブランチの途中に戻って先に別の開発をしないといけないとか、特定のコミット位置から別のブランチを作成したい時のアレ。 例えば $ git log --all --decorate --graph --oneline * ab7b929 (HEAD -> develop) 図書館にレシピの本を置いたよ。たーのしー * 7cb8ef3 図書館をつくったよ。わーい * 9f0e540 服がぬげたよ。 * 85767d5 カレーはからい。たーのしー * 175658e 温泉がみつかったよ。 * a9b3d53 ボスがふえたよ。たーのしー * e0e054e じゃぱりまんを作ったよ。わーい * 94b8397 でんち * 6fe1920 バスてきなもの。たーのしー * 98f5f9b ジャパリパークの敷地をつくったよ。わーい。 94b8397 でんち から別のブランチを切ってジャパリバスを作りたい
はじめに チーム内の共有ブランチから自分の作業ブランチを切って作業していた際、 コミットコメントを打ち間違えてしまったのでコメントを修正します。 コミットの履歴の改変になるので作業は注意をしながら行います。 また、共有ブランチでは行わないようにしてください。 コミットをやり直す方法 使用するコマンド git commit --amend 直前にしたコミットをやり直します。 前回のコミットにファイルの追加を行ったり、コミットコメントの変更を行ったりできます。 使用例 たとえば以下のようなコミットがあったとします。 commit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Author: xxxx <xxxx@xxxx.com> Date: Wed Aug 26 12:57:24 2015 +0900 Added text1.txt A sample/text1
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
gitのソースコードをzipで圧縮したいとする。その際、git cloneしたものをzipすると.gitディレクトリが入ってしまったりする。 その際に便利に使えるコマンドがgit archiveである。こちらの記事がわかりやすいので参照していただきたい。 Git リポジトリの内容を zip ファイルにする リポジトリにサブモジュールが含まれない場合はこれで問題ないのだが、submoduleまで含めて再帰的にarchiveしたい場合はどうすれば良いか? こちらのStackOverflowの記事に非常に簡単な手法が紹介されていた。 https://github.com/Kentzo/git-archive-all を使う。 $ pip install git-archive-all $ git-archive-all my_repo.zip # my_repo.zipファイルが作られる Reg
npmコマンドでよく書くパターンにGitで固定のファイルをステージしてコミットするというようなものがある。なんらかの処理を行うメインコマンドのpostコマンドでよくやる。まれにその固定のファイルが更新されないこともあり、その時コミットしてしまうとcommitサブコマンドが正常に(終了コード0で)終了しない。これを避けるためにはステージされることで更新があったかどうかをチェックする必要があることになる。それはdiffサブコマンドの--exit-codeオプションを使うとうまく書くことができる。 例えば更新されているかもしれないfooというファイルをステージして、更新があった場合にのみコミットしたい、とすると以下のようにコマンドをつなげれば良い。 $ git add foo && git diff --cached --exit-code --quiet || git commit --mes
1週間ぐらい作業した内容をgithubのmasterにpushした後、よく考えたらこれ全部別プロジェクトにしたほうがいい・・ という事に気づき、1週間前の状態に戻した。 せっかくの1週間分の作業を失ってしまうのも何なので、あとで別プロジェクトにコピペするために黒歴史ブランチとしてとっておく事にした。 git push origin :masterでgithubのmasterを削除してpushしなおせばいいかと思ったけど、なぜかmasterだけは削除できなかった。 masterを黒歴史branchにする git checkout master git checkout -b black_history git push origin black_history git branch -D master 黒歴史をgithubにもpushした。ローカルのmasterは削除。 1週間前の状態をma
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
一年くらい前から git を使い始め、ここ半年くらいは毎日の開発に git を使っています。昨日 git stash という機能を使っている時に失敗してしまい、何人かの方にアドバイスいただくことによって無事回復することが出来たので、感謝の印として、そして運悪く同じ問題に遭遇してしまった人たち(私もまたやるかも)へのメモとして記しておきます。 御託はいいから、早く回復法を知りたい人のためのまとめ $ git fsck | awk '/dangling commit/ {print $3}' 候補の sha1 がいくつか出てくる(長く開発していると、結構多く候補が出てきます) $ git show --summary 候補のsha1 一つ一つの sha1 の内容を確認 $ git cherry-pick -n -m1 見つけたsha1 いきさつ 私の作業のやりかたでは、 タスク毎にブランチを切
diffの出力は標準でカラー表示されない。 カラー表示するためのコマンドとしてはcolordiffがあるが、多くの場合標準では入っていないためインストールする必要がある。 ところが、diffのカラー表示はgitを使ってもできることを知った。 git diffは比較するファイルがgitの管理下になくても使える。 また、-uオプションをつけなくてもunified diff形式で表示される。 昨今の開発環境ではgitがインストールされている場合が多く、このような環境では便利である。 エイリアス関数を作る gitがインストールされているときはgit diffを使うエイリアス関数(bash用)を作ってみた。 diffu() { local DIFF if hash git &>/dev/null; then DIFF="git diff --no-index" else DIFF="diff -u"
git addを取り消す $ git reset HEAD foo.txt git add で編集内容が index に追加*1されます。 間違えて index に追加した場合に、このコマンドで取り消しができます。 $ git add foo.txt $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: foo.txt # $ git reset HEAD foo.txt Unstaged changes after reset: M foo.txt $ git status # On branch master # Changed but not updated: # (use "git add <file
22:56 @thinca さんからの指摘を追記 @yuroyoro あとお節介ですが、n個前とdiffなら HEAD^ より HEAD~ の方がいいと思いますよ。両者では若干意味が違います。~なら HEAD~3 と数字が書けるのも利点です。あと個人的にはwhatchangedよりlog --statの方が見やすくて好きです。 2010-10-08 22:30:52 via Tween to @yuroyoro @yuroyoro URL このgitconfigの記事に関して質問なのですが、core.excludesfile は $HOME で動きますか?以前試した時ダメで、~/ なら動いたのでこちらを使ってるんですが。 2010-10-08 22:20:49 via Tween to @yuroyoro 「そんな.gitconfigで大丈夫か?」 そんなわけで、仕事でもモリンモリンにgi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く