暑い日が続き、体調不良になりがちな季節ですが如何お過ごしでしょうか？
8月に突入し、これから夏のインターンシップが始まる時期ですね！
Gitを使っている会社にいるので、今回はGitについての記事を書こうと思います。
「Gitを使う会社に行くけど実際にチーム開発で使ったことがない」「転職先がGitを使っている会社だった」と不安になる人は多いと思います。
そのような人向けに今回は実務でGitを使う場合に発生するイベントを1つ1つ追いながら、役に立ちそうなポイントをまとめていきます。
※ この記事内にはCommitとコミット2つの書き方がありますが、英語はコマンド、カタカナは名詞を表しています。
PCの環境構築をしよう
スタートアップ企業等でなければ、PCを貸与されると思います
まずは環境構築を行いましょう。
環境構築とはPCに開発に必要なソフトや設定をしていくことです。
ここは基本的に手順を教えてもらいながら行うことになると思います。
口頭になるか、ドキュメントを読んで指示通りに必要なソフトを入れていきましょう。
セキュリティに関わる設定が多く出てくると思うので、指示通りに進めましょう。
なお、この時点で分からない部分が出てきたり、エラーが発生した場合、企業側のミスであることが多いです。
聞かなければ分からないことが多い部分なので、分からないことがあれば積極的に質問しましょう！
SourceTreeについて
SourceTreeはGUI上でGitを扱うことが出来るツールです。
Gitの初学者向けの本でよく紹介されていることが多いです。
「WindowsでGitを使う」「とりあえず今回だけGitが使えれば良い」という方はこちらの方が良いと思います。
ただMac（Linux系）を使うエンジニアで、長く働いていきたい人にはSourceTreeはあまりオススメしません
理由としては、
- コマンドを意識しない使い方になる（エンジニアならターミナル触れるようになろう）
- コンフリクト解消が面倒
- Git Hook などの次のステップに行く耐性が身に付かない
などがあるためです。
迷ったらTigというツールを使おう
Git関連で入れるべきツールを挙げるならTigというターミナル上で動くツールをオススメします。
CUI上で使用するGitクライアントツールですが、ブランチの確認→addやcommitの流れがとてもスムーズに出来ます。業務でもよく使用しています。
ですが、gitコマンドには慣れ親しんでおくと後々助かることが多いので操作はgitコマンドを使うようにしましょう！
GitリポジトリをCloneしよう
環境構築が終わったらいよいよソースコードをダウンロードします。
GitリポジトリをCloneしましょう。接続先は教えてもらえると思います。
なお今回はmacのターミナル上で操作した場合を想定しています。
git clone git@~~~~~~~~.gitこの時点でよく発生しうるエラーは
remote: Repository not found.Permission denied (publickey)です。（エラーの長文の中に↑が含まれているのでよくエラーを確認してみてください）
remote: Repository not found. が出たら
こちらはリポジトリがないというエラーです。
具体的にはcloneで入力した、git@~~~~.gitが誤っている可能性があります。
まずは、接続先を確認しましょう。打ち間違いがないか、git@ の部分が抜けていないかなど、エラーが出たらすぐに誰かに助けを求めるのではなく、調べることも大事です。
打ち間違いを減らす意味ではコピペは有力です。電子版の導入手順書の場合はコピペを有効活用することで、時間短縮だけでなく、ヒューマンエラーを減らすことにも繋がります。
ちゃんとやっているはずなのにエラーが出る場合は、アカウントが発行されていない、または権限がない場合があります。
Gitでは閲覧権限がない場合、実際に存在していても not found. を返します。
権限がない場合は担当者に確認をしてみましょう。
Permission denied (publickey) が出たら
その名の通り権限がないです。
ただ、Repository not foundと異なり、秘密鍵周りの権限で弾かれていることが多いです。
こちらのエラーが出た場合は、秘密鍵の生成手順や公開鍵が登録できているか確認する必要があります。
生成手順以外は自分でどうにか出来る部分ではないので、担当者に確認を取りましょう。
ブランチを確認しよう
無事にCloneしたらmasterブランチを確認してみましょう。
確認方法は何でも良いのですが、個人的におすすめは↓です（tigでも可）
git log --oneline --graphブランチから分かることは以下の2点です。
- ブランチの命名規則
- ブランチ運用法（Merge運用か、Rebase運用か）
ブランチの命名規則
個人開発ではmasterにどんどん積み重ねる方法でも良いのですが、チーム開発をするとブランチ分けは必須です（ブランチを切るという言い回しが多いです）
なお、ブランチの名前は自由に付けることが出来ます。
そのため、チームによってブランチ名のルールが色々あります。
- feature/[機能名] （接頭語や機能名を各自付けていくパターン）
- suzuki/[チケット番号] （名前やチケット番号が入るパターン）
- その他色々…
新機能はfeature（futureじゃないよ！）、不具合修正はbugfix、緊急性のある修正は hotfix … など、ブランチの役割ごとに接頭語に決まった単語を入れるルールや、開発者の名前を付けて担当が誰かをわかりやすくしているルールが存在します。
git branch -rCloneしたディレクトリで↑のコマンドを叩くと過去に作られてきたリモートにあるブランチの一覧を確認できます。
注意しなければならないのが、feature/ 等はブランチのある場所を表しており、feature/[機能名] はfeature ディレクトリに[機能名]ブランチを置いていることになります。
そのため、bugfixというブランチとbugfix/[機能名]のブランチを共存させることは出来ません。
作ろうとしてもエラーが出てしまいます。
fatal: cannot lock ref 'refs/heads/bugfix': 'refs/heads/bugfix/test' exists; cannot create 'refs/heads/bugfix'↑ bugfix/test ブランチがローカルにある状態で bugfix ブランチを作ろうとしたエラー
$ git push origin bugfix
Total 0 (delta 0), reused 0 (delta 0)
remote: error: cannot lock ref 'refs/heads/bugfix': 'refs/heads/bugfix/test' exists; cannot create 'refs/heads/bugfix'
To gitlab.******/*****.git
! [remote rejected] bugfix -> bugfix (failed to update ref)
error: failed to push some refs to 'git@******/*********.git'↑ bugfix/test ブランチがリモートにある状態で bugfix ブランチをpushしようとしたエラー
ブランチ名のルールを確認せずにいると、思わぬところでエラーが踏んでしまいます。
スムーズな開発が出来るようどんなブランチを作っていくべきかリポジトリのブランチを確認しましょう。
ブランチの運用方法（Merge運用か、Rebase運用か）
個人で実装する場合、ブランチの運用の仕方は気にする必要はありませんが、大人数での開発になった場合、ブランチの運用は大切です。
なぜかと言うと運用方法によって過去の開発ログの確認しやすさが変わってくるからです。
Merge運用とは開発を行い次第masterブランチにmergeしていく運用です。
通常のGitの解説書はこちらの運用方法を進めていくことが多いです。
Rebase運用とはmergeを行う前にrebaseを行い、コードの変更を最新のmasterから始めたようにしてからmergeしてpushする運用です。
複数ブランチが複雑に絡んでmasterにmergeされることがないため、ブランチがとてもすっきりします。
実際の開発現場ではブランチ管理のメリットのためRebase運用が採用されていることが多いです。
だからこそRebase運用についてはある程度事前に学習しておきましょう。
まとめ
今回の記事は長い内容になるため今回は2部構成にしました。（まだ半分なのに4000文字！）
私の職場に限ったことであればいいのですが、環境構築はスムーズに行くことが少ないです😅
理由としては運用の中で環境や手順が変わる可能性があったり、会社ごとの独自ルールがあり思わぬところで躓くためです。
環境構築に関しては外部からの人間はどうしようもないため、よく確認を行いましょう。
Git運用に関しては、過去のログからわかることが多いです。
調べれば分かることは自分で調べることを意識しましょう。
後半は実際にコードを書くときに起こりうるケースについて紹介していきたいと思います。
ここまで読んで頂きありがとうございました！
コメント