間違ってコミットしてしまった、コミットしたらデグレしてしまった。。
こういう時にコミットを取り消すコマンドがあります。
3つほど紹介したいと思います。

gitのリポジトリ

working treeが手元のコード。一番新しいです。
git add ファイル名するとindexというコミット準備段階になります。
index上のファイルにgit commit -m "comment"するとメッセージとともにlocal repositoryに保存されます。最新のlocal repositoryのことをHEADと呼びます。
最後にgit pushすると、GitHubなどチームで管理するrepositoryに移ります。

reset

remoteにpushする前ならこの方法で楽に任意のコミット履歴まで巻き戻せます。
pushしたあとresetするとリモートとの履歴に不整合が起き、git push -fする必要が出てきますので注意。
もし自分のpushの前に誰かがpushした状態で、フォースプッシュするとその人のコミットを消し飛ばすので極力避けましょう。

// 1つ前のコミットに戻りworking treeもリセット
git reset --hard HEAD^

// 4つ前のコミットに戻りworking treeもリセット
git reset --hard HEAD~4

// add を取り消す
git reset --mixed

// 4つ前のコミットに戻りworking treeはそのまま
// つまりコミットのHEAD任意の履歴まで戻り、コード自体は残ったままになる。
git reset --soft HEAD~4

// 誤ってgit resetをした際に元に戻す
git reset --hard ORIG_HEAD

revert

git rest --hardした際に他の人がpushした履歴（コミットログ）が消し飛ぶ危険性を避けるには、新たに打ち消し用コミットを作成する方法があります。
これなら履歴も消えないのでフォースコミットする必要はありません！

git revert <対象のコミットID>

rebase

無駄にコミットをしてしまい、醜くなってしまった時にまとめることができます。
あとで履歴を見たときに見やすく、レビューしてもらうときに余計な手間をかけさせないために使いましょう。

git rebase -i HEAD~3

// こんな画面がviで表示されます。
// pickで残す履歴、sでまとめてしまう履歴を選びます。
// この場合はe331898だけ残し、あとはまとめてしまいます。

pick e331898 wip
s c45e0bf test 6
s 042074b wip

# Rebase 8ac1025..042074b onto 8ac1025 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]

JetBrainのEditorを使っている方

ちなみにIdeaやPhpStormなどJetBrainのEditorを使っている方はここからもrevert, resetできて便利ですよ！
Gitのタブを開く>Log>特定のコミットをクリック> revert commit

gitは、macでsourcetreeを使っています。

仕事で使う時は、会社のgitサーバーにリモートアクセスしてますが、一度、ユーザーID/パスワードで認証してあれば、2回目以降は通常入力する必要はありません。

が、たぶんmacOSをバージョンアップしたため、データは移行したんですが、プルしようとしたら、パスワードの入力を催促され、下記エラーがウィンドウに表示されました。
(サーバー名、gitリポジトリ名は書き換えてます)

git --no-optional-locks -c color.branch=false -c color.diff=false -c color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree fetch origin 
fatal: unable to access 'https://example.com/gitrepos/xxxxx.git/': The requested URL returned error: 500
Completed with errors, see above

自分は更新してないブランチのプルなので通常エラーにならないはずの操作です。他の操作でもローカルでのコミットはできますが、サーバーにアクセスする操作だと同じエラーになります。

ググってもいまいちそれらしきのが見つからず。
知り合いに聞いたのを参考に試した結果、原因がわかりました。

原因

パスワードを間違えていました。

自分でメモしてたパスワードが間違っていて、いくつか試して、正しいパスワードを入力したらうまくいきました。

何かしらキーチェーンがおかしくなっている場合もあるようです。
その場合の修正方法は次の通り。

パスワード修正方法

一度間違ったパスワードを入力してしまうと、デフォルトでキーチェーンにパスワードを登録するチェックがついているので、そのまま間違ったパスワードで実行され、パスワード入力欄が出てきません。
（キーチェーンに登録してなければ、再度パスワード入力欄がでてきます）

その場合は、ユーティリティ→キーチェーンを起動して、gitリポジトリ名（サーバー名）で検索し、キーチェーンデータを削除します。

そして再度、sourcetreeでプルするとパスワード入力欄が出てきますので、正しいパスワードを入力します。
正しいパスワードを忘れてしまって、何度か試したい時は、キーチェーンに登録するチェックをはずして入力、実行します。

まず、戻したいcommitのハッシュ値を調べる。
（調べ方についてはコマンド操作よりVSCodeの拡張機能のGit Graphを使用する方がお手軽）

例えば1ae86e0c3320c2e375d5d505f80813a6f7ba8a55と言うcommitまで戻したい場合は、下記のようにする。

git reset --hard 1ae86e0c3320c2e375d5d505f80813a6f7ba8a55

--hardをつけると強制的にコマンドを実行する。

自分用のメモとして残します。

■やり方

事前に対象ブランチをチェックアウトする。
下記のコマンドで対象ファイルを削除

git filter-branch -f --index-filter 'git rm --ignore-unmatch ファイルパス' HEAD

このままではリモートと競合するため、リモート側の対象ブランチを削除

git push origin :ブランチ名

その後ローカルブランチをコミットする。

git push origin ブランチ名

以上。

コマンドを叩く前に必要なこと

1. vscodeのダウンロード
2. code のインストール

1. vscodeのダウンロード

vscode持ってない人はダウンロード(そもそもvscodeユーザー向けの内容だけど一応)

https://azure.microsoft.com/ja-jp/products/visual-studio-code/

2. code のインストール

この記事が参考になりそう。
便利なので入れましょう。

https://qiita.com/1natsu172/items/b951aa33451dad36bd7c

