社内向け研修資料をQiitaに残しておくシリーズです。本記事では、チームで開発している時の基本的なGitの使い方とどうしてそうなるのかの理由についてまとめてみます。

「理由はわかったので、じゃあ具体的にどういうルールで運用するの？」と思った方は「Git Flow」で検索するか、弊社スタッフであれば各プロジェクトのBacklogのWikiに記載してあるGit運用フローを参照してください。

それでは始めましょう。

Git とは？

現在ソフトウェア開発において広く使われているバージョン管理ツールです。ソースコードに与えた変更点をコミットという単位で記録します。差分が履歴として残ることで、いつ誰がどんな変更を行ったかという情報が残り後から参照できますし、任意の時点の状態を呼び出すことが可能です。

Git の基本的な使い方の解説はサルでもわかるGit入門がおすすめです。

チームで Git を使ううえでもっとも重要なことは？

ズバリ、「他の人に迷惑をかけないこと」です。さらに具体的には、「無意味な履歴を残さないこと」「自分だけの失敗を履歴に残さないこと」になります。

よく「コンフリクトを起こさないこと」と勘違いされるのですが、コンフリクト自体は場合によっては不可避ですし、適切に解消できるものなので、怖がる必要はありません。

無意味な履歴とは？

ホワイトスペースのみのコミットがこれに当たります。例えば、

• 改行コードがLFのファイルをCRLFにしてコミットしてしまう
• スペースによるインデントをタブにしてコミットしてしまう

…など。これらのコミットはコードの改修でもバグ修正でもなく、なんの意味もありません。しかも、git blameでそれぞれの行がいつ最後に変更されたのかを調べる際も、改行コードの変更が全ての行で行われたという記録が残ってしまい、バグ探しの邪魔になってしまいます。Windowsで開発に参加する際は注意してください。

Git には改行コードの自動変換の設定があります。

また、コーディングガイドラインが制定されている時は、PHPであればPHP Coding Standards Fixerを使うなど、自動でコーディングスタイルを合わせてからコミットする方が良いでしょう。CS Fixer自体の設定もチームで合わせる必要がありますが、concrete5であれば設定ファイルが公式リポジトリに含まれていますし、同様のプロジェクトも多いでしょうから、うまく活用しましょう。

自分だけの失敗とは？

Gitに失敗を残すなという話ではありません。バグがいつ発生しいつ解消されたかというのは、プロジェクトの保守の上で重要な情報ですので、隠ぺいはよくありません。

しかし、自分のローカル上だけで発生した失敗は別です。例えば、そもそもの指示を勘違いしていて作り直す、コミットする必要がないファイルをコミットに間違って入れてしまった、などです。このような、そもそも存在する必要がないコミットが履歴に残ると迷惑ですし、修正する作業が無駄です。

（ただし、そのコミットが本番環境にリリースされていないことも条件です。どんな凡ミスでも、本番環境へのリリースまで行ってしまったら、きちんと修正コミットを履歴に残すべきです）

このような自分だけの失敗でプロジェクト全体に迷惑をかけないために、ブランチという機能があります。

ブランチとは？

ブランチ＝枝の用語の通り、時系列に連なった変更履歴を枝分かれさせることができる機能です。枝分かれさせることのメリットは、複数の作業を同時並行することができるという点です。作業ごとに時系列が異なる場合があります。

例えば、Aという修正とBという修正が同時に動いているとします。Aの修正は先に終わりコミットしたが、クライアントの確認に時間がかかっている。Bの修正はあとで終わりコミットしたところ、クライアントからすぐにリリースしてほしいと言われた。Aの修正はまだOKが出ていないので、いったん元に戻すコミットをするべきでしょうか？

答えは、それぞれのブランチを分けておく、です。Aの作業をする際に、A用のブランチを作成してそこで作業する。Bも同様です。このようにブランチを分けることで、リリースしてもよいブランチだけマージすることができます。マージとは、分岐した枝を再度合流させることです。

また、ブランチを分岐しておけば、ブランチごと破棄することができるのも便利なポイントです。

ということで、具体的な作業手順の一例

