概要

ローカルでcircleci buildコマンドを使って設定ファイルを確認しようとしたところ、エラーでタスクが正常終了しない。

console

====>> Checkout code
  #!/bin/sh -eo pipefail
mkdir -p /root/project && cd /tmp/_circleci_local_build_repo && git ls-files | tar -T - -c | tar -x -C /root/project && cp -a /tmp/_circleci_local_build_repo/.git /root/project
/bin/sh: git: not found
tar: empty archive
tar: short read
Error: Exited with code 1
Step failed
Error: runner failed (exited with 101)
Task failed
Error: task failed

実行したconfig.ymlは下記の通り。

config.yml

version: 2
jobs:
  build:
    docker:
      - image: node:12.13.0-alpine
    steps:
      - checkout
      - run:
          name: Greeting
          command: echo Hello, world.
      - run:
          name: Print the Current Time
          command: date

原因

コンソールにも出力されているように、checkout時、コンテナ上でgitが実行できないことが原因。
今回使用しているimage:node:12.13.0-alpineには
gitはデフォルトでは入っていない。

対応

checkout実行前に、apkコマンドでgitを用意してあげる。

config.yml

version: 2
jobs:
  build:
    docker:
      - image: node:12.13.0-alpine
    steps:
      - run:
          name: add git
          command: apk -U add git
      - checkout
      - run:
          name: Greeting
          command: echo Hello, world.
      - run:
          name: Print the Current Time
          command: date

実行結果は以下の通り

console

====>> Checkout code
  #!/bin/sh -eo pipefail
mkdir -p /root/project && cd /tmp/_circleci_local_build_repo && git ls-files | tar -T - -c | tar -x -C /root/project && cp -a /tmp/_circleci_local_build_repo/.git /root/project
====>> Greeting
  #!/bin/sh -eo pipefail
echo Hello, world.
Hello, world.
====>> Print the Current Time
  #!/bin/sh -eo pipefail
date
Sun Dec  1 12:48:31 UTC 2019
Success!

無事、実行されました。

はじめに

今年はKubernetes公式ドキュメント翻訳をはじめとしたOSSコントリビュートを積極的に行ってきました。必然的にGitを使う機会も増えますが、git rebaseで困った経験を紹介します。

TL;DR

git rebaseをした結果、前のコミットと差分がなくなると何もgit addするものがなくgit rebase --continueできません。この場合はgit rebase --skipすると進むことができます。

例

何でもよいのですが、私がmacOSセットアップに利用しているAnsible playbookのリポジトリを例とします。
https://github.com/oke-py/ansible-osx

masterの少し前のコミットから新しいブランチを作成します。

$ git switch -c tmp 54f5666470363af847ae36340a85bfc3bf50166c

適当にファイルを編集してコミットします。

$ vim inventory/group_vars/local/version.yml
$ git add .
$ git ci -m 'test'

rebaseします。

$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: test
Using index info to reconstruct a base tree...
M   inventory/group_vars/local/version.yml
Falling back to patching base and 3-way merge...
Auto-merging inventory/group_vars/local/version.yml
CONFLICT (content): Merge conflict in inventory/group_vars/local/version.yml
error: Failed to merge in the changes.
Patch failed at 0001 test
hint: Use 'git am --show-current-patch' to see the failed patch
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

ファイルを編集してmasterの内容に修正します。すると

$ git diff
diff --cc inventory/group_vars/local/version.yml
index a1036c0,b44c608..0000000
--- a/inventory/group_vars/local/version.yml
+++ b/inventory/group_vars/local/version.yml

$ git status
rebase in progress; onto 4067153
You are currently rebasing branch 'tmp' on '4067153'.
  (fix conflicts and then run "git rebase --continue")
  (use "git rebase --skip" to skip this patch)
  (use "git rebase --abort" to check out the original branch)

Unmerged paths:
  (use "git restore --staged <file>..." to unstage)
  (use "git add <file>..." to mark resolution)
    both modified:   inventory/group_vars/local/version.yml

