目的 HEADからのコミットの個数を指定して複数のコミットを一つにまとめる方法を記載する 方法 下記コマンドを実行する。 $ git rebase -i HEAD~HEADからのまとめるコミット数 エディタが開いたらまとめ元になりたいコミットを「pick」、「pick」コミットにまとめられたいコミットを「squash」と記載する。 具体例 $ git logコマンドを実行したときに下記の出力がなされている時のHEADのコミットとその一つ前のコミットをまとめる方法を下記に記載する。コミットIDが「70044e」のコミットをまとめ元とし、コミットIDが「b0bc13」のコミットをまとめたい。 [21:33:48]MacBook-Pro~/test/git_test$ git log commit b0bc1348910b0c4b9994c83466ab7288746d4414 (HEAD -> master) Author: 大川峻 <okawashun@MacBook-Pro.local> Date: Wed May 5 21:14:15 2021 +0900 テスト記載 1を追記 commit 70044e6aa0856b3eca659e381c40a434668f8582 Author: 大川峻 <okawashun@MacBook-Pro.local> Date: Wed May 5 21:13:03 2021 +0900 テスト用ファイルを追加 commit bfac6cdc0e30e4c4badb9830d4644518d0d0406a Author: 大川峻 <okawashun@MacBook-Pro.local> Date: Wed May 5 21:12:49 2021 +0900 first commit 当該リポジトリで下記コマンドを実行する。 $ git rebase -i HEAD~2 開いたエディタで下記のように記載する。 一つ前のエディタで保存すると下記のエディタが開く。特に編集などせずに保存する。 $ git logを実行したところ下記のように表示され無事にコミットがまとめられた。（まとめたコミットのコミットの時間はまとめ元のコミット時間が適応されるようだ） [21:33:48]MacBook-Pro~/test/git_test$ git log commit 0b334d2c1ca24e1a2af3484b15a32f0c37d8f547 (HEAD -> master) Author: 大川峻 <okawashun@MacBook-Pro.local> Date: Wed May 5 21:13:03 2021 +0900 テスト用ファイルを追加 テスト記載 1を追記 commit bfac6cdc0e30e4c4badb9830d4644518d0d0406a Author: 大川峻 <okawashun@MacBook-Pro.local> Date: Wed May 5 21:12:49 2021 +0900 first commit

could not lock config file C:/home/.gitconfig: No such file or directoryが出てPlease tell me who you areが解決できない事態に陥りました。 結果、HOMEの環境変数が.gitconfigがあるディレクトリになっていなかったので変更すると解決しました。 今までこんなことせずとも良かったのでよくわからないエラーでした。

目次 ・Git ・VSCode ・Ruby ・Node.js ・yarn ・Rails ・確認 Git こちらからダウンロード後、インストール。 セットアップでは何言ってるのかわからないのでそのままスキップを押しまくる。 終了後、Git Bashでユーザー名とEメールを登録する。 $ git config --global user.name "【ユーザー名】" $ git config --global user.email 【メールアドレス】 VSCode こちらからダウンロード。 インストールの際にVSCodeで開くやVSCodeを登録するにチェックを入れておくと後々便利。 完了したら設定をMSアカウントかGithubアカウントで紐付けておくと次からのインストールが楽になる。 Ruby こちらからWITH DEVKITの最新をダウンロード、インストール。 コマンドプロンプトが開いたらとりあえず1,2,3と入力しEnter。 Node.js こちらから適当にインストール。 yarn コマンドプロンプトで npm install --global yarn rails gem install rails でインストール。 確認 ターミナルで適当な場所に移動し、 rails new test_app を実行。完了後に cd test_app rails s を実行してブラウザで確認する。

