はじめに railsでアプリを作成中にgitでプッシュした後に、コミット名を変更したい場合にどうしたらいいのか、学習した内容を記事にしました。 修正するための流れは git commit --amend エディタ内でコミット名を編集 git push -f origin リポジトリ名 の流れになります。 直前のコミットを書き換える git commit --amend このコマンドを使用することで、前回のコミットにファイルの追加を行ったり、コミットコメントの変更を行ったりできます。 ×××××@×××××MacBook-Pro ××××× % git log commit ×××××××××××××××××××××××××××××× (HEAD -> main, origin/main) Author: ××××× <××××××××××××××××××××> Date: Mon May 3 14:43:02 2021 +0900 first commit # ここのコミット名を編集したい まず、 ×××××@×××××MacBook-Pro ××××× % git commit --amend のコマンドを実行すると、エディタが表示されるので、insertモードにして、コミット名を編集します。 編集が完了したら、 「ESCボタン」　からの、、、 :wq # 編集したエディタを保存するコマンド これで、コミット名がローカル上に反映されるので、次は、リモートリポジトリに編集内容を反映させます。 強制的にリモートリポジトリを書き換える これまでの過程で、ローカルリポジトリのコミット名の書き換えは完了しましたが、リモートリポジトリには反映されていません。 しかし、いつものように git push origin main(master) などと入力した場合はエラーが発生します。 これはリモートリポジトリととローカルリポジトリに不整合が生じているからです。 これを解決するために強制的にローカルブランチをリモートブランチに上書きできるコマンドを実行します。 git push -f origin リポジトリ名 これで、pushしたコミット名を編集することができます。 このコマンドは強制的にブランチを上書きするコマンドなので、使用する際は注意が必要です。

最近はmasterだと怒られるようになりましたね。 $ git config --global init.defaultBranch main を実行しておくだけでOKです。 世の中的にmaster廃止でmainをデフォにする動き GitHub上で新規リポジトリ作るとmainになってましたが、ローカルから作るとまだmasterがデフォルトになってました。 新しいGitHubリポジトリではmainブランチがデフォルトに 最近CLIツールをアップデートしましたが、gitのv2.30.1で怒られました。 $ 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> みたいな感じで怒られました。 ローカルで作るとmasterだしタイプぐせもついてたから気にせずgit push origin masterとか打ってしまうのでmasterにしてましたが、 そろそろ世の中に合わせないといけないタイミングみたいですね。 ローカルでもmainにしていきましょう。

コミットとは ファイルやディレクトリの追加/変更をリポジトリに記録する操作のこと 実行したときの動き リポジトリ内では前回コミット~現在の状態までの記録したコミット(リビジョン)が作成される コミットは時系列順につながった状態でリポジトリに格納される コミット名 コミット情報から計算された重複しない英数字40桁で命名される この名前を指定してリポジトリ内からコミットを指定する コミットのタイミング バグ修正 機能追加 コミットメッセージ コミット時に入力必須 誰が見てもわかりやすい変更内容にするよう心がける 例)1行目 : コミットでの変更内容の要約 2行目 : 空行 3行目以降 : 変更した理由

コミットとは ファイルやディレクトリの追加/変更をリポジトリに記録する操作のこと 実行したときの動き リポジトリ内では前回コミット~現在の状態までの記録したコミット(リビジョン)が作成される コミットは時系列順につながった状態でリポジトリに格納される コミット名 コミット情報から計算された重複しない英数字40桁で命名される この名前を指定してリポジトリ内からコミットを指定する コミットのタイミング バグ修正 機能追加 コミットメッセージ コミット時に入力必須 誰が見てもわかりやすい変更内容にするよう心がける 例)1行目 : コミットでの変更内容の要約 2行目 : 空行 3行目以降 : 変更した理由 参考 https://backlog.com/ja/git-tutorial/intro/03/

