間違えてGitHubにpushしてしまった時の対処法。 間違えてGitHubにpushしてしまった！ そんな時はターミナルで以下の４つをやればいいだけです。 （１）git branch （２）git reflog （３）git reset --hard （２）で取得した値 （４）git push -f （１）ブランチ一覧を表示 （２）過去にコミットした履歴を見る （３）コミットを取り消すことができる（自分のPC上のデータを削除） （４）GitHub上のデータを削除 感想 今までGItHubDesktopしか使っていませんでした。 しかし、GItHubDesktopだけではできることが限られてしまいます。 なので、今後はいろいろなコマンドも少しずつ覚えていくことにします。

はじめに 共同開発中に何度も『こんなときってどのコマンド使うんだっけ？』、『エラーが表示されるけどどうしよ、、、』と慌てた自分がいたのでメモ書きが誰かの参考になればと思い記事を作成しました。　　 注意点 自分のメモ書き用も兼ねておりますので、間違った点はご指摘していただけると幸いです。 リモートリポジトリ（GitHub）のコードをローカルリポジトリに複製 $ git clone リモートリポジトリのURL ディレクトリにリポジトリ作成 $ git init ローカルブランチで作成したブランチをリモートリポジトリに登録 $ git push -u origin 作成したブランチ名 変更箇所をステージングにあげる $ git add . ローカルリポジトリに保存 $ git commit -m "コミットメッセージ" ローカルリポジトリにmainブランチを新規作成 $ git branch -M main ローカルに新規のブランチを作成 $ git checkout -b ブランチ名 リモートリポジトリ（GitHub）を登録 $ git remote add origin リモートリポジトリのURL リモートリポジトリにプッシュする $ git push origin main 全てのブランチを確認（ローカルブランチ） ＄ git branch -a 現在の作業ブランチの確認 ＄ git branch リモートブランチの追跡一覧 $ git branch -r 追跡したいブランチの作成 $ git fetch origin <追跡したいブランチ名> 新規ブランチの作成 $ git branch ブランチ名 ブランチの移動 $ git checkout 移動したいブランチ名 新規ブランチの作成&そのブランチに移動 $ git checkout 移動したいブランチ名 既存ブランチ名の変更 $ git branch -m 変更したいブランチ名　変更後のブランチ名 【直前より前のコミットを取り消す】 $ git reset --hard HEAD コミットの履歴は残して内容だけを取り消す $ git revert コミットだけを取り消したい $ git reset --soft HEAD^ n個前のコミットを取り消してワークツリーの変更も取り消したい $ git reset --hard HEAD~{n} n個前のコミットだけ取り消したい $ git reset --soft HEAD~{n} 直前のコミット（push済み）のコミットメッセージを修正して再度プッシュしたい $ git commit --amend -m "新しいコミットメッセージ" $ git push -f origin 先ほどpushしたリモートブランチ pull = fetch + merge（コンフリクトを無くす） $ git pull ローカルの「master」ブランチまで更新されていない（mergeされていない） $ git fetch 誤って実行してしまったpullの取り消し $ git merge --abort ※mainブランチに誤ってpullしまった時に使う 誤って違うブランチにコミットした時のキャンセル $ git cherry-pick ファイルの差分を確認したい $ git diff ローカルファイルで変更を保存しないで別のブランチに移動（変更分を退避させる） $ git stash 一番最後に保存した状態に戻す $ git stash pop Gitの管理をやめる 絶対に打ち込んではいけないコマンド（gitの管理下におけるファイルの削除） $ rm -rf .git/ ファイル別に管理をやめる $ git rm ファイル名 ローカルリポジトリのステータス $ git status 作業ブランチにmainブランチを反映させるまでの流れ↓ ローカルブランチに移動 $ git checkout ローカルブランチ名 作業中のローカルブランチにmainブランチ反映 $ git merge　main

