git configをプロジェクトによって使い分ける - QiitaGit v2.13.0（2017/05/10リリース）でgit configにConditional includes（条件付きインクルード）という機能が実装され、特定のリポジトリに対して一括でgit configを適用できるようになりました。 会社用と個人用でプロファイルを使い分けたり、たまに使う設定をまとめて適用する場合などに役立ちそうです。 設定方法 includeIfセクションを使います。git configコマンドか、~/.gitconfigを直接編集して追記します。
git-hyper-blame のセットアップ方法と使い方
任意のコミットを無視して git blame してくれるやつ。いわゆるメガコ ミットを無視した blame をしたいときに使える。 なぜかセットアップにひどくハマったのでメモ。 セットアップ方法# git clone してくる $ git clone https://github.com/google/proto-quic.git 以下のように、パスの通ったディレクトリに git-hyper-blame という 名前のシンボリックリンクを作る。git のサブコマンド hyper-blame が 利用可能になる $ ln -s ~/src/github.com/google/proto-quic/depot_tools/git_hyper_blame.py ~/bin/git-hyper-blame ※ Python は macOS Sierra 付属の /usr/bin/python (P
一気に書いた新規ファイルを一部git addしたい時にはgit add -Nが便利 - Takuji->find;
新機能作ったりする時、コード書くのに集中しすぎるとコミットする前にめっちゃ色々混ざったファイルができてしまったりして、最悪な感じになることが多い。 自分は割と細かい単位でコミットするようにしている(あとで戻せるように)ので、こうなってしまった時今まではチマチマと手動で消してaddして、commitして、undoしてみたいなことをやっていたが、ミスったりすると数時間分の作業が消える。 そういう時にはgit add -N (file path) すると、ファイルの存在だけindexに乗せることができるので、あとはgit add -pでパッチモードにしてがんばる。 そもそもちゃんと細かくコミットしろよって話でもある。
git blameによるSRP（単一責任原則）の定量化 - どこでも見れるメモ帳
はじめに ソースコードを静的解析することでSRP（単一責任原則）を定量的に算出します．*1 svn blameによるSRP算出*2を参考に、git blameによる算出をshで行ってみました． このSRP値が最大のモジュールが王様モジュールに相当します． # 単一責務性の違反指数（SRP） # SRP＝R＋U＋((L/100)－5) # R：修正リビジョンのユニーク数 # U：修正ユーザのユニーク数 # L：モジュールのライン数 function get_SRP() { local target_filepath=$1 echo $(( \ $(git --no-pager blame --line-porcelain $target_filepath | sed -n 's/^summary //p' | sort | uniq -c | sort -rn | wc -l) + \ $(
Git の仕組み (1) - こせきの技術日記
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
GitHub Training
GitHub for Developers, Kyoto Japan Class delivered on June 04 2014 Teachers Jordan McCullough (Twitter, GitHub) Installation The Git-SCM Web Site (All Platforms) The GitHub for Mac Client The GitHub for Windows Client and Command Line Minimum is 1.8.0 or higher. Earlier versions can have issues with HTTPS credential prompting. Command Line History Coming soon
ghq: リモートリポジトリのローカルクローンをシンプルに管理する - 詩と創作・思索のひろば
以前紹介したghqというツールで GitHub のリポジトリを手元に簡単クローンしてたのを、環境が新しくなったついでに Go で書き直し、完全リニューアルしました。（前は zsh だったのでなんだかなーと思ってた。） そもそも何をするツールか GitHub や Google Code Project でホストされている Git、Mercurial のリポジトリを手元にクローンすることができます。リポジトリは設定したルート（デフォルトで ~/.ghq）以下に、以下のようなパスで置かれます。 ~/.ghq/github.com/motemen/ghq go get と似てますね。同じような感じで ghq get <URL> します。 % ghq get https://github.com/motemen/ghq clone https://github.com/motemen/ghq ->
もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術
はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ
「天下一.gitconfig大会」の意外な結末 - Cybozu Inside Out | サイボウズエンジニアのブログ
先日（※1）、「.gitconfigの書き方や、gitのTipsについてワイワイ情報交換しましょう！」という趣旨で社内勉強会が開催されました。題して「天下一.gitconfig大会」。ここに我こそはと、5名の強者がネタをエントリしました。 業務後の時間にもかかわらず、いろんな部署から20人以上が参加。社内で最も大きな会議室が、ほぼいっぱいに。 「さいきょうの.gitconfig」（天野 祐介） 「jenkins先生にライブラリの更新をお願いする」（田中 裕一） 「おれさまの.gitconfigでぎっとぎとにしてやんよ」（佐藤 鉄平） 「git のよくある誤解 No.1 rebase について」（山本 泰宇） 「rebase すべき時とその作法」（星野 喬） 天野が、.gitconfigのベストプラクティスを探求していたら、いつの間にかシェルのベスト環境を構築していた……というオチで笑いを取
怠惰にgitを使うためのシェル活用術、またはgst一族 - Qiita
Git Advent Calendar / Jun. 6/12 担当@T_Hashです。 明日も仕事でだるいのですが、怠惰はプログラマの美徳といいます。というわけで僕が日々の仕事で怠惰にgitを使うための設定を共有したいと思います。 zsh ↓を参考にした設定を.zshrcに記述して、右プロンプトにブランチ名とステータスを表示させています。コマンドを叩かずに状態が見えて非常に便利です。 git のブランチ名 と作業状態 を zsh の右プロンプトに表示＋ status に応じて色もつけてみた 緑だとクリーンな状態、赤だと未コミットの変更があります。「緑が正常な状態、緑に戻って来たら一段落してコーヒー飲もう」とか考えながら作業をしてます。 あと、zshはgitのコマンドも補完してくれるので地味に重宝します。 gst: git status git statusは常に叩くクセを付けた方がいいと
イラストでわかる！git入門の入門
こんにちは、アシアルの志田です。 社内でもgitが浸透し、皆バージョン管理といえばgitだよね、という空気になってきました。 ですが、これまでバージョン管理システムを使ったことがない人にオススメしても、 「gitて…まあ…そりゃ…ねえ、いつかやらないといけないけど…」 「ギット？ジット？俺はgiはジと読む派なので、gitは胡散臭いと思う」 「そもそもバージョン管理して何が嬉しいの？なんか難しそうでいやだ」 というような反応ばかりでした。 きっとみんな、gitって難しくて訳のわからんもんだと思っているのでは？と思い、 今回はgit入門の入門、gitってなんだ？というところから、簡単にgitを使う際の流れについてご説明します。 ちょっと不安を覚えるようなイラストがついていますので、頑張って読んでください。 バージョン管理ってなに？ プログラムを書いていて、こんなことありませんか？私はあります…
Gitを使い始めたらやっておきたい便利な設定いろいろ
こんにちは、中川です。 Gitを使い始めてから、Subversionを使う機会がめっきり減ったこの頃です。 Gitだとローカルだけで簡単に使い始められるのもいいですが、気軽につくれるbranchや、mergeのしやすさがたまりませんね。 インストール直後の状態でも普通に利用できますが、 ちょっとした設定でさらに使いやすくなる方法をご紹介したいと思います。 ※今回ご紹介する内容はいずれも私のMacBook上での動作確認となり、Windows環境は考慮していませんがご容赦ください。 ■ユーザー名とE-mailアドレスの設定 まずは、最初にユーザ名と、メールアドレスを設定してしまいましょう。 $ git config --global user.name "yoshiki" $ git config --global user.email "yoshiki@example.com"
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to ZFS · GitBook (Legacy)
入門書には載ってない Git & GitHub Tips