目的

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

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

リポジトリの状態遷移図

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

ブランチ：master

問題事象と解決策

ここでは主人公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

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

git pushするとrejectしてしまった時の対処

目的

リポジトリの状態遷移図

問題事象と解決策

めでたしめでたし