これはQiitaで開催されている「新人プログラマ応援 - みんなで新人を育てよう！」イベントの投稿記事です。 Git Aliases について Git の設定で Git command の alias の設定が可能です。 これにより、よく使う操作を短いコマンドで実行ができます。 Qiita では多くの方が Git Aliases に関する記事を書いていて参考になる記事がたくさんあります。 私がよく使う alias しているコマンドもいくつか紹介しようと思います。 単純な短縮のための alias は省きます。 force push は push --force-with-lease を使うようにする これはド定番ですが必須で登録しておきたい alias です。 .gitconfig pf = push --force-with-lease Ref: 最新の main branch を参照する ローカルで main branch は作成しない運用にしているので、最新の main を参照するときは fetch して remote の main を detach するようにしています。 .gitconfig om = !"git fetch --prune && git switch -d origin/HEAD" ローカルのmainブランチを使わない運用については下記記事を参照ください。 最新の main branch を元に rebase する 上述の操作とほぼ同じです。 .gitconfig ro = !"git fetch --prune && git rebase origin/HEAD" 作業途中の編集を記録する 作業途中でブランチを変更するときに git stash は便利ですが、stash していることを忘れたり、stash しすぎると取り出すのに苦労したりします。 そのため、作業途中の変更は基本的に commit するようにしています。 また、stash list とちがって git log は参照頻度が高いため、忘れ去られるなんてこともなくなるとおもいます。 .gitconfig cw = !"git add . && git commit --no-verify --allow-empty -m '[ci skip] wip'" マージ済みブランチを削除する ローカルにマージ済みのブランチが溜まっていってしまうので一括で削除できるようにしています。 .gitconfig bc = !"git branch --merged origin/HEAD | grep -vE 'HEAD' | xargs git branch -d" ブランチを push する 新しくローカルでブランチを作成したときに --set-upstream オプションを使って毎回 origin [branch名] と記述するのが面倒です。下記の記事のように現在のいるブランチ名を参照して push するようにしておくと楽です。 .gitconfig pu = !"git push -u origin $(git branch --format='%(refname:short)' --contains)" というのを最近までずっと使っていたのですが、現在参照しているブランチしかpush することないし HEAD でいいじゃんとなっています。 .gitconfig pu = !"git push -u origin HEAD"

git push --force-with-lease の仕組み git push --forceの代わりに安全なgit push --force-with-leaseを使おうとよく言われるが、内容をいまひとつ理解していなかったので絵に描いた。 git push --force-with-lease は絶対安全ではない ただし以下のように他人が追加のコミットをした状態でも、git push --force-with-leaseが成功して、他人の追加コミットを消してしまうことがありえる。 git push --force-with-lease は絶対安全ではない。