no changes added to commit (use "git add" and/or "git commit -a")

差分がなくなります。この状態でgit rebase --continueしてみます。

$ git add .
$ git status
rebase in progress; onto 4067153
You are currently rebasing branch 'tmp' on '4067153'.
  (all conflicts fixed: run "git rebase --continue")

nothing to commit, working tree clean

$ git rebase --continue
Applying: test
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

No changesと言われて進めません。沼から出れなくなりました。

これまではどうしていたかというと、git rebase --abortして抜け出した後、新しいブランチを作成してgit cherry-pickやcp（gitを諦めた！）していました。

どうすべきだったのか、それはgit rebase --continueではなくgit rebase --skipです。よく見るとgit rebaseしたときに出ているんですよね・・・

You can instead skip this commit: run "git rebase --skip".

ふと、これに気付いて解決しました。

おわりに

• git rebase --continue
• git rebase --skip
• git rebase --abort

ちゃんと覚えて使えるようになりましょう、という教訓でした。

サンプルコード

# --containsオプションを付けることで自分が今いるブランチが表示される
$ git branch --contains
* develop

# 先頭の * が邪魔な場合はcutを使用すればいい
$ git branch --contains | cut -d " " -f 2
develop

参考

• 現在のブランチ名を取得するコマンド - Qiita

こんにちは、ZeniZeniです。

問題

最近サークルで複数人開発を経験したんですが、そのときTagやLayerといったProjectSettingsフォルダーに入っているような設定項目の競合でかなり痛い目を見ました。
何が起こったかというと、それらの.assetフォルダはよくある.gitattributeの設定ではLFSのトラッキング対象となっており、バイナリファイルで管理されるようになります。そのため、異なるTag編集を行ったブランチをマージして、コンフリクトが発生したとき、下の画像のように両方の変更を反映させることができなくなります。

しかしUnityプロジェクトをGitHubで管理する場合は、ほとんどの場合でGit LFSを使うと思います。そのため、Git LFSを使ったうえでProjectSettingsフォルダー内のファイルはLFSのトラッキング対象から外して、txtデータで扱う方法が望まれます。
ProjectSettingsフォルダー内のファイルで50MB超えるようなものはない…はず…

対処法

対処法は簡単で、ディレクトリ毎にLFSの適用を変えればいいのです。こちらのサイトが参考になりました。
具体的には、ProjectSettingsフォルダー内にも.gitattributesファイルを新しく作成し、そこに
*.asset !filter !diff !merge text
と書くだけです。

こうすれば、上の画像のようにTagなどで競合が起こった時に、両方の変更をうまく反映させることが可能になります。

初投稿です。

今年5月から勉強始めた駆け出しのフルスタック（完全に立ち往生した）エンジニアです。
冒頭では適当に自己紹介するのがお作法っぽいので自己紹介しました。もう少し続きます。
勉強始めてもう半年ですがもうこの世界は完全に理解（立ち往生）しましたね。
わからないことしかないです。
これ以上はオチがないのでカットします。

本題

さて、そんなわからないことだらけの僕が内外共に唯一褒められたことがある点。
Gitが使えることですね。
いやいや俺も使えるがなw
そんなんで調子乗んな

そう...。

と言うわけで(?)MakeIT AdventCalendar初日では僭越ながらGitの基本的な使い方についてサラーっとメモ程度に書いていきたいと思います。
つい一週間前まで、あるコンテストに出すアプリをチームで開発してたんですけどその中でもaddもcommitもpushもpullもわからんって人が複数いました。めっちゃ辛かった。
オチがつかないのでカットで。

Gitとはなんぞや

ググろうな。冗談です。
でも今回は雰囲気でGitの機能は理解してるけど使い方がイマイチって方対象で端折ります。

基本的なコマンドと用語

repository

リポジトリと読みます。管理場所です。ここにソースコードとかドキュメントをプロジェクト||アプリごとに保存します。
これにはリモートとローカルがあり、ローカルリポジトリになります。
ローカルで作業した内容をリモートにアップロードすることで自分以外の方にも共有できます。