説明 前回はコマンド一覧のみを書きましたが今回から具体的な使い方の説明をしていきます。 本記事は初学者向けとド忘れしたときの手助けになればと書いています。 git init ->リポジトリの初期化 作成したディレクトリまで移動しgit initコマンドを叩く下記の一文が出ていれば成功です。 「Initialized empty Git repository in /Users/Desktop/git/.git/」 これでgitでバージョン管理する準備ができました。 % git init hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: hint: hint: git config --global init.defaultBranch <name> hint: hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and hint: 'development'. The just-created branch can be renamed via this command: hint: hint: git branch -m <name> Initialized empty Git repository in /Users/Desktop/git/.git/ git status ->リポジトリの状態確認 初期化すぐに「git status」を行うと図１の画面になり何もない事が表示されます。 新しくファイルを追加して再度、「git status」を行うと図２のようになります。 このように状態を確認できるコマンドです。 図１ % git status On branch master No commits yet nothing to commit (create/copy files and use "git add" to track) 図２ % git status On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) README.md nothing added to commit but untracked files present (use "git add" to track) git commit ->リポジトリの歴史を記録（詳細なコミットメッセージを記述できる） 「git add」コマンドでステージングさせ「git commit」を行うとエディタが表示され下記のように表示されます。 記述できるようにするにはキーボードの「I」を押し「-- INSERT --」と表示されれば記述できるようになります。 終わればキーボードの「esc」を押し「:w」で保存して「:q」で終わるとコミットが行われます。 うまく行くと図２のようになります。 図１ ここにコミットメッセージを記述 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # On branch feature-D # Your branch is up to date with 'origin/feature-D'. # # Changes to be committed: # modified: README.md # ~ ここから下に変更した理由や詳細を記述 ~ ~ ~ ~ ~ ~ -- INSERT -- 図２ [feature-D 8136cbd] Edit 1 file changed, 2 insertions(+), 2 deletions(-) git commit -m "コミットメッセージを記述する" ->リポジトリの歴史を記録（1行のコミットメッセージを記述する） こちらも「git add」コマンドを行った後に「git commit -m」を行います。 「git commit -m」はダブルクオーテーションの中にコミットメッセージを記述して行います。 下記の様になれば成功です。 % git commit -m "Add index" [master 4ae8ec7] Add index 1 file changed, 1 insertion(+) git commit -am "コミットメッセージを記述する" ->git addとgit commit -mを同時に行う 「git commit -am」は「git add」と「git commit -m」を一回のコマンドで行えます。 使い方は「git commit -m」と同じでダブルクオーテーションの中にコミットメッセージを記述して行います。 下記の様になれば成功です。 % git commit -am "Add feature-C" [feature-C cfaf6ef] Add feature-C 1 file changed, 1 insertion(+) git commit --amend ->コミットメッセージを修正 「git commit --amend」を行うと下記の画面のようにエディタが立ち上がります。 ※エディタの操作については簡単ではありますが上記の方の「git commit」の所で説明しているのでわからない場合は参考にしてください。 コミットメッセージが書かれている所を消して再度、記述します。 詳細も必要に応じて書き保存して終了すると図２の様になります。 図１ Edit　←これがコミットメッセージ # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # Date: Sun Jun 20 13:53:16 2021 +0900 # # On branch feature-D # Your branch is ahead of 'origin/feature-D' by 1 commit. # (use "git push" to publish your local commits) # # Changes to be committed: # modified: README.md # ~ ここから下に詳細などがコミット時に書かれていた場合その詳細も表示されます ~ ~ ~ ~ ~ ~ ~ ~ -- INSERT -- 図２ % git commit --amend [feature-D f64802f] Amend Date: Sun Jun 20 13:53:16 2021 +0900 1 file changed, 2 insertions(+), 2 deletions(-) 今回はここまで 簡単ではあるのですが僕が学習していてつまづいたりこうやって書いてくれているとありがたいという気持ちで書いたので初学者や慣れ始めた方達の助けになればと思っています。 他のコマンドもまた書いていきたいと思っています。

