#author("2023-08-16T20:36:07+09:00","default:irrp","irrp") →Git関連 #contents *一般 [#j6324b22] -[[【Git】git stashで割り込みタスクにスマートに対応する - NRIネットコムBlog>https://tech.nri-net.com/entry/git_stash_interrupt_task]] 2023.7 -[[入門書を終えた人に捧げる、社会人のためのGit中級編 - Qiita>https://qiita.com/yamamoto7/items/fe15a1e7e360b4015fae]] 2020 -[[[初心者向け] Gitで間違ったブランチにしたコミットを別ブランチに付け替える | DevelopersIO>https://dev.classmethod.jp/articles/git-rebase-branch-miss-commits/]] 2023.7 -[[gitの操作でまちがったときの取り消し練習>https://snap.hyuki.net/20190303213218/]] 2023.6 -[[Git ローカルで変更した内容を取り消す方法 - Qiita>https://qiita.com/saku2021/items/22b3525cbcdf497274fa]] 2021 -- git add前 -> git checkout . -- git add後 -> git reset HEAD . -- 直前のコミットをやり直し(push前) -> git commit --amend -git pull したら自分がローカルで修正したバイナリファイルがリモートで更新されていてマージに失敗したときの対処 git checkout --theirs <file> ※リモート側を活かし、自分の修正は捨てる(バックアップは取っておく) git add <file> git commit -m xxx git push -[[git checkoutを禁止してgit switch/restoreに慣れる - WILLGATE TECH BLOG>https://tech.willgate.co.jp/entry/2023/02/28/113000]] 2023.2 -[[「Git Workflow 👇 https://t.co/NVp8h5nh84」 / Twitter>https://twitter.com/NikkiSiapno/status/1593882400983072769]] 2022.11 --&ref(Git関連/git_workflow.jpg); --この図でいう Staging はインデックスと同等と考えて良い -&ref(Git関連/gitcommand.jpg); -[[[ver 1.2] Git でよく使われるコマンドにイラストによる説明を加えて1枚のチートシートにまとめてみた - Qiita>https://qiita.com/kozzy/items/b42ba59a8bac190a16ab]] 2019 -git remote ... ローカルリポジトリがどのリモートリポジトリと紐づいているか調べる -[[Gitを使ってやらかした時、git reflogさえ使えればわりかしなんとかなる - Qiita>https://qiita.com/getty104/items/cfd98f5f0ea89ef07bf0]] 2022.4 -[[git で一番危険なコマンドは init?>https://qiita.com/yuji96/items/136b6c8346d99b581f1d]] 2022.4 --それは git init -[[たまに使うGitコマンド集 - Qiita>https://qiita.com/goamix/items/d910871db4b53d77bffe]] 2022.3 -[[便利な「git-サブコマンド」を作成する>https://qiita.com/b4b4r07/items/6b76a5f969231e5e9748]] 2015.9 -git add したのを取り消したいときは git reset または git restore -[[git pull を強制し、リモートでローカルを上書きする方法>http://www-creators.com/archives/1097]] 2018.7 $ git fetch origin master $ git reset --hard origin/master -[[git pullとgit pull --rebaseの違い - Qiita>https://qiita.com/Hashimoto-Noriaki/items/6e183f738289cf288b23]] 2022.3 --fetch してから merge するか rebase するかの違い -[[リモートのgitブランチをローカルにチェックアウトする>https://www.setoya-blog.com/entry/2012/11/04/132746]] 2012.11 git branch -a git fetch git checkout -b <local branch> <remote branch> -[[実務でどんな git コマンドを使っているか振り返ってみる>https://qiita.com/west-hiroaki/items/74cccbc22b2cc7a4aacb]] 2019.6 -[[Gitを使いこなすための20のコマンド>http://sourceforge.jp/magazine/09/03/16/0831212]] *rebase と merge の違い [#z6afdc64] -[[rebase したらちょっと前に入れた修正が巻き戻ってた - Qiita>https://qiita.com/satomihoya/items/c126fcc939a9a454fd1b]] 2022.6 --force push は歴史の改変なのだということを強く意識しましょう -[[Git でrebaseを迷わず活用できるようになる - APC 技術ブログ>https://techblog.ap-com.co.jp/entry/2022/06/02/120001]] 2022.6 -[[あなたはmerge派?rebase派?綺麗なGitログで実感したメリット - BIGLOBE Style | BIGLOBEの「はたらく人」と「トガッた技術」>https://style.biglobe.co.jp/entry/2022/03/22/090000]] 2022.3 -[[Gitワークフロー設計について - 電通国際情報サービス TechBlog>https://tech.isid.co.jp/entry/2022/01/24/Git%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%95%E3%83%AD%E3%83%BC%E8%A8%AD%E8%A8%88%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6]] 2022.1 -[[pushしてからrebaseはダメ! - Qiita>https://qiita.com/riku929hr/items/15415d34ee5fc412c126]] 2022.3 --pushするまではrebase、pushしたあとはmerge -[[リベースでのコンフリクトを直そう – GIT>https://off.tokyo/blog/%e3%83%aa%e3%83%99%e3%83%bc%e3%82%b9%e3%81%a7%e3%81%ae%e3%82%b3%e3%83%b3%e3%83%95%e3%83%aa%e3%82%af%e3%83%88%e3%82%92%e7%9b%b4%e3%81%9d%e3%81%86-git/]] -[[ブランチを途中からリベースしたい - Qiita>https://qiita.com/mitashun/items/98ab98e83c0bba1ecba8]] 2022.2 -[[git rebaseを初めて使った際のまとめ>https://qiita.com/panti310/items/e0ec74b47c6c219f2a8b]] 2018.2 --トピックブランチcheckoutから git rebase master などとする。 --この場合、rebase した master ブランチ側の最新状態をトピックブランチにマージする --rebase後はトピックブランチはあたかも master 側の最終コミット後から分岐したかのようになる -[[こわくないGit>https://www.slideshare.net/kotas/git-15276118]] 2012 --コミットには1つ前のコミットへのポインタがある。この一連をコミットグラフと言う --merge には2種類ある。Fast-Forward と Non Fast-Forward --Fast-Forward(早送り)はmasterのラベルをtopicの最新コミットの位置へ張り替えるだけ。topicのコミットとmasterのコミットが枝分かれしていない場合に使える。 ---FFは処理が簡単だが、「ここからここまでマージした」という履歴が残せないため、revert するときにコミット位置をユーザが調べる必要が生じる。 --Non Fast-Forward topicとmasterが枝分かれしていたとき、真面目に普通にマージすること --rebaseのイメージ↓ --&ref(rebase.png); --共有しているブランチ(リモートでブランチ作成したのを共有しているブランチ)でリベースしてはいけない。pushできなくなるため。 --rebaseするとコミットがまとまるので見やすくなるが欠点もあり、pushされたブランチをリベースするとpushできなくなる。マージしたという事実は失われる。マージに比べてコンフリクトの解消が面倒。 *revert と reset の違い [#mf422244] -[[取り消しのGitコマンドの種類を覚えておく - Qiita>https://qiita.com/ym0628/items/b91f17e2916785875a3c]] 2023.8 --reset,revert -[[【Git】後から必要なくなった実装を取り消す方法〜revertとreset〜 - NRIネットコムBlog>https://tech.nri-net.com/entry/git_revert_reset]] 2023.7 $ git revert <commit> $ git reset <commit> -[[【Git入門】git commitを取り消したい、元に戻す方法まとめ - RAKUS Developers Blog | ラクス エンジニアブログ>https://tech-blog.rakus.co.jp/entry/20210528/git#reset%E3%81%A7%E3%82%B3%E3%83%9F%E3%83%83%E3%83%88%E3%82%92%E5%8F%96%E3%82%8A%E6%B6%88%E3%81%97%E3%81%A6%E3%81%AA%E3%81%8B%E3%81%A3%E3%81%9F%E3%81%93%E3%81%A8%E3%81%99%E3%82%8B]] 2023.4 -git revert と git reset はどちらもコミットの取消に使えるコマンド。違いは、どのように元のコミットを取り消すかという点 --git revert: git revert コマンドは、新しいコミットを作成して、その新しいコミットで元のコミットの影響を取り消します。そのため、元のコミットの記録は残り、他の人が参照することができます。また、git revert コマンドは、元のコミットを取り消した後に新しいコミットを行うため、再度 push する必要があります。 --git reset: git reset コマンドは、ローカルリポジトリのHEADとブランチのポインタを前に戻すことで、元のコミットを取り消します。そのため、元のコミットの記録は残りません。また、git reset コマンドは、元のコミットを取り消した後に、新しいコミットを行わないため、再度 push する必要はありません。 -git revert は元のコミットを取り消した後に新しいコミットを行うのに対し、git resetは元のコミットを取り消した後に新しいコミットを行わない。 また git revert は元のコミットを取り消した後に他の人も参照できるのに対し git reset は元のコミットを取り消した後に他の人は参照できない。 -revert や reset に渡すコミットのハッシュは git log で調べることが可能。 $ git log --pretty --abbrev-commit *ブランチの削除 [#occcbdd9] -[[不要ブランチを削除したい! - Qiita>https://qiita.com/matsu_aki/items/69f7b70b56d279e7b2b6]] 2023.3 -git で作ったブランチを削除するには、 git branch コマンドを使用します。 -1. ローカルブランチを削除する git branch -d <branch-name> -2. リモートブランチを削除する git push <remote> --delete <branch-name> -1ではローカルブランチを削除します。2ではリモートブランチを削除します。 -注意: git branch -d は、まだマージされていない変更を含むブランチを削除しようとすると、エラーが発生します。 -その場合は、 git branch -D <branch-name> を使用して強制的に削除します。 -また、git push <remote> --delete <branch-name> で削除する場合、該当のブランチがローカルに存在しない場合にはエラーが発生します。