駆け出しの新人エンジニアですが、それにしても頻繁にgit stashというコマンドを使用することが多いのでメモのような形でここに残しておきます。

そもそもgit stashとは

ローカルで作業を行っている際、加えた変更をそのままどこかに一時的に保存しておきたいときに使えるコマンドです。そして、この一時的にどこかに保存した変更はもちろん元に戻すことができます。

変更を避難させる

$ git stash -u

これはよく僕が使っているコマンド。
-u　これはオプションだが、追跡されていないファイルもすべて避難させるという意味があるらしい。
Vscodeでうまくstashできない時があり、-uを付けたら解決したので頻繁に使っている。

　避難させた変更を元に戻す

$ git stash apply

これで避難させた変更を再び蘇らせる。stash listにはそのまま残るらしい。

stashした履歴？を確認する

$ git stash list

これをするとリストで避難させた履歴を確認することができる。
applyはこのリストの一番最新のものを蘇らせることができるコマンド。

　まとめ

git stashは奥が深そう。

特に駆け出しの時に、周りの優秀なエンジニアの方が次々とmasterにmergeしていっているときとかに使えると思うので、新人のうちからでも覚えておくと助かるコマンドかもしれない。

概要

• プルリクエストをマージしたあとに、GitHub側（remote側）のブランチを消したあとの流れがよく分からなかったので整理してみた。

前提

• 書いた人は普段業務でSubversionしか使ってない人です。
• 以下のブランチがあることを想定
  • mainブランチ
  • featureブランチ
• 今回、feature → mainにマージして、featureブランチを削除する

手順

1. プルリクエストがマージされたときにGitHub上のfeatureブランチを削除
2. ローカル側でmainブランチに移動 git checkout main
3. GitHub側のmainブランチにマージした内容を、ローカルのmainブランチに反映する git pull origin main
4. ローカル側のfeatureブランチを削除する git branch -d feature

はじめに

本記事ではGitの基本概念。具体的には、リポジトリ、コミット、ワークツリー、インデックスについて説明していきます。
※投稿について間違った説明、解釈をしている場合はぜひコメントお願い致します。

