gitは通常、変更がaddされていない場合はコミットを作成しない(--allow-emptyが必要)。
しかし、pre-commitフックで何らかの操作を実行し、結果として差分が消失した場合でもコミットは作成される。

pre-commit

#!/bin/sh

git diff --cached | 対象ファイルに対してなんか色々処理 | 最後に再度addする

例えば上のようなフックで「色々処理」の結果、addしたファイルの変更が元に戻ったとする。この時でもコミットは作成される。git diff HEAD~..HEADには何も表示されない。

更に極端なことを言えば、フック内でファイルを全てreset(アンステージ)してもコミットは作成される。

pre-commit

#!/bin/sh

git reset 
#賽の河原的なアレ

だからどうしたという話だが、ちょっと興味深かったのでメモ。

概要

次のツイートを見て便利そうだと思った。

これは本当にとても便利なgitのログ機能なんですが、 git log -L :関数名:ファイル名 でその関数の履歴が見れます pic.twitter.com/wcul1OYr0W

— ほぼろ (@rhoboro) May 22, 2019

どうやら

git log -L :<関数名>:<ファイルパス>

という形式で特定の関数の変更履歴が見られるらしい。
このツイートでは Python の関数の変更履歴を表示していたが、Ruby のメソッドでもできるか試してみた。

例

試しに Active Support コア拡張機能の String#truncate の変更履歴を確認してみる。ローカルに Rails のリポジトリを git clone して、次の git コマンドを実行する。

git log -L :truncate:activesupport/lib/active_support/core_ext/string/filters.rb

本当に truncate のログと差分だけ表示された！メソッドの変更を追跡するのにファイルごとだと粒度が大きいので、メソッドごとに表示できるのは便利だ ☺️

何度も引っかかったのでメモ。

前提

• GitHub登録済み
• Gitインストール済み
• Git Bash使用

秘密鍵・公開鍵生成

Git Bashを使います。現在地は~(/c/Users/[Username])です。以下のコマンドで鍵を生成します。

ssh-keygen -t rsa -b 4096 -f ~/.ssh/[filename]

[filename]にはrsa_githubなど好きな名前を付けましょう。これで、RSA方式の4096bit長の鍵が生成されました。

公開鍵をGitHubに登録する

1. ブラウザを開き、GitHubのSettings->SSH and GPG keysに行きます。
2. SSH keysのNew SSH keyをクリックします。
3. Titleに適当な名前を付けます。
4. 下のKeyに公開鍵を貼り付けるのですが、ここでGit Bashの方に戻ります。

Git Bashで.sshフォルダに移動します。

cd .ssh

そこでlsすると、[filename]と[filename].pubの二つのファイルがあると思います。.pub有りが公開鍵、.pub無しが秘密鍵です。公開鍵の内容をコピーします。catで表示してコピーでもいいですが、以下のコマンドが便利です。

clip < ~/.ssh/[filename].pub

これでクリップボードに公開鍵がコピーされました。そして、ブラウザに戻りましょう。4.で説明したKeyに公開鍵をペーストします。ペーストしたら、Add SSH keyで保存します。これで、GitHubでの操作は終わりです。

SSH接続の設定をする

Git Bashで.ssh直下にconfigファイルを作ります。

touch config

あとはvimなりatomなり好なものでconfigを編集します。自分はatom使いたいので、

atom config

で、atomで開きます。以下のように書き込みます。

config

Host github
    HostName github.com
    IdentityFile ~/.ssh/[filename]
    User git

左の空白はtabです。
さらに、windowsではssh-agentにaddする必要があります。ssh-agentを起動します。

ssh-agent bash

ssh-agentに先ほど生成した秘密鍵を登録します。

ssh-add ~/.ssh/[filemname]

登録できたか確認します。

ssh-add -l

鍵の情報が表示されていればOKです。

接続の確認

それでは、接続できるか確認してみましょう。

ssh -T git@github.com

これで、以下のように表示されていれば成功です。

Hi [Username]! You've successfully authenticated, but GitHub does not provide shell access.

GitLabでもやることは大体一緒です。

どのコミットを修正したいか

git rebase -i HEAD~3

修正対象を pick から edit にする

 pick xxx1
 pick xxx2
 edit xxx3

author を変えたい時

git commit --amend --reset-author

