【Git Tips / GitHub Tips】Git・GitHub関連の Tips集📝 (git 操作チートシート / Git管理削除 / Git初期化)

Gitの管理を終わらせる
Gitコマンドでは、ありませんが、.gitディレクトリをプロジェクトから削除すれば、Git管理状態を削除する(終わらせる)ことができます。
rm -r .git
# Permission deniedになる場合
sudo rm -r .git

ブランチ名の変更方法(ローカル, リモート)
- ブランチ名が長すぎることでCIが転けたので、ブランチ名の変更方法(ローカル, リモート)をまとめる。
ローカルのブランチ名を変更
git branch -m 古いブランチ名 新しいブランチ名
# 今いるブランチの名前を変更する場合
git branch -m 新しいブランチ名
リモートブランチ名の変更
- リモートブランチに関しては、名前を変更するのではなく、名前を変更したブランチを新たにpushします。
- PRとかコードへのコメントとかは新しいブランチにはないのでご注意ください。
手順としては、
- ローカルのブランチ名を変更
- 変更したブランチを新たにリモートへpush
- Rename前のリモートブランチをClose or 削除する
変更したブランチを新たにリモートへpush
git push origin -u new-branch
Rename前のリモートブランチを削除する
git push origin --delete old-branch
参考・引用

【Github】プルリクエストを出した後に ドラフトに変更する

Reviewerにアサインした人を外す方法

プルリクエストレビューの却下

Git ブランチを削除する方法 (ローカル、リモート)
// ローカルのブランチを削除する場合
git branch -d localBranchName
// リモートのブランチを削除する場合
git push origin --delete remoteBranchName

GitHubで特定行へのパーマリンクを素早く表示する方法

GitHubにて、PRのMerge先を後から変更する方法は?
GitHubでは、Pull Request(以下PR)を作成した後でも、次のような手順でマージ先のブランチ(Base Branch)を変更することが可能です。
手順:
- 対象のリポジトリのGitHubページで、変更したいPRを開きます。
- PRのタイトルの右側付近にある「Edit」ボタン(鉛筆アイコン)をクリックします。
- もし「Edit」ボタンが表示されない場合、あなたに編集権限がない可能性があります。その場合はリポジトリ管理者またはPRの作成者に依頼してください。
- 「Edit」モードに切り替わると、PRのタイトルの下部にある「base」ブランチを選択するプルダウンが表示されます。
- 現在設定されているブランチ名をクリックし、変更先のブランチ(例えば
main
やdevelop
)を選択します。 - ブランチを変更したら、画面下部の「Save」または「Update pull request」ボタンをクリックします。
これで、PRのマージ先が新しいブランチに切り替わります。
なお、マージ先を変更すると、差分やコンフリクト状況が再計算されるため、変更後にPRの差分や状態を確認し直すことをおすすめします。

GitHub上でのdiff確認を見やすくする方法

git pull してコンフリクトした際に、git pullを取り消すには?
「git pull」は内部的に「git fetch」と「git merge」(もしくは設定によっては「git rebase」)を行っています。
コンフリクト発生時にまだマージが完了していない状態であれば、マージを中断(取り消し)するには以下のコマンドを使います。
-
マージを行っている場合:
git merge --abort
これにより、マージ開始前の状態に戻ります。
-
リベースを行っている場合(pull.rebaseなどの設定が有効なとき):
git rebase --abort
こちらもリベース開始前の状態に戻ります。
もしすでにマージコミットしてしまった場合
もしマージコミットまで完了してしまった場合は、以下のように手動で履歴を戻す方法があります。
-
直前のコミット(マージコミット)を取り消す:
git reset --hard HEAD^
-
HEAD^
(あるいはHEAD~1
) は直前のコミットを指します。 - これによってマージコミットも含め 作業ツリーの状態が完全に マージ前の状態に戻ります。
-
-
もしpushしてしまった場合:
既にリモートに反映されていると、単純にローカルでresetしてpushするだけでは履歴が「強制的」に書き換わることになるため、他のメンバーへの影響を十分考慮してください。必要に応じて下記のコマンドを使いますが、一般的にはチーム内での合意が必要になります。git push --force
このコマンドを使うとリモートの履歴が書き換わり、push後にチームメンバーが持っている履歴との整合性が崩れる可能性があります。
まとめ
-
コンフリクト解消前:
- まだマージ・リベースが完了しておらず衝突が起きている状態なら
- マージ:
git merge --abort
- リベース:
git rebase --abort
で「pull前の状態」に戻ることができます。
- マージ:
- まだマージ・リベースが完了しておらず衝突が起きている状態なら
-
コンフリクト解消後にマージコミットが入った場合:
- ローカルだけであれば、
git reset --hard HEAD^
でマージ前の状態へ戻る - リモートにもpushしている場合は要注意。強制push(
git push --force
)は履歴の書き換えになるため、チーム全体の了承のもと行いましょう。
- ローカルだけであれば、