そもそもGit(ギット）とは？

結論、Gitとは、ファイルの変更履歴を記録、追跡するためのバージョン管理システムです。
Gitは、「いつ、誰が、どのファイルのどの箇所を、どんなメッセージを残して変更したか」をファイルの変更履歴として残してくれます。Gitのおかげで、共同開発やファイルの変更履歴の記録などをより簡単にこなすことができるようになりました。

リポジトリ

バージョン管理を行うには、バージョンの保存場所が必要です。
その保存先のことを”リポジトリ”と言います。リポジトリという箱の中にバージョン情報（ファイルの変更履歴）の１つ１つが保管されているイメージです。

コミット

先ほどリポリトリは箱だ。と説明しましたが、コミットは箱の中身です。
”コミット”は1つ1つのバージョンのことを指します。また、コミットを作成することを”コミットする”と言います。
今回詳しい説明は省きますが、1つ1つのコミットには様々な情報が入っています。
主な６つを紹介します。
・リビジョン番号
・コミットした人
・コミットした日時
・コミットしたときのファイル内容の差分
・コミットメッセージ
・親コミット（1つ前のコミット）のリビジョン番号

ワークツリーとインデックス

”ワークツリー”は,Gitでバージョン管理されているフォルダの中身を指します。
はじめに、ファイルに変更が加えられるとまずはワークツリーに変更が反映されます。この段階では、前回のコミットされたフォルダと比較して、前回との変更箇所がわかるだけです。
次に、ワークツリーから次のコミットに含めたいファイルの変更箇所を選択します。このことを”ステージする”と言います。
そして、ステージされたファイルの変更箇所は”インデックス”に反映されます。
最後にインデックスへステージされた変更箇所のみをコミットします。
”インデッックス”はファイルの変更からコミットまでの中間地点的な役割を果たしています。
ではなぜ、インデックスが必要になるのかと言うと、インデックスはコミットを行う前に、ワークツリーの変更箇所の中から関連性のある変更のまとまりを選択してくれるからです。

Gitってなに？

Gitは「変更履歴を管理する場所」
ファイルやデータを書き換えるごとに保存するまではいいが、雑多に保存しているとあとで困る。
・変更内容
・変更した理由
・変更した日時
・変更した人
をわかりやすく、しっかり管理することによって作業をスムーズに進めることができる。

こうしたことを一手に担ってくれるのがGitである。
「バージョン管理システム」とも言う。

Gitの役割

・変更履歴を順々に記録する
・記録する際にメッセージ(誰が、何を、なぜ変更したか)をつける

まとめ

Gitを使うことによってデータの変更履歴を管理することができ、作業の引継ぎ、修正、変更などをスムーズに進めることができるようになる。

管理したくないファイルとは

例えば
・MacOS Windowsなどで自動生成されるファイル
・パスワードが記載されているファイル　
等々

外す方法

間違えてpushをしてしまいコミットを取り消してもう一度pushするもエラー。その事を伝えるも「pushを消していますか？」と聞かれてしまいました。pushを消すと調べてみても、出てくるのはコミットを消す方法ばかり……。ということで今回は私が行ったpushを消す方法をまとめたいと思います。

まずはgit logでコミット履歴を見る

するとコミットIDなどの情報がたくさん出てくると思います。

<commit id 1>
satou
取り消したい最新のコミット

<commit id 2>
tanaka
この状態まで戻したいというところのコミット

コミットIDをコピーし、git reset

git reset --hard <commit id 2>

コミットIDは最新の取り消したいコミットのものではなく、その一つ前の状態、「ここまで戻したい」という所のものを入れてください。

その状態でpush

git push -f

これでpushをなかったことにできました。後は変更を加え、またいつも通りコミット、pushしてください。

• 環境
  • Windows10 Pro バージョン1909
  • git version 2.25.0.windows.1
  • git-lfs/2.9.2 (GitHub; windows amd64; go 1.12.7; git 0274d856)

事象 : Gitをpullしていたりしたらいつの間にか怒られるようになった

リポジトリがリベースされたりしたのでごにょごにょしていたら怒られるようになった。

# 変更していないのに変更したファイルがある・・・
$ git status
On branch {リポジトリ}
Your branch is up to date with 'origin/{リポジトリ}'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   src/main/resources/hogeA.zip
        modified:   src/main/resources/hogeK.zip
# ...省略...
# 変更をなかったコトに！・・・できない
$ git reset --hard HEAD
Encountered 2 file(s) that should have been pointers, but weren't:
        src/main/resources/hogeA.zip
        src/main/resources/hogeK.zip
HEAD is now at 804xxxx ほげほげ

Gitは、音声、動画、高画質な画像などの大きなファイルを扱うことはあまり得意ではありません。Gitリポジトリにそのような大きなファイルを含めると、git clone、git push、git pullの処理に膨大な時間がかかる場合があります。
Git LFS（Large File Storage 以下、LFS） は、前述した問題を解決すべく、GitHub、Microsoft、Atlassian、および他のコントリビュータによって開発されているGitの拡張機能です。これにより、大きなファイルをより効率的に扱うことができるようになります。
Git LFSの使用方法 – Backlog ヘルプセンター

おおぉぉ、.gitattributesファイルを見るとzipファイルはLFSが指定されている。コマンドでも見れる。

 git lfs track | grep -i zip
    *.zip (.gitattributes)

原因1 : ポインタになってないファイルがあるから

チーム内に git-lfs 有効にしてない人がいたり、たまたまマージのタイミングでポインタになってないファイルがあるのが原因です。
Git LFS で次のエラーメッセージが出たときの一発対処法：Encountered 3 file(s) that should have been pointers, but weren't: - Qiita

「ポインタになってないファイル」・・・？

通常、gitは差分を管理しており各クライアントはその差分をGitHubなどのgitリポジトリサーバと共有しています。これに対して、git lfs機能を経由して追加されたファイルはファイルの実体は別のオブジェクトストレージ（図のLarge File Storage）などに保存されそのハッシュ値、保存先だけがgitリポジトリで管理されます。
Git LFSについて調べてみた. チームリポジトリにGit LFSを適用する際の注意点 | by Kota Tsuyuzaki | nttlabs | Medium

対応 : 変更なしと仮定してindexに登録する

# コミットしていないファイルを短縮表示して
$ git status -s
 M src/main/resources/hogeA.zip
 M src/main/resources/hogeK.zip
# ４文字目以降を切り出して
$ git status -s | cut -c 4-
src/main/resources/hogeA.zip
src/main/resources/hogeK.zip
# そのファイルを変更なしと仮定(assume)してindexに登録する
$ git status -s | cut -c 4- | xargs git update-index --assume-unchanged
# そしてコミットしていない変更はなくなった
$ git status
On branch {リポジトリ}
Your branch is up to date with 'origin/{リポジトリ}'.

nothing to commit, working tree clean

• 参考
  • git status -s でちょっと幸せになれる - Qiita
  • 【 cut 】コマンド――行から固定長またはフィールド単位で切り出す：Linux基本コマンドTips（60） - ＠IT
  • Git - git-update-index Documentation

原因2 : 自分がGit LFSを有効化していないから

チーム内に git-lfs 有効にしてない人がいたり、たまたまマージのタイミングでポインタになってないファイルがあるのが原因です。
Git LFS で次のエラーメッセージが出たときの一発対処法：Encountered 3 file(s) that should have been pointers, but weren't: - Qiita

「チーム内に git-lfs 有効にしてない人」・・・？私？

# 自分の設定を見てみると・・・lfsの設定がない。
$ git config --global -l | grep lfs
$
# git lfsコマンドが使えるからって有効化されているわけではないんだ・・・。
$ git lfs version
git-lfs/2.9.2 (GitHub; windows amd64; go 1.12.7; git 0274d856)

対応 : Git LFSを有効化する

参考 : Git Large File Storage - アトラシアン製品ドキュメント

# LFSを有効化する
$ git lfs install
Updated git hooks.
Git LFS initialized.
# 設定が追加された
$ git config --global -l | grep lfs
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true

Linuxコマンド

　$ mkdir [既存フォルダ名]/[Newフォルダ名]：フォルダを作成(メイクディアー)
　$ touch src/components/[ファイル名]：ファイルを作成
　$ rm [ファイル名]：ファイルを削除
　$ rmdir [フォルダ名]：フォルダを削除
　$ cat [ファイル名]：ファイルの閲覧
　$ git grep：git管理下のファイルを検索
　$ vim [フォルダ名]/[ファイル名]
　$ cdコマンド：ディレクトリを移動
　$ lsコマンド：ディレクトリの内容を表示 (ls -a コマンドで、隠しファイルを含めたディレクトリ全内容を表示)
　$ cpコマンド：ファイルをコピー
　$ mvコマンド：ファイルの移動とファイル名の変更。

git管理

基本的なGitコマンド

（参考）https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/how-to-basic-git.html

① ローカルリポジトリの新規作成(initialize)

　cdコマンドで該当ディレクトリに移動 => $ git init

② ステージングエリアに追加

$ git status  （ステージにAdd前：赤色、Add後：緑色）
$ git add .  or $ git add [ファイル名]

③ ローカルリポジトリにコミット

　$ git commit -v（$ git commit -m 'メモ'）
　①vimというエディターで開かれる
　②編集：「半角英数字」→「i」
　③メッセージ入力画面（１行目：変更内容の要約、２行目：改行、３行目：変更した理由）
　④「esc」→「:wq」→「Enter」保存

④-1 コミットの変更履歴を確認

　$ git log
　(変更履歴１行だけ：$ git log --oneline)
　(差分だけ：$ git log -p)
　「j」とすると下に移動
　「k」とすると上に移動
　「q」とすると終了

④-2 変更差分を確認

　$ git diff（ステージとの差分）
　$ git diff HEAD（ステージとコミットの変更差分）

⑤ ローカルリポジトリをリモートリポジトリ(github=origin)にPush

　$ git push origin master
＊gitをgithubに登録 $ git remote add origin <Clone名>
　(例)git remote add origin https://github.com/Niyomong/shampooo.git

⑥ Git管理から外す.gitignore（パスワード、自動生成されるファイル等）

(.gitignoreファイルの書き方)
　・#から始まる行はコメント
　・指定したファイルを除外 (例)index.html
　・ルートディレクトリを指定 (例)/root.html
　・ディレクトリ以下の除外 (例)dir/
git rmコマンド：コミットしたファイルGitの管理から削除(ファイル削除してもGitからは削除されない)
　$ git rm [ファイル名]
　$ git rm -r [ディレクトリ名]
ファイルは残すけど、Gitの管理からは削除
　$ git rm --cashed [ファイル名] ＊.gitingoreに追記が必要

⑦ ブランチ（大人数の開発）

・ブランチ一覧
　$ git branch
・新しいブランチへの切替
　$ git checkout -b [新しいブランチ名]
・既存のブランチに切替
　$ git checkout [既存ブランチ名]
・直近にコミットしたブランチをPush
　$ git push -u origin HEAD
　$ git push origin [ブランチ名])
・ブランチを削除
　$ git branch -d [ブランチ名]

その他Git

・Gitをクローン

$ git clone xxx
(例)git clone git@github.com:Niyomong/shampooo.git

・gitのversion確認

　$ git version

・その他git

$ git mv [移動したいファイル] [移動先のフォルダ]/　：ファイルの移動
(例)git mv src/App.js src/components/
$ git mv [変更前のファイル名] [変更後のファイル名]　　：ファイル名の変更
(例)git mv src/components/App.js src/components/stock_index.js
$ git status
変更したファイルを閲覧
$ git diffで修正履歴確認