● gitで一番最後のコミットを取り消してステージングに戻す

git reset --soft HEAD~

● gitで一番最後のコミットを取り消して、修正自体も行わなかったことにする

git reset --hard HEAD~

● 作業中ブランチにいながら、派生元ブランチ（master）で行われた更新を取り込む（マージする）

ブランチが master とそこからブランチを切った devブランチがあるとします。
例 : devブランチを作業しながら master に適用されたアップデートを取り込む方法です。

1. source tree アプリの場合

・「フェッチ」をクリックして取り込む
・ブランチ「dev」をダブルクリックしてチェックアウトする
・「マージ」をクリックしてマージするコミットを選択（オプションも合わせて選択）してマージを実行する

2. git コマンド の場合

（現在の作業ブランチは dev とします。）

# origin を更新
git fetch origin

# 作業中ブランチへ master を取り込む(--no-ff有無については運用ルール等によります。)
git merge --no-ff origin/master

● git の タグ打ち用 空コミット

git commit --allow-empty -m "タグ打ち用コミット"

● gitの最新コミットの日付を表示させる

git log -1 --format=%cd
// Fri Jan 19 16:15:35 2024 +0900

git log -1 --format=%cd --date=short
// 2024-01-19

git log -1 --format=%cd --date=format:'%Y-%m-%d %H:%M:%S'
// 2024-01-19 16:15:35

● aicommits

https://github.com/Nutlope/aicommits

● aicommitsのインストール方法

1. aicommits をグローバルインストールする

npm install -g aicommits

2. Opena AI のトークンを作成する

https://platform.openai.com/account/api-keys

3. Opena AI のキーを設定する

aicommits config set OPENAI_KEY=<your token>

設定が完了するとホームディレクトリに .aicommits というファイルが作成されます。

● aicommitsの使い方

git add -A
aicommits

オプションなしの aicommits を実行すると、コミットメッセージの候補を1つだけ表示してこれでいいか Yes , No で聞いてきます。 よければ Yes を選択するとコミットされます。

● aicommitsの便利なオプション

・Conventional Commits形式のメッセージを作成してくれる

--type conventional
  （または）
-t conventional

以下のようなメッセージになります。

style: Remove unnecessary gap in Header module
feat: allow provided config object to extend other configs

Conventional Commits
https://www.conventionalcommits.org/en/v1.0.0/

・メッセージの候補の数複数件作成してくれる

以下のようにすると 3件の候補を出してくれます

--generate 3
  （または）
-g 3

● aicommitsのおすすめオプション

aicommits --generate 3 --type conventional

スニペットに入れるか、シェルのコマンドにしておくと良いでしょう。

● git で staging- で始まるタグがついたコミットの中から最新を取得したい

git fetch --tags
git tag --list 'staging-*' | sort -V | tail -n 1

● githubで staging というタグをつけでCentOSのステージングサーバーにデプロイさせる

以下の手順で用意します。

1. GitHub Actionsのワークフロー作成: リポジトリの.github/workflows/ディレクトリ内にワークフローファイル（例：deploy-staging.yml）を作成します。

2. トリガーの設定: on セクションで、push イベントとタグの名前を指定します。例えば、staging-* のようなパターンを使用できます。

3. ジョブの定義: デプロイプロセスを実行するジョブを定義します。この中に、必要なステップ（例えば、ソースコードのチェックアウト、依存関係のインストールなど）を含めます。

4. サーバーへのSSH接続: デプロイスクリプトをサーバー上で実行するためには、GitHub ActionsからサーバーへのSSH接続が必要です。これには、SSHキーを用いて認証を行います。

5. デプロイスクリプトの実行: SSH接続を確立した後、リモートサーバー上でデプロイスクリプトを実行します。

6. セキュリティ: セキュリティを保つために、秘密鍵はGitHubのSecretsに安全に保存し、ワークフローで使用します。

