#初めに
客先でGit番長みたいな扱いになりつつあるのですが、不慣れな方が結構やりがちなミスの傾向がつかめてきました。
社内外でgit運用を広める流れがあるのでたたき台としてまとめてみます。参考にして頂ければリベースする苦労が報われて幸いです。
前提としてgit自体の設定こそ済んでおり、git cloneかgit initでローカルリポジトリ作成を実施して作業し始めたあたりの初心作業者がやりがちなミスを想定してます。
#パターン1 Gitなのにコピーされたファイルが増える。
例えばtest.txtというファイルがリポジトリに登録されてた場合に、test_0118.txtとかtest_old.txtを追加したコミットをされる初心者の方って結構いる場合があったりします。
これに関してはgitの概念をなんかアクセスが若干不便なファイルサーバみたいな認識になっていると陥りがちです。
特に新しい改修の方として別名ファイルを参照するように修正が入っているとdiffが結構面倒なことになりますね。
(なりました。)
##パターン1の対策
まずテンポラリの改修を複数パターン試したい場合、
- それぞれを別ブランチで試す。
- 適宜stashを駆使する。
等の徹底を図ってもらいましょう。最悪テンポラリでファイルを追加するにしてもコミット時には動作として上手くいっているファイルを元のファイル名と同じに合わせてもらい、それ以外のファイルはコミットに含まない形でコミットを作成してもらいましょう。
Gitはファイルを差分で管理する(雑な表現)という前提を理解してもらうと不必要にファイルを増やすことを避けてもらえるように思われます。
#パターン2 .gitignoreに追加すべきファイルが残っている。
これも初心者のうちはあると思います。コミットに個人の開発環境で出たログ等を含める必要は大抵の場合ないのですが、初心者のうちはよくわからずコミットに含めがちです。
パターン1に関しても言えるのですがgit使い始めの人はステージングの概念をあまり分かっていない面もあるため、差分として見つかったものを全てステージングし、コミットしてしまう場合が多いようです。
##パターン2の対策
共通で作業を行う際は先に.gitignoreを慣れている人が編集しておくのが一つの手です。
またステージングの概念に関しても早いうちに理解してもらい、良いコミットを作成するのに慣れてもらうのが良いかもしれません。
#パターン3 コミットメッセージに書くべき情報がない/コミットメッセージに不要な情報がある。
これに関しては初心者関係あるか微妙ですが起きちゃったからにはもう…ね…！って感じで記載しておきます。
以前Git活用方法を伝えた初心者の方のpushされたコミットを確認してみた所、
タイトル行:(変更したファイル名.c)
メッセージ本文:(変更したファイル名.c)を改修
のようなメッセージが出てきたことがありました。これに関してはどのファイルを改修したか？という情報に関しては基本的にすぐ見れるのでコミットメッセージに書くことは正直意味がないです。
むしろコミットメッセージに関してはwhyの部分、何を目的に改修したのかをリポジトリ毎のルールで書いて欲しいと思います。
そのままだとこの辺の作業が全く意図を理解不能になるためコミット内容の方からコミットメッセージを類推・メッセージを修正し本人に確認を取りました……。
##パターン3の対策
コミットメッセージのルールを確認し、誰かが変なメッセージを即座に指摘できる体制づくりが大切かと思われます。
今回の場合は本人がローカルだけにコミットを保持しており、発見が遅れた面があります。
特にテンポラリのコミットでない場合かつブランチを切っている場合は他の作業者に状況を見せる意味でもローカルにコミットを保持し続けず、pushはマメに行うことを徹底してもらいましょう。
#さいごに
あまり凝った内容となっていない(ある程度フェイクを含みたいのもあってボカシた表現になっているのもあります)のでわかりにくい面も多いですが、あるあると一笑して頂いたりこういう点は気を付けようなどと思っていただければ幸いです。
あくまで決してこういったコミットをした人を非難したい訳ではなく、既にできる側から教えるときこういうことに注意してもらうよう教えていくとよりスタートや理解が早まるかな等の共有ですので、うっかりやってしまった人を責めずチーム一丸となってやっていきましょう。
またGit番長の皆様へ置かれましてはこういう事例があってもめげずに頑張っていきましょう。私もこんな事ありました等言っていただけると励みになります。
ここまでお読みいただきありがとうございました。