$ git log --name-status --author="$(git config --get user.name)" | grep -E '^(A|M|D)\b' | awk '{ print $2 }' | sort | uniq git logの最後にディレクトリ名を入れると、そのディレクトリ以下のファイル一覧を取得することができます。昔書き捨てたスクリプトがあった気がするんだけどどこにやったかな〜というときに便利です。どうぞご利用ください。
岩手県立大学ソフトウェア情報学部 Advent Calendar 2015の4日目です。 @otukutunではなく、私が書いてみました。 1年早いですね。 今年はQiita全然かけませんでしたが、Advent Calendarで挽回していきたいと思います。 みなさん、Git Rebase使ってますか? 私は正直なんか怖いと思っていました。 ログが書き換わるとか、 Pushするときに強制的にしないといけないとか、 なんでそんなことしなきゃいけないの? と ずっと謎だったのですが、 最近、一緒に開発している方から教えてもらったので、 共有したいなと思います。 そもそも なんで Git Rebaseするのか? はじめに、Rebaseの意味とは、 Re Baseなので、 基点を変える ということです! なんでそんなことをするかと言いますと、 最新のコミットをPullRequestで送るためです!
※この記事は元々「Gitのこれやめて!リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで!!」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
例えば、個人ではGithub、会社ではGHEのアカウントを持っているなどの場合、同じマシンでアカウント(コミッター名)を使い分ける方法。 単純に、--globalを付けなければリポジトリ単位で設定できるので、使用頻度が高い方を--globalで設定し、もう一方はリポジトリ単位で設定する。 ファイルでいうと、--globalをつけるとhomeの設定~/.gitconfigに、つけないとそのリポジトリ内の設定./.git/configに書かれるということになる。 メインのアカウント(~/.gitconfig) git config --global user.name "メインアカウントのユーザ名" git config --global user.email "メインアカウントのメールアドレス"
ungitはnode.jsで動くグラフィカルなgitクライアントです Learn Git Branchingみたいな直感的なGUIで操作できるので とても分かりやすいです インストール 今回はnvmを使用してnode.jsを入れます $ git clone git://github.com/creationix/nvm.git ~/.nvm $ source ~/.nvm/nvm.sh $ nvm install v0.10.22 $ npm install -g ungit $ nvm use v0.10.22 ログイン時も有効にしたい場合は.bashrcに以下のように書いておきます if [ -d $HOME/.nvm/ ] then source ~/.nvm/nvm.sh nvm use v0.10.22 > /dev/null fi 起動 以下のコマンドで
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
システムの技術的負債にどう挑むか?~『レガシーコード改善ガイド』著者マイケル・フェザーズが語る課題と解決策~
zaki50 @zaki50 第7回ウフィカ社内ハンズオン Git 基礎編の資料を公開しました http://t.co/Tdhr2MK6 説明しながらを前提にした資料なので説明が足りてない感じですみません 2012-05-16 18:17:22
git先日、msysGit(Git for Windows)がいよいよ公式に UTF-8 をサポート! という記事で「UTF-8 対応のコードがコミットされた」ことをお伝えしましたが、ついに、UTF-8 対応の新バージョン、msysGit 1.7.10 がリリースされました。いよいよ Windows でも日本語ファイル名を扱えるようになったので、「git では "詳細設計所仕様書.xlsx" をコミットできないんでしょ?」とブーブーいってた人を説得できる材料はそろいました!!!!それを記念して、この記事では UTF-8 対応の msysGit 1.7.10 を試してみた ブーブーいう人を黙らせるための「GUI で git する Windows 向けツール」まとめの2本立てでお送りしたいと思います。UTF-8 対応の msysGit 1.7.10 を試してみたさっそく Google Code
Paris, la ville lumière, s'enrichit d'une nouvelle attraction sensationnelle qui fera le bonheur des amateurs de sensations fortes et des fans de super-héros. Le Batman Escape Game a ouvert ses portes, proposant une expérience immersive unique dans l'univers du Chevalier Noir. Ce nouvel escape game situé en plein cœur de la capitale promet de devenir un incontournable pour tous... Il n’y a rien de
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
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 -
ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行(説明ページから引用)。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)
思い浮かんだ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)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く