GitHub CLI の gh pr create を使って、ターミナルからプルリクをさっと開いて効率アップした話です? 今回使用するのは、hubではなく、GitHubの公式ツールとなっている gh - The GitHub CLI toolです。今のところ(2020/02/26現在)まだ Beta版となっていますが、少しずつ使っていこうと思います。 インストール お馴染みの brew で簡単インストールです ? console $ brew install github/gh/gh 試す これまでは feature ブランチにて git add と git commit を済ませたら、該当のリポジトリをブラウザのタブから探したりしてプルリクを作っていましたが、プルリクを作るまでをターミナルでやっちゃいます。 console $ gh pr create -w これで、git add 、git commit の流れでぱっとブラウザ上にプルリクエストが作成されたものが立ち上がります?✨ エイリアスにして更に時短 試してみて感動しましたが、このコマンド自体を忘れてしまうのでまた調べてたら意味がない...ということで、エイリアスにします。 bash なら .bash_profile などに追加してみて下さい！ .bash_profile alias pr="gh pr create -w" これで、prと打つだけでプルリクが開いてくれるので快適になりました? オマケ: bash_profile の簡単な書き方 私は以前、.bash_profileの開き方すら分からず、vim での書き方も分からなかったので、私的に一番簡単だと思う方法を載せておきます?♀️ ホームディレクトリで console $ open .bash_profile そんなファイルないよと言われたら作ってあげてから開く console $ touch .bash_profile $ open .bash_profile エイリアスを書いたら、ターミナル再起動か、.bash_profile を読み込んであげる console $ source ~/.bash_profile さっとプルリク、楽ちんなのでみんなも是非してみて下さい✌️
GitHub CLI の gh pr create を使って、ターミナルからプルリクをさっと開いて効率アップした話です?
今回使用するのは、hubではなく、GitHubの公式ツールとなっている gh - The GitHub CLI toolです。今のところ(2020/02/26現在)まだ Beta版となっていますが、少しずつ使っていこうと思います。
お馴染みの brew で簡単インストールです ?
$ brew install github/gh/gh
これまでは feature ブランチにて git add と git commit を済ませたら、該当のリポジトリをブラウザのタブから探したりしてプルリクを作っていましたが、プルリクを作るまでをターミナルでやっちゃいます。
git add
git commit
$ gh pr create -w
これで、git add 、git commit の流れでぱっとブラウザ上にプルリクエストが作成されたものが立ち上がります?✨
試してみて感動しましたが、このコマンド自体を忘れてしまうのでまた調べてたら意味がない...ということで、エイリアスにします。 bash なら .bash_profile などに追加してみて下さい！
.bash_profile
alias pr="gh pr create -w"
これで、prと打つだけでプルリクが開いてくれるので快適になりました?
pr
私は以前、.bash_profileの開き方すら分からず、vim での書き方も分からなかったので、私的に一番簡単だと思う方法を載せておきます?♀️
ホームディレクトリで
$ open .bash_profile
そんなファイルないよと言われたら作ってあげてから開く
$ touch .bash_profile $ open .bash_profile
エイリアスを書いたら、ターミナル再起動か、.bash_profile を読み込んであげる
$ source ~/.bash_profile
さっとプルリク、楽ちんなのでみんなも是非してみて下さい✌️
はじめに TECH::EXPERTというプログラミング教室に通っている添野と申します。 この記事は「GitやGitHubがよく分からん」というひと向けの記事です。 Gitとは 「ギット」です。私はずっと「ジット」と読んでいましたが、ギットです。 Gitの学習は大切です。なぜ大切かというと、 勉強しないとチーム開発の際に他メンバーに確実に迷惑をかけまくるからです。 つまり、人間関係がギットギトになります。ギットだけに・・・w 茶番はさておき、本題です。 プログラミングはポケモン 皆さん、ポケモンはやったことあるでしょうか。 やったことない方向けに簡単に説明すると、ポケモンという可愛い動物を捕まえて育てるゲームです。 育てる方法は結構残酷で、野生のポケモンや他人のポケモンをボコボコにして経験を積みます。 我々が今学んでいる「プログラミング」もポケモンの育成に近いところがあります。 rails newで捕まえたポケモンに愛情を注ぎながらdef indexなどの技を覚えさせるわけです。 ポケモンと違うのは、トレーナーである私たちがボコボコにされる点です。 Gitは「ポケモン預け屋」 ポケモンの世界には「預け屋」というお店があり、預けたポケモンを適当に育ててくれます。 Gitはプログラミングにおける「預け屋」です。 そして、ポケモンの「預け家」との最大の違いは預けたポケモンを育てるのが別の人間である点です。 なぜGitを使うの？ 育成が楽になるからです。ピカチュウの育成は超大変です。 レベル999までレベルアップ可能なピカチュウをレベル130にするのがプログラミングです。 そして、レベル130になったピカチュウをお客さんに提出したら 「あと1日で70レベ上げて」みたいなことを言われます。 これを楽にするために下記のように分業したとします。 ・Aさん ピカチュウの毛並みを整える 「フロントエンド」 ・Bさん １０万ボルトを覚えさせる 「バックエンド」 ・Cさん ボルテッカーを覚えさせる 「バックエンド」 ・Dさん ピカチュウに木の実やタウリンをあげる 「インフラ」 みたいな感じです。 ポケモンのピカチュウは可愛いので、全部やりたいと思うかもですが、 実際には罵詈雑言(エラー)を吐きつけてくるピカチュウを育てます。 分業でも大変 例えば「１０万ボルトを覚えさせる作業」は下記のような手順になります。 ピカチュウに電気を空気中から集める方法を教える ピカチュウに電気を蓄えさせる方法を教える 体に蓄えた電気を体外に放出する方法を教える 体から発した電気を敵に目掛けて放出させる方法を教える しかし、この作業を終えた後に 「体内の電気を増幅させる方法を教える」のを忘れた！これじゃ2ボルトしか打てない！ とかなったとします。 こうなると 「また新しいピカチュウを捕まえる」 「今いるピカチュウにどうにか2ボルトを忘れてもらって10万ボルトを教え直す」 などという非常に面倒な手順を踏まなきゃいけません。 ところがどっこい！ ここでGit様の降臨です。 Gitを使えば、先ほどの1~4の作業の履歴が残ります。つまりセーブデータです。 つまり、3の直前のセーブデータに戻り、電気を増幅させてから、3~4の方法を教え直せます。 そうこうしている間に、残りの育成をAさんたちが同時にやってくれている、みたいな感じです。 みんなの育てたピカチュウを最終的に合体させてつよつよピカチュウを爆誕させます。 ライチュウにはさせない Gitには他にもいいところがいっぱいあります。 例えば、みんなで「強くて可愛いピカチュウ」を作ろうとしていたのに、 突然Dさんが「俺はライチュウがいい」とか言い出して突然ピカチュウを進化させてしまったとします。 dropboxとか他のクラウドサービスではもうライチュウでいくしかないのですが、 Gitなら「セーブデータ」が残っているので、Dさんの暴挙を却下してピカチュウに戻すことができます。 情報分野ではこれが簡単に起きてしまうので、これを防げるのがGitのいいところです。 以上がGitの大まかな説明になります。 これ以降はGitの学習で頻出する概念を説明していきます。 GitHub GitとGitHubは違います。 Git →預かり屋の仕組みそのもの GitHub → 預かり屋のWebサービス版 という感じです。GitHub以外にもいろんなサービスがありますが、 預かり屋の仕組みそのものはGitだけです。 GitHub Desktop ターミナルからgit add . git commitみたいな呪文を唱えるやつを、 ボタンをぽちぽちクリックするだけで簡単に使えるようにしたソフトです。 リポジトリ ピカチュウのセーブデータがいっぱい入ってるメモリーカードです。 ローカルリポジトリ 自分のPCに入ってるメモリーカードです。 リモートリポジトリ 自分のPCに入ってなくて外部のサーバーにあるメモリーカードです。 ※サーバー ＝ 画面のない、世界のどっかにある誰かのでかいPC ここにピカチュウをアップロード(コミット・プッシュ)して合体(マージ)させます。 ローカルでライチュウにしちゃっても、ここからまたピカチュウをダウンロードできます。 クローン リモートからピカチュウをダウンロードすることです。 インデックス 自分のピカチュウを一旦置いておく場所です。 git addするとここに置かれます。GitHub Desktopだと変更次第勝手に置かれる。 ここで「ピカチュウでいいよな？」っていう確認をします。 ピカチュウ以外にもルージュラのレベルを上げたなら「ルージュラも置いとくか」ということも可能。 逆に「ルージュラはレベル上げたけどいらね」と思ったら除外することも可能です。 上記をやるメリットは「コミットがゴチャゴチャしなくて済むこと」です。 ピカチュウとルージュラの育成を分けてセーブしておけば、 あとで見たときに「これはピカチュウのセーブデータだな」とひと目で分かります。 コミット インデックスにおいたピカチュウをリポジトリ(メモリーカード)に記録する操作です。 つまりセーブ。ポケモンでいうと「レポート」です。こまめにやりましょう。 適当にやってると、トラブルが起きた時にどのセーブデータかわからなくなったり、 そもそも戻りたいセーブポイントに戻れなくなります。 この作業はローカルで行われます。 コミットメッセージ セーブデータに「これはピカチュウのセーブデータだよ」と書く機能です。 ちゃんと書かないとコミットを細かく分ける意味がなくなります。 プッシュ コミットしたセーブデータをローカルからリモートにアップロードすることです。 やらないとGitを使う意味があまりないので、ちゃんとやりましょう。 ブランチ ピカチュウ本体から育成用のピカチュウの分身Aを作る作業です。 マスターブランチというのがピカチュウ本体で、そこから分身A,B,C...を生成して それぞれ技を教えたり、毛並みを揃えたりする感じです。 プル リモートからローカルにデータをダウンロードすることです。 他の作業者がピカチュウをアップロードした時とか、自分でマージした後に必ずやります。 マージ ピカチュウ本体にピカチュウの分身を融合させる作業です。 ピカチュウの分身Aから作ったピカチュウの分身Bを、ピカチュウの分身Aに融合させるのもこれです。 プルリクエスト マージする前に「このピカチュウでいいよな？」と他の人に確認してもらいたい時に、 確認してもらったりコメントをもらえる機能です。 LGTM プルリクエストで「そのピカチュウ最高じゃん！合体させてオッケー！」って承認するコメントです。 Looks good to meの略らしい。 デプロイ ピカチュウをモンスターボールから出してバトルの舞台に置くこと。 「いけっ！ピカチュウ！」 コンクリフト AさんとBさんが二人ともピカチュウの分身Aを育ててしまった状態。 Aさんはすでにピカチュウ本体に合体させてしまっており、Bさんの育成した分どうしようっていう状態。 .gitignore ピカチュウをGitの束縛から開放するために、開放先を指定するためのファイル。 /log/* .gitignoreに書ける呪文の一種。 ここに「ピカチュウ 俺のとなり」って書くとマサラタウンのサトシになる。 まとめ 以上がGitについての説明になります。 結論を1行で書くなら「Gitを使うとプログラミングが圧倒的に楽になる」です。 はじめは難解に感じてメリットをあまり感じないかもですが、大規模な設計になるほど必要になるので、 必ず使いこなしていきましょう。くれぐれも、ピカチュウをライチュウにしないように。 他にもプログラミング学習の役に立つ記事を書いていますので、是非ご活用ください。 おすすめ記事 【Rails男子必見】エラー系女子との会話が弾む3つのテクニック【モテたい】 Railsは"5つの属性"を意識しろ それでは。 添野又吉(@enjoy_omame) https://twitter.com/enjoy_omame
TECH::EXPERTというプログラミング教室に通っている添野と申します。 この記事は「GitやGitHubがよく分からん」というひと向けの記事です。
「ギット」です。私はずっと「ジット」と読んでいましたが、ギットです。
Gitの学習は大切です。なぜ大切かというと、 勉強しないとチーム開発の際に他メンバーに確実に迷惑をかけまくるからです。 つまり、人間関係がギットギトになります。ギットだけに・・・w
茶番はさておき、本題です。
皆さん、ポケモンはやったことあるでしょうか。 やったことない方向けに簡単に説明すると、ポケモンという可愛い動物を捕まえて育てるゲームです。 育てる方法は結構残酷で、野生のポケモンや他人のポケモンをボコボコにして経験を積みます。
我々が今学んでいる「プログラミング」もポケモンの育成に近いところがあります。 rails newで捕まえたポケモンに愛情を注ぎながらdef indexなどの技を覚えさせるわけです。 ポケモンと違うのは、トレーナーである私たちがボコボコにされる点です。
rails new
def index
ポケモンの世界には「預け屋」というお店があり、預けたポケモンを適当に育ててくれます。 Gitはプログラミングにおける「預け屋」です。
そして、ポケモンの「預け家」との最大の違いは預けたポケモンを育てるのが別の人間である点です。
育成が楽になるからです。ピカチュウの育成は超大変です。
レベル999までレベルアップ可能なピカチュウをレベル130にするのがプログラミングです。 そして、レベル130になったピカチュウをお客さんに提出したら 「あと1日で70レベ上げて」みたいなことを言われます。
これを楽にするために下記のように分業したとします。
・Aさん ピカチュウの毛並みを整える 「フロントエンド」 ・Bさん １０万ボルトを覚えさせる 「バックエンド」 ・Cさん ボルテッカーを覚えさせる 「バックエンド」 ・Dさん ピカチュウに木の実やタウリンをあげる 「インフラ」
みたいな感じです。
ポケモンのピカチュウは可愛いので、全部やりたいと思うかもですが、 実際には罵詈雑言(エラー)を吐きつけてくるピカチュウを育てます。
例えば「１０万ボルトを覚えさせる作業」は下記のような手順になります。
しかし、この作業を終えた後に 「体内の電気を増幅させる方法を教える」のを忘れた！これじゃ2ボルトしか打てない！ とかなったとします。
こうなると 「また新しいピカチュウを捕まえる」 「今いるピカチュウにどうにか2ボルトを忘れてもらって10万ボルトを教え直す」 などという非常に面倒な手順を踏まなきゃいけません。
ここでGit様の降臨です。 Gitを使えば、先ほどの1~4の作業の履歴が残ります。つまりセーブデータです。 つまり、3の直前のセーブデータに戻り、電気を増幅させてから、3~4の方法を教え直せます。
そうこうしている間に、残りの育成をAさんたちが同時にやってくれている、みたいな感じです。 みんなの育てたピカチュウを最終的に合体させてつよつよピカチュウを爆誕させます。
Gitには他にもいいところがいっぱいあります。
例えば、みんなで「強くて可愛いピカチュウ」を作ろうとしていたのに、 突然Dさんが「俺はライチュウがいい」とか言い出して突然ピカチュウを進化させてしまったとします。
dropboxとか他のクラウドサービスではもうライチュウでいくしかないのですが、 Gitなら「セーブデータ」が残っているので、Dさんの暴挙を却下してピカチュウに戻すことができます。
情報分野ではこれが簡単に起きてしまうので、これを防げるのがGitのいいところです。 以上がGitの大まかな説明になります。 これ以降はGitの学習で頻出する概念を説明していきます。
GitとGitHubは違います。
Git →預かり屋の仕組みそのもの GitHub → 預かり屋のWebサービス版
という感じです。GitHub以外にもいろんなサービスがありますが、 預かり屋の仕組みそのものはGitだけです。
ターミナルからgit add . git commitみたいな呪文を唱えるやつを、 ボタンをぽちぽちクリックするだけで簡単に使えるようにしたソフトです。
git add .
ピカチュウのセーブデータがいっぱい入ってるメモリーカードです。
自分のPCに入ってるメモリーカードです。
自分のPCに入ってなくて外部のサーバーにあるメモリーカードです。 ※サーバー ＝ 画面のない、世界のどっかにある誰かのでかいPC
ここにピカチュウをアップロード(コミット・プッシュ)して合体(マージ)させます。 ローカルでライチュウにしちゃっても、ここからまたピカチュウをダウンロードできます。
リモートからピカチュウをダウンロードすることです。
自分のピカチュウを一旦置いておく場所です。 git addするとここに置かれます。GitHub Desktopだと変更次第勝手に置かれる。
ここで「ピカチュウでいいよな？」っていう確認をします。
ピカチュウ以外にもルージュラのレベルを上げたなら「ルージュラも置いとくか」ということも可能。 逆に「ルージュラはレベル上げたけどいらね」と思ったら除外することも可能です。
上記をやるメリットは「コミットがゴチャゴチャしなくて済むこと」です。 ピカチュウとルージュラの育成を分けてセーブしておけば、 あとで見たときに「これはピカチュウのセーブデータだな」とひと目で分かります。
インデックスにおいたピカチュウをリポジトリ(メモリーカード)に記録する操作です。 つまりセーブ。ポケモンでいうと「レポート」です。こまめにやりましょう。
適当にやってると、トラブルが起きた時にどのセーブデータかわからなくなったり、 そもそも戻りたいセーブポイントに戻れなくなります。
この作業はローカルで行われます。
セーブデータに「これはピカチュウのセーブデータだよ」と書く機能です。 ちゃんと書かないとコミットを細かく分ける意味がなくなります。
コミットしたセーブデータをローカルからリモートにアップロードすることです。 やらないとGitを使う意味があまりないので、ちゃんとやりましょう。
ピカチュウ本体から育成用のピカチュウの分身Aを作る作業です。 マスターブランチというのがピカチュウ本体で、そこから分身A,B,C...を生成して それぞれ技を教えたり、毛並みを揃えたりする感じです。
リモートからローカルにデータをダウンロードすることです。 他の作業者がピカチュウをアップロードした時とか、自分でマージした後に必ずやります。
ピカチュウ本体にピカチュウの分身を融合させる作業です。 ピカチュウの分身Aから作ったピカチュウの分身Bを、ピカチュウの分身Aに融合させるのもこれです。
マージする前に「このピカチュウでいいよな？」と他の人に確認してもらいたい時に、 確認してもらったりコメントをもらえる機能です。
プルリクエストで「そのピカチュウ最高じゃん！合体させてオッケー！」って承認するコメントです。 Looks good to meの略らしい。
ピカチュウをモンスターボールから出してバトルの舞台に置くこと。 「いけっ！ピカチュウ！」
AさんとBさんが二人ともピカチュウの分身Aを育ててしまった状態。 Aさんはすでにピカチュウ本体に合体させてしまっており、Bさんの育成した分どうしようっていう状態。
ピカチュウをGitの束縛から開放するために、開放先を指定するためのファイル。
.gitignoreに書ける呪文の一種。 ここに「ピカチュウ 俺のとなり」って書くとマサラタウンのサトシになる。
以上がGitについての説明になります。
結論を1行で書くなら「Gitを使うとプログラミングが圧倒的に楽になる」です。 はじめは難解に感じてメリットをあまり感じないかもですが、大規模な設計になるほど必要になるので、 必ず使いこなしていきましょう。くれぐれも、ピカチュウをライチュウにしないように。
他にもプログラミング学習の役に立つ記事を書いていますので、是非ご活用ください。
おすすめ記事
【Rails男子必見】エラー系女子との会話が弾む3つのテクニック【モテたい】 Railsは"5つの属性"を意識しろ
それでは。
添野又吉(@enjoy_omame) https://twitter.com/enjoy_omame
目次 今回の確認内容 ブランチを作ってチェックアウトします。 git branch 以下のコマンドを実行し、最新のコミットからブランチを作ります。 $ git branch * master $ git branch bra20200226 $ git branch bra20200226 * master チェックアウトはしていないので、まだMasterを参照しています。このときに.git配下がどのように変わったかを見てみます。 $ tree -a ├── .git │ ├── logs │ │ ├── HEAD │ │ └── refs │ │ └── heads │ │ ├── bra20200226 │ └── refs │ ├── heads │ │ ├── bra20200226 logsとrefs配下にブランチが作られました。作られたファイルの中身を見てみると、以下のように最新のコミットから作られたことがわかります。 $ cat .git/logs/refs/heads/bra20200226 0000000000000000000000000000000000000000 2deb1b0751cbfeffdc75683b2f61e476ef970640 Chapa <hoge@hoge.com> 1582664128 +0900 branch: Created from master $ cat .git/refs/heads/bra20200226 2deb1b0751cbfeffdc75683b2f61e476ef970640 $ git cat-file -p 2deb1b0751cbfeffdc75683b2f61e476ef970640 tree e6c5d9e73c33771f1878aa6edc1a5df1939e6351 parent 17e88b45fdb1b3e8831df0c209204f290d6ca614 author Chapa <hoge@hoge.com> 1581171878 +0900 committer Chapa <hoge@hoge.com> 1581171878 +0900 2nd commit. add and modify git checkout では、チェックアウトして、.git配下がどのように変わったかを見てみます。 $ git checkout bra20200226 Switched to branch 'bra20200226' $ git branch * bra20200226 master ├── .git │ ├── HEAD │ ├── index │ ├── logs │ │ ├── HEAD それぞれの中身を見ると以下のようになっています。 $ cat .git/HEAD ref: refs/heads/bra20200226 $ cat .git/refs/heads/bra20200226 2deb1b0751cbfeffdc75683b2f61e476ef970640 $ cat .git/logs/HEAD 0000000000000000000000000000000000000000 17e88b45fdb1b3e8831df0c209204f290d6ca614 Chapa <hoge@hoge.com> 1580696403 +0900 commit (initial): first commit 17e88b45fdb1b3e8831df0c209204f290d6ca614 2deb1b0751cbfeffdc75683b2f61e476ef970640 Chapa <hoge@hoge.com> 1581171878 +0900 commit: 2nd commit. add and modify 2deb1b0751cbfeffdc75683b2f61e476ef970640 2deb1b0751cbfeffdc75683b2f61e476ef970640 Chapa <hoge@hoge.com> 1582664726 +0900 checkout: moving from master to bra20200226 HEADの参照ブランチが変わりました。参照ディレクトリを見るとどのコミットを参照しているかがわかります。 今回のおさらい ブランチを作るとオブジェクトとして何かが作られるわけではなく、参照ディレクトリ配下にファイルが作られていきました。チェックアウトすることでHEADの参照先が変わることも確認できました。 次回はブランチでコミットを進めたときにどのように変化していくかを追っていきたいと思います。
ブランチを作ってチェックアウトします。
以下のコマンドを実行し、最新のコミットからブランチを作ります。
$ git branch * master $ git branch bra20200226 $ git branch bra20200226 * master
チェックアウトはしていないので、まだMasterを参照しています。このときに.git配下がどのように変わったかを見てみます。
$ tree -a ├── .git │ ├── logs │ │ ├── HEAD │ │ └── refs │ │ └── heads │ │ ├── bra20200226 │ └── refs │ ├── heads │ │ ├── bra20200226
logsとrefs配下にブランチが作られました。作られたファイルの中身を見てみると、以下のように最新のコミットから作られたことがわかります。
$ cat .git/logs/refs/heads/bra20200226 0000000000000000000000000000000000000000 2deb1b0751cbfeffdc75683b2f61e476ef970640 Chapa <hoge@hoge.com> 1582664128 +0900 branch: Created from master $ cat .git/refs/heads/bra20200226 2deb1b0751cbfeffdc75683b2f61e476ef970640 $ git cat-file -p 2deb1b0751cbfeffdc75683b2f61e476ef970640 tree e6c5d9e73c33771f1878aa6edc1a5df1939e6351 parent 17e88b45fdb1b3e8831df0c209204f290d6ca614 author Chapa <hoge@hoge.com> 1581171878 +0900 committer Chapa <hoge@hoge.com> 1581171878 +0900 2nd commit. add and modify
では、チェックアウトして、.git配下がどのように変わったかを見てみます。
$ git checkout bra20200226 Switched to branch 'bra20200226' $ git branch * bra20200226 master
├── .git │ ├── HEAD │ ├── index │ ├── logs │ │ ├── HEAD
それぞれの中身を見ると以下のようになっています。
$ cat .git/HEAD ref: refs/heads/bra20200226 $ cat .git/refs/heads/bra20200226 2deb1b0751cbfeffdc75683b2f61e476ef970640 $ cat .git/logs/HEAD 0000000000000000000000000000000000000000 17e88b45fdb1b3e8831df0c209204f290d6ca614 Chapa <hoge@hoge.com> 1580696403 +0900 commit (initial): first commit 17e88b45fdb1b3e8831df0c209204f290d6ca614 2deb1b0751cbfeffdc75683b2f61e476ef970640 Chapa <hoge@hoge.com> 1581171878 +0900 commit: 2nd commit. add and modify 2deb1b0751cbfeffdc75683b2f61e476ef970640 2deb1b0751cbfeffdc75683b2f61e476ef970640 Chapa <hoge@hoge.com> 1582664726 +0900 checkout: moving from master to bra20200226
HEADの参照ブランチが変わりました。参照ディレクトリを見るとどのコミットを参照しているかがわかります。
ブランチを作るとオブジェクトとして何かが作られるわけではなく、参照ディレクトリ配下にファイルが作られていきました。チェックアウトすることでHEADの参照先が変わることも確認できました。
次回はブランチでコミットを進めたときにどのように変化していくかを追っていきたいと思います。
https://yu8mada.com/2018/06/07/how-to-use-git-s-pull-command/#content-1-1
参考のoption3。 参考
gitのコマンドですぐ忘れてしまう、でも使いたくなるコマンドをまとめました。 マージ済みローカルブランチの一括削除 既にmaster/developにマージされているローカルブランチを一括で削除するコマンド $ git branch --merged|egrep -v '\*|develop|master'|xargs git branch -d 消したリモートブランチを完全に消す リモート上で消したはずが、fetchしてもローカルに残っているブランチを完全に消すコマンド $ git fetch --prune 直前のコミットを無かったことにする 直前のコミットの歴史を完全に消す $ git reset --hard HEAD^ 特定のコミットまでの歴史を完全に消す $ git reset --hard {コミットID} コミットの内容を打ち消す 直前のコミットの内容を、相殺するコミットをする $ git revert HEAD 特定のコミットの内容を、相殺するコミットをする $ git revert {コミットID} 強制的にpushする ローカルの変更をリモートのブランチに強制的にプッシュさせる $ git push -f origin {ブランチ名} 参考文献 この記事は以下の情報を参考にして執筆しました。 Gitでマージ済みブランチを一括削除
gitのコマンドですぐ忘れてしまう、でも使いたくなるコマンドをまとめました。
既にmaster/developにマージされているローカルブランチを一括で削除するコマンド
$ git branch --merged|egrep -v '\*|develop|master'|xargs git branch -d
リモート上で消したはずが、fetchしてもローカルに残っているブランチを完全に消すコマンド
$ git fetch --prune
直前のコミットの歴史を完全に消す
$ git reset --hard HEAD^
特定のコミットまでの歴史を完全に消す
$ git reset --hard {コミットID}
直前のコミットの内容を、相殺するコミットをする
$ git revert HEAD
特定のコミットの内容を、相殺するコミットをする
$ git revert {コミットID}
ローカルの変更をリモートのブランチに強制的にプッシュさせる
$ git push -f origin {ブランチ名}
この記事は以下の情報を参考にして執筆しました。
