git と mercurial の diff を美しく表示するために必要なたった 1つの設定 (原題: diff-highlight 1.0.0 をリリースしました) - Hack like a rolling stone
Git の diff を美しく表示するために必要なたった 1 つの設定 #git にインスパイアされて作り始めた diff-highlight にあれこれ手を入れ、1.0.0 として正式リリースしました。 diff-highlight と git-contrib/diff-highlight の違い 差分の中で +/- の行数が一致していないときのハイライトの扱い git-contrib/diff-highlight での表示 +/- の行が一致していないとハイライトされません。 diff-highlight では、マッチする行を認識してハイライトします。 +/- の行数が一致しても、文字単位でのハイライトをしてくれないケースがある git-contrib/diff-highlight での表示 差分の 1行目同士を比較しているため、pager の行がハイライトされていません。 diff-
もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術
はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ
GitHub Training Kit
Open source courseware from the GitHub Professional Services team.
Git の diff を美しく表示するために必要なたった 1 つの設定 #git - 詩と創作・思索のひろば
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
卜部昌平のあまりreblogしないtumblr
前回の続き。 前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。 で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えてお
Git で変更されたファイルを簡単に無視する設定 - 永遠に未完成
管理下に置かれてるんだけどなぜか無駄に変更されてしまうファイルというのがたまにあって、まあ管理方法見直せという話もあるんだけど、それも叶わない場合、そういうのは無視したい。 その方法についてはこの記事が詳しいのだけど、私はこれを以下のように alias 設定している。 [alias] ignore = update-index --assume-unchanged unignore = update-index --no-assume-unchanged ignored = !git ls-files -v | grep "^[a-z]"これで、 git ignore {file} ファイルを無視する git ignored 無視されたファイルの一覧を表示する git unignore {file} 無視されたファイルを元に戻す という風に直感的に扱えるので便利。
Gitレポジトリを移行する方法 - tanacasinoのメモ
既存のGitレポジトリを、GithubやBitBucketのようなホスティングサーバに移行したり、逆にローカルサーバのGitBucketやGitLabなどに移行したい場合、まあ単純にpushすればいいやんと思ったら、思うような結果にならなかったり、面倒な手順になってしまったりしてしまった。 どうも自分のワーキングのレポジトリから飛ばそうとすると、tagだったりbranchだったりが移行できていないかったりするのです。 ぐぐると、いったんローカルにリモートと同名のブランチ作って(checkoutして)から、push --all, --tags とかしてる奴とかありますがそれは面倒だなぁやだなぁみたいな。 最終的には、これが一番楽な手順かなと思う手順に行きつけたのでここに記す。 $ git clone --mirror <SOURCE_REPOSITORY_URL> $ cd <REPOSIT
gistコマンドよりちょっと便利なgisty - SWDYH
メモやちょっとしたスクリプトなどをペーストするとgitのリポジトリとして管理してくれるgistというサービスがあります。そのgistにコマンドラインから投稿するツールがあって、それは前に少し紹介したんですが、それをもうちょっと便利にしたものを作りました。 swdyh's gisty at master ― GitHub http://github.com/swdyh/gisty/tree/master gistコマンドとの違いはこんな感じです。 ポストするときにファイルを指定。ファイル名、拡張子つきでアップされる。 ポスト時に複数ファイルを指定できる。 ポスト後、ブラウザで開く。(Macのみ) ポスト後、ローカルにcloneする。 過去のgistにアップしたのを全部のclone、またはpullする機能 gistyを使うと簡単にファイル名と拡張子つきでポストできて、そのままローカルにclon
git? tig! | Atlassian Japan 公式ブログ | アトラシアン株式会社
私は Git の大ファンですが、そのためほとんどの UI (ユーザーインターフェース)、特に IDE に統合されているものに関してはそれほどの大ファンではありません。これらの UI は複雑でややこしいのです。これらはいくつかの一般「VCS」言語をコマンドにマップしようとします。または隠しすぎるので、何が起こっているのか理解しずらくしてしまいます。更にひどい場合： Tcl/Tk で書かれています… 端的に言えば、私はこれらの UI を信頼していません。 コマンドラインは私のためのものです。自分のコマンドラインは好きなので、これは素晴らしいものです。ほとんどいつでも履歴の「グラフィック」ビューを見られることや、コミットを準備している時に少し助けてもらえるのは良いことです。 tig で入力する。tig はテキストモード、 Jonas Fonseca によって書かれた git 用の ncurses
zshでgitのコマンドやブランチ名を補完できるようにする | qnyp blog
zshでのgitコマンドの入力補完を設定する方法はいくつかあるようですが、最近はgitのソースツリーにcontrib/completion/git-completion.zshというものが含まれているので、今回はそれを利用する手順を紹介します。 設定を行うと、以下のようにコマンドやリモートリポジトリ、ブランチ名の補完ができるようになります。 今回、動作を確認した環境は以下の通りです。 Mac OS X 10.8.3 zsh 5.0.2 git 1.8.2.3 zshとgitをHomebrewでインストールしている場合は、zshの設定を行うだけで作業完了です。git 1.8.2.2に含まれる補完定義ファイルとgit 1.8.2.3に含まれるそれとでは結構違いがあるようなので（コミットログ）、gitはできるだけ最新版にアップデートしておきましょう。 Homebrewを使っていない場合は、補完定
twiwt.org - このウェブサイトは販売用です！ - twiwt リソースおよび情報
このウェブサイトは販売用です！ twiwt.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、twiwt.orgが全てとなります。あなたがお探しの内容が見つかることを願っています！
git の運用指針 - Cube Lilac
ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが（ただのコミットマシーン状態）、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。 前提 まず始めに、現在のプロジェクトの状況は下記のようになっています。 開発は 1 人のメインコミッタ（私）と数人のサポートコミッタ（アルバイト等）で行われる メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態 サポートコミッタに対しては、基本的に 1 機能（1 チケット）を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあ
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 から元に戻せる。特にコミットす
愛知県の社会福祉法人 清凉会は、老人ホーム・デイサービス・特別養護老人ホーム・保育園などを運営しております。
ABOUT SEIRYOU GROUP 清凉グループについて 清凉グループでは、「あふれる笑顔～慈悲の心で～」を経営理念として掲げ、 地域における介護・保育ニーズにお応えすべく、複数の施設を運営しております。 今後も地域の皆様の生活に寄り添う場所として、個々の施設と連携し、よりよいサービスを追求していく所存です。 清凉グループからのお知らせinformation
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
Git で複数のリポジトリをまとめたり、逆に切り出したりする - Qiita
~/repo1/subdir に ~/repo2 を入れる あるリポジトリのサブディレクトリに別のリポジトリの中身を入れたいとき。たとえば、あるリポジトリのサブディレクトリを切り出して別のリポジトリとして管理しているものを、元のリポジトリに合流させたいとき。 cd ~/repo1 git remote add repo2 ~/repo2 git fetch repo2 # サブディレクトリの内容に repo2 の内容をマージする # （repo2 と内容が似ているサブディレクトリを自動で判別） git merge -s subtree repo2/master # ↑でうまくいかないときにはパスを指定する↓ git merge -X subtree=subdir repo2/master # そもそも ~/repo1/subdir が存在しないときには↓ git read-tree --p
Learn Git Branching
A interactive Git visualization tool to educate and challenge!
git 1.8.2 リリースノートを眺めて、新機能把握と設定を追加 | Act as Professional
世の中はGoogleリーダーで盛り上がってる中、Livedoor Readerに移行した@HIROCASTERでございませう。 そんななか、ひっそりと git 1.8.2 がリリースされました。 リリースノートを眺めていたら知らない機能があったので書いておきます。 git check-ignore * “git check-ignore” command to help debugging .gitignore files has been added. 1.8.2からの新機能です。 .gitignore ファイルに記述されてい内容と実際のファイルが該当するかチェックできます。 例えば .gitignore ファイルに /tmpと書いたとします。 $ git check-ignore -v ./tmp .gitignore:1:/tmp ./tmpのように1行目の設定に該当して、exclu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitのdiffを見やすく表示する - Qiita
git add したあと、commit するの忘れてて reset --hard しちゃったけど、取り戻したい #git - Qiita [キータ]![git add したあと、commit するの忘れてて reset --hard しちゃったけど、取り戻したい #git - Qiita [キータ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/adbaf09775fe6b713d0b3670963d78f7f02a1ad1/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9Z2l0JTIwYWRkJTIwJUUzJTgxJTk3JUUzJTgxJTlGJUUzJTgxJTgyJUUzJTgxJUE4JUUzJTgwJTgxY29tbWl0JTIwJUUzJTgxJTk5JUUzJTgyJThCJUUzJTgxJUFFJUU1JUJGJTk4JUUzJTgyJThDJUUzJTgxJUE2JUUzJTgxJUE2JTIwcmVzZXQlMjAtLWhhcmQlMjAlRTMlODElOTclRTMlODElQTElRTMlODIlODMlRTMlODElQTMlRTMlODElOUYlRTMlODElOTElRTMlODElQTklRTMlODAlODElRTUlOEYlOTYlRTMlODIlOEElRTYlODglQkIlRTMlODElOTclRTMlODElOUYlRTMlODElODQmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTAwZTBjM2RkODk4YWUxMTE2MTM3Mzk0NzJkYTA3ZDI0%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQweW9zaGlvcmkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTA4YTg5ZDczZTQ1NjEwNjI3MGY3ZmMwMjU0MDdiYmVi%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Db5f931c45f0432b71eed2ceb96d948bf)
