初めに

Gitの初心者は言われたことがあると思いますが、「Gitはやられながら学ぶもの」と言われてますけど、必ずそうではないこと、証明して見せたいと思います。

概要

社内で企画者やデザイナーなどまだGitに慣れていないメンバーがGitを使える機会が多くなってきましたが、何より「Gitへの恐怖感」が大きいところ、それをまずなんとか乗り越えてもらえたかったです。
それに、ターミナルにも慣れてもらえようにしました。

この記事では、簡単なコマンドはもちろん、よく遭遇するトラブル、その解決策と、予防方法まで軽く触っていきたいと思います。

背景知識

Git?

Gitとは、バージョン管理ツールです。チーム開発など複数人で開発を進める際に便利に使えます。

簡単に言えば、個人（ローカル）の作業結果を遠隔（リモート）に貯めておくことになります。

特にチームで運用する場合は、作業の効率向上、不具合防止のため、運用ルールを決めている場合が多いです。

Git意外にも、SVNなど色々あります。

GitHub? GitLab?

両方とも、Gitのレポジトリーをクラウド上で利用するサービスです。一番大きい違いは、独自ドメインで運用できるかどうかです。

• Github : 独自ドメインでサービス不可。
• Gitlab : 独自ドメインでサービス可能。

自分のブランチをリモートのレポジトリーに入れる依頼をPull Requestと呼ぶか、Merge Requestと呼ぶかなどが違うくらいで、基本的にコマンドは同じです。

Gitクライアント？

Gitが難しい！というユーザーに使ってもらえるため、UIが揃ったツールを指す場合によく使われます。Source TreeやGithub Desktopが有名です。

しかし、Gitのコマンドに慣れた方が、理解と成長につながると思うので、OSに基本的に内蔵されているTerminalやPowerShell、Git Bashなとのツールを中心に説明したいと思います。

Gitの設定

• MAC：基本搭載
• WIN：Git Bashをダウンロード＆インストール

実践

作業前フロー

新しい作業を始める場合

チームでGitプロジェクトを始めるくらいですと、多分Gitとプログラムの達人なので、細かい内容は割愛します。

$ git init

既存のブランチをクローンする場合

一番実践的な場合です。

基本ブランチをクローン

$ git clone {repository_address.git}

masterやmainブランチがクローンされます。

特定ブランチをクローン

まず、リモートブランチからどのブランチをクローンするかを決めます。

$ git branch -r

そのブランチだけ、クローンします。

$ git clone -b {work_branch} {repository_address.git}

間違ったら削除＆再クローンになるので、おすすめはしないです。

欲しいブランチをプル

リモートブランチからどのブランチをクローンするかを決めるのは同じです。

$ git branch -r

ローカルにブランチを生成します。ブランチ名は、リモートに存在するブランチ名と一致しないといけません。

$ git branch {work_branch}

ローカルに、本当にそのブランチが生成されたか一覧を確認します。

$ git branch

生成したブランチに移動します。

$ git checkout {work_branch}

リモートの作業ブランチをプルします。

$ git pull origin {work_branch}

こちらが一番無難で、確認ポイントが明確なのでお勧めします。

注意
リモートにあるブランチを全部プルするのは意味がありません。自分の作業に合致するブランチだけをプルして作業しましょう。

作業後フロー

作業したファイルを確認します。

$ git status

思わず修正したファイルがあったり、自動的に変わったファイルがあるか確認します。例えば、MACの場合ですと.DS_Storeなどが一緒に変更される場合が多いです。不要なファイルが頻繁に生成される場合は、ルールに従って.gitignoreに登録しておきましょう。

修正したファイルの確認が終わって、リモートに反映させるファイルを選択します。複数の場合は、スペース１個で区分します。

$ git add {work_file1} {work_file2}

このファイルたちがなぜ修正されたか、内容を記載します。リモートブランチからどのブランチをクローンするかを決めます。

