概要 git pull した時にマージされるブランチ、いわゆる「上流ブランチ」が何かを知りたい時、git status -sb の出力を読んだり、ファイル .git/config の中身を読めばわかるのですが、そんなことしなくても、 $ git rev-parse --abbrev-ref @{u} すれば、わかるんです。 git status -sb -s はshort formatで出力するためのオプション、-b はshort formatにおいてブランチ情報を出力するためのオプションで、出力の一行目にブランチの情報が現れます。 上流ブランチが設定されてない場合にはローカルブランチ名だけが出力されます。 $ git status -sb | head -1 ## master 上流ブランチが設定されている場合にはローカルブランチ名の後に"..."、そのあとに上流ブランチ名が出力されます。 $ git status -sb ## master...origin/master 上流ブランチと同期されてない場合には、上流ブランチ名の後に、ローカルブランチと上流ブランチがコミットいくつ分離れているかが出力されます。上流ブランチより遅れている場合は $ git status -sb ## master...origin/master [behind 7] のように出力され、この状態で git pull すると origin/master のコミット7つがfast-forwardでマージできます。 $ git log --oneline master...origin/master|wc -l 7 逆に手元のブランチの方が進んでいる場合は $ git status -sb ## master...origin/master [ahead 1] と出力され、この場合は git push するとローカルブランチと上流ブランチが同期されます。 一方、ローカルブランチと上流ブランチが分岐している場合、つまり git pull --ff-only が失敗し、git pull でマージコミットが生成される状況では $ git status -sb ## master...origin/master [ahead 1, behind 7] のように、ローカルブランチと上流ブランチの、共通の祖先を経由した距離が出力されます。 $ git log --oneline master...origin/master|wc -l 8 また、設定された上流ブランチが削除されるなどして存在しなくなった場合には、 $ git status -sb ## feature...origin/feature [gone] のようにgoneと出力されます。 .git/config master の上流ブランチが origin/master である場合、.git/config には以下の内容が記載されています。 [branch "master"] remote = origin merge = refs/heads/master この値は以下のようにしても読み出せます。 $ git config branch.master.remote origin $ git config branch.master.merge refs/heads/master ここで branch.master.merge の値 refs/heads/master はリモートリポジトリでの表現であり、ローカルリポジトリでは refs/remotes/origin/master で表現されることに注意が必要です。 @{u} gitrevisions(7) に説明があるように、@{u} もしくは @{upstream} で上流ブランチを参照できます。 $ git rev-parse --abbrev-ref @{u} origin/master $ git rev-parse --abbrev-ref @{upstream} origin/master 先に説明した二つの方法では上流ブランチの表現を得るには出力を加工する必要がありましたが、この方法だとそのまま出力してくれるので簡単です。
git pull した時にマージされるブランチ、いわゆる「上流ブランチ」が何かを知りたい時、git status -sb の出力を読んだり、ファイル .git/config の中身を読めばわかるのですが、そんなことしなくても、
git pull
git status -sb
.git/config
$ git rev-parse --abbrev-ref @{u}
すれば、わかるんです。
-s はshort formatで出力するためのオプション、-b はshort formatにおいてブランチ情報を出力するためのオプションで、出力の一行目にブランチの情報が現れます。
-s
-b
上流ブランチが設定されてない場合にはローカルブランチ名だけが出力されます。
$ git status -sb | head -1 ## master
上流ブランチが設定されている場合にはローカルブランチ名の後に"..."、そのあとに上流ブランチ名が出力されます。
$ git status -sb ## master...origin/master
上流ブランチと同期されてない場合には、上流ブランチ名の後に、ローカルブランチと上流ブランチがコミットいくつ分離れているかが出力されます。上流ブランチより遅れている場合は
$ git status -sb ## master...origin/master [behind 7]
のように出力され、この状態で git pull すると origin/master のコミット7つがfast-forwardでマージできます。
$ git log --oneline master...origin/master|wc -l 7
逆に手元のブランチの方が進んでいる場合は
$ git status -sb ## master...origin/master [ahead 1]
と出力され、この場合は git push するとローカルブランチと上流ブランチが同期されます。
一方、ローカルブランチと上流ブランチが分岐している場合、つまり git pull --ff-only が失敗し、git pull でマージコミットが生成される状況では
git pull --ff-only
$ git status -sb ## master...origin/master [ahead 1, behind 7]
のように、ローカルブランチと上流ブランチの、共通の祖先を経由した距離が出力されます。
$ git log --oneline master...origin/master|wc -l 8
また、設定された上流ブランチが削除されるなどして存在しなくなった場合には、
$ git status -sb ## feature...origin/feature [gone]
のようにgoneと出力されます。
master の上流ブランチが origin/master である場合、.git/config には以下の内容が記載されています。
[branch "master"] remote = origin merge = refs/heads/master
この値は以下のようにしても読み出せます。
$ git config branch.master.remote origin $ git config branch.master.merge refs/heads/master
ここで branch.master.merge の値 refs/heads/master はリモートリポジトリでの表現であり、ローカルリポジトリでは refs/remotes/origin/master で表現されることに注意が必要です。
@{u}
gitrevisions(7) に説明があるように、@{u} もしくは @{upstream} で上流ブランチを参照できます。
@{upstream}
$ git rev-parse --abbrev-ref @{u} origin/master $ git rev-parse --abbrev-ref @{upstream} origin/master
先に説明した二つの方法では上流ブランチの表現を得るには出力を加工する必要がありましたが、この方法だとそのまま出力してくれるので簡単です。
謎のmigrationがあるためgit log全体を検索 対象のファイルが含まれるコミットを発見 $ git log --all -- 'db/migrate/2020323*' commit d178513009038b0d6473de95a685c9402da14123 Author: Cozy <dummy-mail@gmail.com> Date: Fri Mar 27 18:20:29 2020 +0900 〇〇のcolumn名変更 あった。glob対応してるのが嬉しいね git branchでコミットが含まれるbranchを検索して発見 $ git branch -a --contains d178513009038b0d6473de95a685c9402da14123 remotes/origin/feature/dummy-feature-branch これにて一件落着 ?
謎のmigrationがあるためgit log全体を検索 対象のファイルが含まれるコミットを発見
$ git log --all -- 'db/migrate/2020323*' commit d178513009038b0d6473de95a685c9402da14123 Author: Cozy <dummy-mail@gmail.com> Date: Fri Mar 27 18:20:29 2020 +0900 〇〇のcolumn名変更
あった。glob対応してるのが嬉しいね
git branchでコミットが含まれるbranchを検索して発見
git branch
$ git branch -a --contains d178513009038b0d6473de95a685c9402da14123 remotes/origin/feature/dummy-feature-branch
これにて一件落着 ?
最近設計フェーズでgitを使ってなかったら絶望的に忘れてきたので急いでメモ。 過去のコミットを修正。 直前のコミットはgit commit --amendで修正できる。 $ git add . $ git commit --fix (コミット) $ git rebase -i HEAD^^^^^^^^^ --autosquash
git commit --amend
$ git add . $ git commit --fix (コミット) $ git rebase -i HEAD^^^^^^^^^ --autosquash
チーム開発の主な流れ チーム開発の流れとしてまず最初に 1.リードプログラマーがプロジェクトのリボジトリを作成 2.そのリポジトリを各々がforkしてcloneする git clone https://github.com/ユーザー名/リボジトリ名.git 3.各プログラマーが各々のリポジトリ先にfork先に追加 git remote add リモート名(originなどの名前) https://github.com/開発の代表者/リボジトリ名.git 4.作業用ブランチを作成 git checkout -b (branch名) 5.リボジトリで各プログラマーは開発をスタートする。 ここでの注意点 １タスクごとにコミットをしていく git add フォルダー or ファイル名 git commit -m "タスク名" 6.ある程度commitがたまったらpush git push origin master 7.プッシュしたらリードプログラマー宛てにPullRequestを行います ここでconflictがでた場合下記を参照にしてください https://help.github.com/ja/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github 8.PullRequestを行う時の注意点 WHAT(どのような実装) WHY (なぜ実装したのか) といった形でリクエストを送るとよりリードプログラマーに送ります 9.リードプログラマーは、送られたきたPullRequestをメッセージを確認した後にマージを行います 注意点 PullRequestを行ってもFork/cloneしたリポジトリは本家にmasterが追従しているわけではありません。 マージした後は各々のマスターブランチ に移動して コマンド)git fetch upstream にて更新を行い コマンド)git checkout master コマンド)git merge upstream/master で本家のmasterに追従させることができます。 変更が無い場合には "Already up-to-date." と表示されて終了です! おわり 自分自身最初にgithubを使いチーム開発をした際に手順、注意点を復習としてまとめさせていただきました。 少しでも参考になれば私も嬉しいです
チーム開発の流れとしてまず最初に 1.リードプログラマーがプロジェクトのリボジトリを作成
2.そのリポジトリを各々がforkしてcloneする git clone https://github.com/ユーザー名/リボジトリ名.git 3.各プログラマーが各々のリポジトリ先にfork先に追加 git remote add リモート名(originなどの名前) https://github.com/開発の代表者/リボジトリ名.git
4.作業用ブランチを作成
git checkout -b (branch名)
5.リボジトリで各プログラマーは開発をスタートする。 ここでの注意点 １タスクごとにコミットをしていく
git add フォルダー or ファイル名 git commit -m "タスク名"
6.ある程度commitがたまったらpush
git push origin master
7.プッシュしたらリードプログラマー宛てにPullRequestを行います
ここでconflictがでた場合下記を参照にしてください https://help.github.com/ja/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github
8.PullRequestを行う時の注意点 WHAT(どのような実装)
WHY (なぜ実装したのか) といった形でリクエストを送るとよりリードプログラマーに送ります
9.リードプログラマーは、送られたきたPullRequestをメッセージを確認した後にマージを行います
PullRequestを行ってもFork/cloneしたリポジトリは本家にmasterが追従しているわけではありません。 マージした後は各々のマスターブランチ に移動して コマンド)git fetch upstream にて更新を行い コマンド)git checkout master コマンド)git merge upstream/master で本家のmasterに追従させることができます。 変更が無い場合には "Already up-to-date." と表示されて終了です!
自分自身最初にgithubを使いチーム開発をした際に手順、注意点を復習としてまとめさせていただきました。 少しでも参考になれば私も嬉しいです