● 1. リポジトリの.github/workflows/ディレクトリ内にワークフローファイル（例：deploy-staging.yml）を作成します。

cd .github
mkdir workflows
vi workflows/deploy-staging.yml

.github/workflows/deploy-staging.yml

● 1. メインのブランチを main から develop に変更する

GitHubのレポジトリのトップから「Settings」直下の Default branch から変更します。

すでに main ブランチでコミットがある場合は以下のようにしてローカルもリネームします

git branch -m main develop
git fetch origin
git branch -u origin/develop develop
git remote set-head origin -a

● 2. mainブランチを気軽に削除できないようにする

GitHubのレポジトリのトップの「Settings」 →「Branches」から「Add branch protection rule」をクリックします。
ブランチ名「main」を入れて保存します。

これで main から develop にマージを行った時の main ブランチ自動削除は無くなります。

""GitHub Team or Enterprise organization account. が必要です""

● git で tagをつける

ローカルリポジトリへタグ (v1.0.0) をつける

git tag v1.0.0

リモートリポジトリへつけたタグをpushする

git push origin v1.0.0

● git で tagを削除する

「ローカルリポジトリ」・「リモートリポジトリ」のタグ『v1.0.0』を削除するには

git tag -d v1.0.0
git push -d origin v1.0.0

● git で tagを付け直しする

以下の順番でおこないます

・ ローカルリポジトリのタグを削除
・ リモートリポジトリのタグを削除
・ ローカルリポジトリ笑タグをつける
・リモートリポジトリへつけたタグをpushする

「 コミットのリストからタグをつけたいコミットを右クリック」→「New Tag」

● .gitattributes でできること

大きく分けて以下の3つあります。今回は改行の扱いを .gitattributes で指定します。

・バイナリファイルの diff を表示する
・改行文字の扱いを設定する
・Linguist の扱いを設定する

引用 : .gitattributes に関するメモ

● .gitattributes で改行コードを指定する

プロジェクトのトップに .gitattributes ファイルを以下の内容で保存します。

*           text=auto
*.txt       text
*.bat       text eol=crlf
*.php       text eol=crlf
*.js        text eol=lf
*.jpg    binary
*.png    binary
*.gif    binary
*.mp4    binary

.bat と .php を CRLFにします。
.js をLF に指定します。

● 改行コードが違うと困ること

Linuxのシェルの改行コードがLFではないと、実行できません。
逆にWindowsのコマンドスクリプトの改行コードがCRLFではないと、実行出ません。

引用 : Gitで管理しているソースの改行コードに注意

● .gitattributes で改行コードを指定する

.gitattributes で改行コードを指定する

● git の設定の autocrlf でも改行コード変換はできるけど

以下のように設定すると、clone や pull したときは CRLF にして push するときに LF にすることができますが、 拡張子ごとに細かい指定はできません。

git config --global core.autocrlf true

● gitignore を globalで設置する

mkdir -p ~/.config/git
vi ~/.config/git/ignore

例えば、以下のように、グローバルで除外したいファイルやディレクトリを記述します