元のコミットを再適用

git rebase --continue

注意

上記の例の場合、
xxx1
xxx2
のコミッターのローカルブランチが不整合で使えなくなります。

gcm "find_by!にした"

gcm 'find_by!にした'

https://garakuta-toolbox.hatenablog.com/entry/2017/11/19/161534

テスト

echo hoge!

hoge!

echo "hoge!"

echo "hoge"
hoge

echo 'hoge!'

hoge!

背景

• 結構前にcommitしてしまったものにデカイファイルがあった
• commitをかなりした後にリモートにpushしようとしたら「デカイファイルがあるのでremote rejectしました」エラーが出た
• git rm そのファイル をしてcommitしても、一度commitされてるファイルなので、pushしようとする
• 最初にcommitした時点に戻って、ファイルを取り除かないといけない！

$ git push -u origin local-staging-darkorange
Enumerating objects: 149, done.
Counting objects: 100% (149/149), done.
Delta compression using up to 8 threads.
Compressing objects: 100% (114/114), done.
Writing objects: 100% (114/114), 115.08 MiB | 1.85 MiB/s, done.
Total 114 (delta 81), reused 0 (delta 0)
remote: Resolving deltas: 100% (81/81), completed with 29 local objects.
remote: warning: File sheets-export.zip is 55.36 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB
remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.
remote: error: Trace: 501288f695fd5ee39c76eee83cda62a8
remote: error: See http://git.io/iEPt8g for more information.
remote: error: File wnjpn.db is 193.70 MB; this exceeds GitHub's file size limit of 100.00 MB
To https://github.com/***
 ! [remote rejected]   local-staging-darkorange -> local-staging-darkorange (pre-receive hook declined)
error: failed to push some refs to 'https://github.com/***'

したこと

$ git log -p wnjpn.db
commit 239b04ceb8b988a900af5100734c07314ca1d44a
Date:   Fri May 17 11:52:12 2019 +0900
    ボタン変更など

$ git log --oneline
4492c9c4 (HEAD -> local-staging-darkorange) modify
bab5be53 *** テストスクリプト作成
a4e50bd1 項目数に制限がない項目を同等に扱う
9afb0a4c rule_form_element.csv変更
ecefa5ac trush iconの表示方法の変更
d2bcc121 *** テストスクリプト
239b04ce ボタン変更など

$ git rebase -i HEAD~7
Checking out files: 100% (20/20), done.
Stopped at 239b04ce...  ボタン変更など
You can amend the commit now, with
  git commit --amend 
Once you are satisfied with your changes, run
  git rebase --continue

$ git rm --cached wnjpn.db
rm 'wnjpn.db'
$ git commit --amend
$ git rebase --continue
Successfully rebased and updated refs/heads/local-staging-darkorange.

参考

http://shuzo-kino.hateblo.jp/entry/2014/05/22/222251
https://chaika.hatenablog.com/entry/2016/03/22/181243
https://qiita.com/megu_ma/items/a438a71c84145f14d04e

事の始まり

ブランチAにコミットするはずの内容を間違えてブランチBにコミットしてしまった。
チームのSlackで助けを求めたところ、cherry-pickコマンドでなんとかするのが良さそうということが判明。

チェリーピックってなんすか

ブランチβにあるコミットの更新内容を、ブランチαに取り込むことができるgitの機能とのこと。
この説明を見たときは正直「マージでも同じなんじゃね？」と思ったけど、どうやらそうではなく、あくまでコミット単位で取り込めるというのがチェリーピックの特徴ということがわかった。

例えばブランチβに分岐してから１０個のコミットが生まれていた場合を考えてみる。
これをαに「マージ」しようとすると、それまでの１０個のコミットでの変更内容が全てαへと適用されてしまうことになる。
一方、これを「チェリーピック」で処理すれば、5個目と6個目のコミットで生じた変更分だけをαに取り込むことができるということ。

どうすれば使えるんだい

打ち込むコマンドは次の通り。

git cherry-pick　[commit-ID]

//一連の複数コミットをまとめてチェリーピックしたい場合は始点コミットと終点コミットをピリオド二つで結ぶ
git cherry-pick　[commit-ID-start]..[commit-ID-end]

※複数コミットをまとめる場合、始点コミットは「取り込みたいコミットの一つ前」を指定する必要がある。