タイトルの通り、分かったつもりだったんですよ。 でも、個人でしか使っていなかったしGithubDesktopで使っていたのでよく分かっていなかったのです。 きちんと理解すべく勉強してみました！ 間違い等あればご指摘お願い致します。 GitとGitHub Git ファイルの変更履歴を記録できるバージョン管理システムです。 いつ、何を変更したかが一目瞭然です。 GItHub Gitを使ったWebサービスです。 お互いのコードをレビューしたりできるなど、チーム開発を便利にできます。 リポジトリ リポジトリとは保管庫とか棚と考えれば分かりやすいと思います。 以下の絵のようなイメージですかね。 ローカルリポジトリとリモートリポジトリ ローカルリポジトリは自分のPC上のリポジトリで、リモートリポジトリはWeb上のリポジトリです。 ここまでは理解できます。 私が理解できなかったのはaddとかpushとかのコマンドでどういう状態になっているかということです。 これはGitの構造を理解することで解決できました。 まずはコマンドから説明し、最後に絵でまとめを説明します。 add 自分の作業ディレクトリからステージング環境へ追加することです。 //今の作業ディレクトリ以下全ての変更を追加する $ git add . //指定したファイルだけ追加する $ git sample.txt commit ステージング環境からローカルリポジトリへ追加することです。 $ git commit -m "○○○の変更" push ローカルリポジトリからリモートリポジトリへ追加することです。 $ git push origin <リモートリポジトリ名> 最後に絵で流れを説明します。 forkとclone こちらも先に説明をして最後に絵で説明します。 fork AさんのGitHub上のリモートリポジトリをBさんのリモートリポジトリにコピーすることです。 コピーすることでAさんのリポジトリには影響を与えず色々試せるということです。 forkは以下のようにGitHub上で行うことができます。 clone AさんのリモートリポジトリからBさんのローカルリポジトリにダウンロードすることです。 もしくはBさんのリモートリポジトリからBさんのローカルリポジトリにダウンロードすることです。 cloneは以下のようにGitHub上で行うかコマンドで行うことができます。 コマンドの場合は上記のURLをコピーし以下のコマンドを入力します。 $ git clone <URL> 以下がforkとcloneを絵で説明したものです。 branch(ブランチ) これは図で説明するのが分かりやすいですかね。 1つのリポジトリから派生して作業することで、複数人で作業することができたり、元のリポジトリに影響を与えずにコードの変更ができたりします。 ブランチを作成することをブランチを切ると言います。 なんかこう、パラレルワールド的な感じですよね。並行世界がある感じ。 ブランチの切り方はプロジェクトによって様々だと思いますが、GitFlowとかを見るとmain(本番環境用)からdevelopブランチ(開発)を切り、そこからさらに細かくブランチを切っていくというのが多いみたいです。 ブランチを切る際のコマンドは以下です。 //以下のコマンドで今いるブランチを確認 $ git branch 例： *develop *<-このマークが今いるブランチを表す //以下のコマンドで今いるブランチから新しくブランチを切る $ git checkout -b sample1 ->sample1というdevelopから派生したブランチを切ることができた pullrequest(プルリクエスト)とmerge(マージ) 例えばBさんがfeatureブランチで作業していて「変更したよ」とpushします。 それをdevelopブランチに合体させてもいいかを「確認して欲しいよー」とリクエストするのがpullrequest(プルリクエスト)で、OKが出て合体することをmerge(マージ)と言います。 以下が説明の図です。 説明① 説明② pullとfetchとmerge pullはfetchとmergeを組み合わせたものなのですが、わかりにくいので図で説明します。 先にどういう時に使うかを説明します。 例えば、AさんとBさんがいてそれぞれ同じリモートリポジトリからcloneしています。 Aさんがローカルで作業をしリモートリポジトリに反映させたものを、Bさんのローカルにも反映させたいという時にpullを使います。 コマンドは以下です。 //pull $ git pull //fetch $ git fetch //merge $ git merge ここで私のつまづいたポイントであるリモート追跡ブランチというものが出てきます。 リモートブランチはリモートリポジトリの中にあるもの。 ローカルブランチはローカルリポジトリに中にあるもので、普段pushするところ。 リモート追跡ブランチはローカルリポジトリに中にあり、リモートリポジトリをローカルにコピーしただけの読み取り専用のもの。 言葉だと分かりにくいので図にします。 今回は以上です。 次はrevert(リバート)やrebase(リベース)などまとめようと思います！