※HTML/(S)CSSまでならできるデザイナー向けの内容 Gitとは 「分散型バージョン管理システム」である（ほかに集中型がある） 誰がなんのためにどこを変更したのか確認できる 「複数人で同じソースを修正する時に使うシステム」という理解でOK プロンプト Linuxなどのターミナル上に表示される「$」など、「ここにコマンド打てますよ」のサイン bashではPS1変数に「どう表示させるのか」が格納されていて、自分で変更することができる エンジニアとの会話でよく出てくるから覚えておいた方がいい プロンプトの記号の意味 terminal [NAME +]$ # ステージングされているがコミットが終わっていない [NAME <]$ # リモートの方が歴史が進んでいる [NAME >]$ # ローカルの方が歴史が進んでいる [NAME =]$ # リモートもローカルも同じ進み [NAME %]$ # リモートにないファイルが追加されている [NAME *]$ # リモートにもローカルにもあるファイルの内容が異なる よく使うコマンド 基礎編（「教えられる」レベルにしておくとよい） リモートの変更を落とす terminal $ git fetch プロンプトの記号が<か>になる ↑「手元の状態と比べて進んでるのかどうか」を言ってくる リモートの変更を反映させる terminal $ git pull プロンプトの記号が=になる pullにはfetchが含まれているようだが、私は自分を信じられないのでどっちもやる ブランチを作る terminal $ git checkout -b {ブランチ名} やる前に親ブランチを更新（fetch→pull）しておかないとエンジニアに死ぬ程叱られる 最新Gitではgit switchに修正されているよう ちなみに接頭にハイフンがつくやつは「オプション」と呼ばれている（「bオプションつけて」とか言われる） 保存する修正ファイルを選択する terminal $ git add {ファイルパス} プロンプトの記号が+になる。これを「ステージング」という git add .ですべてのファイルを選択 修正を保存する terminal $ git commit -m '{コミット名}' ブランチをサーバに上げる terminal $ git push -u {ブランチ名} 初めてpushする時は必ず-uをつける。するとプロンプトに例の記号が表示されるようになる。これはローカルとリモートのブランチの紐付けがされたことを示す。一度-uをつけたら、次回から-u {ブランチ名}をつけなくてよい -fで強制的にpush。上書きしてよいかよく確認してから行う 親ブランチに合流する（1） terminal # 親ブランチにcheckout(switch)してから $ git merge {ブランチ名} --no-ffで「マージした」というコミットを残す 自分の修正の後に、親ブランチの修正をくっつける 親ブランチに合流する（2） terminal $ git rebase {親ブランチ} #自分の作業ブランチで 自分の修正の途中に、親ブランチの修正を入れる mergeかrebaseか、合流の仕方はエンジニアの指示に従った方がよい気がする 差分を確認する terminal $ git diff --name-onlyでファイル名だけの一覧 「diffを見てください」とか言う 便利編（「できる」レベルにしておくとよい） 当該ファイルの修正履歴を一覧する terminal $ git log {ファイルパス} -pでどんな変更をしたか表示する コミットを一覧する terminal $ git log --onelineでコミット名だけの一覧 コミットIDを確認できる 当該コミットを当該ブランチにくっつける terminal $ git cherry-pick {コミットID} 「チェリーピクる」とか言う（言わない） コミット名を修正する terminal $ git commit --amend 修正を1つ前のコミットに忍ばせる terminal $ git commit --amend --no-edit 歴史が変わるので、pushしてないかpushしたことがバレてないブランチでのみ行う 当該コミットでどんな変更があったか一覧する terminal $ git show {コミットID} --name--onlyでファイル名だけの一覧を表示する コミットしてないファイル、あるいはゴミ（Untracked file）を消す terminal $ git clean -nで消すファイルを選ぶ -fで強制的に消す 複数のコミットを1つにまとめる terminal $ git rebase -i HEAD~{コミットの個数} $ git rebase -i HEAD~~~~ {コミットの個数}には、「1つ前のコミットから数えた個数」を入れる。2つ目はコミットの数だけ~を書く 履歴がキレイになるから重宝する 参考https://qiita.com/takke/items/3400b55becfd72769214 リモートの内容に書き換える terminal $ git reset --hard origin/{ブランチ名} 「何がなんだかよくわからなくないしもう今までの修正ゴミにしちゃってもいいや」という境地になったらやるやつ （蛇足）ターミナル操作への思い たとえば terminal $ exit ってした時にターミナルが閉じるのを見ると、「GUIでバツボタン押してる裏でこんなことが…」「Exitって言ったら閉じた…えらい…」という感動があるので、マークアップレベルのデザイナーも使うべきだと思っている。世界が変わる。 あと、黒い画面カッコイイ。
※HTML/(S)CSSまでならできるデザイナー向けの内容
[NAME +]$ # ステージングされているがコミットが終わっていない [NAME <]$ # リモートの方が歴史が進んでいる [NAME >]$ # ローカルの方が歴史が進んでいる [NAME =]$ # リモートもローカルも同じ進み [NAME %]$ # リモートにないファイルが追加されている [NAME *]$ # リモートにもローカルにもあるファイルの内容が異なる
$ git fetch
<
>
$ git pull
=
pull
fetch
$ git checkout -b {ブランチ名}
git switch
$ git add {ファイルパス}
+
git add .
$ git commit -m '{コミット名}'
$ git push -u {ブランチ名}
-u
-u {ブランチ名}
-f
# 親ブランチにcheckout(switch)してから $ git merge {ブランチ名}
--no-ff
自分の修正の後に、親ブランチの修正をくっつける
$ git rebase {親ブランチ} #自分の作業ブランチで
自分の修正の途中に、親ブランチの修正を入れる
mergeかrebaseか、合流の仕方はエンジニアの指示に従った方がよい気がする
merge
rebase
$ git diff
--name-only
$ git log {ファイルパス}
-p
$ git log
--oneline
$ git cherry-pick {コミットID}
$ git commit --amend
$ git commit --amend --no-edit
$ git show {コミットID}
--name--only
$ git clean
-n
$ git rebase -i HEAD~{コミットの個数} $ git rebase -i HEAD~~~~
~
$ git reset --hard origin/{ブランチ名}
たとえば
$ exit
ってした時にターミナルが閉じるのを見ると、「GUIでバツボタン押してる裏でこんなことが…」「Exitって言ったら閉じた…えらい…」という感動があるので、マークアップレベルのデザイナーも使うべきだと思っている。世界が変わる。 あと、黒い画面カッコイイ。
TL;DR 存在しないはず（既にマージされたとか削除済み）の、ブランチを削除 なんか、ブランチに残ってて気持ち悪い 対象読者 CircleCI 2.0以上 消したはずのブランチが何故か残っている コマンドで確認しても存在しない git branch --remote # (-r でも可) # origin/issues/#568-spa-container # origin/master # origin/production # origin/staging 削除手順 リモートにもローカルにもないリポジトリなのだし、深く悩まず削除 心当たり 多分、ビルドの途中で消したとか？（記憶にないけど） 削除の手順 もう一度、同じ名前のブランチを作成 CicleCIのjobが走るはずなのでjobをキャンセルする(キャンセルしなくてもいいかもしれない) 対象ブランチを削除 完了 はー すっきり 参考 https://discuss.circleci.com/t/how-can-i-remove-an-old-branch/1323/15
CircleCI 2.0以上
git branch --remote # (-r でも可) # origin/issues/#568-spa-container # origin/master # origin/production # origin/staging
リモートにもローカルにもないリポジトリなのだし、深く悩まず削除
多分、ビルドの途中で消したとか？（記憶にないけど）
はー すっきり
https://discuss.circleci.com/t/how-can-i-remove-an-old-branch/1323/15
・上記のようなエラーが出た場合はターミナルで以下のコマンドを入力すると解決できます。 git commit -n -m 'コメント内容をここに記述'
・上記のようなエラーが出た場合はターミナルで以下のコマンドを入力すると解決できます。
git commit -n -m 'コメント内容をここに記述'
Git 2.23.0で追加されたswitchとrestoreについての個人的なメモ 個人的なメモなので従来のやり方は私が普段使ってたコマンドだし、ここに書いてないことも色々追加されているが使っていないので割愛。 背景: Highlights from Git 2.23 マニュアル: switch, restore マニュアルにはTHIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.と書かれているので、それなりの覚悟で使用してください。 switch 今まではブランチを切り替えるのにはgit checkoutを使用していたが、 git switchでできるようになった。 $ git switch my-feature Switched to branch 'my-feature' Your branch is up to date with 'origin/my-feature' 今までは新規のブランチを作成し、ブランチを切り替えるのにはgit checkout -bを使用していたが、git switch -cでできるようになった。 -bは--branchの省略。-cは--createの省略。 $ git switch -c my-new-feature Switched to a new branch 'my-new-feature' restore 今までは現在のディレクトリ内のすべてのファイルを復元するにはgit checkout .を使用していたが、 git restore .でできるようになった。 今までは作業ディレクトリの内容を変更せずにHEADを指定されたコミットを指すように変更するにはgit resetを使用していたが、 git restore --staged .でできるようになった。 所感 switchはいいと思う。restoreは今も昔も同じく難しいのでは？...
Git 2.23.0で追加されたswitchとrestoreについての個人的なメモ 個人的なメモなので従来のやり方は私が普段使ってたコマンドだし、ここに書いてないことも色々追加されているが使っていないので割愛。
背景: Highlights from Git 2.23 マニュアル: switch, restore マニュアルにはTHIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.と書かれているので、それなりの覚悟で使用してください。
git checkout
$ git switch my-feature Switched to branch 'my-feature' Your branch is up to date with 'origin/my-feature'
git checkout -b
git switch -c
-b
--branch
-c
--create
$ git switch -c my-new-feature Switched to a new branch 'my-new-feature'
git checkout .
git restore .
git reset
git restore --staged .
switchはいいと思う。restoreは今も昔も同じく難しいのでは？...