[git]複数のcommitをまとめてcherry-pickする
https://dackdive.hateblo.jp/entry/2016/06/06/203542

このコマンドを打ち込むことで、現在チェックアウトしているブランチに、指定したコミットIDの内容を適用させることができる。

コミットIDそのものはgit logコマンドを実行すると確認可能。

なんかコンフリクト出ましたけど

実際にコマンドを実行してみたところ、コンフリクトが発生してしまった。
どんなときもすんなり行けるという訳ではないらしい。というか、私のコミットの粒度がおかしいんだと思う。

error: could not apply b80f80c... [コミットメッセージ]
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

vi [file]コマンドでコンフリクトを解消すればいいよ！みたいな情報を見かけたので、実行してみる。
viを実行してから/<<<コマンドでコンフリクト箇所を検索。

E486: Pattern not found: <<<

えええ・・・コンフリクト箇所が見つからないってこと？

結局

このファイルは４０万行くらいあるファイルだったので、キャパオーバーを起こしてしまったのかも。
試しにVSCodeで検索をかけてみたところ、ちゃんと見つかった。１万３０００箇所くらい。
とても人力ではやっていられないので、チェリーピックでの方法は諦めることに。トホホ。
今後似たようなケースに遭遇したら、チェリーピックって方法もあったなあぐらいに覚えておくことにします。

さて、そもそもの問題は解決していないままなんですけどどうしましょうかね（頭抱え）

はじめに

ある課題でBitbucketをつかってコードを管理していくことになりました。これはその時にGitでの管理の仕方の理解がガバガバすぎて大失敗したので、その反省・自分の中での整理をまとめてみることにしました。
要するに自分に対する戒めです。すいません。

なにをやっちゃったんですか？

今回やらかしたことを一覧で。

• ブランチ作成のルールを決めていなかった
• commitのルールを決めていなかった

要するに運用のためのルールがガバガバでした。
具体的に言うと、

1. ブランチを乱立させる（一人での開発なのに、そのブランチで何をしていたかわからなくなるなど）
2. commitがまとまってのコミットで変更が多すぎてなんやこれ、みたいになる
3. コミットのメッセージが統一されていない

最悪でした。

ブランチのルール

まずは上でやらかしたことの一つ、ブランチから。
まずは自分でブランチのルールを調べなおし、よさげなルールをパクることにしました。（参考サイトは後述）
で、どのような感じにしたかというと、こんな感じです。

ブランチ名	役割
master
develop	主にここに開発中の内容をマージする
feature	developから分岐、各機能をつくるときに切る

とりあえず、簡単にしないとわからなくなりそうだな、ということでかなりきりつめました。
これだけでもだいぶわかりやすくなり、良かったです。

commitのルール

二つ目の問題点だったcommitのルール、要はタイミングとメッセージについて。（ここも参考サイトは後述）

commitのタイミング

commitのタイミングですが、大きすぎるとわからなくなる、ということで、自分で分けたタスクの一つが終わったらコミットということにしました。
参考サイトのそのままという感じなのですが、自分的には
- 作業進度がはっきりわかる（何ができたか）
- レビューしてもらうときもわかりやすそう
という理由でこのようにしました。

commitのメッセージ

メッセージのルールは、過去にRubyで作業をしていた時を思い出し、再度自分の中でルール付けをしました。

コメント名	意味
[add]	何かしらのファイル、機能の追加を表す
[update]	機能などに修正があったとき
[delete]	ファイルなどの削除
[fix]	バグ修正

これらをメッセージの頭につけ、その後に具体的な内容を書くというスタイルにしました。（個人の課題なので少な目に、自分でわかる範囲にしました）
これでどこで何をしてがはっきりしました。

終わりに

振り返ってみれば、どれも開発前に考えろよ、というようなことでした。
まだまだまだまだ自分の実力が低いなぁと感じるところです。
これからも精進できるよう頑張ります。
ここまで読んでくださっていれば、ありがとうございます。

参考サイト

ぼくが実際に運用していたGitブランチモデルについて
→ブランチのルールについてで、とても分かりやすかったです。
Git 作業における commit と push の頻度について
→qiitaの記事。あまりcommitのタイミングみたいな記事がなかったのでとてもありがたかったです。