ソースコードなどのファイルやフォルダ等の管理については、今や多くの現場で「git」を使っていることが多いと思います。
今回は、gitを使った業務の流れについて、まとめておきたいと思います！
主にコーディングをする開発者視点でまとめていきます。
ローカルに作業ブランチを作成する
メインブランチから作業ブランチを作成します。
その前にメインブランチを最新化することを忘れずに！！
// メインブランチに移動しておく
// メインブランチにいる状態で、最新化する
git pull リモートリポジトリ名（originと名付けていることが多い） メインブランチ名
// メインブランチから作業ブランチを作成する
git checkout -b 任意の作業ブランチ名作業ブランチで、コーディングを行う
作成した作業ブランチにいることを確認し、コーディングを行います。
// 現在のブランチの一覧表示
// * がついているブランチが現在のいるブランチ
git branchコミットする
コーディングが終わったら、作成したファイルやフォルダをコミットします。
作業内容を確定し、保存するイメージです。
// コミット対象のファイルをインデックスに追加する
git add ファイル名
// コミットする
git commit -m "任意のメッセージ内容"- コマンド操作では、インデックスに追加 → コミット の手順ですが、
実務での会話の中では、併せてコミットするとよく表現しています。 - オプション「-m」は省略できますが、その場合、テキストエディタが自動起動され、そこでメッセージを任意入力します。
リモートリポジトリへプッシュする
これまでは、ローカル上での作業でした。
ここでは、ローカル上で作成しコミットしたファイルやフォルダを、リモートリポジトリにプッシュ（反映）します。
git push リモートリポジトリ名 作業ブランチ名プッシュにより、ローカルで作成した作業ブランチが、リモートリポジトリに共有されることになります。
つまり、他の作業者も自分が行ったコーディングを参照することができるようになります。
プルリクエストを作成し、レビュー依頼をする
プルリクエストは、gitの機能ではなく、GitHubやGitLabなどのgitをホスティングするWebサービスの機能になります。
（gitコマンドの操作ではありません。）
ブラウザ上で、プルリクエストを作成し、作成後はプルリクエストのURLをレビュー者に通知し、レビュー依頼をします。
レビュー後、指摘事項がある場合
- レビューによりコードの不備等の指摘があり、修正の必要がある場合は、コード修正をする。
- 修正後、コミット・プッシュする。
- 再度レビューをしてもらうようレビュー者に連絡する。
※この時、プルリクエストは再作成しません。
プッシュをした時点で、一度作成しているプルリクエストに反映されることになります。
ここまでが、開発作業者の行う流れとなります。
補足
マージについて
これまでの流れで、ローカルに作業ブランチを作成し、リモートリポジトリにプッシュしましたが、最終的には、リモートのメインブランチに作業ブランチを反映させる必要があります。
このメインブランチへの反映をマージと言い、マージは開発者以外の担当者が行います。
（レビュー者が、レビューOKの後、マージさせるパターンが多いと思います。）
Sourcetreeを活用しよう！
これまでは、gitコマンドによる操作をご紹介してきましたが、ある程度gitコマンドの操作に慣れてきた場合は、Sourcetreeも併用することをオススメします！
こちらの公式サイトからダウンロードできます。
SourcetreeはGUIツールであり、GUIツールを使うことのメリットは以下の点があるかなと感じます。
- これまでのgitコマンドの操作をマウス操作で行うことができる
- どのファイルのどこを修正したのか・どのファイルを新規作成したのか等、視覚的に見やすくなる場面が多い
もちろん、最初からSourcetreeを使用して、開発を行ってもいいと思います。
ただ、Sourcetreeの裏ではgitコマンドが実行されていて、そのgitコマンドにはどんなものがあるのかを理解しておくためには、まずはある程度自分でコマンド入力して慣れておくことをオススメします。
また、今回はSourcetreeをご紹介しましたが、他にもGUIツールはありますので、色々触ってみて、自分に合ったものを探してみるのもいいと思います！
