gitignore で ディレクトリ全体を除外して、特定のファイルのみ監視対象にする
● gitignore で ディレクトリ全体を除外して、特定のファイルのみ監視対象にする
# ディレクトリ全体を除外
/logs/*
# このファイルは git 管理する ↓
!/logs/2022_04_27_14_16_47.log
作業中ブランチにいながら、派生元ブランチ（master）で行われた更新を取り込む（マージする）
● 作業中ブランチにいながら、派生元ブランチ（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 の ユーザー名を確認する
ユーザー名を確認する
git config user.name
メールアドレスを確認する
git config user.email
ユーザ名を設定する箇所は以下の3つがあります
| レベル | 影響範囲 | 設定ファイルパス | コマンドオプション |
|---|---|---|---|
| system | システム上の全ユーザー | /etc/gitconfig | --system |
| global | 該当ユーザー | ~/.gitconfig | --global |
| local | 該当リポジトリ | .git/config | --local |
● 設定箇所を指定してgit のユーザー名を確認する
git config --global user.name
git config --system user.name
git config --local user.name
設定してない場合は何も表示されませんのでこちらのコマンドからどこに設定があるのかを発見することができます
git pull するときに編集箇所が重なって競合する場合に一時的に退避する git stash
● (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
GitLab CI/CD から ssh でデプロイ先サーバーへ接続し、デプロイ先サーバーでコマンドを実行する
● 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で別ブランチの特定コミットを別のブランチに対して適用する
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 であるファイルの更新履歴を見る
更新日のみ
git log -- path/to/myfile.html
詳細
git log -p path/to/myfile.html
git コミットログを後から修正
● git コミットログを後から修正
最新のコミットログを後から修正します
git commit --amend
実行すると vi が起動するのでテキストを修正します。
修正が完了したら [esc] に続けて wq [enter] 入力して保存します。
git clone した後で git の 更新対象から外す
● 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は手元の変更が失われる。
git branch した時の HEAD detached from xxxxxx 現象 と直し方
● 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 diff で 特定の 2つのコミットの差分を表示させる
● 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 で 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）対応版を作ってくださってる方がいるのでこちらからダウンロードしましょう。
gitlab へ ssh接続で失敗する時の対処法
● 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 で 「ある特定のファイル」を誰が更新したかを調べる
git log -p ファイルのパス で特定のファイル更新を調べることができます
git log -p app/myscript.js
間違って master にコミットした修正を別ブランチへ移す
● 間違って 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 などでブランチのツリーを確認します。
){kind=link}
git で 複数のコミットを1つにまとめる
● git で 複数のコミットを1つにまとめる
あまりにコミットが多いと、他人が見た時に更新ファイルが見つけにくいという問題がおきるというのが .git あるあるの一つです。
そこで複数のコミットを1つにまとめてみましょう。
● HEAD から 合計3つのコミットを1つにまとめる
git rebase -i HEAD~~~
git log のリストに変更ファイルを表示する 等 git log の便利な機能
● 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 が修正されたので取り込む
● 開発用ブランチで作業中に master が修正されたので取り込む
よくある光景です。
1. マージにて取り込む場合
現在作業中のブランチにいるとします。 リモートの情報を取得してから origin /master を取り込みます。
git fetch
git merge origin/master
2. リベースにて取り込む場合
現在作業中のブランチにいるとします。 リモートの情報を取得してから ローカルの master を再度ベースに変更します（リベース）。
git fetch
git rebase master
git tag でタグをつける / git のタグを取り消す
● 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 リポジトリ単位に設定する場合
git config --local core.quotepath false
マシン全体に設定する場合
git config --global core.quotepath false
● git diff での日本語の文字化けを防ぐ
.bash_profile
export GIT_PAGER="LESSCHARSET=utf-8 less"
git で 後からブランチを作成する
●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 で「削除したファイル」「更新したファイル」のみ抽出する / zip 圧縮する
● 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
失敗しない GitHub への push 方法
● 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 できます。