- 投稿日:2020-09-20T19:49:25+09:00
Gitのmasterブランチ意外、全てのブランチを一括削除する
タイトルの通りに、
master
ブランチ意外全て削除するのは以下のコマンドです。
'master'
の代わりに他のブランチ名を変えることもできます。ターミナルgit branch | grep -v 'master' | xargs git branch -D長くて覚えづらいので、aliasを作成しました。
~/.zshrcalias gbr="git branch | grep -v 'master' | xargs git branch -D"
- 投稿日:2020-09-20T17:03:37+09:00
GitのFast Forwardの動作を確認してみる
はじめに
前回の記事からの続き。
理想を追い求めたCI/CDパイプラインでは環境とブランチが1対1に紐付き、その間では1つのコンテナベースを渡り歩かせるのが原則となっているため、Commitとコンテナベースを一意に紐付ける識別子が必要になる。一方で、GitLabではデフォルトのマージはmergeCommitとなり、CommitIDが都度作られてしまうことから、コンテナべベースを一意に識別するためには、外部から識別子を渡してあげなければいけない。外部から渡すということは人力の作業が増え、自動化原則から外れてしまう。対応するには、mergeCommitをしないFast Forwardなマージを考える必要がある。Fast Forwardなマージとは
GitLab Docs参照。
なぜか日本語ドキュメントでもこのパートは訳されていないけど……。さらに、Fast ForwardとNon Fast Forwardの違いをしっかり説明してくれているのが以下のブログ
「こわくない Git」というスライドを発表しました
ちょうわかりやすい。Gitに苦手意識のあるすべての人が読んでおくと良いと思った。Fast Forwardでは、たしかにスライド中にある「マージをしたという記録が残らない」「マージが取り消しづらい」がデメリットになってしまうので、これについては、「ちゃんとタグで記録残していきましょう」なんだろうな……。
実際に動かしてみる
さて、実際に以下のようなGitLab Flowを運用していると仮定して実験してみる。
- masterブランチ
- productionブランチ
- 開発時 feature/issueXX ブランチ単一featureブランチからの単純なFast Forward
初期状態
feature/issue01 では b.txt の追加と a.txt の修正をした状態から、productionへの反映をやってみよう。
Commitグラフは以下のような状態がスタートだ。masterへのマージ
ブランチからマージリクエストを送り、Fast Forwardなマージを行う。
たしかに、マージの記録が非常に分かりにくいが、ブランチはfeature/issue01と同じCommitIDに移動している。
productionへのマージ
ブランチからのマージではないので操作方法に一瞬悩むが、新規のマージリクエストからであれば、masterブランチからのマージリクエストを作成できるので、そこから行う。
これで、production も master と同じところまで進んだ状態になる。
さて、ここまでは基本的なFast Forwardの動作なので特に考えることはないはずだ。
複数featureブランチからのFast Forward
では、複数人で開発を行っていて、feature ブランチが並走している場合はどうなるだろう?
一度、これまでの開発の feature は削除して新たに feature/issue02、feature/issue03 を作る。初期状態
以下の開発を行ったと仮定する。
- feature/issue02: c.txtの追加
- feature/issue03: b.txtの修正マージ前のCommitグラフは以下のようになる。
masterへのマージ
まずは、feature/issue02 をマージする。
Commitグラフは上記のようになり、c.txt は追加されているが、b.txt の修正は取り込まれていない状態だ。
ここから更に、feature/issue03 をマージする。すると…
この場合はファイルが競合していなくても、どうやら Fast Forward なマージはできないようだ。
Rebase をしてみよう。なんかそれっぽくマージされたように見える。
リポジトリの中身は問題ないだろうか。ちゃんと feature/issue02 と feature/issue03 が取り込まれている!
productionへのマージ
ここまでできていれば一安心で、production へのマージは単一featureブランチと同じように実施可能だ。
先に進んでいるmasterブランチの過去のCommitIDからproductionブランチにマージする
feature/issue04 ブランチの開発については master ブランチへのマージまで完了していてあとは production 環境にデプロイするだけなのだけど、もろもろの事情でちょっと待って、と言われてるところに次の feature/issue05 ブランチの開発が来ていて stage 環境にはデプロイしなきゃいけないからとりあえず master ブランチは進めないと、といった状況になった場合の方法論(今回は stage 環境ないけど…)。
さらに考えると、この stage 環境での開発を先に production 環境にデプロイしないとといけないケースも想定できるが、そこまでいくともはや Fast Forward は諦めて別の方法を考えた方が良いと思うので、一旦除外する。初期状態
以下の開発を行ったと仮定する。
- feature/issue04: d.txtの追加、c.txtの追加 → masterブランチへのマージ
- feature/issue05: 上記の後、e.txtの追加、d.txtの修正 → masterブランチへのマージCommitツリーは以下の状態。
feature/issue04ブランチは以下の状態。
masterブランチおよびfeature/issue05ブランチは以下の状態。
productionへのマージ
さて、上記の master ブランチからマージをかけてしまうと、当然 master ブランチの最新の状態になってしまう。今回のケースであれば、まだ feature/issue04 が残っているから、そこからマージしてしまうというのも一つの手段だ。ただし、今回は分かりやすくするために残しているが、通常は feature ブランチは、master ブランチへのマージが完了した時点で消してしまうため、この手段が使えない。
こういう時は、タグを使おう。
と言うか、冒頭に書いたように、Fast Forwardなマージコミットの場合、マージした際にタグをつけておかないとワケが分からなくなるため、本来はそのタイミングで付与しておくべきだろう。タグを作ったら、そこからブランチを作ることができる。
ブランチができれば、後は普通にブランチから production ブランチにマージすれば良い。
production ブランチの内容も、しっかり feature/issue04 のみが取り込まれ、feature/issue05 は入っていない状態になっている。
- 投稿日:2020-09-20T13:58:48+09:00
Github初心者②Gitの設定を簡単にやってみよう
Gitの設定を簡単にやってみよう
Github初心者①Gitに続き続編でGitの設定をしていきたいと思います。本当は①をGitの設定にしておくべきだったかもしれないのですが、書き直すのは面倒なのでとりあえず自分にとってのメモ程度で書かせていただきたいと思います。
まずはこちらからGitのダウンロードを行なってください。
Git入門
参考記事_1
参考記事_2
ダウンロードできましたら、こちらのコマンドを順番にGitの登録を行なってください。Gitの設定をするコマンド git configコマンド
①
git config
とは、Gitの設定内容を変更するためのコマンド$ git config --global user.name "username"②設定値の一覧を確認する
$ git config --list③特定の設定値を確認する
$ git config user.nameいったん①で登録したらこれでGitは使える状態になります。
- 投稿日:2020-09-20T10:57:00+09:00
GitBashの"stdout is not a tty"で怒られないように
はじめに
1年ぐらい悩んでいましたが、たった今、対策が見つかりましたのでご報告します。
現象
GitBashでリダイレクトやパイプを使った時に、こんなメッセージが出てうまくいきません。
$ python bin/regression.py > out.txt stdout is not a tty毎回これが出る度に回避策を考える日々。
回避策(例)
- less が使えず、流れるメッセージを見つめ、見たいところでCtrl-Cで強制終了。その後スクロールバーをつかって見たいところを調整。
- リダイレクトできないため、プログラムでファイルに出力するコードを書く。もしくはDOSコマンドプロンプトを起動し、実行する。
Git Bashのttyで怒られないように も試したんですがうまくいかないんですよ。
対応
(A) 本腰入れて調べてみました。するとこんな話を見つけました(参考文献参照)
コマンドに拡張子をつける
(自分) それだけ? うそやろ。根拠ねーじゃん。
(A) いい? じゃぁ、やってみるよ。(コマンドを実行)
$ python.exe bin/regression.py > out.txt(自分) え、うそっ、動いてる。まじかよ。パイプはどうなってるっーーーー!!!?
(A) (コマンドを実行)
$ python.exe bin/regression.py | less(自分) げ、出た。スペースで次のページ行けるよぉ。すげー。
(自分) 根拠?どーでもいいじゃん。動きゃいいんだよ!
参考