前置き git rebaseコマンドについて学んだのまとめます。ものすごく単純な例で説明します。 git rebaseは何ができる？ 以下の２つのことができます。 コミットをつなげ直すこと コミットをまとめる まずは、「1.コミットをつなげ直すこと」について記載します。 実例(コミットをつなげ直す) 以下の例で説明します。 開発者がAさん、Bさんの2名いるとします。 test.txtという空のファイルがあります。これがmasterブランチとします。 開発のゴールは、test.txtに"a","b","c"という文字を追加したファイルを作ることとします。 Aさん、Bさんで作業を以下のように分担します。 Aさんには"a"を追加してもらう Bさんには"b","c"を追加してもらう AさんはブランチAを切り、test.txtに"a"という文字を追加しました。 BさんはブランチBを切り、test.txtに"b"という文字を追加しました。 Bさんは"c"を追加する前にAさんの作業内容を取込みたいとします。 ここでBさんはAさんの作業内容取込に、mergeとrebaseの2つの手段がとれます。 以下の実例でmergeする場合と、rebaseする場合の両方やってみます。 準備 空のファイルtest.txtがあるmasterブランチの状態まで準備します。 $ mkdir test $ cd test $ git init $ touch test.txt $ git add test.txt $ git commit -m 'initial commit' Aさんの作業 "a"という文字を追加します $ git checkout -b branchA $ echo a >> test.txt $ git add test.txt $ git commit -m 'add a' Bさんの作業 "b"という文字を追加します $ git checkout master $ git checkout -b branchB $ echo b >> test.txt $ git add test.txt $ git commit -m 'add b' BさんがAさんの作業内容を取込(rebase Version) # rebaseします。(branchBにいる状態で、branchAを取込) $ git rebase branchA # conflictするので解消します $ cat test.txt <<<<<<< HEAD a ======= b >>>>>>> 4d86c92... add b # 解消後 cat test.txt a b # rebase続行 $ git add test.txt $ git rebase --continue # エディタが開いてコミットコメントの編集画面になりますが、そのまま保存して続けます # コミットログ確認 $ git log --oneline --graph * f68bdb7 (HEAD -> branchB) add b * d17bed1 (branchA) add a * a1d7f67 (master) initial commit git logを見ると、mergeと違ってコミット履歴が一直線であることがわかりやすいですね。 BさんがAさんの作業内容を取込(merge Version) mergeとの違いも気になるかと思いますので、mergeバージョンと比較してみます。 # マージ $ git merge branchA # conflictするので解消します。 $ git add test.txt $ git commit -m 'merged branchA' # コミットログ確認 $ git log --oneline --graph * ff731a9 (HEAD -> branchB) merged branchA |\ | * e2915b7 (branchA) add a * | 63fff00 add b |/ * b9ef1dd (master) initial commit git logを見ると、コミット履歴が一直線ではありません。mergeなので当然ですね。 まとめ 上記の「BさんがAさんの作業内容を取込」のrebaseバージョンとmergeバージョンのコミットログを 確認するとわかるように、rebaseはmergeと違って、過去のコミットを今のブランチにつなげ直す ことができます。 実例(コミットをまとめる) 次はコミットをまとめてみます。作業者はさきほどと異なり、Aさん1人とします。 test.txtに"a"を追加してコミット。(commitA) test.txtに"b"を追加してコミット。(commitB) test.txtに"c"を追加してコミット。(commitC) ここで、commitBとcommitCをまとめてしまいたいとします。 準備 $ mkdir test $ cd test $ git init $ touch test.txt $ git add test.txt $ git commit -m 'initial commit' $ echo a >> test.txt $ git add test.txt $ git commit -m 'add a' $ echo b >> test.txt $ git add test.txt $ git commit -m 'add b' $ echo c >> test.txt $ git add test.txt $ git commit -m 'add c' $ git log --oneline --graph * 1f9a66d (HEAD -> master) add c * bc48053 add b * f8625d9 add a * 239ee02 initial commit コミットをまとめるときはrebaseのiオプションを指定します。 引数には、まとめたいコミットの1つ前のコミットIDを指定します。 ここでは、commitBとcommitCをまとめたいので、commitBの1つ前のcommitAのコミットIDを指定します。 $ git rebase -i f8625d9 上記コマンドを打つと、エディタが開きます。 pick bc48053 add b pick 1f9a66d add c # Rebase f8625d9..1f9a66d onto f8625d9 (2 commands) （以下割愛) まとめたいcommitBとcommitCが表示されています。一番上のコミットは統合元のコミットになるのでいじらず、 その下のコミットの「pick」を「squash」(統合)に変更します。 pick bc48053 add b squash 1f9a66d add c # Rebase f8625d9..1f9a66d onto f8625d9 (2 commands) （以下割愛) 保存すると、続いてコミットメッセージの編集画面になります。 # This is a combination of 2 commits. # This is the 1st commit message: add b # This is the commit message #2: add c # Please enter the commit message for your changes. Lines starting (以下割愛) 「add b」のメッセージに「add c」のメッセージをまとめます。 # This is a combination of 2 commits. # This is the 1st commit message: add b and c # This is the commit message #2: # Please enter the commit message for your changes. Lines starting (以下割愛) コミットログを確認してみます。 $ git log --oneline --graph * 4139507 (HEAD -> master) add b and c * f8625d9 add a * 239ee02 initial commit commitBとcommitCがまとまりました。 まとめ コミットを細かくしすぎた場合は、git rebase -i でコミットをある程度まとめると コミットログが見やすくなりますね。 今回は以上です。

