Gitを使ったことがない人向けにチーム開発でコードがマージされるまでの流れ（利用するコマンド）をまとめてみたいと思います。
Gitをつかったソースコードの管理とは
Gitはソースコードのバージョン管理を行うためのツールです。
会社での開発の場合、複数の人がソースコードの変更を行います。
なので、
- ソースコードを共有できるようにしておくこと
- 誰がいつどこに変更を加えたか確認できること
- 製品のリリース等に合わせてバージョンが管理できること
が必要になります。
なので、gitとgit レポジトリと言われるgithub, gitlabなどを利用してソースコードをみんなで管理できるようにしています。
大体下記のような流れで開発が行われていきます。
- 編集するコードを自分のPCにダウンロードする(clone)
- 変更を加える
- レポジトリにアップロードしてマージをしてマージをしてもらう要求（pullRequest）
- 加えた変更に対して、詳しい人（上司、先輩など）がレビューを行い、修正→レビューを繰り替えす（コードレビュー）
- OKが出たらコードの変更を受け入れる（マージ）
チーム開発を行うときのコード修正の流れ
会社に開発者として配属された場合は既に開発中のコードがあって、そこに手を加えていく場合が多いと思うので、既にレポジトリ、コードがある前提で解説します。
git をコマンドラインで使えるようにする。
使っているOSに合わせてgitをダウンロード、インストールしてコマンドプロンプトやターミナルで使えるようにします。
コマンドプロンプトやターミナルで
git --help
と打って「コマンドが見つかりません」的なメッセージが表示された場合はこの手順が必要です。利用できるコマンドの一覧が表示された場合は既にインストール済みです。
インストールされていない場合は、以下のサイトからダウンロードし、インストーラーに従ってインストールします。
https://git-scm.com/
gtihubからローカルにフォルダを落としてくる
「このアプリケーションのXXを修正して。レポジトリのURLはXXXだから」
みたいな感じで仕事が振られるのではないでしょうか。
とりあえずそのURLにアクセスしてみます。
画面のどこかに「code」(またはcloneなど)というボタンがあるはずなので、そこに表示されているURIをコピーします。
画面はgithubのものです。gitlab等でも同様にソースコードのcloneをするためのボタンが存在するはずです。
コマンドプロンプトで、ソースコードをコピーしたいディレクトリに移動してcloneを行います。
git clone {{上記URL}}
例）git clone git@github.com:account-name/repo-name-sample.git
このコマンドの後、カレントディレクトリ（今コンソールで見ているディレクトリ）に落としてきたソースの名前のフォルダがあるはすです。
なかったらなにかに失敗していると思いますので、エラーメッセージを確認してください。
ブランチの変更
コードを落として来たらまずブランチを変更したほうがいいです。
git cloneした時点で大体masterブランチやdevelopブランチなどという一番メインで使っているブランチに設定されていることが多いです。
そのブランチはみんながソースコードをダウンロードしたり、製品出荷に使われたりする大事なものなので、勝手に変更を加えると上司に怒られちゃいます。
ブランチの変更は
cd {{さっきクローンしたソースのフォルダ名}}
git checkout -b {{新しく作るブランチの名前}}
例）git checkout -b sample
もしくは
git branch {{新しく作るブランチの名前}}
git checkout {{新しく作るブランチの名前}}
例）git branch sample
git checkout sample
git checkoutはブランチを切り替えるときに使うコマンドで、上記の用に-bをつけると新しくブランチ作ることになります。
git branch は新しいブランチを作るときに使うコマンドです。
ブランチの名前はチームでルールがあることが多いです。（修正するバグの概要、課題管理番号、通し番号など）
周りの人に確認してみましょう。
ソースコードの編集
バグ修正とか新機能追加とか与えられた仕事を頑張ってください。
修正を行うとき、キリがいいタイミングで定期的に下の「編集したファイルの確認」〜「レポジトリにPush」までを行うことをおすすめします。
- 自分のPC上で行った編集を定期的にレポジトリにバックアップすることができるのでローカルのフォルダが壊れたときに安心
- コミットログ（変更を行った際のメッセージ）がわかりやすい
というメリットがあります。（ここらへんはチームや個人の癖やルールがあると思うので、他の人のやり方を見るのがいいと思います。）
編集したファイルの確認
編集が終わったら修正点を確認します。
git status
自分が変更するつもりではなかったものが修正の中に入ってしまっていないか確認しましょう。
修正したファイルのコミット準備
コミットというのは「今回修正したファイルはこれです！」という提出意思表示のようなものです。
修正をコミットする準備として、確認したファイルを今回の修正の範囲としてアップロードしますよ、という宣言的なものをします。
git add .
もしくは
git add {{修正をコミットするファイルのパス}}
git add .の場合はgit statusに表示されたすべてのファイルをコミットすることになります。
いろんなファイルに修正は加えたけど特定のファイルだけをコミットしたい場合はgit add {{修正をコミットするファイルのパス}}を使いましょう。
コメントをつけてコミット
コミットするときに何を変更するかコメントをつけておくことをおすすめします。
git commit -m "コメントしたい内容を書き込む"
コメントの付け方はチームによってルールがある場合があるので他の人のものを参考にしましょう。
レポジトリにPush
コミットしてもまだレポジトリには反映されていません。
下記のようにgit pushすることで、レポジトリに反映され、他の人達にも確認できる状態になります。
git push origin {{作ったブランチの名前}}
例）git push origin sample
レポジトリからpull Request(Merge Request)を提出
レポジトリの画面に移動して、Pull Request（MergeRequest）を提出します。
Pull Request（MergeRequest）というのは、「masterブランチ（もしくは他のリリースブランチなど）に私の修正を入れてください！」という修正要望です。この要望をレポジトリの管理者が受け入れると晴れて修正が反映されることになります。
(Pull RequestとMargeRequestは同じようなものですが、GitHubというレポジトリを使っているか、GitLabというレポジトリをつかっているかによって名称が異なります。)
以下githubの場合の手順です。（他のレポジトリでもだいたい同じ流れです）
先程pushした自分のブランチを表示し、画面右側にあるPull Requestボタンを押します。
コメントや、Reviewerを指定して、pullRequestを提出します。
レビューと修正
Reviewerからコメントが送られてきたら「ソースコードの編集」から「レポジトリにPush」までの手順を繰り返します。
最終的にマスタブランチ（もしくはその他ターゲットブランチ）に修正がマージされたらお仕事完了です！
困ったときのいろいろ
いろいろ変更加えたらわけわからなくなったのでリモートレポジトリPushしてある状態にもどしたい！
git fetch origin
合わせたいブランチにreset
git reset --hard origin/{{合わせたいブランチ名}}
例）git reset --hard origin/sample
マスタブランチに他の人の習性がマージされている！（マスタブランチが自分がPullしたときの状態より新しくなっている！）
masterブランチに切り替える
git checkout master
masterを最新の状態にする
git pull origin master
自分の作業ブランチへ切り替える
git checkout {{作業ブランチ名}}
例）git checkout sample
mergeコマンドでmaserブランチの内容を取り込む
git merge origin master
蛇足
githubとかgitbucketとかgitlabとか似たような名前があるけど何？
gitはソースコードを管理するツールの名前、githubとかgitbucketとかgitlabはレポジトリ（保管場所）の名前です。
その他チームごとの運用体制
この他タグの運用とか、CIの仕組み（コードの品質を保つための仕組み）などチームによってルールがある場合が多いです。