Write yourself a Git!
This article is an attempt at explaining the Git version control system from the bottom up, that is, starting at the most fundamental level moving up from there. This does not sound too easy, and has been attempted multiple times with questionable success. But there’s an easy way: all it takes to understand Git internals is to reimplement Git from scratch. No, don’t run. It’s not a joke, and it’s
Git commit 時のメールアドレスをディレクトリによって使い分ける - Qiita
複数の組織に属していてレポジトリによって git commit 時のメールアドレスを使い分けたい場合がある。 これまでは ~/.gitconfig で設定したデフォルトではないメールアドレスを使いたいレポジトリごとに git config user.email=project-specific@example.com のようにメールアドレスを設定していた。 レポジトリごとに設定しないといけないので結構面倒だ。 特定のメールアドレスを使うレポジトリは決まったディレクトリ以下に置くことが多いので、親ディレクトリレベルでメールアドレスを設定できたらいいな、と思っていた。 これ絶対やり方あるよな、と思いたって検索したら出てきたのでメモ。 Conditional include を使うと、特定条件を満たす場合のみ別の config を include することができる。 条件として .git ディレ
Git - Book
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
いつのまにかGitのshallow cloneが”Push”も"Pull"もできるように超進化していたよ！ すごーい！ - ブログなんだよもん
流行りに乗ってフレンズ用語を活用しようと思って、タイトルで力尽きたブログはこちらです。 はじめに 基本的なpushとpull 元になるリポジトリの作成 shallow cloneリポジトリの作成とPush full-repoとshallow-repoでの相互のpull & push まとめ はじめに 不向きと言われながらもgitでGBを超える巨大リポジトリを取り扱うことはあります。 そんなときの強い味方が Shallow Clone。 これは任意の世代だけを持ってくるので、どうせ滅多に参照しない1年以上前の履歴とか持ってくる必要がない便利な機能です。 なんですが、最近まで私の中では「shallow clone(笑)」な印象でした。 というのも、Gitのshallow cloneには制約が多く、fetchが出来ないのでputもpushも使えずせいぜいがCIサーバでのビルド時くらいだろうと思っ
GitHubのトレーニングに役立つリンク集 - ikeike443のブログ
※最初に断っておきますが、この記事はもちろん、このブログ全体もそうですが、私の個人ブログであって、会社の公式見解とは一切関係ありません 自分のチームや会社でGitHubを使いたいんだけど、チームメンバーにGitHubを使ったことのある人が自分以外いないよ、みたいなケースがあるかと思います。 そんな時に役立つリンク集を紹介しておきます。 英語のリソース GitHub Guides Mastering Markdown Mastering Issues Understanding GitHub Flow GitHub Training YouTube channel GitHub Services curriculum "Kit" GitHub for Developers GitHub for Everyone Pro Git 2 eBook GitHub Git Cheat Sheet P
人間らしいGitのエイリアス | POSTD
断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .gitconfig は、ユーザ名の設定だけが記されたものです。そして、その次に一般的なものはこれです。 [alias] ci = commit cia = commit -a cam = commit --amend cama = commit --amend -a cl = clean cldf = clean -df res = reset resa = reset HEAD ... # 82 more 4-character aliases このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま
Githubで特定のpull requestをローカルに持ってくる - Qiita
概要 OSSのメンテナっぽいことをやるとき、githubで特定のpull requestの正当性を確認したいということがあると思う。ブランチチェックアウトすれば良くね？って単純に考えていたけど、結構面倒くさかったので、メモっとく。 やり方 とりあえず、repositoryをcloneして、branchを見てみる。 $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/feature/support_gemfile remotes/origin/master remotes/origin/test_1.0.0
Gitでリモートリポジトリを巻き戻す - tmtms のメモ
Gitで間違ったコミットをリモートリポジトリに push してしまった後に、それを無かったことにするには、リモート側での作業が必要だと思っていたのですが、ローカルからの操作でもできることがわかったので備忘録的に書いておきます。 次の状態にあるとします。アルファベットはコミットだと思ってください。 リモート: A-B-C master ローカル: A-B-C-D masterローカルで変更を加えてDの状態になっています。 git push すると次のようになるのですが、 リモート: A-B-C-D master ローカル: A-B-C-D masterここで、D は間違いだったと気づきました。 リモートリポジトリの master のバックアップ用のブランチを作ります。これは必須ではありませんが、念のため。 % git push origin master:master_bakこれで次の状態に
Gitコミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
git rebaseについてのtips | けーこ in サンフランシスコ
エンジニアの友達にgithubなどgitを使用した共同開発時の豆知識を教えてもらったので、忘れないようにメモしておきます。Thanks, Shawn! マスターとのマージ時には事前にgit rebaseを使う gitを使って共同開発をすると、たまにこんなコミットメッセージを見る機会があるかもしれません。 Merge branch ‘master’ of git://github.com/hogehoge これは、最新のマスターを私のブランチにマージしたわよ、という意味合いのコミットメッセージなのですが、正直いりません。開発者それぞれがブランチとマスターをマージするたびにこのようなメッセージをログに残してしまうと、それだけでコミット履歴を占有し、重要な情報をたどるのが困難になります。 このマージ時のコミットメッセージが発生してしまう原因は、左側の図のようにpull requestを出す前に最
GitHub for Windows Shell が凄い便利 - お だ のスペース
GitHub for Windows からインストール出来ます。GUI でも操作出来るんですが、コマンドに対応した操作が良くわからないので shell を使ってます。 shell は PowerShell です。なので bash に慣れていない Windows ユーザーにも安心ですね。 で、この PowerShell かなり便利です。日本語の入出力も無問題！*1また入力補完がかなり強力です。 git のコマンド補完は当然ですが、コマンドに対応したファイルも補完してくれます。 例えば、git add の後に {tab} を押すと、git add 出来るファイルが次々と出てきます。これは msysgit の GitBush では無かったはずです。 と、ここまでは良いことずくめなんですが一つ問題が。この ファイルの入力補完ですが パスに日本語があると化けます。 順に見ていきましょう。 まずは、リ
git でファイルごとのコミット数を取ってきて，プロジェクト中のホットなファイルを割り出すという試み - その手の平は尻もつかめるさ
途中の段階でプロジェクトに入った時などに，「どれがそのプロジェクトの中心となっているファイルなんだろうか」というのを手っ取り早く知りたくなる時があります．僕はあります． そこで「どのファイルが盛んに変更されているのか」という点を指標として注目すると，良い感じにそこら辺取れるのでは無いかと思って試してみました． コミット数が多いファイルは多く変更を加えられているということから，そうしたファイルはホットであるということが言えそうな気がしたので，git でファイルごとのコミット数を取ってきて，それをソートして見てやれば良いよな，という意識でやっていきました．もちろんコミットの粒度などもあるでしょうから一概にはそうとは言い切れませんが，参考にはなる気はします． 使うスクリプトは至って簡単．以下の様な感じです． git ls-files | while read file ; do commits=
履歴を残したまま複数のgitリポジトリを統合する - Qiita
半年ほど前のことでうろ覚えなのですが、pixivで複数のリポジトリを統合したときの方法を紹介します。 AAAAAリポジトリとBBBBBリポジトリを統合し、ZZZZZという大きなリポジトリを作成します。もちろんコミットログを統合前まで遡れるようにするのが絶対条件です。 最終形↓ ZZZZZ .git AAAAA BBBBB filter-branch まず、新しくgit clone AAAAAしてきます。（なぜなら、このディレクトリはこの後使い捨てられるので、pushされてないbranchとがあると困るからです） 次にcd AAAAAして、次のコマンドを実行します。 git filter-branch --index-filter \ 'git ls-files -s | sed "s@\t\"*@&AAAAA/@" | GIT_INDEX_FILE=$GIT_INDEX_FILE.new
gitで差分を抽出してpatchで使えるファイルを生成 | 秋山ブログ
gitで差分を抽出してpatchで使えるファイルを生成したい時、毎回同じ検索ワードで検索して、毎回同じサイトを見ていたので、自分用にメモ。普通のpatchコマンドで取り込めるdiffファイルをgitで作成する – kanonjiの日記という記事が自分にとって一番分かりやすかった。このページを参考に、自分が使う用に書いておく。 $ # ファイルを生成 $ git diff (diffの方法) > (パッチ名.patch) $ # 実行結果を確認 $ patch --dry-run -p1 例 $ git diff develop features/dummy > diff.patch $ patch --dry-run -p1 gitに関する書籍
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to Write a Git Commit Message
Git でリモートのいらないブランチとタグを丸ごと消し去る - Qiita
Keeping A GitHub Fork Updated
Gitでやらかした時に使える19個の奥義 - Qiita
Blogger