add

$ git add ファイル名

変更したファイルをステージングします。
※ ステージングというのは変更を加えた内容を登録すること

commit

$ git commit -m "クォートの中にメッセージを書きます"

コミットとは、変更を加えた内容と変更前との差分を記録し、ローカルリポジトリに反映します。
git addだけでは仮置きとなるのでこれをしないと実際に変更は反映されません。

push

$ git push

このコマンドでローカルリポジトリに反映させたコミットをリモートリポジトリに反映させて共有します。

pull

$ git pull origin ブランチ名

originはrepositoryを指定しています。基本的にoriginとなっています。
このコマンドで指定したbranchの変更を取り込みます。
※ branchについては↓

branch

ブランチと読みます。
リポジトリを作成した際にmasterと言うブランチが自動で作られるのですが、ここが仕事の成果(出来上がったアプリとかシステム等)が置かれる場所だとお考えください。
ブランチと言うのは一人一人が仕事をするデスクです。
例えば1つのアプリを５人で作ります。
5人分に仕事分ければさっさと終わるのにわざと1人用デスク1つに5人で集まって作業する意味ないですよね。
と言うかお互いの仕事が邪魔でしかないですよね。
5人分のデスクを用意しましょう。理論上仕事は分ければ早く終わります。
ブランチを分けることをブランチを切ると言います。
ブランチを切りましょう。

※ ただし一人の場合は切らなくても構いません。自分しかタスク振られていない仕事にデスクがいくつ合っても意味ないですからね。

※ チームで開発する場合にはチームで決められたルールがあるはずなので従ってください。ルールがない案件に出くわした場合は逃げろ。

$ git checkout -b ブランチ名

参考↓

git branchで現在の自分のリポジトリにあるブランチを確認しています。
ただし、これはローカルリポジトリにしか反映されていません。
これをリモートに反映させるにはコミットと同じようにgit pushします。　※ブランチはgit addする必要はありません。
やってみましょう。

ダメです。怒られます。
fatal: The current branch sample-new-branch has no upstream branch.
To push the current branch and set the remote as upstream, use
要するに"君がgit pushしようとしているブランチはリモートには存在しないけど本当にこのリポジトリで合ってるの？"って聞かれています。
これは別のリポジトリのブランチを誤ってpushしようとしてないか？と言う事故防止の確認ですので初回は必ず聞かれます。
問題なければメッセージの下に書かれている

$ git push --set-upstream origin ブランチ名

を実行しましょう。

え？コマンドが長い？

$ git push -u origin ブランチ名

なんとこれでも同じ意味のコマンドになります。-uはupstreamの-uです。
こっちで覚えましょう。

簡単な流れ

1. ファイルやドキュメントに変更を加えたら$ git addでステージング
2. ステージングしたらgit commitでコミットしてローカルリポジトリへ変更を反映させます。
3. 最後に、git pushでリモートリポジトリにローカルリポジトリとの変更差分をアップロードしましょう。

サンプル

※ 今回はサンプルかつ僕一人しか操作しないのでブランチは切りません。
これに関してはプロジェクトごとにルールとかも決めるべきだし従うべきだと思っているのでここでデモはしません。

ローカル

---

リモート

sample.txtの内容↓

---

変更を加える

-となっている部分が変更前
+となっている部分が変更後

---

addしてcommitしてみる

※ git statusは作業環境の状態を確認する為のコマンドです。
modifiedは修正が加えられたファイル名を示しています。
これをコミットしてgit statusで状態を確認すると

nothing to commit, working tree clean
これは"進捗まだですか？"って意味です。冗談です。
日本語訳すると"現在作業環境内では特に変更が加えられてないからコミットすることなんてないよ。"
つまり先程加えた変更は無事にコミットされたということですね。
確認してみましょう。git logでコミットの履歴を確認できます。

無事にコミットされていますね。
ローカルはこれで反映されましたが、リモートはどうでしょうか。

ローカルでは最新のコミットメッセージは"Fixed text to show diff"となっていますね。
つまりリモートでは反映されていません。

