こんにちは。
現役エンジニアの”はやぶさ”@Cpp_Learningです。
チームでソフトウェア開発をしています（最近はチームリーダを務めています）。
ソースコードの管理にはGitを使っています。
Gitが便利なのは間違いないのですが、どんなに便利なものでも使い方を間違えると大変なことになります。Gitや刃物は正しく使いたいですよね。
本記事では、チームでソフトウェア開発をした経験から「このGitの使い方は良くないよな…」という「Gitの悪い使い方（アンチパターン）」を紹介します。
という人は以下の記事が参考になります。
なぜ正しい使い方ではなく悪い使い方を紹介するのか？
「Gitの正しい使い方」を考えてみると…意外と難しい。。
チームで話し合い「Gitの運用ルール」を決め、上手く運用できれば正解だと思いますが…
チームAとチームBが合併したとき、各チームで「Gitの運用ルール」が異なると、とても揉めます。。
また、ルールをガチガチに決めてしまうと自由度が減り窮屈な開発になってしまいます。
そのため、これだけは知っておきたい「Gitの悪い使い方（アンチパターン）」をチームで情報共有し「Gitの悪い運用は避けつつ、より良い運用方法を模索しましょう」という方針でソフトウェア開発を進めています。
本当にあったGitのアンチパターンまとめ
以下の基本概念を理解していれば、自然とGitのアンチパターンが見えてきます。
『ソースコードを管理するのためにGitを使う』
以降から、社内で本当にあったGitのアンチパターンを紹介します。
他人のアカウントでログインしてコミット
チームの全員が使用できる共有PCからGitを使う場合、誤って他人のアカウントを使ってコミットしてしまう人がいます。
「ソースコード管理」を具体的に書くと以下の通りです。
【ソースコード管理】
- ソースコードの変更履歴（差分）が分かる
- いつ・だれが・何を変更したか分かる
- ソースコードのバージョンが分かる
「ソースコード管理が上手くできない」というのは、上記❶～➌のどれかが分からなくなるパターンがほとんどです。
今回の場合「だれが変更したか？」が分からなるGitのアンチパターンです。
ファイル名を変更する
ソースコードを書いている途中でファイル名を変更したいときがあります。
例えば、”image.cpp”に動画を扱う処理が書かれていたら、”video.cpp”にファイル名を変更したくなります。
しかし、Gitで管理しているのは”image.cpp”のソースコードなので、ファイル名を勝手に変えると管理できなくなります。
ケースバイケースですが、”video.cpp”を新規作成してGitの管理に追加し、ソフトウェア開発を進めた結果、本当に”image.cpp”が不要だと判断できた場合には、Gitの管理から削除するのが良いと思います。
ソフトウェア開発をする前に、クラス図を設計していれば、不適切な名前のファイルを減らすことができます
コメントでソースコードの編集履歴を残す
ときどきソースコードにコメントを多用する人がいます。
適切なコメントはソースコードを理解する補助になりますが、不必要なコメントはかえってソースコードの理解を妨げます。
例えば、以下のようなコメントを書く人がいます。
int a = 0; // hayabusaが追加
こんなのも
// 2019/10/02 修正
void hoge();
ソースコードをGitで管理していなかったときの名残りで、変更履歴をコメントで書く…
このようなコメントは不要です！変更履歴はGitが管理してくれるので、安心してください！
「いつ・だれが・何を変更したか？」については、全てGitが管理してくれます
ソースコード全修正❶ -コーディング規約編-
タブはスペース4つ分が好き？その気持ち分かるよ！
え？スペース２つのコードがあったから全部直した！？
…そのエディタのタブ設定スペース２つになってるよ。。
結果、Gitのリポジトリに「コード全修正」の履歴が残りました。
Gitのルールより先に、コーディング規約をチームで話し合うべきでしたね。
統一感のないコードは読みにくいので、Gitのルールより先にコーディング規約を検討することをオススメします
ソースコード全修正❷ -コンフリクト(conflict)編-
え？プッシュ(push)できない？
多分コンフリクト(conflict)だね。じゃあプルリクエスト(pull request)を…
何？プル(pull)し直して、コード全部消して修正分をコピペしたらできた！？
…それ誰かの修正（コミット）を無視したのと同じだよ。
エラーが出ない方法を模索するのは、とても大切な作業ですが「そもそも何故エラーが出たのか？」を考えることが重要です。
Gitに限らずエラーメッセージを読みましょう
ソフトウェア設計図がない
基本的にUMLでソフトウェア設計図を作成し、開発する機能を明確にしてから、Gitによるソースコード管理を実施するのが良いです。
そして、クラス単位あるいはパッケージ単位で担当者を割り当てれば、１つのソースコードを複数人で編集するケースが減るため、結果としてコンフリクトの発生頻度を減らせます。
個人的には、コンフリクトが発生しやすい状況を作らないことが重要だと感じています。
コンフリクトが頻度に発生している開発は、一度ソフトウェア設計図を見直し、担当者を明確にすると良いかもしれません。
１つのソースコードを複数人で編集すると、コンフリクトが発生しやすいです。クラス図などのソフトウェア設計図を作成し、どのクラスを誰が担当するかを決めておくと、コンフリクト発生頻度を減らせます
プッシュ忘れ
繰り返しますが、コンフリクトが発生しやすい状況を作らないことが重要だと感じています。
プッシュ（push）し忘れると、派生元の異なるブランチができやすく、結果としてマージするときのコンフリクト発生率が高くなります。
帰宅前に必ずプッシュすること
みたいなルールでGitを運用しているチームもいるようです。
「どのタイミングでプッシュすべきか？」については、一度チームで話し合うと良いですね。
コンフリクトができるだけ発生しない開発を心掛ける
コミットメッセージが言葉足らず
なぜこんな修正を？コミットメッセージは…
〇〇さんの指示通りに修正
うーん。Issueのリンクとか張ってあれば指示の内容が分かるかもしれないけど…
コミットメッセージには、コミット内容（どう修正したか？など）を簡潔に記述してほしいです。
「だれの指示で」みたいな情報は、Gitではなくプロジェクト管理ツールを使うのが良いですね。
コミットメッセージとソースコード変更履歴（差分）をみて、コミット内容を理解できるのが理想的です
Second commit is major update
ソースコードを大幅修正してからコミットする人がいます。
これは、極論すれば「コミット＝メジャーアップデート」みたいになっています。
マージ前のコードレビューが大変になるし、万が一コミット後のコードが動かず、リセット(reset)する場合、大幅な手戻りが発生します。
どれくらいの頻度でコミットするかは、チームで話し合う必要がありますが…
変数名を変更
または
不要なコメント削除
これくらい小さな修正でもコミットすれば良いと考えています。
小さく小さくコミットして、手戻りが発生しても微修正で済みようにしたいですね
masterブランチで直接作業
masterブランチは、リリースしたソースコード、あるいはリリース可能な品質のソースコードを管理するブランチです。
そのため、masterブランチで直接作業してはいけません。
他のブランチで作業し、テストも済ませ、リリース可能な品質を保証できた時点でmasterブランチにマージ(merge)します。
という人は、以下の記事が参考になります。
ブランチ名が不適切
ブランチの命名規約には、とても悩んでいますが、developブランチから派生したfeatureブランチなら以下のような命名が良いと感じています。
【ブランチ命名規約】
- feature_[派生元バージョン]_[クラス名]
- feature_[派生元バージョン]_[機能名]
一方、以下のような命名は悪い例だと感じています。
【悪いブランチ名】
- branch_hayabusa
ブランチであることは、明白なので”branch”というブランチ名には何の情報も含まれていません。
”branch”ではなく、”feature”や”hotfix”などを頭につけ、どういう意図のブランチか明示すると良いです。
あと、繰り返しますが「誰が変更」という情報はGitが管理しているので、ブランチ名に担当者の情報は不要です。
ただし、コンフリクトの発生リスクを下げるために、担当者を明示する場合は問題ありません（突発的な対応で手の空いてる人が一時的に担当する場合などを想定）
おわりに -Gitを気持ち良く使うには-
今までに経験したGitのアンチパターンを思い出しながら、本記事を書きました。
他にも「ウッ」となるアンチパターンがあった気もするけど…思い出せないので、これくらいにしておきます（思い出したり、今後の開発で何か気づきがあれば追記します）
冒頭にも書きましたが「正しいGitの使い方」はチーム毎に異なると思うし、細かいルールを決めなくても上手く運用できてるチームもいます。
ただし、「Gitの悪い使い方（アンチパターン）」については。どのチームも共通だと感じたので、備忘録も兼ねて「アンチパターンまとめ」を作成しました。
本記事で紹介したアンチパターンを回避するだけで、Gitによるソースコード管理が上手くいくかもしれません。
本記事が「Gitの運用ルールを見直すきっかけ」あるいは「Gitを気持ち良く使うためのヒント」になれば嬉しいです。
