branch

ブランチを指定してclone

% git clone [url] -b [branch name] [dir name]

空のブランチを作る

$ git checkout --orphan [branch name]

任意のコミットから新ブランチを派生させる

$ git checkout -b [branch name] [commit hash]

commit

空のコミットをする

$ git commit --allow-empty -m "[commit message]"

tree形式でコミットログを表示

$ git log --graph --all --pretty=format:'%C(yellow)%h%C(cyan)%d%Creset %s %C(white)- %an, %ar%Creset'

diff

コミット単体のdiffを見る

$ git show [commit hash]

GitHub上のdiffファイルのエクスポート

Adding .patch (or .diff) to the commit-URL will give a nice patch:
How to download a single commit-diff from GitHub?

https://github.com/foo/bar/commit/${SHA}.patch

差分ファイルを抽出する

一個前のコミットから現在のコミットまでの差分を取り出したい時は、

git archive --format=zip --prefix=root/ HEAD `git diff --diff-filter=d --name-only HEAD^ HEAD` -o archive.zip

--format=zip を付けるとzipで固めてくれます。
--prefix=root/ は抽出したファイルをrootディレクトリに入れた状態にしてくれます。
-o archive.zip で出力先と出力名を指定しています。
HEAD は抽出元のコミットで、抽出したいファイルやディレクトリをgit diffを使って指定しています。

push

すべてのローカルブランチを指定したリモートリポジトリにプッシュする

$ git push <remote> --all

stash

退避

$ git stash

stashした一覧

※git logのオプションが使える

$ git stash list

変更内容に含まれるファイルの一覧

$ git stash show [stash name]

復活

$ git stash apply [stash name]

削除

stash applyで変更を復活した場合は、stashリストのなかに復活済みの変更が残されている
これを削除するには、次のコマンドを使用する

$ git stash drop [stash name]

復活と削除を同時に行う

$ git stash pop [stash name]

log

commit履歴をブランチ別のツリー形式で表示

$ git log --oneline --graph --all

$ git lg -10

tips

プルリクでコンフリクトしたら：rebase編

# masterを最新状態にする
$ git checkout master
$ git pull

# トピックブランチをcheckout
$ git checkout dev-hoge

# トピックブランチをmasterの最新状態にrebase
$ git rebase master

# コンフリクトを解消する

# addしてrebaseを完了
$ git add .
$ git rebase --continue

# トピックブランチのリモートに強制push
$ git push -f origin dev-hoge

# この後プルリク

【例】
dev-A、dev-Bが同時進行中で競合派生。
dev-Aを先にリリース。
dev-Bをマージしようとするとコンフリクト。

*   91c78c6 Merge pull request #2 from project/dev
|\
| *   f4865e9 Merge pull request #1 from project/dev-A
| |\
|/ /
| * cfcdb54 dev-Aの変更
|/
| * e63117f dev-Bの変更
|/
* 46c27a7 first commit

↓↓↓

dev-Bをrebaseして、dev-Aリリース後のmasterからブランチを派生しなおす。
コミットハッシュがこのように整理される。

*   408493e Merge pull request #4 from project/dev
|\
| *   a7a8c8c Merge pull request #3 from project/dev-B
| |\
| | * c11bba6 dev-Bの変更
| |/
|/|
* |   91c78c6 Merge pull request #2 from project/dev
|\ \
| |/
| *   f4865e9 Merge pull request #1 from project/dev-A
| |\
|/ /
| * cfcdb54 dev-Aの変更
|/
* 46c27a7 first commit

カレントディレクトリ（.gitignoreファイルが置いてあるディレクトリ）の書き方

× ./
〇 / （ドットは要らない）

特定ディレクトリ以下

× FolderA（フォルダのみの指定となって、ディレクトリより下がignoreの対象とならない）
〇 FloderA/

---

↓このサイトの開発時技術情報です。
債券計算サイト

これなんの記事?

と思ったあなたのためにまずは説明を。

あなたは自分のpcでとあるプロジェクトの作業をしようとしています、「githubのこのリポジトリcloneして作業お願いします」と言われたので、ささっと作業してpush。

ふう、今回もスマートに作業を終わらせてしまった・・・と悦に浸っていたのですが次の日会社に出社すると「よお!クラウド!」、「あ、クラウドじゃん!」、「クラウドさんチーッス!」と言い始める同僚社員たち、なぜ誰にも言ったことのない自分のハンドルネームが!?と困惑するあなた、全ては昨日の作業が原因だったのです。

なんとgithub上で閲覧できるコミット履歴に自分が個人的に使っているHNが表示されてしまっているではないですか！

何が起こったの?

ローカルリポジトリごとにユーザー情報を設定していなかったため、グローバルに登録されたユーザー情報が使用されてしまっていたのです。

gitのコミットにはコミットしたユーザーの情報が含まれることはご存知でしょうか。

git log で出力したコミット履歴を見ていくとこんな表記があるはずです。

Author: †kuraudo† <kuraudo@sefirosu.com>

で、この情報どこから出てきたの?ということなんですが、gitインストールして初回のコミット前にみなさんユーザー情報(ユーザー名&メールアドレス)を登録しているはずです。
↓多分こんなの

git config --global user.name †kuraudo†
git config --global user.email kuraudo@sefirosu.com

この設定、 --global オプションがついているため、各ローカルリポジトリ別にユーザー情報の設定がなければ全てのローカルリポジトリで使用されます。
恐らくクラウドさんことあなたはgitインストール初期にgitの公式を見て言われるがまま自分の好きなユーザーネームと個人で使用しているメールアドレスを入れてしまったのでしょう。

そしてcloneしたてのローカルリポジトリにはuser情報の設定がないため、globalに設定された上記のユーザー情報がそのまま使用されてしまったというわけですね。

ローカルリポジトリ別の設定を確認するには、git管理下のディレクトリに入って git config --local -l コマンドで確認できます。

core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.precomposeunicode=true
...(略)

こんな感じで色々設定があると思いますが、 user.name と user.email という設定は存在していないはずです。

どうしたらいいの?

今回のような悲劇を繰り返さないためにはどうすればいいかというと前述の通りlocalでユーザー情報の設定を追加してあげれば良いわけですね。

git config --local user.name kasyuu
git config --local user.email xxx@xxxx.com

git log --local で確認してちゃんと設定されていればOK

user.name=kasyuu
user.email=xxx@xxxx.com

コミットしてpushし直してみましょう。

ちゃんと自分のユーザー名が表示されましたね。

ちなみにアイコンにgithubのアイコンが表示されていることに気づいた方もいるかもしれませんが、githubやgitlab等大半のリモートリポジトリホスティングサービスでは、ユーザー登録時に使用したユーザー名とメールアドレスがコミットユーザー情報と一致した場合、自動的に登録されているユーザー情報と紐づけてくれます。

そのため、基本的には使用しているホスティングサービスで使用しているユーザー名とメールアドレスを登録するのが良いでしょう。

さいごに

そのため、基本的には使用しているホスティングサービスで使用しているユーザー名とメールアドレスを登録するのが良いでしょう。

正直これが一番言いたかった。
(あまり気にしない方もいるかもしれませんが、登録されていないユーザーの名前がgithub等のコミット履歴に並ぶの気持ち悪くありません?アイコンも表示されないので視覚的にもわかりにくいですし・・・)