---

pushしてリモートに反映させよう

正常に反映されていますね。

---

pullで変更をリモートからローカルに取り込む

git pushしたばかりなので変更はありません。
Already up to date.となっていますね。
"既に最新の状態だよ"ってことです。

変更がある場合↓

リモートで変更した内容がローカルに反映されました。
このコマンドはチームで開発する時には頻繁に使います。
コミット溜め込んでから投げるやつのせいで発生するエラーがあるのですが、実際に体験して苦しんで欲しいのでここではやりません。

---

あとがき

今回は本当に簡単にしか説明しておりません。PRとかmergeとかも説明してないですしね。
チーム||プロジェクトごとに運用変わったりするので"正解"ってのがないんですよね。
まあまともに運用してて事故がなければ大して難しいことはないしaddとcommitとpushとpullできれば死なないです。
それ以外はチームに従ってください。個人でやる場合はどんどん事故りましょう。
そもそもGit自体が事故が起こっても問題ないようにする為のバージョン管理ツールであると思っているので、どんどん事故って覚えた方がいいです。事故られて怒る奴は運用方法が下手なんだと思います。
ちなみに僕は怒ります。forceされると血管が浮き出るぐらい怒ります。
身に覚えのある方はツイッターで適当に懺悔しててください。

他にも色々書きたいことはありますが、まずはGitの使い方に慣れましょう。
課題とかメモとか、それこそ記事書くときなんかGit使うと便利ですよ。
文字とコードは全部Gitに保存してやるよってぐらいの気持ちで使いましょう。
Git使えないとプログラマーとして終わってるって過激なこと言う人もいるので是非使ってみてください。

最後に、ここまで読んでいただいてありがとうございました。是非他のまともな記事を探してみてください。
advent-calendar初日でこんな初歩的なこと書いててサークル追放されないか心配ですが、明日からは僕と違って優秀な方々が便利なtipsとか便利なsomethingを記事にしてくれると思うのでよかったら見ていただけると皆の記事を書く励みになります。
※ 枠埋まらなくて僕は後5日分ぐらい出没します。

爆速で簡単にgit checkoutをしたい

個人的にvimを使い出してから,vimmerになってきた自分ですがvimを使えば使うほどマウスやトラックパッドを触っている時間がどうしても鬱になってしまう...

gitのブランチ移動も毎日のようにしますが

git branch -> コピペ -> git checkout ペースト

なんてことしていたらそれだけで集中が途切れてしまいます.

なんとかできないものかと頭を抱えていたある日...

pecoとかいう神ツールがあった

え、まだpecoを使ってないの？？？ - Qiita

公式レポジトリはこちら

こちら何かと言うと標準出力をインタラクティブにgrepしてくれることができます.

$ brew install peco

で簡単にインストールできます.

実際使ってみるとこんな感じ↓↓↓↓

標準出力を pipe | で peco に渡してあげるとあいまい検索でgrepできます.

だからなんだって感じですけどこれを git checkout に応用してみます.

git branch | peco | xargs git checkout

master から develop にcheckoutしてみます.

こんな感じで一度もマウスに触れることなく,スムーズにcheckoutを終えることができました.

iterm2なんかを使ってると,コピペがうまくできなくてマウスでカーソル選択して何度も何度も command + c を連打して...

というストレスフルなcheckoutとはもうおさらばです.

何度も使うコマンドってやっぱりできるだけストロークは少なく,快適に終えたいですよね.

とはいえ流石に毎回 git branch | peco | xargs git checkout とか打ってられないので

お好みのshell configにaliasを貼っておくと便利です.
僕は少々乱暴ですけど

alias br='git branch  | peco | xargs git checkout'

ってやってます⤴️

Macでgitをインストールする

公式サイトからインストール

https://git-scm.com/downloads

ダウンロードしたらgitのバージョンをターミナルで確認

$ git --version
git version 2.23.0

https://qiita.com/sudahiroshi/items/3d8adca693cd21d0b849

vi ~/.netrc

