- 投稿日:
特定ブランチ以外を全部消す
Git 2.25.1で確認
# マージされてないのは残す
git branch -d $(git branch | grep -vP <PCRE pattern>)
# 強制削除
git branch -D $(git branch | grep -vP <PCRE pattern>)
参考:git-branch - List, create, or delete branches (git-scm.com)
マージコミットをリバートする
Git 2.25.1で確認。基本-m 1
で問題ないと思われる
git revert -m 1 <commit>
コミット間のハッシュを見る
Git 2.25.1で確認
# 新しい順
git log --pretty=format:'%H' <commit>..<commit>
# 古い順
git log --pretty=format:'%H' <commit>..<commit> --reverse
- 投稿日:
VisualStudio 2022でGitの署名コミットをしようとしたらエラーを吐いたのでその対処法
前提条件
- Gpg4winをインストールしている
- cmdから署名コミットができる
- 最低限以下の設定がある
[user]
name = your-name
email = your@example.com
signingkey = XXXXXXXXXXXXX
[commit]
gpgsign = true
確認環境
下記のgpgはGpg4winにバンドルされているものです
Env | Ver |
---|---|
Visual Studio Community 2022 (64 bit) | Version 17.5.1 |
Git | 2.40.0.windows.1 |
gpg | 2.3.4 |
エラー内容
このエラーをコピーしようとするとVisualStudioがクラッシュしたので頑張って写経しました
Git failed with a fatal error.
Git failed with a fatal error.
hint: core.useBuiltinFSMonitor=true is deprecated; please set core.fsmonitor=ture instead
hint: Disable this message with "git config advice.useBuiltinFSMonitorConfig false"
error: cannot spawn gpg: No such file or directory
error: gpg failed wqrite commit object
対処方法
GitのGlobal Config設定変更で対処する
- 次のコマンドを流す
git config --global gpg.program "C:\Program Files (x86)\GnuPG\bin\gpg.exe"
gpg.exe
のパスは環境に応じて書き換えること
参考までにWindowsのGlobal Configは%USERPROFILE%.gitconfig
にあるのでファイルを編集して対応する場合は、下記内容を追記することで対応できる
[gpg]
program = "C:\\Program Files (x86)\\GnuPG\\bin\\gpg.exe"
- 投稿日:
これは、かつて参画したGitHubを利用したプロジェクトでブランチフローが悪く事故が多発したので考案し、運用した内容です。
基本的には後々の運用を考えた時に情報源になり、かつGit操作に極力手間を取られることがなく、CI/CDを回しながら品質を維持できる内容で考えています。
フローの要件として考えたこと
取り回しが単純明快であること
開発以外の要素に振り回されないように単純なフローにしていて、世に言われる履歴の綺麗さとか言うのは個人的には関心が薄いので重視していません。その代わりコミットが壊れないことや、インデックスとして見やすくなるような部分を重視しています。
GitHubとの相性が良いこと
まず個々の開発タスクをIssueベースで管理し、Pull Requestベースで取り込む運用としました。
Pull Requestの取り込み方式はSquash Mergeとし、メインブランチのコミット履歴がPull Requestのマージコミットになるようにしました。
これはメインブランチのコミット履歴はPull Requestのマージコミットだけあれば後から追えるというのと、メインブランチのコミットログを単純にする意味でこの方式にしています。
CI/CDを活用しやすいこと
これは割とどこでもやっていると思いますが、ブランチ名にdevelop
とかstaging
, production
とか付けて管理することで、自動的に環境を識別できるようにしました。
実際に運用したフロー
フロー図
フローの運用内容
develop/main
ブランチを最新ブランチとする運用develop/main
ブランチ相当のものが複数ある状態というのが世の中にあると思いますが、管理が非常に大変なのでそれはしない方向にしました
- 機能ブランチを
develop/main
ブランチに取り込むのはSquash Merge- 基本的に変更履歴を見る時はGitLensや
blame
で変更行からPull Requestを当てて、そこを見に行くという運用にしていました
- 基本的に変更履歴を見る時はGitLensや
- 機能ブランチに
develop/main
ブランチを取り込むのはmerge
- 一般的には
rebase
が多いと思いますが、次の観点から採用しませんでした- どのポイントで取り込んだのかわからない
merge
と比較した場合にコンフリクト対応に手を取られる- 経験上ここで事故が頻発する
- 素直に
push
出来ない
merge
であれば以下のように単純な流れに出来ますし、push前に差分確認して事故を防ぐことも容易ですgit switch develop/main
git pull
git switch -
git merge -
- コンフリクトがあれば解消
git push
- 一般的には
- デプロイ方式によるルートブランチ分割
- ルートブランチ名によってデプロイ先を変更できるようにしました
- GitHub Actionsでブランチ名を拾って環境変数を差し替えることでデプロイするワークフローを組んでいます
staging/
やproduction/
ブランチはdevelop/main
からcheckout
する運用です- これらはデプロイするためだけの使い捨てブランチなので毎回生えます
あとがき
このフローの利点としてはマージでコンフリクトが起きても基本的にCurrentとIncomingを一回比較するだけで済むのでコンフリクトの解消が簡単で、コンフリクト時はIncomingが壊れないようにCurrentを直すのが基本になり、Currentを優先する場合は適宜上書きするといった内容です。
ブランチの合流はmerge
だとマージコミット分一回の解消だけでいいので事故の発生要因が低いのがrebase
と比較した時の利点です。rebase
だとコミット回数分再帰的に合流させる必要があるのでブランチの寿命が長かったりすると苦行になってきます。
このフローができた経緯としては元々はGitHub Flowをベースにしていたのですが、色々やっていくうちにこうしたらもっと良くなるのではないか?というのを試行錯誤していてこの形に落ち着いたのですが、後から調べたらGitLab Flowに近い形式に見えたので、似た内容は既に誰かが考えているものだなと感じました。
上で挙げた内容の他にもGitHubのリポジトリ設定でブランチ保護のルールを設定したり、Pull Requestのマージ設定でSquash mergingだけ許可したり、ヘッドブランチの自動削除をするなど、基本的に面倒なことを考えたり、しなくて良い様にするなど、開発に注力しやすいように環境を整えると心理的な抵抗が少なく運用できて便利だなと感じています。
- 投稿日:
MSYS2でzsh使いたくない?使いたいよね?そう、使いたい!
しかしその上で一つ大きな障害があります
MSYS2のzshでプロンプトにGitのブランチを表示させようとすると微妙に上手くいきません
問題
.zshrc
を使ってPROMPT
に現在のGitブランチの状態を表示させようとするとフリーズするケースがあります
具体的には以下のような設定を書くとターミナルのサイズ変更時にシェルがフリーズします
原因は不明ですがPROMPT='$(git)'
だけでフリーズするのでGit for Windowsとの相性がなにか良くないのだと思っています
# git functions
current_git_branch() {
(git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/')
}
parse_git_dirty() {
local DIRTY=$(git status -s | tail -1)
if [[ -n $DIRTY ]]; then
echo "%{$fg_bold[magenta]%})%{$fg_bold[red]%}✗"
else
echo "%{$fg_bold[magenta]%})%{$fg_bold[blue]%}✓"
fi
}
print_git_prompt() {
local FIND_BRANCH=$(git branch 2> /dev/null | tail -1)
if [[ -n $FIND_BRANCH ]]; then
echo "%{$fg_bold[magenta]%}(%{$reset_color%}%{$fg_bold[yellow]%}"$(current_git_branch)$(parse_git_dirty)" %{$reset_color%} "
else
echo ""
fi
}
# setting propmt
PROMPT="
%{$fg_bold[cyan]%}%n%{$reset_color%}%{$fg_bold[blue]%}@%m%{$reset_color%}:%{${fg_bold[green]}%}%~%{$reset_color%}
%(?:%{$fg_bold[green]%}➜:%{$fg_bold[red]%}➜) %{${reset_color}%}"'$(print_git_prompt)'
RPS1="%(?..%{$fg_bold[red]%} [ %? ]%{$reset_color%}) %D - %*"
解決策1
プロンプト表示に使うgitバイナリだけmsys2の物に差し替えると上手くいくようになります
具体的には以下のようにしてGit for Windowsと競合しないようにMSYS2のGitを構成しPROMPT='$(msys2_git)'
のように呼び出してやると上手くいきます
pacman -S git
mv /usr/bin/git /usr/bin/msys2_git
課題
- msys2/gitをアップデートするときに毎回リネームをする必要がある
- ここが面倒で脆弱性に繋がる可能性がゼロではない
解決策2
Git for Windowsだけでやる場合の方法です
add-zsh-hook precmd
でプロンプトに出したいコマンドを呼び出し、変数の値を書き換えてそれを表示するスタイルでやると上手くいきます
課題
- プロンプトの速度が遅い
- プロンプトする時に一瞬フォーカスが飛ぶ(別プロセルがコールされ一瞬窓ができている気がする