.DS_Store
.idea/*

● 1. Slack に GitHub を連携させる

1. http://slack.github.com/ にアクセスする
2. slack の URLを入れる（ログインする）
3. slack に GitHub から メッセージが送られてくるので GitHub に ログインしてコードを入力する

● 2. 連携したい「チャンネル」に以下の メッセージを送信するとGitHubから 情報が返ってきます

・現在購読しているGitHubリポジトリの通知を表示する

/github subscribe list features

・新たに GitHubリポジトリを指定して通知を受け取る

/github subscribe owner/repository

● github token の作成

・Github ログイン
　　　↓
・Settings
　　　↓
・Developer Settings
　　　↓
・Personal Access Tokens
　　　↓
・Toikens(classic)

こちらからトークを作成してクリップボードにコピーします。

あとは

git clone https://..........

で。 最初にメールアドレスとパスワードを入力させられるので、そこにメールアドレスと先ほどコピーしたトークンを入力します。

● git ステージング(staging)したファイルの取り消し

git reset HEAD <ファイル名>

● VS Code (Google Chrome 拡張機能)

https://chrome.google.com/webstore/detail/vs-code/kobakmhnkfaghloikphojodjebdelppk/related?hl=ja

これをインストールして、GitHubのリポジトリーを表示した上で「.」（ドット） を押すとブラウザ内にvscodeが立ち上がります

その他便利な拡張 GitHub上でのコードレビューに使えそうなChrome拡張をいくつか試してみた | DevelopersIO

● gitignore で ディレクトリ全体を除外して、特定のファイルのみ監視対象にする

# ディレクトリ全体を除外
/logs/*

# このファイルは git 管理する ↓
!/logs/2022_04_27_14_16_47.log

● git の ユーザー名を確認する

ユーザー名を確認する

git config user.name

メールアドレスを確認する

git config user.email

ユーザ名を設定する箇所は以下の3つがあります

引用 : https://bit.ly/3CgaTFQ

● 設定箇所を指定してgit のユーザー名を確認する

git config --global user.name
git config --system user.name
git config --local user.name

設定してない場合は何も表示されませんのでこちらのコマンドからどこに設定があるのかを発見することができます

● (git stash save) で 変更ファイルの一時的な退避を行う

git stash save

● (git stash list) 退避したファイルの表示

（退避を行ったときのコミットIDが表示されます。ファイル一覧は表示されません。）

git stash list

● (git stash apply) 退避したファイルを戻す

git stash apply stash@{0}

● 現在の git の編集ファイルステータスの表示

git status -uall

● Macなどローカルマシンで秘密鍵と公開鍵を作成します

# 鍵の作成
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa__deploy_from_gitlab_cicd

# 公開鍵
cat ~/.ssh/id_rsa__deploy_from_gitlab_cicd.pub

# 秘密鍵
cat ~/.ssh/id_rsa__deploy_from_gitlab_cicd

表示される公開鍵、秘密鍵をクリップボードにコピーしておきます

● デプロイ先のサーバーマシンにSSH接続して authorized_keys に公開鍵を登録します

cd .ssh
vi authorized_keys
（ここでviから先ほどクリップボードにコピーした鍵をペーストする。）

● 公開鍵の前に command="<実行したいコマンド>" を記述する

（例）例えば次のように設定すると

command="echo 'SSH OK!!!'; pwd" ssh-rsa AAAAB3NzaC1yc2EAAAA...........(省略)...........== Gitlab_CICD

SSH接続するとコマンドを実行してすぐ切断されます。

（実行例）

SSH OK!!!
/var/www/vhosts/my-host.com

これを使ってデプロイするコマンドを記述しておきます。

例） .bash_profileを読み込んでパスを設定した後、deploy.sh を実行する場合

command="source ~/.bash_profile; echo '' ; echo '● SSH Command Start ↓' ; sh deploy.sh ; echo '● SSH Command End ↑' ; echo''; " ssh-rsa AAAAB3NzaC1yc2EAAAA...........(省略)...........== Gitlab_CICD

deploy.sh の内容は好きに作成してください。

設定後にssh正しく接続できるか確認します

（コマンド例）

ssh -tt <ユーザー名>@<サーバIP> -p <ポート番号> -i ~/.ssh/id_rsa__deploy_from_gitlab_cicd

● Gitlab管理画面に接続して秘密鍵を登録します

グループかプロジェクトの「Settings」→「CI/CD」→「Variable」から「Add Variable」をクリックします。
次のような設定で作成します

Key   : id_rsa__deploy_from_gitlab_cicd
Value : <先程のコピーした秘密鍵>
Type  : File

合わせて「SSH_IP_ADDRESS」「SSH_USER」に変数を設定しておいても良いでしょう。

● Gitlab管理画面 CI/CD → Editor から YAML ファイルを編集する

管理画面から編集します。 編集が完了すると対象のリポジトリの .gitlab-ci.yml に保存され、 Job が1つ実行されます。

YML ファイルサンプル

（build のステージは省略しています。デプロイの前にビルドが通ることを確認した方が良いでしょう）

stages:
  - deploy

cache:
  paths:
    - node_modules/

deploy_production:
  stage: deploy
  image: kroniak/ssh-client
  before_script:
    - apk add curl
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
  script:
    - ip addr show
    - curl -s http://httpbin.org/ip
    - curl -s inet-ip.info
    - pwd
    - ssh -tt $SSH_USER@$SSH_IP_ADDRESS -p 22 -i ~/.ssh/id_rsa

● WARNING: terminal is not fully functional エラーとなるときは

接続先のターミナルを

.bash_profile

# change TERM
export TERM=xterm

としておきましょう。

● gitで別ブランチの特定コミットを別のブランチに対して適用する

git cherry-pick を使用します

git cherry-pick [取り込むコミットID]

複数の連続したコミットをいちどに取り込むことも可能です

git cherry-pick [始点となるコミットの１つ前のコミットID]..[終点となるコミットID]

● git cherry-pick でコンフリクトが起きた場合の対応

かなりの確率でコンフリクトは起こると考えておいた方が良いのでその対応を知っておきましょう。 コンフリクトが起きると次のようなログ出力となります

Auto-merging local/resources/xxxx.cs
Auto-merging local/resources/bbbb.cs
CONFLICT (content): Merge conflict in local/app/Http/Requests/cccc.cs
CONFLICT (content): Merge conflict in local/app/Http/Controllers/dddd.cs

CONFLICT (content) となっているファイルを修正、保存します。

その後に修正したファイルを追加してコミットします。

git add local/app/Http/Requests/cccc.cs
git add local/app/Http/Controllers/dddd.cs

コミットします。コメントの先頭に [cherry-pick] → をつけてわかりやすいようにします。（書き方はなんでもokです）

git commit -m "[cherry-pick] → [fix] ○○○の不具合を修正"

とします

● git であるファイルの更新履歴を見る

更新日のみ

git log -- path/to/myfile.html

詳細

git log -p path/to/myfile.html

● git コミットログを後から修正

最新のコミットログを後から修正します

git commit --amend

実行すると vi が起動するのでテキストを修正します。
修正が完了したら [esc] に続けて wq [enter] 入力して保存します。

● git clone した後で git の 更新対象から外す

git管理下には置きたいけれど 今回のブランチに限り 変更を追跡されて欲しくない時は
assume-unchanged または skip-worktree を設定することで追跡から外すことができます。
なお、これは開発側（更新、コミット、push を行う側）に設定します。

・1.assume-unchanged

assume-unchanged を設定する

git update-index --assume-unchanged <ファイル名>

取り消す

git update-index --no-assume-unchanged <ファイル名>

・2.skip-worktree

skip-worktree を設定する

git update-index --skip-worktree <ファイル名>

取り消す

git update-index --no-skip-worktree <ファイル名>

どちらもブランチごとに有効 ブランチを移動した際は再度設定が必要です

● 設定の確認

git ls-files -v

設定されているファイルには先頭に 半角の h が表示されます

● 設定するとどういう挙動となるか？

設定すると、git status での更新されたファイルリストに表示されなくなります。
git add -A でステージするファイルに追加されることもありません。

ただ設定したローカルリポジトリのみに有効なので、 別のローカルにて設定忘れたまま更新してコミット・push されるともちろんリモートに反映されます。

● assume-unchanged と skip-worktree の違いは？

基本的にskip-worktreeで良い。
イメージとしては、skip-worktreeは手元の変更を優先するが、 assume-unchangedはリポジトリの変更を優先する。

そのため、git reset --hardを実行したような場合は、 assume-unchangedは手元の変更が失われる。

まるまる引用 : http://htak.hatenablog.com/entry/2016/02/08/000000

● git branch した時の HEAD detached from xxxxxx 現象 と直し方

git の HEADとは何？

HEADとは
今自分が作業している場所（コミット）を示すリファレンスです。コミットするたびに自動的に移動します。

です。

git の HEAD が今どこを指しているかを調べる

cat .git/HEAD 

git の HEAD の移動履歴を調べる

git reflog

HEAD detached from とは

ブランチを確認したときに、そのブランチの最新コミット以外のコミットをHEADが参照しているときに HEAD detached になります。

git branch

結果例

* (HEAD detached from e40590e)
  master

これは HEADがそのブランチの最新コミット以外の特定のコミットを指している状態です。

HEAD detached from を直す

HEADをあるブランチの最新コミットに移動したい場合は

git branch 

でブランチを表示して、そのブランチへ移動します。

まだ一度もチェックアウトしていないリモートに存在するブランチへ移動したいときは

git branch -r

でリモートのブランチ一覧を表示して確認します。

master ブランチで移動する場合

git checkout master

これで戻ります。

● 強制的にリモートに合わせる

git fetch origin
git reset --hard origin/master

● git diff で 特定の 2つのコミットの差分を表示させる

git diff 古いほうのコミットID  新しいほうのコミットID

（「古いほうのコミットID」「新しいほうのコミットID」は 順番逆でも差分は表示されますが、patch を作成する時に、順番が逆だとリバースパッチを作成してしまうので注意。）

例

git diff f2244fdacdc8cc8ef6e8fde146842e35570e059d f007eb9f355424252687e7958f718927d70224ca

・ファイル名のみ表示の場合は --name-only をつけます

git diff 古いほうのコミットID  新しいほうのコミットID --name-only

・ファイルを抽出して ZIP で圧縮する

git archive --format=zip --prefix=root/ HEAD `git diff --diff-filter=d --name-only 古いほうのコミットID  新しいほうのコミットID` -o ./sabun.zip

./sabun.zip に圧縮します

Windows の場合は git bash から実行してください
普通のコマンドプロンプトだとコマンドが実行できないことがあります

● git で commit の変更をバッチファイル（パッチ）にする

git diff コマンドでパッチファイルを作成する

まずは確認します

git diff 古いコミットID 新しいコミットID

これで更新ファイルと更新内容確認します。

問題なければバッチファイルを作成します。ファイル名を後に指定するだけです

パッチファイル(myfile.patch)を作成する

git diff 古いコミットID 新しいコミットID > myfile.patch

これでバッチファイルが作成できました。

Windows用に改行コードを CR+LF にする場合は nkf をかませます

git diff 古いコミットID 新しいコミットID | nkf -Lw > myfile.patch

● windows マシンで パッチファイルを元に更新を適用させる

patch.exe -p1 --dry-run < myfile.patch

オプション

-p1　1階層階層の違いを無視します。
--dry-run　ドライラン（テスト実行します）

これでエラーが表示されなければ --dry-run をはずして実行します

patch.exe -p1 < myfile.patch

参考
https://qiita.com/sea_mountain/items/7d9c812e68a26bd1a292
http://2hz.org/akebia/item/699

● windowsマシンの patch.exe

こちらに、ユーザーアカウント制御（UAC）対応版を作ってくださってる方がいるのでこちらからダウンロードしましょう。

https://blogs.osdn.jp/2015/01/13/patch.html

● gitlab へ ssh接続で失敗する時の対処法

● OpenSSHキーの登録

秘密鍵「id_rsa_my_gitlab」を登録します。

ssh-add ~/.ssh/id_rsa_my_gitlab

● ssh-add がエラー「Could not open a connection to your authentication agent.」となる場合

authentication agentを起動してあげましょう

eval "$(ssh-agent)"

● 接続のテスト

次のコマンドで接続のテストが行えます。

ssh -T git@gitlab.com

これでうまくいけばOKです。

● .ssh/config へ登録する

vi ~/.ssh/config

# Gitlab
Host gitlab
  	User git
  	Port 22
 	HostName gitlab.com
	IdentityFile ~/.ssh/id_rsa_my_gitlab
	TCPKeepAlive yes
	IdentitiesOnly yes

もちろんパーミッションは 0600 で！

これで

ssh -T gitlab

でテストして接続できればokです

● git で 「ある特定のファイル」を誰が更新したかを調べる

git log -p ファイルのパス で特定のファイル更新を調べることができます

git log -p app/myscript.js

● 間違って master にコミットした修正を別ブランチへ移す

既に master に複数のコミットを行ったあとで、masterからはそのコミットを削除したい場合。

手順としては、

「1. 現在の master 状態から新しいブランチを作成」
「2. master ブランチの不要なコミットを消す」

だけです。簡単ですね。

● 現在のブランチを確認

git branch

● 退避させるブランチ「moved__20201110a」を作成し、移動する

git checkout -b moved__20201110a

（ブランチ名はなんでもokです。）

● master ブランチへ戻る

git checkout master

● A. master ブランチからコミットを取り消す（おすすめ）（git revert を使う方法）

git log とコミットIDを表示させる

git log --pretty=oneline

git revert 【コミットID】

実行するとエディタが立ち上がるので、コメントを記述して [esc] → : → wq します。
指定したコミットを打ち消す、コミットが実行されます。
リモートにも反映させることができます。

● B. master ブランチからコミットを取り消す（git reset を使う方法）

git reset --hard HEAD~4

最新から 4つ のコミットを取り消します。 （コミット自体をなかったことにします。）

以上です。 Souce Treeや VS Code などでブランチのツリーを確認します。

● git で 複数のコミットを1つにまとめる

あまりにコミットが多いと、他人が見た時に更新ファイルが見つけにくいという問題がおきるというのが .git あるあるの一つです。
そこで複数のコミットを1つにまとめてみましょう。

● HEAD から 合計3つのコミットを1つにまとめる

git rebase -i HEAD~~~

● git のログを表示する

git log

（　↑　↓　キーで移動して q で終了します。）

● git log のリストに「変更ファイル」を表示する

git log --name-status

● git log のリストに「変更ファイル」を表示する （変更情報なし）

git log --name-only

● 1コミット１行のワンライナーで表示（ コミットIDフル表示 ）

git log --pretty=oneline

● 1コミット１行のワンライナーで表示（ コミットID省略表示 ）

git log --oneline

● 1コミットログをグラフ表示

git log --graph

● 開発用ブランチで作業中に master が修正されたので取り込む

よくある光景です。

1. マージにて取り込む場合

現在作業中のブランチにいるとします。 リモートの情報を取得してから origin /master を取り込みます。

git fetch
git merge origin/master

2. リベースにて取り込む場合

現在作業中のブランチにいるとします。 リモートの情報を取得してから ローカルの master を再度ベースに変更します（リベース）。

git fetch
git rebase master

引用 : https://bit.ly/30mAsTA

● tag には 2種類存在します

https://git-scm.com/book/ja/v2/Git-の基本-タグ

Git のタグには、軽量 (lightweight) 版と注釈付き (annotated) 版の二通りがあります。

軽量版のタグは、変更のないブランチのようなものです。特定のコミットに対する単なるポインタでしかありません。

しかし注釈付きのタグは、Git データベース内に完全なオブジェクトとして格納されます。 チェックサムが付き、タグを作成した人の名前・メールアドレス・作成日時・タグ付け時のメッセージなども含まれます。 また、署名をつけて GNU Privacy Guard (GPG) で検証することもできます。 一般的には、これらの情報を含められる注釈付きのタグを使うことをおすすめします。 しかし、一時的に使うだけのタグである場合や何らかの理由で情報を含めたくない場合は、 軽量版のタグも使用可能です。

● 計量版タグのつけ方

軽量版のタグを作成するには -a、-s あるいは -m といったオプションをつけずにコマンドを実行します。

● git tag でタグをつける

ローカル

git tag -a v1.2.3

リモートへ push

git push origin v1.2.3

● git のタグを取り消す

タグ「v.1.2.3」を取り消します

ローカル

git tag -d v1.2.3

リモート

git push origin :refs/tags/v1.2.3

● github で tag に対して release を作る

/tags/ の一覧画面からリリースを作成したいタグの右側の「...」をクリックして Create release から作成します

● git の日本語の文字化けを直す

このコマンドで文字化けが治ります

.git リポジトリ単位に設定する場合

git config --local core.quotepath false

マシン全体に設定する場合

git config --global core.quotepath false

● git diff での日本語の文字化けを防ぐ

.bash_profile

export GIT_PAGER="LESSCHARSET=utf-8 less"

●git で 後からブランチを作成する

ブランチを作成するのを忘れて作業をしてしまった！！
そんな時に後からブランチを作成する方法です。

1. まだコミット前の場合

普通に新しいブランチを作成するとそのブランチに変更したファイルも引き継がれます

例: 新しいブランチ my_new_branch を作成する。（ + 作成後にブランチに移動）

git checkout -b my_new_branch

以上です。
これだけでokです。

2. コミット後の場合

2-1. git stash で一時退避（退避したデータの確認もしておく）

git stash
git stash list

2-2. 新しいブランチ（my_new_branch）を作成し、そのブランチへ移動する

git checkout -b my_new_branch

2-3. stash したファイルを戻す

git stash pop

● git diff で 現在のコミットと1つ前のコミットの差分ファイル名のみ表示させる

git diff --name-only HEAD HEAD~1

● git diff で 現在のコミットと1つ前のコミットの差分ファイル名のみ表示させる　「削除ファイルのみ」

git diff --name-only HEAD HEAD~1 --diff-filter=d

● git diff で 現在のコミットと1つ前のコミットの差分ファイル名のみ表示させる　「削除以外のファイルのみ」

git diff --name-only HEAD HEAD~1 --diff-filter=D

● 差分ファイルを圧縮する

git archive --format=zip --prefix=root/ HEAD `git diff --diff-filter=d --name-only HEAD^ HEAD` -o ~/2020_06_18__11_46_09__sabun.zip

● 1. ssh鍵の作成

ローカルのマシンで

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa__github

とします。
.ssh/ ディレクトリ内に鍵ファイル

id_rsa__github
id_rsa__github.pub

が作成されます。

● 2. GitHubへ鍵の登録

GitHubのWEBサイトの

「右上のメニュ」　→ 「Setting」  → 「SSH and GPG keys」 → 「New SSH Key」

から鍵を登録
（ id_rsa__github.pub の中身をコピペ ）
します

● 3. SSH接続のテスト

sshの設定に githubを加えます

vi ~/.ssh/config

下記の内容を追記

# GitHub
Host mygithub
  User git
  Port 22
  HostName github.com
  IdentityFile ~/.ssh/id_rsa__github
  TCPKeepAlive yes
  IdentitiesOnly yes

mygithub という名前で設定を作成しました。

ssh 接続をテストします。

ssh -T mygithub

Hi <ユーザー名>! You've successfully authenticated,

と出ればOKです。

● 4. GitHubでリポジトリを作成する

GitHub　WEBサイトからリポジトリを作成してください 。

● 5. GitHubで作成したリポジトリをローカルへ clone する

通常

git clone git@github.com:<ユーザー名>/<プロジェクト名>

としますが、これの「github.com」を「mygithub」に書き換えます。

git clone git@mygithub:<ユーザー名>/<プロジェクト名>

● 6. ローカルからGitHubへ push する

git push origin master

以上で失敗せずに push できます。