machine 192.168.xx.xx
login xxx
password yyy

chmod 600 .netrc

https://qiita.com/r-tamura/items/c6e49a3eb7f7f8aafb9d

GPGでパスワードを暗号化する
GPGとは
GPG (GNU Privacy Guard)はOpenPGPの規格に沿って作られた暗号化ソフトで、GNU GPLのもとで公開されているオープンソースソフトウェア。

.netrcの暗号化
GPGで作った鍵を持っていない場合は以下のコマンドで鍵を生成する
$ gpg --gen-key
鍵生成には時間がかかる場合がある。今回行った環境では30分ほどかかった。
参考 : ssh 越しに「gpg --gen-key」を実行したときに乱数生成の段階までくるとハングしてしまったかのようになるのは，「単に時間がかかっているから」らしい．約20分もかかった．

.netrcを暗号化する
暗号化を行うとホームディレクトリに.netrc.gpgファイルが生成される。次に元の.netrcファイルを削除

$ gpg -e -r ~/.netrc
$ ls .netrc*
.netrc .netrc.gpg
$ rm .netrc

git credential helper用のスクリプトに実行権を与え、gitの設定にcredential helperとして追加する
gitで用意されているgpgを使ったnetrc利用のスクリプトがあるので、それに対して実行権を与えることで使えるようになる。

$ sudo chmod +x /usr/share/doc/git-1.8.3.1/contrib/credential/netrc/git-credential-netrc
$ git config --global credential.helper /usr/share/doc/git-1.8.3.1/contrib/credential/netrc/git-credential-netrc
これで、git push,git pullするときに自動的に復号されるので、ユーザ情報の入力なしでpush,pullができるようになる。

まとめて git pull したいときは

$ find . -name .git -printf '%h\n' | xargs -I{} sh -c 'cd {}; git pull;'

これをaliasにでも登録しておけば、OK

もう少しスマートな方法が分かれば、更新します。

おしまい

はじめに

この記事はGitHub Actions Advent Calendar 2019の８日目の記事です。

５日目にも書いたんだけど、枠が余ってたので書いておこうかなって。

本当はリリースノートの準備をするActionについて書こうかと思ったんだけど、明日の人が書くっぽいので今日はお手軽なネタで、Git のログを綺麗にする rebase について書こうと思います。

rebase

今更機能的な説明は必要ないですよね？
チームで開発してたり、複数機能を並行して開発してたりして、ブランチが入り乱れることってよくありますよね。
気にせずにPRをマージすると、ログが汚くなったり、コミットグラフが入り組んでしまって、割れ窓理論よろしく開発意欲が失われる気分になる諸兄も多いのではないかと。
個人的には交差したグラフを見るとあーぁって気になります。私、気になります。
交差ってほどじゃなくてもこのレベルで、もうちょっとなぁってなる派。

スカッシュマージやリベースマージにする手もありますが、元コミットを残しておきたいとか、リバートするのにマージコミットは必要とかいろいろあるので、できればリベースしてからマージしたいかなと。
するとこうなるわけで。

cirrus-actions/rebase

そこで GitHub Actions でリベースできるようにすれば、ローカルでどうこうしなくても（PRの段階でコミットを整理してあれば）マージボタンを押す前に /rebase とコメントするだけでリベースしてくれる素敵 Action があります。

GitHub action to automatically rebase PRs

何も考えずに、.github/workflows/rebase.yml として、README に書かれているフローを保存しましょう。

後は PR をレビューしてもらって、マージしてもいいことになったら、 /rebase とコメントを打って、少し待ちましょう。

自動的にそのブランチが master から生えたようにリベースされます。

その後普通にマージボタンを押すだけで見やすいグラフの出来上がりです。簡単。

コミットについては言及していません。
typo とか test とかちょっと修正、みたいなコミットメッセージを乱発してれば、それはそのまま残ります。
このコミットを掃除するのはPRを投げた人の責任範囲だと思います。その範囲内でリベースもしてくれれば必要ないのですが、必ずしもみんなが対応できるとは限らないので、こういった簡単な Actions があると便利ですね。