説明 前回はコマンド一覧のみを書きましたが今回から具体的な使い方の説明をしていきます。 本記事は初学者向けとド忘れしたときの手助けになればと書いています。 git init ->リポジトリの初期化 作成したディレクトリまで移動しgit initコマンドを叩く下記の一文が出ていれば成功です。 「Initialized empty Git repository in /Users/Desktop/git/.git/」 これでgitでバージョン管理する準備ができました。 % git init hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: hint: hint: git config --global init.defaultBranch <name> hint: hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and hint: 'development'. The just-created branch can be renamed via this command: hint: hint: git branch -m <name> Initialized empty Git repository in /Users/Desktop/git/.git/ git status ->リポジトリの状態確認 初期化すぐに「git status」を行うと図１の画面になり何もない事が表示されます。 新しくファイルを追加して再度、「git status」を行うと図２のようになります。 このように状態を確認できるコマンドです。 図１ % git status On branch master No commits yet nothing to commit (create/copy files and use "git add" to track) 図２ % git status On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) README.md nothing added to commit but untracked files present (use "git add" to track) git commit ->リポジトリの歴史を記録（詳細なコミットメッセージを記述できる） 「git add」コマンドでステージングさせ「git commit」を行うとエディタが表示され下記のように表示されます。 記述できるようにするにはキーボードの「I」を押し「-- INSERT --」と表示されれば記述できるようになります。 終わればキーボードの「esc」を押し「:w」で保存して「:q」で終わるとコミットが行われます。 うまく行くと図２のようになります。 図１ ここにコミットメッセージを記述 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # On branch feature-D # Your branch is up to date with 'origin/feature-D'. # # Changes to be committed: # modified: README.md # ~ ここから下に変更した理由や詳細を記述 ~ ~ ~ ~ ~ ~ -- INSERT -- 図２ [feature-D 8136cbd] Edit 1 file changed, 2 insertions(+), 2 deletions(-) git commit -m "コミットメッセージを記述する" ->リポジトリの歴史を記録（1行のコミットメッセージを記述する） こちらも「git add」コマンドを行った後に「git commit -m」を行います。 「git commit -m」はダブルクオーテーションの中にコミットメッセージを記述して行います。 下記の様になれば成功です。 % git commit -m "Add index" [master 4ae8ec7] Add index 1 file changed, 1 insertion(+) git commit -am "コミットメッセージを記述する" ->git addとgit commit -mを同時に行う 「git commit -am」は「git add」と「git commit -m」を一回のコマンドで行えます。 使い方は「git commit -m」と同じでダブルクオーテーションの中にコミットメッセージを記述して行います。 下記の様になれば成功です。 % git commit -am "Add feature-C" [feature-C cfaf6ef] Add feature-C 1 file changed, 1 insertion(+) git commit --amend ->コミットメッセージを修正 「git commit --amend」を行うと下記の画面のようにエディタが立ち上がります。 ※エディタの操作については簡単ではありますが上記の方の「git commit」の所で説明しているのでわからない場合は参考にしてください。 コミットメッセージが書かれている所を消して再度、記述します。 詳細も必要に応じて書き保存して終了すると図２の様になります。 図１ Edit　←これがコミットメッセージ # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # Date: Sun Jun 20 13:53:16 2021 +0900 # # On branch feature-D # Your branch is ahead of 'origin/feature-D' by 1 commit. # (use "git push" to publish your local commits) # # Changes to be committed: # modified: README.md # ~ ここから下に詳細などがコミット時に書かれていた場合その詳細も表示されます ~ ~ ~ ~ ~ ~ ~ ~ -- INSERT -- 図２ % git commit --amend [feature-D f64802f] Amend Date: Sun Jun 20 13:53:16 2021 +0900 1 file changed, 2 insertions(+), 2 deletions(-) 今回はここまで 簡単ではあるのですが僕が学習していてつまづいたりこうやって書いてくれているとありがたいという気持ちで書いたので初学者や慣れ始めた方達の助けになればと思っています。 他のコマンドもまた書いていきたいと思っています。

はじめに プルリクエストをした際に、「1 commit behind "master"」が発生しているという指摘をいただいたため、その対応の記録です。 状況 恥ずかしながら、指摘を受けた段階では、何が起きているのか理解できていませんでした。 そこでブランチを見に行ったところ、以下の画像のような状況でした。 赤線がmasterブランチ、緑線が開発ブランチです。 赤丸のところで、開発ブランチ（develop1）をmasterブランチにマージし、その後、別の開発ブランチ（develop2）を切って、次の作業を開始し、緑丸の上から３つ目のところで、プルリクエストをして、「1 commit behind "master"」が発生しました。 原因 今となっては、何をしてしまったのか、よくわからないというのが正直なところではありますが、develop1ブランチをmasterブランチにマージするときか、develop2ブランチを切るときに何かやらかしたのだと思います。 ※レビュー待ちの時間に、次にやることをあれこれとコードを触りながら考えていたので、それが失敗の元だったと思います。皆さんは、お気をつけください。 対応 まずは、ローカルリポジトリのmasterブランチにリモートリポジトリのmasterブランチを反映させます。 git checkout master git pull origin master 次に、現在の開発ブランチ（develop2）にmasterブランチをマージします。 git checkout develop2 git merge master コンフリクトが発生していれば、ここで解消する必要があるかと思いますが、私の場合は、コードを修正していたわけではないので、コンフリクトは発生していませんでした。 あとは、いつもどおり、commit、pushで完了です。 git commit -m "behindの解消" git push origin develop2 これにより、上記画像のとおり、赤線（master）と緑線（develop2）が合流しました。 さいごに さて、いかがでしたでしょうか？ コンフリクトの解消についての記事は割と出てくるのですが、「○ commit behind "〇〇"」などで検索しても解決方法がなかなか見つけられなかったので、記事にしてみました。