※ 個人blogに投稿した記事（投稿日：2019/10/10）をQiitaに移行しました 背景 現場で新しいPC（離任された方が使用していたPCを引き継ぎ）に変更になったので、Git For Windows をインストールした。 Git For Windowsのバージョンは「2.23.0」。 現象 Gitコマンドを実行したところ、以下のようなエラーメッセージが表示された。 Warning: 'C:\ProgramData/Git/config' has a dubious owner: '(XXXXX)'. For security reasons, it is therefore ignored. To fix this, please transfer ownership to an admininstrator. 自分の場合、「XXXXX」がこのPCを前に使用していた方のユーザーアカウントだった。 現場のポリシーとして、PCの使用者を変更する場合は、クリーンインストールせず引き継ぎ。 よって、今回 Git For Windows は前任者の方がインストールしていた状態だったところに上書きインストールしたような形になった。 解決策 メッセージの指示通り、「C:\ProgramData/Git/config」のプロパティから所有者を変更しようとしたが上手く行かず、 configファイルを自作して「C:\ProgramData/Git/config」に配置した。 参考 stackloverflow - Latest Update brings Github error on pull, push, or sync

はじめに チーム開発でgitを使うので、いずれ起こるかもしれないコンフリクトに対して適応できるようにします。 手始め 「hoge.txt」ファイルを作成します。中身は以下のようになっています。 hoge.txt こんにちは 新たなブランチを作成する git checkout -b [ブランチ名]でブランチの作成と切り替えを同時に行います。 $ git checkout -b second git branchで現在のブランチを確認できます。 $ git branch master * second secondでのファイルの編集 hoge.txtに文字を１行追加してコミットします。 hoge.txt こんにちは こんばんは $ git add hoge.txt $ git commit -am "add こんばんは to hoge.txt" masterでのファイルの編集 masterブランチに戻ります。 $ git checkout master Switched to branch 'master' $ git branch * master second この時hoge.txtは１行のままです。 secondブランチとは違う文を追加していきます。 hoge.txt こんにちは おやすみなさい そしてコミットします。 $ git add hoge.txt $ git commit -am "add おやすみなさい to hoge.text" [master ce42458] add おやすみなさい to hoge.text 1 file changed, 2 insertions(+), 1 deletion(-) マージしてコンフリクトを起こす ここからが本題です。作成したsecondブランチをmasterブランチにマージしてコンフリクトさせます。 $ git merge second Auto-merging hoge.txt CONFLICT (content): Merge conflict in hoge.txt Automatic merge failed; fix conflicts and then commit the result. はい、これでコンフリクトが発生して「自動マージが失敗しました」と表示されています。 この状態で任意のエディタでファイルを確認すると以下のようになっています。(私の場合はVScodeです) こんにちは <<<<<<< HEAD (Current Change) おやすみなさい ======= こんばんは >>>>>>> second (Incoming Change) この場合「おやすみなさい」がカレントブランチの内容です。 そして「こんばんは」がsecondブランチの内容です。 今回はどちらも残したいので周りの<<<<<<< HEADと=======と >>>>>>> secondを消します。その後コミットを実行します hoge.txt こんにちは おやすみなさい こんばんは $ git add hoge.txt $ git commit -am "merge second" [master 61e9866] merge second 以上でコンフリクトを解消できました。 マージしてブランチが不要になった場合はgit branch -dを使いましょう。 $ git branch -d second Deleted branch second (was d8fbc89). 参考