最後に

GitHub Actions 便利ですよね。こういう小さい便利を積み上げていけるといいなと思います。

弁護士ドットコムの ITS/Git 運用ガイドライン

この記事について

• この記事は、 弁護士ドットコム Advent Calendar 2019 - Qiita  の 1 日目の記事になります。
• 初日となる本記事では、弁護士ドットコム株式会社の ITS (Issue Tracking System, 課題管理システム )/Git 運用のガイドラインを加筆修正の上、公開します。
  • 当社でも、開発におけるビジネスの優先順位が不明瞭で、見える化されていない時期もありました。
  • 本ガイドラインは、開発に関わる人員が数人から数百人レベルに成長する過程で、都度メンテナンスされてきた当社の知見です。
• 目新しいものはなく手垢のついた内容かもしれませんが、開発現場を改善する一助となれば幸いです。
• また、公開日の本日は PHPカンファレンス 2019 の開催日です。
  • 2019/12/01(日) 17:00 まで申し込めます。
  • これを読んだアナタもぜひご参加ください。
  • 本記事で、実際に働いているメンバーへ興味を持たれる方もいらっしゃると邪推して、末尾に登壇者情報を付記しますのでご確認ください。

ITS 運用ガイドライン

• 当社では、 ITS として Redmine/Jira/GitLab Issue などを利用してきました。
• ITS を頻繁に変更することは好しくありませんし、どれを使ってもそれなりの運用はできると思います。
• 本件において唯一得た学びとしては、フルマネージドサービスを利用すべきだということです。
• 保守運用や局所最適などの負荷から開放され、本来注力すべき開発に集中することが出来ます。

目的

• 基本的に「個人依頼」ではなく、「チーム共有」する文化を育み、以下 3 つを実現したい
  1. 共有されないことによるリスクの低減
     • 別施策とバッティングして、想定外のバグを発生してしまう
  2. 依頼を受けた人の共有するコストを削減
     • 「〇〇さんに DM したよー。」「聞いてないよー。」
  3. 複数人でフォロー出来る体制で属人化を防止
     • 「今日は私はお休みです。明日以降で対応します。」
• これらは ITS を利用しなくても実現できるが、チケット駆動開発を推奨することで見える化に繋げた
• また、情報整理や対話のきっかけとして、チケットのテンプレートも用意している

チケットテンプレートとは

• 大きく分けて、バグ（不具合）とストーリー（それ以外）、 2 種類のテンプレートを用意している
• テンプレートはあくまでガイドラインなので、全項目を埋める必要はない
  • 軽微な変更や、該当しない項目は空欄可
• テンプレートを無視しても問題ない
  • 詳細な企画書を添付する、あるいはもっと良い書き方があれば柔軟に変更可

バグテンプレート

# 概要

- xxx

# 発生環境

- 端末/OS/ブラウザなど
- バグが発生した日付・時間

# 再現手順

- どのURLから、どのリンクをクリックしたか・どんな値を設定したかなど具体的に

# 期待した結果

-

# 実際の結果

- xxx

# 備考

- スクリーンショットや補足があれば

ストーリーテンプレート

# 概要

- 「誰の」ためのストーリーか
- 「何を」したいのか
- 「なぜ」そうしたいのか

# 背景/目的

- xxx

# 受け入れ基準

- 「これが実現していれば目的は達成できる」という基準

# 対象デバイス

- PC
- SP

# 備考

- スクリーンショットや補足があれば

Git 運用ガイドライン

• 当社では、ソースコード管理サービスは GitLab を利用しています。
• GitLab は、 GitHub に親しい機能を無料で使えることから、当社もオウンド運用をしていますが、そもそも設計思想が異なります。
• 本件において唯一得た学びとしては、フルマネージドサービスを利用すべきだということです。
• 保守運用や局所最適などの負荷から開放され、本来注力すべき開発に集中することが出来ます。

必ずブランチを切ってからコミットする

• no branch, no commit. no ticket, no branch.

目的

