こんにちは、webエンジニアのtakaです。
この記事を開いたということは、HTML・CSS・JavaScriptあたりはそこそこ勉強できていて、さぁ初めてチームに加わり他の人と共同で開発するといった方がほとんどと思います。
どの現場に行ってもチームで開発する限りバージョン管理つまりGit（ギット）の知識は必要不可欠です。
新しくエンジニアを面接するときは必ずgitコマンドを使えるか聞きますし、新しく参画したエンジニアが「ちょっとgitコマンドに詳しくなくて・・・」なんて言っていたら、「あぁこいつ初心者か」と思います。
自分がそう思われたら、いやですよね。
そういうことがないように今回の記事勉強していってください。
早速いきましょう。
開発環境の構築
さぁ、会社にジョインした初日です。
会社から初期化されたmacが支給されました。
あれこれdockerやMAMPの初期設定をします（ここでは説明を省きます）。
直近のタスクはt-file株式会社のコーポレートサイトのコーディングです。
ソースコードの取得
おそらくあなたが開発するプロジェクトは、既にある程度出来上がっているはずです。
ソースはgithubやbitbucketなどのバージョン管理システムで管理されています。
担当の方にgithubやbitbucketにアクセスできる権限を付与されるので、git cloneを利用し、自分のパソコンにソースコードを取得しましょう。
※macの程で進めますので、windowsの方は適宜コマンドを変えてください。
ターミナルを開きます
dockerやMAMPのhtdocs以下までcdを利用し移動します
$ cd /path/to/docker/or/mamp/git cloneを利用しローカルにソースコードを取得します
$ git clone https://github.com/example/project.gitls で cloneできたか確認します
$ ls
projectprojectというフォルダができました。
cd で projectフォルダに移動します
$ cd projectgit statusでgit管理されているか確認
$ git status
On branch mastertips!
git statusは今の状況を出力するだけの安全なコマンドなので、困ったときはとりあえずgit statusで状況確認をしよう。
tips!
On branch master とは、今ローカルのブランチはmasterですという意味です。masterは本番環境と同じ状態のブランチです。masterブランチでは作業をしてはいけません。
ちなみにブランチとは「枝」という意味で、masterから新しく枝を作り、そこで開発したものをmasterにマージ（統合）させるというのが開発のサイクルです。
開発準備
環境構築ができたので、開発に取り掛かっていきたいと思います。
とりあえずgit statusをもう一度試してみましょう。
$ git status
On branch master今ローカルつまり自分のパソコンはmasterブランチにいます。
担当の方にブランチの命名規則を聞きましょう
開発するブランチの命名規則は「feature-{チケットNo}」という設定にしましょうか。
多くの会社でBackLogやRedmineなどのタスク管理ツールを利用しており、機能毎にチケットを作るのが一般的です。
そのチケットには番号が割り振られており、チケット番号をブランチ名にすることがよくあります。
機能開発という意味の「feature」とチケット番号を組み合わせて他の人のブランチ名と被らないようにしているのですね。
今回割振られたチケットの番号は100なので「feature-100」というブランチ名を作成します。
担当の方にどのブランチから切れば良いか聞きましょう
一般的にmasterブランチは公開用のブランチで、開発中のものを置くブランチとして「develop」ブランチがあります。
※会社によって「dev」であったり「staging」だったりする。
担当の方に何ブランチから切ったらいいか尋ねると、developブランチから切って欲しいとの指示が来ました。
リモートのdevelopブランチをローカルに持ってくる
git branchコマンドを利用するとローカルつまり自分のパソコン内のブランチの一覧を確認することができます。
$git branch
masterさっきクローンしたばかりなのでmasterブランチしかないですね。
それではリモートのブランチを確認してみましょう。
git branch -a とオプションを加えます。
$ git branch -a
master // ローカルのmaster
remotes/origin/develop // リモートのdevelop
remotes/origin/HEAD -> origin/master // リモートのmaster
remotes/origin/feature-99 // リモートのfeature-99
・・・リモートのdevelopブランチがありました。
次のコマンドでリモートのdevelopブランチをローカルに持ってきます。
$ git fetch origin develop
$ git checkout -b develop origin/developgit fetachによって、リモートリポジトリの最新の履歴の取得だけを行います。
git checkout -b develop origin/developは、
リモートのdevelopブランチを参考にして、ローカルにdevelopブランチを作成し、かつ現在のブランチから作成しらブランチに移動します。
developブランチにいるか確認
$ git status
On branch developdevelopブランチをローカルに持ってくることができました。
ブランチの作成
「feature-100」ブランチを作成する
developブランチから新しく「feature-100」ブランチを作成していきます。
$ git checkout -b feature-100git checkout -b はさっきも利用したように、新しくブランチを作成しながら移動します。
新しく作るブランチ名は「feature-100」となり、どのブランチから作成されるかというと、今回何も設定していないので今いるブランチ（=develop）から作成されます。
ローカルに「feature-100」ブランチが作成でき、今「feature-100」ブランチにいるか確認
$ git branch
develop
feature-100 // ローカルに作成されている
master$ git status
On branch feature-100feature-100ブランチにいますね。okです。
tips!
ブランチを切る前は必ずpullを行い最新の状態に更新しておこう。
ブランチ切る前はpullすると、体に染み付かせましょう。
$ git pull origin develop開発が始まった
feature-100ブランチで開発を進めます。
簡単なコーディング作業が終わりました。
開発が終わった
開発が終わったので、自分の修正をマージ（統合）してもらう必要があります。
マージしてもらうためには、自分のローカルにしかないさっき作業を含んだブランチをリモートに上げる（push）する必要があります。
作業したファイルを確認する
はい、まずgit statusを行いましょう。
$ git status
On branch feature-100
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: index.html // 修正したファイル
modified: style.css // 修正したファイル修正したファイルを確認できました。
インデックスに登録する
addすることによってコミット対象にすることができます。
この辺りはとりあえず鵜呑みにして実戦で慣れていきましょう。
$ git add .addの後ろの「.」は、配下のファイル・フォルダ全てという意味です。今回の例ではindex.htmlとstyle.cssですね。
ファイル指定してaddできますが、修正したものは基本全てaddしましょう。
コミットする
コミットすることでファイルの変更をgitレポジトリに保存できます。
$ git commit -m "トップページの修正"コミットする際にコミットメッセージを登録する必要があります。
コミットメッセージは型が決められている場合が多いので、担当の方に聞きましょう。
-m “メッセージ” とすることで、コミットとコミットメッセージの登録を1コマンドで実行することができます。
プッシュする
コミットができたのでプッシュします。
$ git push origin feature-100ローカルのfeature-100ブランチをリモートにプッシュします。
リモートにfeature-100ブランチがあるか確認してみましょう。
$ git branch -a
develop
feature-100
master
remotes/origin/develop
remotes/origin/HEAD -> origin/master
remotes/origin/feature-99
remotes/origin/feature-100 // リモートのfeature-100ブランチ
・・・ありましたが、自分の修正を含んだfeature-100ブランチをマージ（統合）する必要があります。
プルリクエストを行う
プルリクエストとは、feature-100ブランチをdevelopブランチなどにマージしてくださいというリクエストです。
GithubたbitbucketのGuiで操作できます。
プルリクエストの方法も会社によって書き方が異なるので担当の方に聞きましょう。
まとめ
イメージが掴めましたか？
今回は、業務で利用する基本的なGitコマンドを記載しました。
gitになれて、早く会社の中で信頼されるエンジニアになってください。