前書き 誤ったメールアドレス情報でコミットしてリモートにプッシュまでしちゃった時があり、 その時の対処法の備忘録。 目的 git log及びSource Tree上に、 誤ったAuthor&Comitter情報が表示されないようにする。 やり方 色々調べて試したところ、以下の２パターンが（比較的）安全（そう） ① git rebaseを使う ② git replaceを使う ①だとmarge時のコミットバージョンは変更できないので、基本②が良いかも。 ※git logでもmerge時のコミットは確認できないが、Source Treeには表示される。。 ②は1個1個の作業負担が大きい（その分慎重かつ安全と言えるが） どちらにも言えるが、 修正対象は勿論それ以外のコミットハッシュ値も変わる可能性があるので、 リモートにも反映させたい場合は注意。 前提 gitのコミット情報を修正する $ git config --local user.name 履歴に残したい名前 $ git config --local user.email 履歴に残したいメールアドレス 修正確認はgit config --local --list 後述するgit commit --amendに--author <履歴に残したい情報>オプションをつけて個別に修正するやり方もあるが、 今回は一貫した修正をしたいので割愛。 ① git rebaseを使う 1. git rebase -i <修正したいcommitの1個前のハッシュ値> 2. git commit --amend --reset-author 3. git rebase --continue # 修正対象のコミットに到達するまで2と3を繰り返す。 # 以下オリジンにも反映したい場合。 4. git push origin <反映したいブランチ> -f 補足： 1. エディタが開かれるので、修正したいコミットのステータスをeditに変えて保存する。 2. --reset-authorで設定してあるコミット情報にauthor&comitterをまとめて反映してくれる。実行前にコミット情報が修正済みであることを確認すること。 3. 次のコミットに照準を向ける? 4. -fで強制的にプッシュする。かなり危険だからチームのブランチなら周知してからやろう。 ② git replaceを使う 1. git checkout <修正対象のcommitハッシュ値> 2. git commit --amend --reset-author # この時の、HEAD（修正後のcommitになるはず）のハッシュ値をメモ 3. 元のブランチをチェックアウト 4. git replace <修正対象のcommitハッシュ値> <修正後のハッシュ値> # 修正したいcommitの分だけ1-4を繰り返す 5. git filter-branch -- --all 6. git replace -d <（修正前の）修正対象のcommitハッシュ値> # 以下オリジンにも反映したい場合。 7. git push origin <反映したいブランチ> -f 補足： 1. この時点で修正対象のcommitがHEADになる。 2. ①と同じ 3. 実行すると修正後のハッシュ値が確認できなくなるので、事前にメモを取ること。 4. 対象のcommitを別のコミットで置換するコマンド。 5. 全コミットの書き換え。（危険、見た目上は特に変化はないが） 6. 修正前のバージョンが（目に見えないが）残ったままなので削除する。 7. ①と同じ。 後書き 基本的に他の方々の記事を凝縮させてもらっただけですので、不明点があれば参考サイトも見てみてください。 もっと簡単に変えられるようになれば良いなあ（セキュリティ甘くなりそうだけど） 参考 https://www.it-swarm-ja.com/ja/git/%e7%89%b9%e5%ae%9a%e3%81%ae%e3%82%b3%e3%83%9f%e3%83%83%e3%83%88%e3%81%ae%e3%81%9f%e3%82%81%e3%81%ab%e3%82%b3%e3%83%9f%e3%83%83%e3%83%88%e4%bd%9c%e6%88%90%e8%80%85%e3%82%92%e5%a4%89%e6%9b%b4%e3%81%99%e3%82%8b%e3%81%ab%e3%81%af%e3%81%a9%e3%81%86%e3%81%99%e3%82%8c%e3%81%b0%e3%81%84%e3%81%84%e3%81%a7%e3%81%99%e3%81%8b%ef%bc%9f/969793577/ https://qiita.com/reikkk/items/aaff2b6656467de14a5e

