こんにちは、バックエンドエンジニアのグッチです。
今日はGitについて書いてみます。
新年度！ チームメンバーや環境が変わるタイミングで今年はGitに挑戦してみませんか？
簡単な内容のため、あまり深いことには触れずにざっくりとしたイメージを伝えられたらと思います。Gitに精通している人は特に得るものもないと思うので、読み物程度にどうぞ。
HTMLやCSSファイルなどのテキストファイルを書いているけどGitって聞いたことないという人や聞いたことはあるけどなんかよくわからないと思っている人たちが一応ターゲットです。Gitを知ることで仕事の負担が減る人がいたらとても嬉しいなーという気持ちで書いてみました。
続編は反響あったら書くかもしれません。
最近のランチ: カリカリベーコンとホールトマトとシーフードミックスの具沢山トマトクリームパスタ
2人分の材料: トマト缶１つ、生クリーム100ml、具材は食べたいだけのものを適当に
目次
こんなことありませんか？
かなり極端な例ですが、主にFTPなどでレンタルサーバーにファイルをあげているような場合に発生しやすいトラブルが、これからご紹介する3つの事例です。
事例の中では、イメージしやすいという理由で「デザイン崩れ」という表現をしています。我々エンジニアが「バグです！」って言われたときには本当にすっごい焦るし、確認フローに問題はなかったか、もっと確認すればよかった……など、いろいろ頭を巡らせながら急いで確認をします。蓋を開けてみるとバグじゃなくて仕様だったなど、バグじゃないことも多いです。すっごいびっくりします。きっとデザイナーさんも同じ気持ちなので、軽い気持ちでデザイン崩れやバグというのは、極力なくそうと思っています。
事例1：簡単な誤字修正を大規模デザイン改修中に頼まれた
※ この物語はフィクションであり、実在する人物・団体・法律などとは関係ありません。
ある日
-
偉い人: HPの大型リニューアル来週だね！ 進捗どう？
自分: いい感じですよー。もう少しでひと段落するので確認をお願いできると思います。
偉い人: そっかーがんばってー！ あ、そうだここ誤字見つけたから明日のクライアントとの打ち合わせまでに直しておいて欲しいんだけどお願いできる？ １文字だからすぐ直せると思うんだけど。
自分: わかりましたー確認します。
偉い人: ありがとう！ よろしくー！
自分: はーい。- 心の声
- ローカルには大改修中のデータしかないよ？
- 来週全取っ替えするから直すの来週でよくない？
- どうしようめんどくさい……。
いにしえからの対処法
男気バックアップにより作業中のソースコードを退避させてから現行コードを入手・修正する。
- ローカルの作業フォルダのフォルダ名を変える
- 現行のHPのコードをFTPでサーバーからダウンロード
- ローカルの作業フォルダーに展開
- 誤字の修正
- ローカルで表示確認
- オッケーだったらFTPでサーバーへアップロード
- 誤字の訂正をしたフォルダーは別の名前にリネーム（念の為に取っておくことにした
- 元の作業フォルダの名前を戻して作業を進める
- 通称 男気バックアップ とは（LIG調べ）
- すべてのファイルをフォルダーごとコピーするバックアップ方法。
- バックアップするたびに同じ量のファイルができるため、HDDやSSDを圧迫する。変なファイルが紛れ込む、作業フォルダで作業していると思ったらバックアップフォルダだった！ などということが起きるともうなにを信用していいのかわからなくなる。
問題点
- 修正作業はちょっとでも、その修正に入るための作業はちょっとではない場合が多い
- フォルダーを作ってから時間が経つと、中身が果たして正しいのかわからなくなる
- 増え続ける「使うんだか使わないんだかわからないフォルダーやzipファイル」が消すに消せない
後日談
イレギュラーで複雑なことをした場合、なんとか修正できたことでほっとすることでしょう。その結果、大幅リニューアルの作業をしている側では誤字の修正を忘れます。そして、次の事例のように修正していないファイルで上書きしてしまい、誤字が復活するところまでがテンプレな展開です。
事例2：繰り返すデグレ（先祖返り）
※ この物語はフィクションであり、実在する人物・団体・法律などとは関係ありません。
またある日
-
偉い人: デザイン崩れてるから急ぎで直して！ お願い！
自分: ！！！ わかりました！〜〜〜 30分後 〜〜〜
自分: デザイン崩れの修正終わりました！ 本番サーバーにアップロードします！ 表示直ってるの確認できました！ 元のタスクに戻ります！
同僚: 機能追加の実装できました！ 本番サーバーにアップロードします！ 動作確認できました！ 次のタスクに移ります！
偉い人: デザイン崩れってさっき直したんじゃなかったっけ？ まだ直ってないから確認お願い！
自分: はははーそんなわけないじゃないですかーちゃんと直しましたよー？ ほんとですよー？〜〜〜 確認後 〜〜〜
自分: そんな……ばかな……
いにしえの対処法
- コミュニケーションミスが減るようにがんばる
- お互いのタスクを認識するようなフローにする
- 次は気をつけよう！ とみんなで認識を新たにする
問題点
- そしてまたやってしまう
事例3：先月変更した内容を元に戻して
※ この物語はフィクションであり、実在する人物・団体・法律などとは関係ありません。
そしてまたある日
-
偉い人: 先月のデザインの大幅リニューアルお疲れ様！ クライアントからの評判もいいよ！ ただ、やっぱり前の方が良かったって言われた箇所があるんだけど、ここの部分だけ戻せる？
自分: ほほう……- 心の声
- とりあえずどこかにあるバックアップを探そう
〜〜〜 数十分後 〜〜〜
自分: 先月のバックアップを確認したけど、ここの修正はこのタイミングじゃない。もっと前だ……さらに遡らないと……〜〜〜 数十分後 〜〜〜
自分: やっと見つけた……。けど結局デザイン見て0から書き直した方が早そう。というかここの修正は先月じゃなくて先々月じゃねーか。先月ってなんだよ！ 嘘つき！
いにしえの対処法
- フォルダーを丸ごとzipなどにしてバックアップを行う
- 置き場に置いておく
- 細かい修正分までぜんぶバックアップするのは面倒なため、節目節目でしかバックアップを取らないことも多い。
問題点
- バックアップのない時点に戻れと言われると詰む
- 日付間違いなどにより、いつのなんのバックアップなのかわからないものができ上がることがあり、消すに消せない
- 誰かが大事に保存しているはずだけど、どこにあるのかわからないという事態になったりする
- 最悪実装箇所が少なければ、バックアップを無視してやり直した方が早いときがある
こういうの、なんとかしたいって人へ
上の3つのエピソードを見て、「あるあるー！」となっている人、「こんなのありえるのか……？」と思う方、いろいろいらっしゃると思います。
我々Web制作会社では通常、Gitを使ってきちんとソースコードのバージョン管理がされているため、このような事故はほとんどありません。一方で、小さい規模の会社やエンジニアのいない部署でWeb周りを管理しているような現場では、まだまだ見られる業務フローではないでしょうか？ そういった状況を、バージョン管理ツールの利用で防ぐことができます。
バージョン管理ツールを使おう
人がミスをするとき、原因が人ではなく作業フロー自体という場合が多くありますよね。
「ソースコードのバージョン管理」を行うことで、これらの事故が減ります。
今回紹介するGitはソースコードのバージョン管理をするのに適しているツールで、ソースコードの変更をコミットという形でぜんぶ履歴として保持することで、すべての変更の履歴をたどることが可能になります。
- コミット
- 誰がどのファイルをどう変更したのかを保存しているデータの塊
みなさんも結果にコミットしましょう。
Gitを導入するにあたって
通常、Gitを使いはじめるにはホスティングサービスでアカウントを作ることになります。ホスティングサービスはいくつかあり、料金体系や無料でできることが異なるので自分たちのチームにあったサービスを選びましょう。
LIGでは主にGitHub、Bitbucketを案件に合わせて使っています。
注意してみる必要がある項目は、
- リポジトリをいくつ作れるか
- プライベートリポジトリが作れるか
- リポジトリへの参加者に制限はあるのか
など。
リポジトリとは、ソースコードなどのファイルを置いておく置き場所のこと。デフォルトでは世界中の人に公開されるようになっています（パブリックリポジトリ）。そのため、クライアントから依頼されたWebページや会社のHPなど、公開してはまずいものは許可した人しか見れないようにする必要があります（プライベートリポジトリ）。
GitHub
無料でプライベートリポジトリが作成できますが、複数人に編集権限を渡したい場合には３人までという制限があります。
僕は主にここを使っています。
Bitbucket
無料でプライベートリポジトリが作成できますが、複数人に編集権限を渡したい場合には5人までという制限があります。
ほかにもいろいろありますが、最初はこの二つのうちどちらかで始めるのがオーソドックスな気がします。どちらも個人で使うのか、複数人で使うのか、商用利用なのか、チームの規模はどれくらいかなどにより、無料で使える範囲や有料プランの料金が異なるため、自分たちにあうかどうか比較、検討が必要です。
有料プランにする必要がある場合は、会社に頑張って交渉しましょう。LIGブログでおすすめって書いてあったって言えばきっと稟議も通りやすいと思います、たぶん。
何が嬉しいの？ メリデメ教えて
とはいってもそんな美味しい話あるわけないと疑っている人もいるでしょう。ここではメリットとデメリットを並べてみます。
メリット
- デグレのリスクが減る
- いつだれがどんな変更をしたのかほぼすべて記録に残る
- ネット上にソースコードを安全に保存できる（有料の場合あり）
- ソースコードをなくすリスクが少ない
- 新しいメンバーが増えたときにデータを渡しやすい
- 転職するときに「Git」使えますと言うと強いかもしれない
Gitのホスティングサービスを使うメリット
- メンバー間でチェックし合うための機能が入っている
- PR（Pull Request）、プルリクエスト、プルリク
- レビュー時に自分では気づけないバグや崩れに気づける
- ほかの人のコードの書き方をレビューすることで自分のスキルアップになる
- どこをどう直して欲しいのか指摘しやすい
- PCの故障や盗難、担当者の退職などでコードを紛失するということがない
- バグった場合にも、コードを書いた人・レビューした人二人の責任なので一人だけが責められることがない
- PR（Pull Request）、プルリクエスト、プルリク
- バグや要望、タスクを整理する機能が入っている
- issue（イッシュー）
- バグ報告、改善要望などを書き込み管理できる
- 修正が終わったものはクローズすると、まだ直っていない課題だけ見れる
- いつ何をやったか振り返れる
- board（ボード、カンバン）
- タスクが今どんな状態なのか整理できる（TODO、レビュー待ち、完了など）
- issue（イッシュー）
デメリット
- 理解度が上がるまであたふたするため、導入初期にはほとんどの場合作業効率が落ちる
- 学習コストが高い
- Git特有の概念の理解がけっこう大変
- ブランチ
- コミット
- プッシュ
- プル
- フェッチ
- マージ
- プルリクエスト
- コンフリクト
- etc…
- 操作方法の習熟（後述するGUIのソフトを使えば多少マシになるはず）
- Git特有の概念の理解がけっこう大変
- チームに一人でもGitやだ！ きらい！ むり！ という人がいると崩壊する（自分だけGitを使うのも可能ではありますが、チームで使うことで本来の威力が発揮されます）
- 運用ルールを決めないとぐちゃぐちゃになる
- 使い方が複雑なため、詳しい人がいないと不安
- たぶん最初は誰でもGitやだ！ きらい！ むり！ ってなる
GUIツールがオススメ
Gitはコマンドでぜんぶの操作が可能ではありますが、かなりハードルが高く、最低でも導入時にはGUIツールの利用をおすすめします。
Sourcetree
https://www.sourcetreeapp.com/
基本無料で使えるので、通常はこちらを使うことになるのでは。設定をやったことのない人には少しハードルが高いかもしれませんが、解説サイトを見ながらチャレンジしてみましょう。
職場のPCではこれを使っています。
GitKraken
UIがとても綺麗で可愛いので、プライベートでの使用のためにインストールしています。個人利用や1年目のベンチャーは無料で使えるようですが、通常は商用利用には課金が必要なので注意しましょう。Pro版は$4/月ほどかかります。
まとめ
Gitについて詳しく説明するとブログの1記事の文量を大きく逸脱するため、今回はざっくりしたイメージを書いてみました。それでもかなり長くなってしまいましたが……！ 具体的な話を知りたい方はLIGの過去記事でシリーズ化されているので、ぜひ読んでみてください。
ほかにも、この記事の中にあるキーワードやソフト名に「使い方」などを足して検索してみてください。
「Git 使い方 わかりやすい」とか「Sourcetree 初期設定 GitHub」などで検索するとわかりやすく説明してくれてる人がいるのではと思います。
それではまた！
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
