カテゴリー : Git

git merge –ff と –no-ff の違いを理解するための日本語・英語の記事まとめ

git merge –ff と –no-ff の違いを理解するための日本語と英語の記事を読み漁ったので、それぞれご紹介します。

Git

git merge –ff と –no-ff の違い

日本語の記事

英語の記事

続きを読む

GitHub から Bitbucket へ Private リポジトリとして fork しつつ開発する方法

GitHub のリポジトリを Bitbucket のプライベートリポジトリへ fork みたいな管理をしつつ、開発する方法をご紹介します。

GitHub Bitbucket

前提

GitHub に Public リポジトリとして公開されている mastodon を Bitbucket の Private リポジトリとして扱いたくなりました。

理由としては、Bitbucket は Private リポジトリが無料 で使えるためです。

GitHub でそのまま fork してしまった方が楽なのですが、GitHub で Private リポジトリを使う場合、毎月 $7 かかるので使ってません。

本記事は、私のように無料で使える Bitbucket で Private リポジトリを運用したい開発者向けの内容です。

続きを読む

[Git] merged な remote branch を一括削除するコマンド

Git で merged な remote branch を一括削除するコマンドをご紹介します。

マージ済みリモートブランチ一括削除コマンド

git branch --remote --merged master | \
grep -v -e master -e release -e staging | \
sed -e 's% *origin/%%' | \
xargs -I% git push --delete origin %

前提として master, release, staging branch は対象外としています。

削除後、リモートブランチの同期

他の人がリモートブランチが削除しても、自分のローカルブランチにはリモートブランチの情報が残ったままです。

以下のコマンドでリモートブランチの情報を同期できます。

git remote prune origin

他にも、

git fetch --prune

git pull --prune

というように –prune オプションを付ければ同期できます。

参考情報

git log -S で過去に削除したコードを探せる

git で過去に削除したコードを探すには git log -S 検索ワード で検索ワードが含まれている commit を検索できるみたいです。

Use git log -S to search in the history for commits that changed . Add an optional -p to see the diff as well.

commit の内容まで確認したい場合は -P オプションを併用するとよいです。

git log -P -S 検索ワード

「あのコードっていつ削除されたんだっけ?」って、たまに調べたいときに git log -S は便利ですね。

[Git] リモートから特定のブランチを指定してcloneする

git でリモートから特定のブランチを指定して clone するには -b オプションを付けて branch 名を指定すればいい。

(例) node リポジトリの v0.12 ブランチを clone する

# git clone -b ブランチ名 https://リポジトリのアドレス
git clone -b v0.12 git@github.com:joyent/node.git

[Git] .git/hooks/pre-commit をスキップしてコミットする

git commit の前に実行されるフックを .git/hooks/pre-commit に 定義しているのですが、たまに無視して commit したいことってありませんか?

pre-commit hook をスキップしてコミットする option

# 長い option
git commit --no-verify
 
# 短い option 
git commit -n

例えば、pre-commit hook を無視して git commit したいシチュエーションとしては、行末に whitespace があると commit させない hook を定義していた場合、既存コードで該当箇所が存在すると hook に引っ掛かってしまいます。

下記のようなケースです。

この例は記事上で見ると分かりにくいのですが var express = require(“express”); の末尾に半角スペースが含まれてしまっています。

$ git diff --cached
 
diff --git a/hoge.js b/hoge.js
new file mode 100644
index 0000000..8504c82
--- /dev/null
+++ b/hoge.js
@@ -0,0 +1 @@
+var express = require("express"); 
 
 
$ git commit
 
hoge.js:1: trailing whitespace.
+var express = require("express"); 
 
# -n を付ければ pre-hook をスキップして commit できます
$ git commit -n

以上です。


参考情報

git stash pop で conflict したときに元に戻す手順

git stash pop でコンフリクトが発生してしまったときに元に戻す手順をご紹介します。

git checkout --ours .
git reset
git checkout .

git stash コマンド自体たまにしか使わなくて、よく忘れてしまうので備忘録として。

[Git] commit の粒度、良い commit message について

git を使った開発フローにおいて「commit の単位」と「良い commit message」について考える機会があったので、個人的に気をつけているポイントとそれを補足する記事をまとめてみました。

個人的に気をつけてるポイント

  • commit の粒度は細かくする
  • commit message は意味ある内容を書く

以下に、ぼく個人が気をつけているポイントが明文化されている記事のリンクを張っておきます。

commit について同じようなポイントで悩んだことがある方は参考にしてみてはいかがでしょうか。

[Git] 誤って git push origin master したときに元に戻す方法

誤って git push origin master したときの対処方法をメモしておきます。

難しいことは考えずに、戻したい commit を全て revert してから master branch を push するだけです。

# 1. 戻したい commit を全て revert する
git revert e70e1149f59a7ebee10e34bcd0c42651bcedf08a
git revert 776eb2334228c42935b4d37b5ac61a0e78f956ef
 
# 2. revert 後に改めて remote branch へ push する
git push origin master

仕事のプロダクトを扱ってる remote branch という前提なので、リスクは負いたくないので git push -f のような force push はやりませんでした。

force push すると更に remote branch がめちゃくちゃになるという危険があるので commit log は汚れますが安全な手段をとりました。

[Git] merge で conflict したときにマージ前の状態に戻すコマンド

git merge で conflict したときにマージ前の状態に戻すコマンドは、

git reset --hard ORIG_HEAD

です。

たまに使う機会があって毎回ググっているので、このブログにもメモとして残しておきます。


参考情報

gitでマージ作業を中止して元の状態に戻す – TIM Labs