ゴール & 目的 業務でGitを使っているがそこまでコマンドを知らない人や、これからGitを使っていきたいから少し調べ始めた人向け。 今後業務に役立って欲しい。 アジェンダ はじめに Gitとは 覚えて欲しいコマンド Git特徴 Gitの開発フロー コミットルール できればやって欲しくないこと。 Gitlab 終わりに はじめに Gitは開発でなくてはならない存在になっている。 これらを理解することがエンジニアでは必須事項なので覚えて欲しい。 既に業務で使っているため、基礎の基礎は割愛してポイントを絞った勉強会になっています。 ただ、基礎の基礎で不明点があれば、是非とも質問して欲しいです！ Gitとは プログラムのソースコードのバージョン管理システムです。 Linuxカーネルの産みの親であるリーナス・トーバルズがGitを作りました。（神） バージョン管理システムはCVSやSVNなど昔からあり、SVNが大変便利でした。 ただ、複数人対応する際にマージ祭りが多く大変でしたが、 ちょうどそれら問題を解決が得意なGitが広く使われるようになり、今の主流になりました。 覚えて欲しいコマンド 長い説明を色々語りたいところですが、単刀直入に以下のコマンドを覚えてくれれば問題ありません。 1. 最新状態を取ってくる＆不要なブランチ情報を削除 git pull --prune ブランチを最新化するコマンドだが、pruneを追加することで、リモートブランチで削除されたブランチを削除することができる。 ローカルに色々ごちゃごちゃ溜まっている人がいると思うので、実行していない人がいたら是非一回実行してみてください。スッキリします。 2. 今までの変更を全て差し戻す git checkout . コミット前限定で、修正をなかったことにしたい場合。 「.」をファイル指定することで、ファイル単位で差し戻すことが可能。 3. git管理外のファイルを全て削除したい git clean -dn #削除対象を表示する git clean -df #削除を実施する 検証用でいらないくなったファイルやディレクトリを一括で削除したい場合便利 今は必要なさそう？と思いますが、必要な時がきます。 4. ファイルをリネームしたい。 git mv hoge.txt fuga.txt 普通にmvでファイル名をリネームしたり移動したりすると、gitからは削除された扱いになり、変更履歴が消滅してしまう。 git mvすることで、変更履歴を引き継いだ状態になるので、これは是非とも覚えて欲しいです。 似たようなコマンドでgit rmがありますがこれは特に使わなくてもOK。 5. 直前のコミットや何らかの作業を無かった事にする（変更状態も削除。） git reset --hard HEAD^ push前限定で、コミットやマージ作業を無かったことにしたい場合。 「^」の個数分、何個前に戻るか決めれる。3つ戻りたい場合は「HEAD^^^」 何かやらかしたか！？と思ったらこれを使えばなかったことになります。 6. 直前のコミットや何らかの作業を差し戻す。（変更状態は残る。） git reset --soft HEAD^ hardだとコミットした変更までも消えてしまうので、それが嫌ならsoftを使いましょう。 hardとsoftの違いがいまいちわからない人はsoftを使った方が良いかもしれないです。 7. 指定のブランチの最新状態を今のブランチに取り込む。(originを忘れないで) git pull --prune git marge origin/<branch> または git pull origin <branch> 上のコマンドと下のコマンドはいずれもマージの挙動が同じだが、マージの履歴の残り方が若干が違います。 「git pull origin 」するとスッキリした履歴になるが、 どこからマージしたのかちゃんと残したい場合、上のコマンドでやった方が精神衛生上良い。 上のコマンドにある「origin/」について リモートブランチを指しているので、pull後にoriginを指定すると必ず最新版になる。もしoriginを付けなかった場合は、自分のローカルブランチの状態を取り込むことになるので、古い可能性が出てくる。 8. ログをもう少しよく見たい git log --graph --oneline ログ表示をグラフィカルにしたい場合に使うが、基本的にgitlabのgraphページやvscodeのgit historyの拡張でも十分だったりします。 9. 途中まで変更した内容を一時的に退避したい git stash 急な作業が入り、ブランチを切り替えたい場合があるが、コミットしたくない。困った。。という場合に使う。 退避したものを復元 git stash list git stash apply <number> または git stash pop　※適用と当時にstash情報が削除されます。 その他 stashが難しい場合は、コミットしても良いと思います。 その際に下記のオプションをつけると、前回コミットした内容を修正することができます。 git commit --amend つまり、amendコマンドで何回コミットしても、コミットは一つのままです。 やって欲しい設定 git config --global --add merge.ff false git config --global --add pull.ff only 筆者はrebaseなどの歴史改変や、merge時のfast-forwardを使わない(使いこなせない)のもありますが、 まずGitを始める人は自分がどこからどこへマージしているかをキチンと把握できるまでは、この設定をした方が良いかと思います。 詳細は下記の記事を参照していただければと思います。 Git特徴 リモートリポジトリ、ローカルリポジトリという概念がある。 ブランチを切る、ブランチをマージなどが得意であり、複数人が同時に作業することを想定した設計 Gitlab/Githubのようなサイトがある これらは素のGitが裏で走っているが、それに追加機能としてGUIやissue、MRなどの認証機能をつけたものと解釈してOK。 またGitですが、ありとあらゆるコマンドが用意されているため、考え付かないような操作をすることができる。 ここがポイントで、なんでも出来る＝好き勝手すると崩壊する危険性を伴っています。 つまりGitは使いやす過ぎる故、十人十色の運用方法があるため、運用が破綻する前にチーム内や部署でルールを決めていく必要がある。 Gitの開発フロー 如何様にも運用できてしまうGitはルールがないと本当に死んでしまいますので、過去の先人たちが考えまくりました。 そこで出た開発フローを軽めに紹介します。 複数人で開発する際に特にこだわりがなければ、いずれかの開発フローに従ってみて、 その後、チームにあった方法に改良していくことをお勧めします。 Git-flow ヴィンセントさんが考案したものです。こちらの記事が役に立ちます。 個人的にこれが一番しっくり来ています。 ブランチがそれぞれ意味を持たせて運用しているので、縦割りの関係でわかりやすいです。 必要なブランチが多いですが、それぞれ必要な理由がわかれば、簡単に受け入れることができると思います。 master：本番環境にあるソースコードで、テストがされているもの develop：開発中のメインブランチ hotfix/hoge：本番で不具合があったときに作成される一時的なブランチ feature/fuga：新規機能やタスクをする際に作成するブランチ 補足：feature/のようにスラッシュ区切りでブランチ名を作成すると、gitとしてはフォルダのような区切りとして扱われます。 feature/ fuga piyo Git-flowですが、2つのブランチに対してマージする工程が少し面倒な箇所があります。 ですが、ちゃんとコマンドが用意されていたり、SourceTreeの機能になっていたりしているので、簡単にフォローできたりしますので、 気軽に試してみてください。 gitlab-flow & github-flow GitlabのMRや、GithubのPRを活用した開発フローもあります。 今はこちらの方が主流になっているかと思うので、こちらにも目を通していきます。 コミットルール コミットする際のルールも整えていく必要があります。 コミットの粒度や内容によって、Gitの履歴が大変見辛くなりますので、大変でしょうが覚えて欲しいです。 これらを意識すると少しだけ恩恵もあったりします。 例えば、二行目を空けてコミットするなどをすると、 GitlabやGithubのコミット画面で詳細を見る「・・・」ボタンが表示されたりします。 できればやって欲しくないこと。 ※ここで述べていることは、現場によって大きく異なる部分です。 流派の違いもあるので、一例と思ってください。 rebase、git pull origin masterなどの fast-forward関連。 git pullのみはOK force push 歴史改変するコマンドはメリットデメリットが多いです。 証跡を残して仕事する場合チームだと、おすすめしません。 どうしてもrebaseがしたいのであれば、、、 一度もpushしていないローカルブランチなら、rebaseやsquashなどなんでもOK push後、MRを出す前にrebaseやsquashを行い、乱雑な履歴をクリーンアップする。 MRを出した後はrebase禁止。 Gitlab MRする際の小技としてissueを紐付けてクローズする方法が2つほど、あります。 MRの本文に、closes #123 とclosesの単語とクローズしたいissue番号をつける コミットの文章にcloses #123をつける。 closes #123 #124 と複数書くことや fixed #123 #124と書くこともできたりします。 https://www.codelab.jp/blog/?p=2289 終わりに いかがだったでしょうか。 Gitの表面を説明したのみで、まだまだGitは深いです。 分からないことがあれば、いつでも聞いてください！ ご清聴ありがとうございました！！ その他、 リンク ここのブログが分かりやすかったので、興味があれば、色々みてみてください。 https://kray.jp/blog/git-why-explanation/ https://kray.jp/blog/git-pull-rebase/