$ git commit -m "作業内容"

会社やチームにもよりますが、大体の場合は書き方がルールとして定まっているので、それに従いましょう。

これで、プッシュです。

$ git push origin {work_branch}

これが終わったら、リモートのレポジトリーに自分のコードが反映されていることが確認できます。

これで終わりではありません。多くの場合リモートの親ブランチに適用（マージ）させる場合、コードレビューというのがありまして、シニアーやチームリーダー、場合によっては同僚からレビューをもらうことになります。

大体レビューでチェックする項目は以下になります。

• ルールに従った書き方、命名になっているのか
• シンプルで、わかりやすいか（無駄がないか）

それ以外、実装に関して質問される場合もあるので、なぜそのコードを書いたかは自分でも納得していて、他人に明確に説明しないといけないです。

失敗した場合

簡単な流れですが、思わぬところで事故が起きます。慌てず、落ち着きましょう。

違う内容の作業が混ざってしまったよ！まだコミットしてないけど。。。

危険度：無

作業途中に気づいて、$ git statusをしてみたら見覚えのないファイルが修正されていました。しかし、まだコミット前なので、全然問題ないです。

解決策

• 各ファイルの修正内容を確認して、各々の作業内容に合わせてコミットを進めます。
• 作業と関係ないファイルが生成されたら
  • 削除します。
  • 作業フォルダの外に写します。
• 修正しなくても良いファイルだったら、$ git checkout {work_file}で元に戻します。

予防策

作業が終わったらコミットを忘れずに！後で修正事項が発生するのは当たり前なので、完璧にしてからコミットをやるという考え方から自由になって欲しいです。

コミットしてから気づいちゃった！違う内容の作業が混ざっていたよ！

危険度：★

$ git statusもせず、いつも通り$ git add .でコミットしてしまったらよく起きます。「エラーも出ないし、とりあえずいいか？」と安易な考えでプッシュを進めてしまうと、作業内容がごちゃごちゃになってチームの作業に影響するので、解消しておきたいです。

もっというと、コードレビューの際に許されない（返される）ので、自分で解消した方が早道です。

解決策

• $ git reset HEAD-で作業内容はそのまま残して、add, commitは取り消します。
• この状態で、各ファイルを確認して各々の作業内容でadd, commitを進めます。
• 作業内容は全部戻す＆以前の修正を全部取消したい場合は$ git reset --hard HEAD-を実行します。

予防策

$ git statusを徹底に！そして$ git add .の乱用にも注意！

コンプリートって出たけど何？

危険度：無

リモートに上がっている作業内容と自分の作業内容が重なっている（同じ箇所で違う作業をコミットしている）ので、どちらかを選択しないといけないです。滅多に起きない！ほどではないですが、起きても、大体の場合は軽く解決できます。

解決策

• リモートでの作業：GithubやGitlabのサイト上で、コンプリートが起きたファイルが編集できるようになっているので、それを利用して適用する箇所を選択します。
• ローカルでの作業：VS Codeでは、コンプリートが起きた箇所に印が表示されます。そこでどっちかを選択するだけです。
  • accept current change : ローカルで修正した内容を適用します。
  • accept incoming change : リモートで修正した内容を適用します。
  • accept both change : 両方を全部適用します。

予防策

100％起きないとは断言できないですが、pushする前にはpullをしましょう。コンプリートが起きてもローカルで解決できるので、少しは安心です。

コミット名を間違って書いてしまったよ！

危険度：無

ターミナルでコミット名を入力していたら、特に日本語の場合だと落ちたりします。コミット名を間違っても作業に危険度まで言えることはありませんが、慌てて対応すると作業内容が乱れます。

解決策

• $ git commit --amend -m "変更したいメッセージ"で再入力します。

予防策

ターミナルが落ちるのは想定外なので、慣れましょう。

まとめ

軽めで説明しました。
後編をお楽しみに！