1. masterブランチをチェックアウト
2. 作業ブランチを分岐（ブランチ名はチームで決められたルールに従いましょう）
3. ローカル環境で開発し、レビューしてもらえる状態になったら作業ブランチをoriginにpushする
4. Backlog(もしくはGitHubなど)で、作業ブランチからdevelopにプルリクエストを作成し、レビューを依頼する
5. 問題なければレビュアーが作業ブランチからdevelopにマージしてくれますので、開発環境にデプロイしクライアントに確認を取ります
6. 確認が取れたら、作業ブランチからmasterにプルリクエストを作成します
7. 問題なければプルリクエストがマージされますので、本番環境にデプロイします

上記の手順は、masterブランチを本番環境と同期したブランチ、developブランチを開発環境と同期したブランチと簡略化したワークフローを想定しています。また、自社サービスではなく受託開発におけるフローをイメージしています。

実際には他の環境のブランチやリリースブランチも存在しますので、くれぐれもチームのGit運用ルールを確認しましょう！

なぜmasterから分岐すべきなのか？

ここが強調したいポイントです。なぜdevelopからの分岐ではダメなのか。理由は、作業ブランチをdevelopから分岐してしまうと、masterにマージできなくなるからです。

developブランチには、開発環境でのみ存在し、まだリリースしてはいけないコードが含まれている可能性があります。そこから作業を開始してしまうと、それらのリリースできないコードが作業ブランチに混入してしまいます。こうなると、もうmasterブランチにマージができません。

作業ブランチは、本番環境に出してもいい状態のブランチから分岐するのが原則です。

コミットの単位について

最後に、これもよくある「どのくらいの頻度でコミットすべきか？」問題について少し補足しておきます。これはググっても諸説あるのですが、個人的にはコミットは作業ログではない！という記事に共感します。

ひとことでまとめると「お願いだからレビューしやすいコミットにしてくれ」ってことなんですが、こればかりはレビュアーになってみないと分かりにくい感覚でもあるので、「少なくともコミットした時点ではバグがないようにしたほうがいい」と言い換えても良いと思います。CTOからお小言を言われながら覚えるしかないのかもしれません

業務でSSHを使ってAzureのDevOpsのリポジトリに接続する機会があったので方法をまとめます。
GitクライアントはSourceTree、TortoiseGitで確認済みです。

1. SSHキーを作成する

1. 以下のコマンドを実行する

ssh-keygen -C "{リポジトリに登録しているメールアドレス}"

1. パスフレーズが求められるが、今回は設定しない

C:\Users\user>ssh-keygen -C "{リポジトリに登録しているメールアドレス}"
Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\user/.ssh/id_rsa):
Created directory 'C:\Users\user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\user/.ssh/id_rsa.
Your public key has been saved in C:\Users\user/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:QyvGK*****Y7C5n*****sZ5c7*****a6p2B*****Dqk {リポジトリに登録しているメールアドレス}
The key's randomart image is:
+---[RSA 2048]----+
|   ***           |
|    ***          |
|*****+ o.        |
|....+***o.       |
|.E+..B+=S        |
|o***+.B. .       |
|**** = .         |
|B*= +*****       |
|=O=. o ***       |
+----[SHA256]-----+

これで、C:Users/{ユーザー名}/.sshに公開キーと秘密キーが生成される

2. DevOpsのリポジトリに生成したSSHキーを登録する

1. 下記画像の通り、セキュリティページにアクセス

1. SSH public keysを選択し、Addを選択する

1. 生成した公開キー(id_rsa.pub)の中身のテキストを貼り付ける。

この時、空白行が入らないようにすること

Discriptionには、任意のわかりやすい名前を付ける(例：会社のPC)

1. Saveを押し、保存する。

3. Cloneする

Clone画面でSSHタブを選択し、SSH用のURLをコピーし、SourceTreeやGitコマンドでcloneする

Pageantに秘密鍵を登録しておく

Cloneする前に、SSHの認証エージェントであるPagent(Putty等に同梱されている)に1で生成した秘密鍵(id_rsa)ファイルを読み込む。読み込む際、ppk形式に変換する。

変換方法は以下を参照

SSH秘密鍵をPutty形式に変換する方法

参照・引用

https://docs.microsoft.com/en-us/azure/devops/repos/git/use-ssh-keys-to-authenticate?view=vsts

たまにgitのコミット日時を変更したくなるときがあります。

git rebase -i

をしたらいけるかと思っていたのですが、いけませんでした。

どうやるか

git commit --amend --date=now

これをやると、直前のコミットの時間を修正して、今の時間にコミットしたことにしてくれます。