特定のファイルだけ、途中から git管理を外すには?
途中から「あるファイルだけ Git 管理対象外」にする代表的な 3 通り
目的 | 方法 | 履歴への影響 | 他の開発者への影響 |
---|---|---|---|
① 以後コミットさせないが、過去の履歴は残して構わない |
.gitignore に追記 → git rm --cached <path>
|
以前のコミットにはファイルが残る | push 後、以降は誰の作業でも無視される |
② 自分の作業 だけで変更を無視したい |
git update-index --skip-worktree <path> (または --assume-unchanged ) |
履歴はそのまま | 自分のローカルだけで有効。他の開発者は追跡を続ける |
③ 過去コミットからも完全に消し去りたい |
git filter-repo (推奨)や BFG で履歴を書き換え |
全履歴から削除される | 履歴改変のため強制 push が必要。共有リポジトリでは慎重に |
① 以後のコミットから外す(最も一般的)
# 1) 無視したいパスを .gitignore に追加
echo "config/local.env" >> .gitignore
# 2) すでにインデックスに載っている追跡情報を消す
git rm --cached config/local.env
# 3) コミット
git commit -m "Stop tracking config/local.env"
# 4) リモートへ反映
git push origin main
-
ポイント
-
--cached
付きなので作業ツリーのファイル自体は残る - commit 以前の履歴にはファイルが残る。機密情報なら③も検討
-
② 自分だけ変更を無視したい(設定ファイルや IDE の一時ファイルなど)
# 追跡は残したまま、変更検知を無視
git update-index --skip-worktree path/to/file
# 取り消すとき
git update-index --no-skip-worktree path/to/file
-
.gitignore
とは違い ローカル限定。他の開発者には影響しない -
--assume-unchanged
も似ているが、こちらは「ほぼ書き換えられない大型ファイル向け」。
日常的に変更が入る場合は--skip-worktree
の方が安全
③ 過去の履歴ごと抹消する(機密情報や巨大バイナリを誤コミットした場合)
-
バックアップ必須:履歴を書き換えるので clone し直せる状態を確保
-
git filter-repo
(Git 公式後継ツール)を使用pip install git-filter-repo # まだなら git filter-repo --path secrets.txt --invert-paths
-
変換後、強制 push
git push --force origin main
-
リモート共有済みのリポジトリでは要アナウンス
→ 共同開発者はgit fetch --all
→git reset --hard origin/main
などで追随 - GUI 派なら BFG Repo-Cleaner でも可(使い方はほぼ同じ)
まとめ
-
「履歴は残って構わない/今後だけ無視」なら ① が王道。
.gitignore
+git rm --cached
で十分 - ローカル専用で一時的に無視したいなら ②
- 誤って機密を上げた/容量が膨れたときは ③ を選択。履歴改変なので慎重に
どの方法でも、目的・チーム体制・リスクに合わせて運用してください。

ローカルで1つ前のコミットに戻した状態をリモート(GitHub)にも反映させる方法📝
ローカルで1つ前のコミットに戻した状態をリモートにも反映させるには、強制プッシュで履歴を書き換える必要があります。
git push --force-with-lease origin [PRのブランチ名]