• コミット履歴を ITS に確実に紐付けること
• レビューのための下準備

概要

• ブランチ名は feature/1234/hoge-fuga-piyo のように [ブランチ種別]/[ITS ID]/[ブランチ内容] で入力
  • ブランチ名の重複を避けるために命名規則を定義

ブランチ種別

• feature : 機能開発
• hotfix : バグ修正
• develop : 機能統合
  • 大きな開発の際に用意してもよい（通常は不要）
    • develop から feature を切って、develop に対してマージする（レビュー必須）
    • master と乖離しないように、定期的に rebase master する

ITS ID

• チケット駆動開発を推奨
• チケットを切らない場合、コミットメッセージに必ず変更理由が分かる詳細を書くこと

ブランチ内容

• 好きに入力
  • キャメルケースは同名で大文字小文字異なると問題となることがあるので、小文字ケバブケース統一を推奨
    • ちなみに、わたしはケバブケースではなくおでんケース（ oden-case ）推奨論者
• 禁止事項
  • master への直コミット禁止

master ブランチへのマージはレビュー必須

目的

• 必ずレビューを通すことで、ミスを防ぐ
• 業務知識の共有を行うことで、属人化を防止

概要

• GitLab 上でのマージリクエストでレビューを通してから master ブランチにマージ
  • 例外は上長承認が必要
    • 運用しながら事例ベースでルールを作っていく
  • マージリクエストには最低限 ITS URL を記載する

マージリクエストはレビュー依頼者がマージする

目的

• レビュー依頼者がマージ後も確実に動作することに責任を持つ
  • rebase や merge 時のコンフリクト解消も責務

概要

• レビュー依頼を受けた側は、問題なければ以下の様なコメントを残す
  • LGTM
  • 
• 問題はないけど、意味のある粒度でコミットをまとめたほうがよい場合は、その旨指摘する
  • 「意味のある粒度」とは、文末に貼っている Git Style Guide の Commits の項 を参考にしている
• レビューが通ったマージリクエストは、レビュー依頼者がマージする

ボールを持っている人を Assignee にする

目的

• アクションし終わったら都度 Assignee を変更することで、誰がボールを持っているか明示する

概要

• レビューを依頼する時 → レビュアーを Assignee に
• レビューし終わった時 → レビュイーを Assignee に
• LGTM を出した時 → レビュイーを Assignee に (マージするため)
• Assignee は「レビューを放置しない」ことに責任を持つ
• 余りに細かいもの (簡単な質問のやりとりなど) は Assignee を変更しなくともよいが、その場合でも Assignee になっている人が責任を持ってコミュニケーションを取ること

参考

• agis/git-style-guide: A Git Style Guide
• github - Git branch name - case sensitive or insensitive? - Stack Overflow

（おまけ） PHPカンファレンス 2019 について

• 今回は、スポンサー枠、一般応募枠含め、当社関係メンバー 3 名が登壇する予定です。

  登壇者情報

• 天重誠二

  • MVCにおける「モデル」とはなにか
  • 天重さんは、ヒトコトでいうと熱い人です。
  • 弁護士ドットコムの次を支える（であろう）サービスの企画・開発に関わっています。

• 狩野秀明

  • 「弁護士ドットコム」を作り続ける開発組織について
  • 狩野さんは、ヒトコトでいうと中庸な人です。
  • 弁護士ドットコムの問題点を一つひとつ改善し、コード品質に責任を持っていただいています。

• 郡山昭仁

  • REST 6+4の制約
  • 郡山さんは、ヒトコトでいうとエネルギッシュな人です。
  • 社内外問わず勉強会や講演を行っていただいており、良い刺激をもらっています。

追伸

• 正直、その場にいかないと感じられないこともあると思います。
• ぜひ足をお運びいただき、ご観覧ください。

最後に

• 弁護士ドットコムに私は 5 年以上いますが、今が一番面白い時期にきていると思います。
• 雇用形態問わず、「一枚噛みたい」という方や「ちょっと見てみたい」という方は、積極採用中ですのでぜひご連絡ください。