目的 二つのコミットを一つにまとめる方法を書く。 1回のコミットにしたかったが間違えて2つに分けてしまい、2つ目のコミットを間違えた場所からしてしまった時の対処法を書く。 前提条件 pushを行い現在レビュー中にRebaseを行った二つのコミット(AコミットとBコミット)をまとめる時を想定する。 最初に行ったコミットをAコミットとし、Aコミットで修正したファイルをAファイルとする。 後に行ったコミットをBコミットとし、Bコミットで修正したファイルをBファイルとする。 Aコミットのpush環境は残っておらず、現在はBコミットの環境のみがローカルに存在するものとする。 実施詳細 ※確認コマンド実行の合間にコマンド$ git logを実行すると良い fetchでレビュー中の情報を取得する Bコミットの環境にfetchでレビュー中のAコミットの環境を得る。 コマンド$ git fetch gerritを実行したがレビュー中に実施したRebaseの情報までは取得できなかった。(コミットIDを指定してcheckoutしようとしてもfatalと言われた→rebaseを行ったため、その情報がGerrit上にはあるがローカルになかったため怒られた) 下記コマンドを実行しAコミットのレビュー中の内容までの情報を取得した。(rebaseの情報も取得できた) $ git fetch gerrit refs/changes/変更番号下2桁/追跡番号/Aコミットのpatch setの番号 fetchした情報をもとにcheckoutをしてレビュー中のファイルAを取得 コマンド$ git checkout AコミットのコミットIDを実行しコミットIDに結びついたファイルを取得した。 下記コマンドを実行してBコミットのファイルを取得した。 $ git cherry-pick -n BコミットのコミットID 取得したファイルをステージングする。 下記コマンドを実行した。 $ git add . 追加したBコミットのファイルを含めてコミットをした。 下記コマンドを実行した。 $ git commit --amend リモートにpushを行う。 下記コマンドを実行した。 $ git push gerrit HEAD:refs/for/ブランチ名
※確認コマンド実行の合間にコマンド$ git logを実行すると良い
$ git log
$ git fetch gerrit
$ git fetch gerrit refs/changes/変更番号下2桁/追跡番号/Aコミットのpatch setの番号
$ git checkout AコミットのコミットID
$ git cherry-pick -n BコミットのコミットID
$ git add .
$ git commit --amend
$ git push gerrit HEAD:refs/for/ブランチ名
コミットするブランチを間違えた！ 僕みたいなぽんこつエンジニアが複数のブランチで平行して作業をしていると、たまにこういうことがあります。 開発中に急遽、ぱいせんから優先度の高い修正を頼まれて、対応した後のあるあるですね。 修正終わって一息ついて、ブランチ変え忘れたまま元の作業を進めちゃうわけです。 そんなときはcherry-pick コミットするブランチを間違えたときに助けてくれるのがcherry-pickです。 cherry-pickは、あるブランチに入れたコミットを、別のブランチにぶち込むGitコマンドです。 以下のコマンドで、別ブランチのコミットをぶちこむことができます。 $ git cherry-pick COMMIT_ID COMMIT_IDには、ぶちこむコミットのIDを入れます。 git log などでコミットIDを調べましょう。 git log を叩いたときに以下のようにログが出ると思います。 以下の xxxxxxxxx...... に出力されているのがコミットIDです。 $ git log commit xxxxxxxxxxxxxxxxxxxxxxxxxx たのしいcherry-pickの手順 1. コミットするブランチを間違える まずはコミットするブランチを間違えます（間違えるな） 2. あわてずログを確認する まずはログを確認して、コミットIDをクリップボードにでもコピーしておきましょう。 コミットIDがないとcherry-pickできません。 $ git log commit xxxxxxxxxxxxxxxxxxxxxxxxxx 3. 正しいブランチに切り替える 本当にコミットしたかったブランチに切り替えます。 ここでまたブランチを間違えると１からやり直すことになります。 以下のコマンドのCORRECT_BRANCHに、正しいブランチ名を入れてください。 慎重に切り替えましょう。 切り替えたあと、 git branch を叩いて確かにブランチを切り替えたことを確認するくらい慎重にやりましょう。 $ git checkout CORRECT_BRANCH 4. cherry-pickマンになる あとはcherry-pickマンになるだけです。 COMMIT_IDには2でコピーしたコミットIDを入れます。 $ git cherry-pick COMMIT_ID まとめ ログからコミットのIDをコピーする 正しいブランチに切り替える cherry-pickする $ git log $ git checkout CORRECT_BRANCH $ git cherry-pick COMMIT_ID
僕みたいなぽんこつエンジニアが複数のブランチで平行して作業をしていると、たまにこういうことがあります。
開発中に急遽、ぱいせんから優先度の高い修正を頼まれて、対応した後のあるあるですね。 修正終わって一息ついて、ブランチ変え忘れたまま元の作業を進めちゃうわけです。
コミットするブランチを間違えたときに助けてくれるのがcherry-pickです。
cherry-pickは、あるブランチに入れたコミットを、別のブランチにぶち込むGitコマンドです。 以下のコマンドで、別ブランチのコミットをぶちこむことができます。
$ git cherry-pick COMMIT_ID
COMMIT_IDには、ぶちこむコミットのIDを入れます。 git log などでコミットIDを調べましょう。
git log
git log を叩いたときに以下のようにログが出ると思います。 以下の xxxxxxxxx...... に出力されているのがコミットIDです。
xxxxxxxxx......
$ git log commit xxxxxxxxxxxxxxxxxxxxxxxxxx
まずはコミットするブランチを間違えます（間違えるな）
まずはログを確認して、コミットIDをクリップボードにでもコピーしておきましょう。 コミットIDがないとcherry-pickできません。
本当にコミットしたかったブランチに切り替えます。 ここでまたブランチを間違えると１からやり直すことになります。 以下のコマンドのCORRECT_BRANCHに、正しいブランチ名を入れてください。 慎重に切り替えましょう。 切り替えたあと、 git branch を叩いて確かにブランチを切り替えたことを確認するくらい慎重にやりましょう。
git branch
$ git checkout CORRECT_BRANCH
あとはcherry-pickマンになるだけです。 COMMIT_IDには2でコピーしたコミットIDを入れます。
$ git log $ git checkout CORRECT_BRANCH $ git cherry-pick COMMIT_ID
概要 Macで生成したSSH鍵を利用して、Windowsでgithubへアクセスしようとしたところ、エラーになった。 WindwosではTortoiseGitを利用してアクセスを試みていた。 原因として、TortoiseGitとMacがデフォルトで生成する鍵の形式は異なるため、エラーになった模様。 対応としては、SSH鍵の形式変換を行う、もしくは別のソフトを利用するといった対応が必要になった。 発生エラー PageantOK Couldn't load this key (OpenSSH SSH-2 private key (old PEM format)) エラー原因 TortoiseGitとMacがデフォルトで生成する鍵の形式は異なるため 対応策 別のソフトを利用する(Sourcetree) SourcetreeはWindows版もあり、そちらであればMacで生成した鍵をそのまま利用できる。 鍵の形式を変換する 以下の手順を実施することで、鍵の形式を変換することができる。 https://qiita.com/ryok/items/be260e6df4ecfb5d5f1d
Macで生成したSSH鍵を利用して、Windowsでgithubへアクセスしようとしたところ、エラーになった。 WindwosではTortoiseGitを利用してアクセスを試みていた。 原因として、TortoiseGitとMacがデフォルトで生成する鍵の形式は異なるため、エラーになった模様。 対応としては、SSH鍵の形式変換を行う、もしくは別のソフトを利用するといった対応が必要になった。
PageantOK Couldn't load this key (OpenSSH SSH-2 private key (old PEM format))
TortoiseGitとMacがデフォルトで生成する鍵の形式は異なるため
別のソフトを利用する(Sourcetree) SourcetreeはWindows版もあり、そちらであればMacで生成した鍵をそのまま利用できる。
鍵の形式を変換する 以下の手順を実施することで、鍵の形式を変換することができる。 https://qiita.com/ryok/items/be260e6df4ecfb5d5f1d
gitの鍵とは 自分のgithubをいじる時はパスワードやユーザーネームは入力しない。 でも他人に自分のリモートリポジトリをめちゃめちゃにされたら困る。 そこで出てくるのが公開鍵と秘密鍵！ 鍵には 公開鍵 と 秘密鍵 の２種類がある。 公開鍵は、githubに送って、秘密鍵は自分のパソコンの中にある。 この鍵が一致することで、本人確認ができてgit hubをいじることができる。 $cd ~/.ssh これで鍵を作成するディレクトリに移動する ssh-keygen で鍵をつくる すると以下のようなのが出てくる Generating public/private rsa key pair. Enter file in which to save the key (/Users/xxx.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: id_rsa.pub これが公開鍵 id_rsa これが秘密鍵 次に $ pbcopy < ~/.ssh/id_rsa.pub これを実行すると超長い鍵がコピーされるので、githubの鍵を貼るところに貼り付ける ssh git@github.com 最後にこれを実行してHi!って返ってきたらおっけー！
自分のgithubをいじる時はパスワードやユーザーネームは入力しない。
でも他人に自分のリモートリポジトリをめちゃめちゃにされたら困る。
鍵には
と
の２種類がある。
公開鍵は、githubに送って、秘密鍵は自分のパソコンの中にある。 この鍵が一致することで、本人確認ができてgit hubをいじることができる。
$cd ~/.ssh
これで鍵を作成するディレクトリに移動する
ssh-keygen
で鍵をつくる すると以下のようなのが出てくる
Generating public/private rsa key pair. Enter file in which to save the key (/Users/xxx.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again:
これが公開鍵
これが秘密鍵
次に
$ pbcopy < ~/.ssh/id_rsa.pub
これを実行すると超長い鍵がコピーされるので、githubの鍵を貼るところに貼り付ける
ssh git@github.com
最後にこれを実行してHi!って返ってきたらおっけー！
herokuにログインしてなかっただけだった。 $heroku login でログインした。 その後は別のエラーにつまづいたが、、、 備忘録。
herokuにログインしてなかっただけだった。
$heroku login
でログインした。
その後は別のエラーにつまづいたが、、、 備忘録。
以下でできます。 git show ${コミットハッシュ} 実行例 $ git show bf79a4685551a67b9231bfc7d5335cbed414c238 commit bf79a4685551a67b9231bfc7d5335cbed414c238 Author: ~~ 省略 ~~ Date: Sat Aug 17 20:53:58 2019 +0900 fugaコミット fuca diff --git a/README.md b/README.md index 0ef7e93..1a57997 100644 --- a/README.md +++ b/README.md @@ -1 +1,3 @@ +hoge +fuga piyo 参考にさせて頂いた記事 gitのコミット指定方法(ハッシュ値、HEAD、HEAD~)を理解して、コマンドを有効活用しよう！ - Qiita
以下でできます。
git show ${コミットハッシュ}
$ git show bf79a4685551a67b9231bfc7d5335cbed414c238 commit bf79a4685551a67b9231bfc7d5335cbed414c238 Author: ~~ 省略 ~~ Date: Sat Aug 17 20:53:58 2019 +0900 fugaコミット fuca diff --git a/README.md b/README.md index 0ef7e93..1a57997 100644 --- a/README.md +++ b/README.md @@ -1 +1,3 @@ +hoge +fuga piyo
未だに??? ????????を使って諸々の操作を行なっていたらCTOに「わかいのにかわいそう...」と、老害扱いを受けました。先月追加された新しいオプション(??? ??????と??? ???????)を使い分けていない、そこのあなたも老害の恐れがあります。— binaryta@U+1F35C (@binaryta) September 30, 2019 こちらのツイートを見て、 「やばいやばい、老害になる前に俺も早速 git switch 使うぞ〜^^」 とコマンドを叩くも、そんなコマンド存在しないぞ？と怒られました もしかして、俺のGitバージョン低すぎ？ git --version で現在使用しているGitのバージョンを確認できます。 git version 2.20.1 (Apple Git-117) git switch等はv.2.23.0以降のようなのでバージョンが低いことが分かりました。 GitのWebサイトからダウンロードする方法もりますが、今回はHomebrewを使います。 まだHomebrewを導入していない方はこちらからインストールしましょう→Homebewa brew update 念の為、Homebrewを最新にしておきます。 brew install git HomebrewでGitをインストールします。 git --version インストールが無事に終わったらバージョンを確認します。 あれ？バージョンが変わっていませんでした。 パスの向き先は正常なようです。 あ、Terminalを再起動するの忘れてた！ git version 2.23.0 無事にアップデートでき、 git switch 等のコマンドを叩くことができるようになりました！
未だに??? ????????を使って諸々の操作を行なっていたらCTOに「わかいのにかわいそう...」と、老害扱いを受けました。先月追加された新しいオプション(??? ??????と??? ???????)を使い分けていない、そこのあなたも老害の恐れがあります。— binaryta@U+1F35C (@binaryta) September 30, 2019
未だに??? ????????を使って諸々の操作を行なっていたらCTOに「わかいのにかわいそう...」と、老害扱いを受けました。先月追加された新しいオプション(??? ??????と??? ???????)を使い分けていない、そこのあなたも老害の恐れがあります。
こちらのツイートを見て、 「やばいやばい、老害になる前に俺も早速 git switch 使うぞ〜^^」 とコマンドを叩くも、そんなコマンド存在しないぞ？と怒られました
git switch
もしかして、俺のGitバージョン低すぎ？
git --version
で現在使用しているGitのバージョンを確認できます。
git version 2.20.1 (Apple Git-117)
git switch等はv.2.23.0以降のようなのでバージョンが低いことが分かりました。
GitのWebサイトからダウンロードする方法もりますが、今回はHomebrewを使います。 まだHomebrewを導入していない方はこちらからインストールしましょう→Homebewa
brew update
念の為、Homebrewを最新にしておきます。
brew install git
HomebrewでGitをインストールします。
インストールが無事に終わったらバージョンを確認します。 あれ？バージョンが変わっていませんでした。 パスの向き先は正常なようです。
あ、Terminalを再起動するの忘れてた！
git version 2.23.0
無事にアップデートでき、 git switch 等のコマンドを叩くことができるようになりました！