はじめに チーム開発でgitを使うので、いずれ起こるかもしれないコンフリクトに対して適応できるようにします。 手始め 「hoge.txt」ファイルを作成します。中身は以下のようになっています。 hoge.txt こんにちは 新たなブランチを作成する git checkout -b [ブランチ名]でブランチの作成と切り替えを同時に行います。 $ git checkout -b second git branchで現在のブランチを確認できます。 $ git branch master * second secondでのファイルの編集 hoge.txtに文字を１行追加してコミットします。 hoge.txt こんにちは こんばんは $ git add hoge.txt $ git commit -am "add こんばんは to hoge.txt" masterでのファイルの編集 masterブランチに戻ります。 $ git checkout master Switched to branch 'master' $ git branch * master second この時hoge.txtは１行のままです。 secondブランチとは違う文を追加していきます。 hoge.txt こんにちは おやすみなさい そしてコミットします。 $ git add hoge.txt $ git commit -am "add おやすみなさい to hoge.text" [master ce42458] add おやすみなさい to hoge.text 1 file changed, 2 insertions(+), 1 deletion(-) マージしてコンフリクトを起こす ここからが本題です。作成したsecondブランチをmasterブランチにマージしてコンフリクトさせます。 $ git merge second Auto-merging hoge.txt CONFLICT (content): Merge conflict in hoge.txt Automatic merge failed; fix conflicts and then commit the result. はい、これでコンフリクトが発生して「自動マージが失敗しました」と表示されています。 この状態で任意のエディタでファイルを確認すると以下のようになっています。(私の場合はVScodeです) こんにちは <<<<<<< HEAD (Current Change) おやすみなさい ======= こんばんは >>>>>>> second (Incoming Change) この場合「おやすみなさい」がカレントブランチの内容です。 そして「こんばんは」がsecondブランチの内容です。 今回はどちらも残したいので周りの<<<<<<< HEADと=======と >>>>>>> secondを消します。その後コミットを実行します hoge.txt こんにちは おやすみなさい こんばんは $ git add hoge.txt $ git commit -am "merge second" [master 61e9866] merge second 以上でコンフリクトを解消できました。 マージしてブランチが不要になった場合はgit branch -dを使いましょう。 $ git branch -d second Deleted branch second (was d8fbc89). 参考

下記を参考にさせていただいています。 https://qiita.com/YuukiWatanabe/items/d326aad1224f2a559843 git revert 間違ったコミットをpushした時にはrevertを使います。 手順は以下になります。 1. git logでコミットIDを確認する $ git log すると以下のように過去にコミットした日付とコメント、IDが表示されます。 ※ logは一番上が最新のコミットでEnterや↓矢印キーで過去のコミットに遡ります。やめる場合はqを押します。 ↓ここがcommit ID commit db95f41cfdde06f7b5d471389e818abc8d7a3e1a (HEAD -> master, origin/master) Author: user <hogehoge@gmail.com> Date: Thu Apr 29 01:03:01 2021 +0900 print('j')を削除 commit fd3dd5ae6bfcd9cc4c682b1974265cde704bceec Author: user <hogehoge@gmail.com> Date: Wed Apr 28 23:24:55 2021 +0900 insta2.py削除 commit IDをコピーしてください 2. git revertでコミットを取り消す git revertでコミットを取り消します。コピーしたコミットidをgit revertの後ろに記述します。 $ git revert db95f41cfdde06f7b5d471389e818abc8d7a3e1a ← commit id するとvimが開きコミットメッセージを要求されるので入力します。 そしてgit pushでrevertした内容でリモートリポジトリを上書きします。 $ git push 以上です 付加情報 gitにはgit reset —hard HEAD^を使ったコミット解消方法がありますがpushをしてしまった場合はrevertを使った方が良いようです。 git reset —hard HEAD^は一つ前のコミットに戻るというコマンドですがこれを使うとgit pushができなくなるようです。