コマンド

以下をCLIで叩く

git grep -l 'hoge' | xargs -I % code %

自分はgrep結果をさらにgrepしたりしたかったので

git grep -l 'hoge' | grep 'hoge' | xargs -I % code %

のようにして開いた。超便利。

タグ？

タグを付けてプッシュしないといけない場面がありました。

普段はソースツリーを使っているのですがやり方を調べてもよくわからず…

ということでコマンドを教わりました

タグをつける

git tag HogehogeTag

その後プッシュ

git push origin HogehogeTag

これでできました。

ソースツリーだとどうやるんだろう…

backlogのgitからSourcetreeでCloneしたい

発生した問題

Cloneできない。認証エラーになる

• Clone元のURLを入力しても、「リポジトリタイプ：ソースパス/ソースURLとして正しくありません」となる。
• その横の[詳細]を押すと「エラー: remote: Authorization required fatal: Authentication failed for ...」となっている。

パスワードを間違えたら、認証ダイアログが出なくなってしまった

• もう一度正しいIDとパスワードを入力したいけど、認証画面が出ない
• どっかに間違えたユーザIDとパスワードが保存されてしまったのだろう

解決策

保存されてしまってる誤った認証情報を消す

• Sourcetreeのメニュー「ツール」＞ オプション ＞ 認証
• 「git保存されたパスワード」の当該URLをクリック ＞ 削除

目的

ローカルリポジトリ、リモートリポジトリで一度削除したファイルA、ファイルBのうち、
やっぱりファイルAだけ復活させて残したい時のgit対処について記載。

基本こちらの記事を教材に、
私の場合は実経験に基づき会話形式で記事を掲載しています。

リポジトリの状態遷移図

①～⑤は、リポジトリのコミット状態遷移を表す。

ブランチ：master

●　　　 ⑤ファイルBを再削除
| 　\
| 　　●　③ファイルA, ファイルBを削除
|　 　 |
●　　|　④ファイルAの削除を取り消し、復活
　\ 　|
　　 ●　②コミット2
　 　|
　　 ●　①コミット1

問題事象と解決策

ここでは主人公Q子と心情とともに、問題事象と解決策を記載。

１．Q子「ファイルA、ファイルBとも要らんらしいな。下記コマンドで削除っと」
　　<ローカルリポジトリ>の③をリモートリポジトリに送信
　　git push

２．そのあと、Q子のもとへi先輩からファイルAを残してほしいと電話が。
　　Q子「えっなんやて、やっぱりファイルAだけ必要やと…！さっき消してもうたやん、i先輩もうちょっとはよ言うてなあ。まあええわ、下記コマンドでさっきのコミットを取り消しっと」
　　<ローカルリポジトリ>の③を取り消し
　　git reset --hard HEAD~

３．Q子「それからファイルAだけ再保存(※1)して、コミット、pushっと」
　　git add ファイルA
　　git commit -m "ファイルAの削除を取り消し、復活"
　　git push
　　
　　※1: ファイル内容変更なくても、なぜか再保存しないとgit addできない。
　　　　 ベストプラクティスではないが、、一度ファイル内にカーソルを置き改行等することで再保存、git addできるようになる。

　　　　　↓
PC画面さんの反応

$git push
To gitlab.com:XXXXX/tutorial.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'gitlab.com:XXXXX/tutorial.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.    
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
puts 'The best way to log and share programmers knowledge.'

　　Q子「ぐおおお…git pushしたらrejectされてもた・・。なになに、non-fast-forwardやて？」

　　Q子、いったん調査に入る

　　Q子「ふむふむ…このリンクによると、上記３．のコミットによって、ブランチが完全に枝分かれした状態になったらしいな。つまり、<ローカルリポジトリ>の②から、関連の無い③の枝と④の枝が生えたってイメージか」

４．Q子「そいでそいで…関連の無い③と④のコミットをつなぎあわせるには、このリンクの方法に書いてある、下記コマンド試したらいいんか」
　　git merge --allow-unrelated-histories
　　　　　↓
PC画面さんの反応

$git merge --allow-unrelated-histories
Removing ファイルB

５．Q子「おおおお、ファイルB削除されたな。この調子でローカルリポジトリからリモートリポジトリにgit add、コミット、pushすれば」
　　git add ファイルB
　　git commit -m "ファイルBを再削除"
　　git push
　　　　　↓
PC画面さんの反応

$git push
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Delta compression using up to 8 threads
Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
To gitlab.com:XXXXX/tutorial.git
   caac238..239dc47  master -> master

　　Q子「うおおおお、やったーーー！これで再度ファイルAだけ作り直さずに済んだわ、早速i先輩に報告や！」

めでたしめでたし

今回の問題事象は、偶々Gitの基本操作を学んでいた筆者がGit操作をしていてもしこんなことが起きたらどう対応すればいいんだろ～勉強と実践では違うとはこのことか～という危機感をもとに問題を生み出しました。（やはりGitをもっと習得するためには、基本操作だけでなく、現場で起きた問題・事例をもとに解いていくことも重要だとつくづく実感）

Q子さんの心情とともに問題と解決策をお送りする中で、実際にファイルを削除してしまったけどやっぱり必要だったという事象は仕事上で十分起こりえる事柄だと思いました。記事を書いてみて、Gitを知っていることで普段の仕事のロスタイムを減らせるメリット（今回の場合ならファイルを作り直すロスタイムを生み出さずに済んだこと）があると、さらにひしひしと実感。。。

もっといい方法があるよ、ここ解釈まちがってるよ等ありましたら、コメントくださいm(_ _)m

もっと技術磨き、頑張るぞーーー！