どこでも使える git diff と git apply - Qiita
Git Advent Calendar / Jun. 28日目の記事です。27日目はつるはしで過去を発掘するでした。 Git リポジトリの外で git diff / git apply あまり知られていないことですが、 git diff と git apply は Git リポジトリの外でも使えます。普通の diff ではできない、バイナリファイルを含む2つのディレクトリの差分を取りたいときなどに重宝します。ちょっと試してみましょう。 $ mkdir dir1 dir2 $ echo foo > dir1/text $ echo FOO > dir2/text $ dd if=/dev/random of=dir1/binary bs=128 count=1 $ dd if=/dev/random of=dir2/binary bs=128 count=1
gitでマージ済みの(リモート|ローカル)ブランチを全て削除.md
gitでマージ済みの(リモート|ローカル)ブランチを全て削除.md マージ済みのリモートブランチを全て削除 git branch -r --merged master | grep -v -e master -e develop | sed -e 's% *origin/%%' | xargs -I% git push --delete origin % remote の master に merge済み の branch をすべて表示して master と develop は消えてほしくないので除外して origin/ を削除して xargs （-I% % で ブランチ名を渡しつつ、全て削除する） マージ済みのローカルブランチを全て削除 $ git branch --merged master | grep -vE '^\*|master$|develop$' | xargs -I %
git を https 経由で使うときのパスワードを保存する - Qiita
git を https 経由で使う場合、pull や push のたびに毎回パスワードを聞かれてしまいます。 これを改善するには git-credential を使うと良いです。 git-credential は git 1.7.9 以降で使用可能です。 なお、古いやり方としては .netrc を使う方法もありますが、パスワードを平文でファイルに保存するので、やらないほうがいいと思います。 使用可能な管理方式 git-credential では、以下のような方法でユーザ名とパスワードを管理できます。 git-credential-store : ファイルに保存します。ただし、パスワードが平文が保存されます。 git-credential-cache : 常駐プロセスに記憶させます。 git-credential-osxkeychain : Mac OS X のパスワード管理を使います。 G
過去に戻れ！reflogを使いこなしてこそGit中級者である。 - カイワレの大冒険 Third
Gitの一番好きなコマンドといっても過言ではない reflog 。 すごく便利なので、使いましょうと言う話です。 簡単にいえば、 reflog で過去を探索し、 reset で好きなタイミングに戻ることができるというテクニックです。 開発していると、ここまでいじっちゃったけど、ここまで戻したいとかそういう欲が出てきます。 そういうときに是非使って欲しいコマンドです。 では説明していきます。 まず説明用に、いくつかファイルを作り、コミットなり色々しときます。 $ cd ~/work/ $ mkdir git $ cd git/ $ git init Initialized empty Git repository in /Users/masudak/work/git/.git/ # 適当にファイルを作る $ touch sample.txt $ git status On branch ma
Atom Git Integration - r7km/s
Atomを使っていて、ファイル一覧やステータスバーの色が変わっていることに気付いたことはあるだろうか。 こいつの正体はGitだ。 Atomは標準でGitレポジトリを管理する機能を備えていて、Gitの一般的な操作は勿論それに関連した様々な機能を備えている。 今回はAtomのGitに関連する幾つかの機能を見ていきながら、それらがどういう風に動くのかを説明していこうと思う。 Git API 最初に言っておくと、この記事で触れるパッケージと機能は全てAtomのCore Git API上に実装されている。 atom.projectというグローバルにアクセスできるオブジェクトがgetRepo()というメソッドを持っており、 これが現在のプロジェクトのGitレポジトリを返すようになっている。 これを使えば、ファイルの状態や変更点など現在のレポジトリの状態を調べられる。 この機能には、git-utilsと
Git活用法 ー コードはいつも1行ごとにドキュメント化されている | POSTD
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか？ 今後、この呼び出しを変更したり削除したりしても安全でしょうか？ // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
Gitコンフリクト解消ガイド（git mergetoolの使い方） - Qiita
ファイル編集がコンフリクトした場合 下記はよくある（忌々しい）コンフリクト画面ですね。 皆さんはコンフリクトのmergeはどんな方法でやっていますでしょうか？ vimやemacsで直接編集している方が多いイメージですが、実際開いてみると、下記のように差分が表示されていると思います。 この画面を見ただけではどのようにmergeすればよいのかわかりません。（Objective-CのARC/MRC双方の開発経験がある人は目をつぶってください・・） gitにはこのようなコンフリクトのmergeを支援するgit mergetoolコマンドが搭載されています。 このままEnterキーを押すと下記のような画面が立ち上がります。 画面幅の都合でフォントが小さいのですが、ここで「mergeしたい差分が作られる直前の状態」と「mergeしたい差分」に注目してみます。 この2つを見比べると、@propertyの
gitのdiff, status, logを極限までコンパクト化＋便利化する - Qiita
git diffを見やすくする git diff --color-words で差分を小さく表示する 通常のgit diffは行単位なので、例えば変数名を一括変更した場合見づらいです。 --color-wordsを指定すると記号やスペースで区切られた単語単位でのdiffを表示できます。gitの設定は不要です。 より細かな表示のカスタマイズも可能です。man git-diffで--word-diffを検索してみてください。 ※ただし、変更が複雑な場合は、通常のgit diffのほうが見やすいこともあります。 .gitattributesを設置してもっと小さく表示する .gitattributesファイルを設置することで、言語文法に基づいて変数名、関数名といった単位でdiffを表示できます ファイル設置後にgit diff --color-wordsとすると、下記のようにさらに小さく表示できま
gitのoriginのurlを変更する。 - 僕の今さら日記
mirahを最初にインストールした時に、 git://github.com/headius/mirah.git の方から持ってきてて、あとから git://github.com/mirah/mirah.git の方が最新なことに気づいて、別にそのまま新たにcloneしてくればいいんですが、 originを変えれないのかな?と思ったのでメモ。 **追記** @murachue さんより教えていただきまして、 % git remote set-url origin <新しいリポジトリURL> が普通とのこと。明らかにこっちのほうが自然なかんじですね! @murachue さんありがとうございます!! 使用した感じは以下のとおりです。 regina% git remote -v origin git://github.com/headius/mirah.git (fetch) origin gi
gitで一部のディレクトリだけチェックアウトする - Qiita
git 1.7からsparse checkout機能が利用できるらしい。 ざっくりとした使い方は以下の通り、 $ git clone リポジトリURL hoge $ cd hoge $ git config core.sparsecheckout true $ echo "hoge.txt" > .git/info/sparse-checkout $ git read-tree -m -u HEAD こうするとワーキングディレクトリ下はhoge.txtファイルだけチェックアウトされる様になるらしい。 これまで制作部スタッフにhtmlファイルを編集してもらうのに社内共有フォルダでファイルの受け渡しをしていたんだけど、この機能を使ったらもう少しスマートにならないかなと考え中。 gitスキルのない制作部スタッフにいきなり今日からgit運用にします。ってのは、ハードル高すぎるので、gitアクセスは
ある程度Gitを操作できるようになってから当たると良いマニュアル/情報源 - Qiita
Gitにある程度慣れ，基本的な操作ができるようになるとより深く知りたくなってくると思いますが，そのときにググって分散した情報を読むのではなく，まとまったドキュメントを活用すると効率が良いです． まずは中級者向けgit helpについて． git help help まずはgit help helpをして，よく使うgit helpについてより良く知っておきましょう．git helpの中でおすすめオプションは以下の2つ． -w HTMLでのmanをブラウザで開く．長いmanを読むときなどは読みやすくて地味に便利 -g ガイド一覧．特定のgitコマンドに縛られないような内容を見ることができます． gitガイド $ git help -g The common Git guides are: attributes Defining attributes per path glossary A Gi
gitでありがちな問題の解決方法まとめ - Qiita
Git Advent Calendar / Jun. 最終日(30日目)の記事です．29日目は「いざという時のためのgit reflog」でした． Git Advent Calendar最後なので，git操作でやりがちなミスからどう回復するかをまとめます．他にもあればコメントもらえるとマージしていきます． ブランチを切り忘れてmasterでコミットしてしまった その時点でブランチを切る&reset --hardで間違ったコミットたちをmasterから消す $ git checkout -b new-branch # masterの最新コミットを消す $ git checkout master && git reset --hard HEAD~
Chefでgitとコンテンツ同期しつつ更新時だけスクリプト実行する - Qiita
この記事は最終更新から1年以上経過しています。 気をつけてね。 ウェブのコンテンツをGitで管理している際に、Webサーバ上でGitリポジトリをチェックしつつ、同期して何かスクリプトを実行する。という手順をChefのレシピで実行してみます。 手順におこす まずやりたいことをスクリプト(台本)にしましょう。 初回はgit clone してシェルスクリプトを流す 定期的にgit ls-remoteして新しいものをチェックする ls-remote の結果、最新がローカルのリポジトリと違ったらpull pull があったらシェルスクリプト実行 まあbashで十分な内容です。４なんかは gitのhookを使うやり方もありますね。 ただ従来bashや他のスクリプト型言語で作られている実行手順はレシピにしてchef-applyで実行すると読みやすい内容で十分な結果を得ることができます。 chef-app
空のディレクトリをgitで管理するには.gitkeepを使う（.gitignoreは使わない） - YomuKaku Memo
gitを使ってバージョン管理を行う際に、プロジェクト全体のツリー構造をそのまま管理する目的で、中身が何も無いディレクトリもgitの管理下に置きたい場合があります。 何も対応しないと、gitは空のディレクトリをバージョン管理してくれません。 中身が空のディレクトリをgitのバージョン管理下に入れるためには、当該の空ディレクトリの中に .gitkeep というファイルを作成してからgitで管理します。 実例 Railsのアプリケーションを新しく作成する場合を例に用います。 $ rails new test_application $ cd test_application $ ls -l vendor/plugins （vendor/pluginsは中身が空なので何も出力されません） 上のように、vendor/pluginsは中身が空です。 このディレクトリをgitの管理下に入れるために、次の
レビューフレンドリーな開発のしかた - tomykaira makes love with codes
2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。 コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。 自分が普段の開発でこころがけていることをまとめてみます。 前提 レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。 なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。 なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。 レビュアーはレビュイーよりも、変更について詳しくありません。 レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
Gitがこわくて触れられなかったけど、このスライドで理解出来るようになったよGitサイトまとめ
触れるのがこわくてずっとGitを避けて来ました。ですが、使わなければならない状況に追い込まれたので初心者ながら少しずつコミットしたりしながらGitの使い方を学んでいたらGitってもしかして楽しいかも!!って思うようになり、もっとGitの事を学びたくて色々勉強出来る資料やサイトを集めていて情報がたまって来たので、ここでまとめていつでも見れるようにしたいと思います。 Gitの仕組みを優しく教えてくれるスライド 素敵なスライドがありましたのでご紹介させていただきます。 うん、見やすい!見やすいよー!! Gitを勉強出来るサイト サルでもわかるGit入門 サルでもわかるGit入門 世界一わかりやすく説明しているサイトです。僕でもわかりました。 Learn Git Branching Learn Git Branching ゲーム感覚で勉強したい時はこちら。このサイト自体がすごい 笑 Gitコマンド
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitでMerge CommitをRevertする方法 - Qiita
Gitを使ったRoute53の管理
http://blog.yuku-t.com/entry/20110427/1303868482
