Gitの覚書 | ワクガンス

新しいSSHキーをローカルで発行、GitHubに登録、既存のプロジェクトに適用する

1. 新しいSSHキーをローカルで発行、GitHubに登録まではリンク先の手順の通り
   SSH Keyの作成とGitHubへ登録 | 公開鍵と秘密鍵
2. 新しいSSHを適用したい既存のプロジェクトのディレクトリへ移動する

   cd path/to/my_project

3. SSHエージェントを起動し、新しいSSHキーを追加する:
   プロジェクトのディレクトリ内で、SSHエージェントを起動し、新しいSSHキーを追加します。

   eval "$(ssh-agent -s)"
   ssh-add ~/.ssh/id_rsa
   			

4. GitリポジトリのリモートURLをSSHに変更する:
   プロジェクトのディレクトリ内で、リモートURLをHTTPSからSSHに変更します。

   git remote -v
   git remote set-url origin git@github.com:your_username/repository_name.git
   			

5. SSH接続のテスト:
   プロジェクトのディレクトリ内で、GitHubへのSSH接続をテストします。
   

   ssh -T git@github.com

これにより、指定したプロジェクトでのみ新しいSSHキーが使用されるようになります。他のプロジェクトやリポジトリには影響しません。
2024-2-21

変更したファイルを確認する

git status

2024-2-21

.gitnoreを使用せずに指定ファイルをコミット対象からはずす

git update-index --assume-unchanged ファイルパス

ファイルの実でディレクトリに対しては適用できない
2024-2-21

Git スタッシュ→ブランチを変えてもファイル内容を変化させない | 自分の開発環境独自の記述をする必要があるときに

Gitのstash機能は、作業中のディレクトリとステージングエリア（インデックス）の変更を一時的に保存して後で再び利用できるようにするものです。 これにより、現在のブランチから他の作業に切り替える際に、未完了の変更が他の作業に影響を与えることなく、クリーンな状態（最後のコミットの状態）で別の作業を始めることができます。

特定のファイルを管理対象外とするには不向きです。PCを再起動する度にファイルのスタッシュ状態は解除されるからです。あくまでブランチ切り替えの際の補助として利用すべきです。

一時的に自分の開発環境のみ有効な設定やコードを記述したいことがあります。この場合、スタッシュが便利です。
ファイルをスタッシュ状態にすると、このファイルはブランチを切り替えても置き変わらなくなります。

ファイルにスタッシュを適用することについて。
ファイル単体にスタッシュを適用という概念ではなく、複数のファイル群にスタッシュを適用するという感じです。
ステージングされているファイルと、ワーキングで変更されたファイルががスタッシュの対象になります。 ワーキングの未変更ファイルと新規ファイルはスタッシュの対象外になります。
スタッシュの適用

		git stash push -m "任意のテキスト"
	

古いバージョンでのスタッシュ。基本的に「git stash push」と同じ役割ですがオプションは少な目。

		git stash save  "任意のテキスト"
	

スタッシュは複数回行えます。以下のコマンドで適用したスタッシュの一覧を確認できます。

	git stash list
	

スタッシュを解除するコマンド

このコマンドはスタッシュされた最新の変更をワーキングディレクトリに適用し、その変更をスタッシュリストから削除します。つまり、一度このコマンドを実行すると、そのスタッシュは再利用できなくなります。

	git stash pop
	

git stash apply：

このコマンドもスタッシュされた最新の変更をワーキングディレクトリに適用しますが、違いはスタッシュリストからその変更を削除しない点です。これにより、必要に応じて後で同じスタッシュを再度適用することができます。

使用例：

git stash apply

2024-4-5　| 2024-4-12

指定ファイルをステージからワーキングに戻す | ステージング状態を解除

ステージに追加

git add backend/animal.php

指定ファイルをステージからワーキングに戻す | ステージング状態を解除

git reset HEAD backend/animal.php

2024-4-9

リモートリポジトリで管理されているファイルを自分の開発環境だけ管理対象外にする | git update-index

	git update-index --assume-unchanged backend/config/cors.php
	

解除も同じ？（未検証）

	git update-index --assume-unchanged backend/config/cors.php
	

2024-4-12

現在のブランチを複製してローカルに新しいブランチを作成、同時にリモートブランチも作成

リモートにある「origin/yagi」をチェックアウトし、それを複製して新しいブランチを作り、リモートブランチとして登録する。

	git checkout -b yagi origin/yagi
	git branch new_branch
	git checkout new_branch
	git push --set-upstream origin new_branch
	

2024-4-12

競合ファイルを修正：コミットしてプッシュしたら競合ファイルエラーが発生しまった場合

Gitで競合が発生した場合の修正手順は以下のようになります。

1. git pullを実行します。
2. 競合を確認する:
   まずは、git status コマンドで競合しているファイルを特定します。
   競合しているファイルを開く:
   競合しているファイルをテキストエディタで開きます。ファイル内では、Gitが競合箇所を特定するために <<<<<<<、=======、>>>>>>> のマーカーを使用しています。例えば以下のような形です：：

   
   <<<<<<< HEAD
   // このブランチでの変更
   const newFeature = () => {
     // コード
   };
   =======
   // リモートブランチでの変更
   const updatedFeature = () => {
     // 別のコード
   };
   >>>>>>> origin/20240425_test_branch
   			

3. 競合の解決:
   競合している部分を確認し、どちらの変更を保持するかを決めます。場合によっては、両方の変更を組み合わせることもあります。必要な変更を行った後、<<<<<<<、=======、>>>>>>> のマーカーを削除します。
   HEADは自分が行ったローカル環境の修正です。

   
   <<<<<<< HEAD
   		
   		let big_cat = 'マーオ';
   =======
   
   		const dog = 'キャインキャイン';
   		let small_cat = 'ミー';
   		
   >>>>>>> 22dc1a1485cf1fda1ad63ca5bff737bd8922cdaa
   
   			

   以下のコマンドで競合を起こしたコミットを調べることができます。
   （例）

   git show 22dc1a1485cf1fda1ad63ca5bff737bd8922cdaa

4. 競合を解決したファイルをステージングに追加します。

   git add -A

   または、

   git add 競合を解決したファイルパス

5. コミットを完了する:

   git commit -m '競合を修正したよ'

6. プッシュする

   git push

2024-5-3

指定ファイルのコミット履歴を調べたい | git log

$ git log -- frontend/src/lib/pages/animal/BigCat.tsx

ログ表示モードになるので、そこから抜けるにはqキーを押す。
2024-5-28

Git pullしたとき他の人によって修正されてしまったファイルを調べる | 指定ファイルに対し、任意のコミットIDとHEADを比較

git diff  コミットID HEAD -- frontend/src/lib/pages/animal/BigCat.tsx

git diff  abcd1234 HEAD -- frontend/src/lib/pages/animal/BigCat.tsx

2024-5-28

xxx

2024-5-3