こんにちは。 恥ずかしい話、 "git push origin master" というコマンドは魔法のように今まで使っていました・・・。 最終的には上記のコマンドの意味合いを着地点として、Gitの使い方をさっと見ていく場とする。 Gitは何のために存在するか？ 結論からGitの役割を言うと、ファイルの変更履歴を保存し、管理するためのツールである。 プログラムを作成する上で、私たちはファイルの中身を常に更新（削除も含む）を行なっていく。その中では、間違った更新や挑戦的な更新も含まれている。また急なトラブルによりファイルが壊れたり、ファイル自体が消えてしまうこともあるだろう。こんなことが起きてしまったときに、人間がタイムマシーンで時間を遡れればいいのであるが、現実的ではない。そんなときに便利となるのが、「バックアップ」である。 バックアップを取るのはGit以外でももちろん可能である。 例えば、Linuxを勉強した者にとっては"cp"コマンドを使ってバックアップを取ればいいのではと思うだろう。 しかし、cpコマンドでは保存はできるが、管理には向いていない。 $ ls aaa.txt backup02.txt backup04.txt backup06.txt backup08.txt backup01.txt backup03.txt backup05.txt backup07.txt backup09.txt 仮にcpコマンドでバックアップを取ろうと思ったら、上記のようにファイルでいっぱいになり、どれがどれかわからなくなるであろう。これを解決する一つの手段がGitである。 Gitの役割を理解したところで、これからGitの仕組みと使い方を見ていく。 Gitのインストール $ git --version git version 2.29.1 上記のように動けばすでにインストール済みである。 もしインストールされていなければ、CentOSnの場合はyumで、Ubuntuの場合はapt-getで"git-core"をインストールしよう。 Gitの基本的な使い方 Gitの初期化 これから下記のようなファイル構造を考える。 今回は簡単のためにfirst_projectの中にsay_hello.shというシェルスクリプトを作成・修正する履歴をGitで管理する状況を考える。 Gitを使うためには、"リポジトリ"と呼ばれる、Gitがファイルの履歴を保存する場所を生成します。 そのためには、first_project下で下記のコマンドを打ちます。 $ git init これにより、".git"と呼ばれるディレクトリが作成されます。（ls -a で確認できる。) これがGitのリポジトリの実体であり、この中にファイルの履歴が保存されていきます。つまり、このファイルがGitにおいてとても大切になっているので、このファイルのバックアップを取っておく必要があります。（後ほど方法は記載します。） .gitの中のファイルは特別な形式に変換されているので直接編集することはできません。そのファイルを編集するためには、リポジトリの内容を通常ファイルとして復元する必要がある。このリポジトリの内容をファイルとして展開する場所をワークツリーと呼ぶ。 上記では リポジトリ： /home/git/first_project/.git/ ワークツリー : /home/git/first_project/ リポジトリへファイルを追加 git add <ファイル名> 上記のコマンドによりリポジトリにファイルを追加することができます。 まず、ファイルを追加するためにsay_hello.shというシェルスクリプトを作成します。 $ vim say_hello.sh ........編集........ $ chmod 744 say_hello.sh chmodはsay_hello.shを実行可能にするために使っている。 このファイルは下記であるとする。 say_hello.sh #!/bin/bash echo "Hello!" 今のファイル構造は下記である。 ここで注意したいのが、ワークツリーにファイルは作られたが、リポジトリには反映されていない。 よって次の作業はリポジトリに今作ったファイルを取り込むことである。 Gitのリポジトリに履歴として追加するためには git add git commit を使う。 この２種類のコマンドを理解するためには、「インデックス」というものを理解する必要がある。 説明のため、次の小節ではsay_hello.shの他に、explain.txtというファイルがあると仮定する。 インデックスとは インデックスとはワークツリーとリポジトリの間にある空間である。 下記の図と睨めっこをしてほしい。 インデックスは単なる空間であるが、インデックスの役割はかなり大きい。 それは、リポジトリにそれぞれのファイルごとに追加することができることである。 詳しくは後ほど述べるが、リポジトリに追加する前には、何を変更したのかをコメントする機能がついている。 もし仮に、インデックスが無く、一度に全てのファイルを追加しなければならなければ、コメントが綺麗にならず、見返すときに苦労する。 上記の図の ①が git add に対応し、 ②が git commit に対応する。 つまり、 git add <ファイル名> : 更新されたファイルをインデックスに追加すること git commit : インデックスのファイルをリポジトリに追加すること。 である。 さて、先程コメントの話をしたが、 なぜコメントをつける必要があるのか？ それは、cpの話を思い出してほしいのだが、cpは保存はできるが管理には向いていない。 なぜなら、違うファイルを比べたときに何が変更されたかがファイルの中身を見るまではわからないからである。一方で、コメントがあることで、毎回commitされる度にどんな変更が加えられたかが明らかである。チーム開発では「他人にもわかる状態」というのはかなり大切な部分となる。 さぁ、コメントの付け方を見てゆこう。 git commitにはコメントの付け方が2つ存在する。 オプションをつける。 vimで書く。 １つ目は、 $ git commit -m "コメント" これで、コメントがつけられる。創造であるが、小さな変更、コメントが短い場合はオプションで良いと思われる。 ２つ目は git commitと打つと自動的にvimが開かれる。これは大きな変更、コメントするべきことが多いときに使われると思われる。 ここまでで、リポジトリへの追加方法を見てきた。 この二つさえ知っておけば、リポジトリに履歴を登録はできる。 次のステップは、そのリポジトリの見方である。 git log と　git diff 読者の皆さん、git logと入力してみてほしい。何が表示されるだろうか？ commitという一意的なコミットID、Author、Date、コメントが表示されると思う。 これはいわゆる、いつ誰が何を変更したかを見れる状態になっているものである。コミットIDは更新する前に戻りたいなどと言ったときの指定に使うことができる。 次に git diffであるが、これはワークツリーとインデックスの差分を表す。 これは、コミットする前に何を変更したかを可視化するために用いられる。詳しい内容は、ファイルを変更して、addして、git diffを自分で入力して確かめてほしい。そんなに難しい内容ではないと思われる。 皆さんもご存知の通り、Gitには3つの領域が存在する。それぞれの差分を表示するには下記のコマンドを使う。 git diff : ワークツリーとインデックス git diff --cached : インデックスとリポジトリ git diff HEAD : ワークツリーとリポジトリ 何を変更したかを具体的にみたいときにかなり役立つので覚えておきたい。 ブランチという存在 ブランチは単独開発では使い道をイメージしづらいが、皆さんは一人で自分自身のポートフォリオを作成しているとしよう。大体は作り終わったのだが、ヘッダーをアップデートしたい状況を考える。このとき、皆さんはそのまま作り始めるだろうか？「うん！」と頷く人も多いだろうが、リスクとして、その更新がうまくいかない可能性もある。また、急にフッターを変更する必要があるかもしれない。そんなときにブランチというものがあったら便利である。 ブランチとは枝分かれしたそれぞれの履歴の道筋のことである。履歴を枝分かれできるんだなぁ。と覚えていただけたら良い。 イメージとしては、上のイメージである。 headerブランチで更新した内容はこの後説明するマージをするまではmasterブランチには影響を及ぼさない。つまり、headerブランチで仮にデータが壊れたとしてもmasterブランチには影響ない。上記の図の状態を作るためには下記のように進めていく。 git branch 上記のコマンドで、今存在するブランチと今どのブランチにいるかがわかる。おそらく皆さんは、masterというブランチしか存在せず、横にアスタリスクがあるであろう。アスタリスクが意味するのは自分がいるブランチである。 git branch <ブランチ名> 上記で新しいブランチが生成できる。今回であれば $ git branch header である。これで新しいブランチが作成された。git branchで確認されたい。 git checkout <移動先ブランチ> 上記でブランチを移動できる。今回であれば、 $ git checkout header とかける。これで、もう一度git branchをするとアスタリスクの位置が変わっているのがわかると思う。その後何かファイルを変更して、addとcommitを2度行い、さらにmasterブランチでもファイルを変更してaddとcommitを行うと上の図の状態になる。 git merge <マージするブランチ名> 次にマージする方法を見ていく。マージとは1つのブランチ内容を別のブランチに取り組むことである。 考える状況としては下記である。 今回はheaderブランチをmasterブランチに取り込みたいので、まずmasterブランチに移動して上記のコマンドを入力する。今回であれば $ git merge header である。これを入力すると、commitと同じようにvimが起動し、コメントを求められる。これで、マージが完了する。 $ git branch -d header その後、上記でheaderブランチを削除できる。 今まで見てきたように、ブランチを切り替えることで、互いに依存せず異なる作業を並行して行うことができる。これはチーム開発でも大きく役にたつ。 最後に git push と git remote add の使い方を見ていく。 ここでは、リポジトリのバックアップを作成することを通じて、上記の2つのコマンドを理解を進める。 上記のようなファイル構造を考える。first_project.gitの中にバックアップ用のリポジトリを作成する。 バックアップ用リポジトリの作成 $ cd /home/git/Share/first_project.git $ git --bare init git init に--bareを付けるとバックアップ用リポジトリが作成される。 次にこのリポジトリにバックアップを取りたいリポジトリを送る作業を行う。 変更の履歴を送る 変更の履歴を送るためには、git pushを使う。 文法は、"git push <送信先リポジトリ> <送信元リポジトリ>:<送信先ブランチ>"である。 今回の例で言えば、 $ git push /home/git/Share/first_project.git master:master である。これで、今のリポジトリのバックアップは取れた。もし、/home/git/first_projectのリポジトリが壊れた場合は $ git clone <複製元リポジトリ> で復元することができる。 ここで、楽をしよう。正直毎回、/home/git/Share/first_project.gitと打つのはめんどくさい・・・。 こんなときに remote addを使用する。Linuxコマンドでいうと alias みたいなもので、push先のリポジトリのパスに別名を付けることができる。 $ git remote add origin /home/git/Share/first_project.git と書くと、このパスは"origin"という名前に生まれ変わる。この"origin"という割り当てる名前はなんでも良いが、慣習としてこの名前が使われる。 一度このコマンドを使うと、次からpushする際は $ git push origin master とかけてスッキリするし、よく見慣れているコマンドになる。（本質的理解） ちなみに、master:masterは左と右が同じ場合は単にmasterと省略できる。 私は最後のコマンドを呪文のように覚えていたので、今回改めて本質を見れたところでスッキリしている。 今回は一人でgitを使うことしか想定できていないが、チームで使うとなるともっと大きな恩恵を得られる。 チームでの話はまた後日書くとする。 では。

現在チェックアウトしていないマージ済みのブランチを一括削除します。 通常は master (あるいは main) ブランチをチェックアウトした上で実施すると良いでしょう。 ウェブを検索すると色々やり方が出てきますが、以下が比較的簡単だと思います1。 Bash または Zsh の場合 git branch -d $(git branch --no-contains | xargs) 削除するブランチがないときは以下のメッセージが出ますが無視して下さい。 fatal: branch name required PowerShell の場合 git branch --no-contains | % { git branch -d $_.trim() } 検索しても本稿の方法が出てこないのは --no-contains オプションが用意されたのが比較的最近だからなのかも知れません。 git/2.13.0.txt at v2.13.0 · git/git ↩