この記事の目的
- 執筆者の作業記録や似た作業をしたときに使うため
ベースブランチとは
ChatGPT曰く...
Git や GitHub などで プルリクエスト（Pull Request）を出すときの「比較対象」になるブランチ のこと！
らしいです。
Githubの画面を思い出して欲しいのですが、PullRequest(PR)を作るとき現在の作業ブランチの反対側。つまり、マージ先のブランチのことをベースブランチと言っているみたいです。
タイトル回収
では、「PullRequestがない状態でベースブランチらしきブランチを見つける」とはどうゆうことか
PRがない = ベースブランチを選択していない。
しかし、ローカル環境で作業ブランチをきる際に、
git checkout -b develop
みたいに、ベースのブランチから作業ブランチを作成しています。（ローカル環境では）
人間的には、
main --> develop
と意図して作成しているが、リモート環境(github)では、PRが作成されていない状態では
??? --> develop
になっております。
なので、今回は???を探す方法を記載していきます。
やり方
結論から言うと、git logコマンドを使います。
git log --graph --oneline --decorate=full
上記のコマンドを実行すると、git系のツールで見たことあるようなツリー上の内容が出力されるかと思います。
* commit_hash (HEAD -> refs/heads/test, refs/remotes/origin/test) test
* commit_hash commitコメント
* commit_hash (refs/heads/develop) Merge pull request #1 from test2
|\
| * commit_hash (refs/remotes/origin/test3) Merge branch 'develop' into test4
| |\
| * | commit_hash commitコメント
リモート環境のログを取得します。そうすると、現在の作業ブランチが一番上(ここで言うとHEAD -> refs/heads/test, refs/remotes/origin/test)に来ると思います。
上から基本的には時系列になっています。なので、HEADから見て、下に向かって過去の作業コミットないようになっています。
git logコマンドには、refs/~という記述があると思いますが、これがマージ元になります。
結論
以下のようなshellファイルを作成し、実行するとおそらくできるかと思います。
#!/bin/bash
git fetch origin
# 100行の間にベースブランチを見つける
git log --graph --oneline --decorate=full -n 100 > git_log.txt
# HEADを含む行番号を取得
HEAD_LINE_NUM=$(grep -n "HEAD ->" git_log.txt | cut -d: -f1)
if [ -n "$HEAD_LINE_NUM" ]; then
# HEADの次の行から順次チェック
TOTAL_LINES=$(wc -l < git_log.txt)
for ((i=$((HEAD_LINE_NUM + 1)); i<=TOTAL_LINES; i++)); do
CURRENT_LINE=$(sed -n "${i}p" git_log.txt)
echo "Checking line $i: $CURRENT_LINE"
# ブランチ情報があるかチェック（括弧内にrefs/があるか）
if echo "$CURRENT_LINE" | grep -q "(.*refs/"; then
echo "Found branch info at line $i"
# ブランチ情報を抽出
BRANCH_INFO=$(echo "$CURRENT_LINE" | sed 's/.*(\(.*\)).*/\1/')
# ベースブランチらしき参照を取得
BASE_BRANCH=$(echo "$BRANCH_INFO" | sed 's/,.*$//' | sed 's|refs/heads/||; s|refs/remotes/||')
echo "First branch below HEAD: $BASE_BRANCH"
break
fi
done
fi
これにより、リモート環境でPRを作成していない状態でベースブランチらしきブランチを見つけることができます
これどこで使うのか
例えば、CI/CD周りでリモート環境下のgithubで管理されているファイル上に変更があった場合になにかしら検知する時などに利用できます。
PRを作る前にpushしている状態から検知することができる。
私の場合、pushされたファイルを見て、リモート環境下でテストコードを実行させる処理を省略したりする際に利用しました。
微妙な点
チーム開発をしていると他の人も当たり前にgithubを操作します。その時に上手くブランチの特定できない場合が存在するみたいです。ブランチがマージされたりしておかしくなるのが原因はよくわかっていないが、事象として確認しています。