20200920のGitに関する記事は4件です。

Gitのmasterブランチ意外、全てのブランチを一括削除する

タイトルの通りに、master ブランチ意外全て削除するのは以下のコマンドです。
'master'の代わりに他のブランチ名を変えることもできます。

ターミナル
git branch | grep -v 'master' | xargs git branch -D

長くて覚えづらいので、aliasを作成しました。

~/.zshrc
alias gbr="git branch | grep -v 'master' | xargs git branch -D"
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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グラフは以下のような状態がスタートだ。

キャプチャ1.png

masterへのマージ

ブランチからマージリクエストを送り、Fast Forwardなマージを行う。

キャプチャ2.png

たしかに、マージの記録が非常に分かりにくいが、ブランチはfeature/issue01と同じCommitIDに移動している。

productionへのマージ

ブランチからのマージではないので操作方法に一瞬悩むが、新規のマージリクエストからであれば、masterブランチからのマージリクエストを作成できるので、そこから行う。

キャプチャ3.png

これで、production も master と同じところまで進んだ状態になる。

さて、ここまでは基本的なFast Forwardの動作なので特に考えることはないはずだ。

複数featureブランチからのFast Forward

では、複数人で開発を行っていて、feature ブランチが並走している場合はどうなるだろう?
一度、これまでの開発の feature は削除して新たに feature/issue02、feature/issue03 を作る。

初期状態

以下の開発を行ったと仮定する。
- feature/issue02: c.txtの追加
- feature/issue03: b.txtの修正

マージ前のCommitグラフは以下のようになる。

キャプチャ4.png

masterへのマージ

まずは、feature/issue02 をマージする。

キャプチャ5.png

Commitグラフは上記のようになり、c.txt は追加されているが、b.txt の修正は取り込まれていない状態だ。

キャプチャ6.png

ここから更に、feature/issue03 をマージする。すると…

キャプチャ7.png

この場合はファイルが競合していなくても、どうやら Fast Forward なマージはできないようだ。
Rebase をしてみよう。

キャプチャ8.png

なんかそれっぽくマージされたように見える。
リポジトリの中身は問題ないだろうか。

キャプチャ9.png

ちゃんと feature/issue02 と feature/issue03 が取り込まれている!

productionへのマージ

ここまでできていれば一安心で、production へのマージは単一featureブランチと同じように実施可能だ。

キャプチャ10.png

先に進んでいる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ツリーは以下の状態。

キャプチャ11.png

feature/issue04ブランチは以下の状態。

キャプチャ12.png

masterブランチおよびfeature/issue05ブランチは以下の状態。

キャプチャ13.png

productionへのマージ

さて、上記の master ブランチからマージをかけてしまうと、当然 master ブランチの最新の状態になってしまう。今回のケースであれば、まだ feature/issue04 が残っているから、そこからマージしてしまうというのも一つの手段だ。ただし、今回は分かりやすくするために残しているが、通常は feature ブランチは、master ブランチへのマージが完了した時点で消してしまうため、この手段が使えない。

こういう時は、タグを使おう。
と言うか、冒頭に書いたように、Fast Forwardなマージコミットの場合、マージした際にタグをつけておかないとワケが分からなくなるため、本来はそのタイミングで付与しておくべきだろう。

キャプチャ14.png

タグを作ったら、そこからブランチを作ることができる。

キャプチャ15.png

ブランチができれば、後は普通にブランチから production ブランチにマージすれば良い。

キャプチャ16.png

production ブランチの内容も、しっかり feature/issue04 のみが取り込まれ、feature/issue05 は入っていない状態になっている。

キャプチャ17.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Github初心者②Gitの設定を簡単にやってみよう

Gitの設定を簡単にやってみよう

スクリーンショット 2020-09-20 13.58.12.png

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は使える状態になります。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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

(自分) げ、出た。スペースで次のページ行けるよぉ。すげー。

(自分) 根拠?どーでもいいじゃん。動きゃいいんだよ!

参考

https://stackoverflow.com/questions/40680812/mysql-git-bash-winpty-mysqldump-stdout-is-not-a-tty-and-stdin-is-not-a-tty/44727575#44727575

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む