Abstract
- 毎回[
git pull -p
]をコマンドで実行し、複数ある作業元となるブランチを個々でPullしていた状態は、無駄な時間がかかる上にミスを誘発する状況であった。 - その為バッチファイルを作成し一連の動作を自動化することにより、作業時間の削減とさらなるエラー防止を図った。
- 現在の状態ではコードに無駄がある。しかし解解決法が分からず、修正できていない。
背景
- 毎回[
git pull -p
]を使用するのが面倒だった。 - pullを忘れたことによる問題が多発した。
- masterブランチやdevelopブランチをpullする前に分岐し、古いバージョンをテスト版として配布してしまった等
- 2023.03.22で変更した理由。
- checkoutで反映している為、バッチファイル実行後[masterブランチ]に移動してしまう問題があった。
- 元のブランチに手動で戻るのが面倒なので、
checkout
を使用する前にカレントブランチの名前を変数に格納し、最後そのbranchに自動で戻るようにした。
本文
コード
@chcp 65001 @rem バッチファイルの文字コードをがUTF-8にする
@rem 230322_git pull UpStream-p & master and Develop branchs apply.
@rem リモートリポジトリから、全てのbranchを削除も反映してpullする
@rem Develop_fix、Develop_feature、develop、masterのローカルリポジトリを最新にする
cd Development_folder_exists_behind
git pull UpStream -p @rem fork元からpullする。削除も反映する
@ for /f "usebackq" %%i in (`"git symbolic-ref --short HEAD"`) do set now_branch=%%i @rem カレントブランチの名前を変数に格納する
@echo "現在のbranchは [ "%now_branch%" ] です。" @rem @echoにしない場合「現在の~」が2つ出力される
git checkout -B Develop_fix UpStream/Develop_fix
git checkout -B Develop_feature UpStream/Develop_feature
git checkout -B develop UpStream/develop
git checkout -B master UpStream/master
git checkout %now_branch% @rem checkoutコマンド使用前に取得したブランチに移動する
@rem 通常時は実行結果を確認しない
@rem pause
コードの背景
- このリポジトリのコラボレーターであるが、forkリポジトリを使用している状態である。
-
@echo off
を使用せず@
を多用しているのは、コマンドは出力してほしい為。 -
@rem pause
はエラーが起きた時、コメントアウトを解除してエラーを表示できるようにする為。- 確認したい際に「pause」を打ち直すのが面倒くさい。
- コマンドを覚えていない為、毎回調べることになる。
コードの説明
@chcp 65001
内容
- バッチファイルの文字コードを
UTF-8
として明示する。 - 日本語の使用がコメント文のみであったとしても、これを使用しないと想定外の挙動を起こすことがある。
- 参照 : UTF-8のバッチファイルが文字化けする時の対処3選
for /f "usebackq" %%i in (`"git symbolic-ref --short HEAD"`) do set now_branch=%%i
内容
- カレントブランチの名前を 変数:now_branchに格納する。
- ループ処理でコマンドを実行するコマンド,カレントブランチの名前を取得するコマンド,変数に格納するコマンドの組み合わせコマンドになっている。
[ループ処理でコマンドを実行するコマンド]
for /f "usebackq" %%i in (`"git symbolic-ref --short HEAD"`) do set now_branch=%%i
↓
for /f "usebackq" %%[アルファベット1文字] in (`"[実行したいコマンド]"`) do [コマンド]
- [変数名]:
now_branch
に [実行したいコマンド]:git symbolic-ref --short HEAD
の結果を格納する。-
"usebackq"
オプション- コマンドの出力をfor文で取り扱い可能にする為のオプションである。
- これがない場合、
(`ファイル名`)
での取り扱いになり、ファイル内のテキストを操作するコマンドとなる。-
"usebackq"
を消した場合の実行結果D:\In_front_of_the_development_folder\Development_folder_exists_behind>for /F %i in (`"git symbolic-ref --short HEAD"`) do set now_branch=%iファイル `"git symbolic-ref --short HEAD"` が見つかりません。
- このように
git symbolic-ref --short HEAD
をコマンドではなくファイル名として認識してしまう。
- このように
-
-
%%i
- このfor文はC#のforeach文と似た構造になっている。
- コレクションの要素(コマンド実行結果)を取得する変数。
- [実行したいコマンド]をiに格納し、[実行したいコマンド]の出力に対して[コマンド]を実行できるようにする。
-
[カレントブランチの名前を取得するコマンド]
git symbolic-ref --short HEAD
-
Gitにおける
symbolic ref
という概念は、refs/head/master
みたいなコミットオブジェクトの参照を指す
引用 : Gitリポジトリのカレントブランチ名を取得する -
--short
オプションでsymbolic-ref
から、ブランチ名のみを切り出し取得している。
[変数に格納するコマンド]
do set now_branch=%%i
↓
do set [変数名]=[格納内容]
- 変数の初期化と代入を行う。
- [実行したいコマンド]:
git symbolic-ref --short HEAD
の出力結果が格納されている%%iを、do setで宣言した[変数名]:now_branch
に代入する。 - これらにより、カレントブランチの名前が
now_branch
に格納される。
cd Development_folder_exists_behind
内容
- このコード以降のコマンドを実行したいフォルダである、
カレントフォルダ(batファイルが存在するフォルダ)の階層に存在しているフォルダに移動する。-
Development_folder_exists_behind
はクローンしたフォルダであり、
このbatファイルが存在するのはローカルリポジトリではなく、
一つ前の階層のフォルダ。
-
git pull UpStream -p
内容
- プルーンオプションを使用してUpStreamからすべてのブランチをpullする。
- プルーンオプション(
-p
)は、リモートリポジトリの削除も反映させる。
- プルーンオプション(
git checkout -B [ローカルブランチ名] [追跡元となるブランチ名]
内容
-
git checkout -B master UpStream/master
-
「ローカルブランチ:
master
を削除し、
追跡元となるブランチ:UpStream/master
を追跡した、
ローカルブランチ:master
を作成する」
-
-B
オプションにより、
元々存在しているローカルブランチを削除し、再度リモートブランチを追跡する同じ名称のローカルブランチ(master
)を作成している。。- 削除の工程を挟む為、プルしたいブランチが編集されていてもエラーが生じず反映することができる。
- 注:
- ここで
checkout
しているブランチは、UpStreamで保護されているブランチであり、コミットしてはいけない物。 - 変更されてはいけない物の為、自身が編集していてもそれを無視し削除して問題がない。
- ここで
- 削除の工程を挟む為、プルしたいブランチが編集されていてもエラーが生じず反映することができる。
-
-
「ローカルブランチ:
実行結果
D:\In_front_of_the_development_folder\Development_folder_exists_behind>git checkout -B master UpStream/master
Switched to and reset branch 'master'
branch 'master' set up to track 'UpStream/master'.
Your branch is up to date with 'UpStream/master'.
実行結果翻訳
ブランチ「master」に切り替わり、リセットされる。
ブランチ 'master' を追跡するように設定する 'UpStream/master'です。
あなたのブランチは 'UpStream/master' で最新になります。
課題点
-
リモート追跡ブランチ(*1)から、ローカルブランチ(*2)にマージする為に「checkout -B」を使用している事。
- 毎回ローカルブランチ
master
を削除し、
リモート追跡ブランチUpStream/master
を追跡したmaster
ブランチを再度作成するという行動には無駄があると考える。 - 一度にリモートリポジトリからローカルブランチにpullしたい。
(fetch->mergeを一括で行いたい)
- 毎回ローカルブランチ
注釈
*1_リモート追跡ブランチ
*2_ローカルブランチ
参考資料 & 謝辞
2023.03.18 投稿時分
-
第17話 ローカルリポジトリに残ってしまうリモート追跡ブランチを一気に削除する prune オプション【連載】マンガでわかるGit ~コマンド編~
- 『わかばちゃんと学ぶ Git使い方入門』
- リモートで削除されたブランチがローカルで溜まっていてそれを削除する方法を探していた時に参考にさせていただきました。
- 共同開発者が使用していたバッチファイルのコード(非公開)
- バッチファイルで自動化する手法に気づかせていただきました。
- バッチファイルの記述方法は此方から参照しています。
-
- バッチファイルの中でコメントを使用する方法
- REMコマンドの使い方
-
-
新しいブランチを作ってそのブランチへ切り替えの部分を特に参考にさせていただきました。
-
新しいブランチを作ってそのブランチへ切り替えの部分を特に参考にさせていただきました。
-
Git_git pullしてリモートリポジトリからローカルに取得する
- fetchとpullの仕組みをまだ理解していなかった為、確認させていただきました。
-
- 記事の校閲をして頂きました。ChatGPTさんありがとうございます。
-
フールプルーフについて
- ChatGPTさんの校閲で削除していますが、記事を記載する際に参考にしていました。
- フェールセーフ : エラーやミスが発生しても被害を最小限にとどめる仕組みにする事。
- フールプルーフ : そもそもエラーや人的ミスが起こせない仕組みにする事。
2023.03.22 更新分
-
バッチファイルで変数を使う方法
- 変数の扱い方の記事として最初に読み参考にさせていただきました。
- シンプルに描かれていて理解しやすかったです。
-
[小ネタ]Windowsバッチでコマンドの実行結果を変数に格納する方法
- コマンドの実行結果を変数に格納する方法と、変数を使用する方法の参考にさせていただきました。
- コマンドの実行結果を変数に格納する方法と、変数を使用する方法の参考にさせていただきました。
-
カレントブランチ名を取得するコマンド
- ブランチ名を取得するコマンドとして最初に参考にさせていただきました。
- ブランチ名を取得するコマンドとして最初に参考にさせていただきました。
-
.bat(バッチファイル)のforコマンド解説。
- 上記参考のコマンドを使用した際、カレントブランチだけでなく所持しているブランチと
*
が実行結果に含まれていました。 - 必要なのは「カレントブランチ名」だけなので実行結果を編集する必要があり、その方法を調べている時に参考にさせていただきました。
- 上記参考のコマンドを使用した際、カレントブランチだけでなく所持しているブランチと
-
gitでカレントブランチ名だけを取り出す
- 上記のコマンドは、自分が必要としていた結果を取得するコマンドではなかった為、最終的にこちらの記事のコメントで記載されていたコードを参考にさせていただきました。
- 上記のコマンドは、自分が必要としていた結果を取得するコマンドではなかった為、最終的にこちらの記事のコメントで記載されていたコードを参考にさせていただきました。
-
Gitリポジトリのカレントブランチ名を取得する
- 「カレントフォルダ」「カレントブランチ」という用語を知らなかった為、「現在居る~」と表記していました。
- こちらの記事を拝見し「カレント~」という用語を知り修正いたしました。
-
symbolic ref
コマンドの意味の説明を参考にさせていただきました。
- UTF-8のバッチファイルが文字化けする時の対処3選
余談
- この記事の内容を全てChatGPTさんに渡し「この内容に合うタイトルを提案してください」と問いかけたら、全て英語に翻訳されました…
- 何度か質問内容を変更して聞いたのですが、記事の内容を置いてから日本語で質問すると英語で返答されてしまいました。
- 「# Abstract」が先頭にあり、
尚且つコードやURLの部分で英語が多かった為に、英語判定されてしまったのだと考えられます。
- [フールプルーフ]の考え方を[フェールセーフ]と勘違いしていました。
- 記事に使用したい言葉が誤用でないか確認した時に覚え間違いに気が付くことができました。