恥ずかしい気もするけど間違えるよりはずっといい。
これもメモしていかないと・・・
レポジトリやブランチをもらってくる系の操作
レポジトリをコピー(clone)してくる
git clone <.git アドレス>
特定のブランチをコピー(clone)してくる
git clone -b <branch name> <.gitアドレス>
ローカルに新しいブランチを作る
現在のブランチのファイル内容そのままで名前だけ変わる
git branch <new branch name>
ローカルで指定のブランチに移る
git checkout <branch name>
ローカルの指定のブランチをremote/originに一致(pull)させる
git checkout <branch name>
git pull origin <branch name>
git pullは実際にはfetchしてmergeするのに似ている。
あえてfetch, mergeと分けたほうがいいこともある。
特に、upstreamなど、origin以外のリモートレポジトリを参照するとき。
あるレポジトリを参照するリモート ブランチに追加。upstreamという名前にする
git remote add upstream <repository .git to refer>
自分のmasterを、公式レポのmasterに追従するときとかに使える。（でも、ものとしては公式とは分離しておく、危ないから）
git checkout master # これはローカルのmaster
git fetch upstream master # upstreamの最新masterをダウンロード
git merge upstream/master # upstreamのmasterブランチを、自分のローカルブランチに統合(merge)
リモートレポはいくらでも作れる。
消す系の操作
ローカルの特定ファイルの修正をなかったことにする
git checkout <file name>
ローカルのすべてのファイルの修正をなかったことにする
git checkout .
ローカルで特定のブランチを消す
git branch -D <branch name to be deleted>
HEADとかの操作系
ローカルで開発しているうちにmasterが進んでいたので、masterの先頭から延びたようにする
git checkout master
git pull origin master
git checkout <developing branch>
git rebase origin/master
Headとは、ツリーとは。。。
勉強して自分の理解を記録していく
rebaseしたらコンフリクトしたので修正してrebase続行
git add <fixed file>
git rebase --continue
git rebaseよくわからない！取りやめ！
git rebase --abort
Pull Request
送るとき
rebaseをきれいに実施して、commit logをきれいにしておくといい
受けたとき
てもとで動作させるために、ローカルにリクエストを持ってくる
$ git checkout <pull request URL>
これでやってみて、動くようならいいし、動かないようなら修正してもらう
PRを間違ってmergeしてしまったとき
