【実務で必須！】Gitって何？プログラミングができるだけだとダメな理由も解説！

はい、どうも！

フリーランスエンジニアの南だいすけです！

今回は【実務で必須！】Gitって何？プログラミングができるだけだとダメな理由も解説！ということで、

Gitのこと全く分かりません！とか、なんか知ってるけど使ったことない。。

みたいな方向けにちょっとしたセミナー形式で解説していきたいと思います！

はじめにいっておきますがGitの基礎的な知識、

実務ではめちゃくちゃ大事です！

なんならパソコン使えると同じくらいのレベルで

使えることが求められるので今回クリアにしておきましょう！

今回は初学者に分かりやすさ重視であくまでイメージしやすいように話しています。

経験者からしたらちょっとそれ違くない？と思うこともあるかと思いますがご了承ください！

耳で聞きたい方はこちら↓

Gitって何？

・Gitとは

まずはじめにGitって何？と言われたらバージョン管理ツールのことです。

ここでは分かりやすいように図を見ながら解説していきます！

はじめに単語をさらっと解説します！

こう言った管理ツールでは主にローカルリポジトリとリモートリポジトリがあり、

簡単にいうとローカルリポジトリが自分のパソコンの中にあるフォルダで、

リモートリポジトリがネットに置いてあるフォルダです。

なので基本的にはじめにリーダーの人とかがプロジェクトのコードが入ったフォルダをリモートリポジトリ。つまりネット上に置いて、

それをメンバーがダウンロードして自分のパソコンで作業をするという流れです。

このダウンロードしてきたフォルダのことをローカルリポジトリだと認識しておけば大丈夫です！

なのでリモートリポジトリはネット上にあってメンバーみんなが見れるフォルダ。

ローカルリポジトリはリモートリポジトリを元にした自分しか見れないフォルダということです。

また基本的にアプリなどは複数人のチームで開発します。

そしてこの画面はAさん、この画面はBさん、この画面はCさん。。。と言った感じで割り振って作業をします。

そこでGitが役に立ちます！

開発の流れは以下です。

各々がリモートのフォルダをダウンロード。それを使ってローカルで作業し、終わったらそれをリモートにアップロードすると言った感じです！

これをすると3つの画面が同時に作ることができます！便利ですよね！

またアップロードするわけですから誰がどんな作業をしたのかも一目瞭然ですし、後にバグが見つかった場合は誰が直せばいいのかも分かりやすくなります！

なんとなくGitについてわかっていただけたかと思います！

・プログラミングスキルとセットの理由

先ほども話した通り、基本的に実務のプログラミングはチームでやることが主です。

なのでプログラミングができるだけではなくこのGitのことを理解していないと仕事にならないんですね。

なのでこれは早めに理解しておく必要がありますし、パソコンが使えるのと同じレベルで必須条件です。

またバージョン管理ツールには有名なもので以下のものがありますが、基本的作業は一緒なので変わった事であたふたすることはないですよ！

・Git
・GitHub
・GitLab
・Backlog
etc...

しかし一生懸命プログラミングを勉強しただけでも精一杯だと思いますし、

案外Gitとは？と言ったサイトや参考書も分かりにくいことが多いので、

ここではめちゃくちゃ噛み砕いて初学者に分かりやすいように解説していきたいと思います！

Gitの使い方

では早速Gitの専門用語や使い方について解説していきます。

こちらはGitFlowと呼ばれるもので図の順で開発が進んでいきます！

①はじめにリモートリポジトリのdevelopをクローン（ダウンロード）
②クローンしてきたdevelopからfeature/〜と言ったブランチ（フォルダのようなもの）を作って作業
③それをリモートリポジトリにプッシュ（アップロード）
④プルリクエスト（メンバーに大丈夫か見てもらうこと）でOKならdevelopにマージ

なので平たくいうとおおもとのものを①でダウンロードして、

②でダウンロードしたもののコピーを作ってフォルダ名を作業内容にあったものを命名、

③で実際に作業し、ネットにアップロード。

④でメンバーに見てもらってOKならおおもとのフォルダに入れて更新

と言った感じだと分かりやすいでしょうか？

・ブランチ

基本的にプロジェクトはいっぱいフォルダがあって、それを最終的にmasterに入れてリリースします。

ブランチとはその各々のフォルダだと思っておきましょう！

具体的に以下が有名です。

・masterブランチ
リリース用の集大成のブランチ

・developブランチ
開発用の集大成のブランチ。featureブランチなどで新しく加えた機能をここに入れて完成させていく。リリースできるとなったらmasterに変更点をいれる。

・featureブランチ
主に作業用のブランチ。作業が終わって問題がなかったらdevelopに変更点をいれる。

なので流れとしたらfeature→develop→masterという流れで新しい作業が追加されていきます！

・コミット

コミットとはセーブみたいな感じで覚えておきましょう！

例えば画面を作るのでしたら、「大枠が完成した！」「詳細の大枠A,B,Cが完成した！」「詳細Aを作りきった！」。。。

みたいな感じで作業が一区切りしたら何をしたかコメントと共にコミットしておきます。

そうすることでローカルリポジトリに変更が保存されます！

ここでポイントなのが細かくコミットしておくことです。

そうすると後々見たときに分かりやすいですし、メンバーからしても作業内容が見やすいです。

・プル

プルとはリモートリポジトリの内容を見て新しい内容があったらそれを更新することです。

リモートリポジトリもどんどん更新されていくので、その都度自分のローカルにダウンロードしておく必要があります。

・マージ

これちょっとプルと似ているのですが、これは別のブランチの内容を見て自分と相違点があった場合はそれだけ反映させるイメージです。

・プッシュ

今まで作業していたfeatureブランチはローカルリポジトリです。それを一旦みんなに大丈夫か見てもらう為にリモートリポジトリとしてアップロードします。

イメージとしてはtwitterで画像をアップするイメージです。

同じ画像はスマホ内にもありますが、ツイートすることでみんなが同じ画像を見れるようになりますよね？

スマホで文字を入れたり、加工をしたらまたツイートすることで変更点がみんなも見れるようになるみたいな感じです！

・プルリクエスト

先ほどプッシュした内容をメンバーに見てもらう作業です！

メンバーがOKだよ！（LGTMなんて書かれる事が多いです）と言ってくれたら自分が加えた作業をリモートリポジトリのdevelopにマージします。

ちなみにこのdevelopにマージする前に最新のdevelopのデータがちゃんとマージできている必要があります。

・コンフリクト

マージするとよく起こるもので、要は自分のブランチとマージ元のデータが競合していますよ。というものです。

。。。競合？と思う方が多いと思うので補足すると、例えばAさんとBさんで開発していたとして、developは文字の色が黒で設定していたとします。

詳しく話すとそれだけで記事一個分になってしまうのでここでは軽く説明します。

2人とも同時に作業をはじめて、Aさんが文字の色を青色に変更して先にdevelopにマージしました。

その後文字の色を赤色に変更したBさんがdevelopにマージしようとするとコンフリクトがおきます。

なぜかというとコンピューター側もどっちが正しいん？？となるからです。

これの解決の仕方は簡単で、仕様通りの方を優先して競合を解決すれば大丈夫です！

こんな感じで開発は進んでいる為、今回話してきたようにGitの知識がないと思うように開発が進められないのがわかっていただけたかと思います！

実務では絶対に求められることなのでその意識は持っておきましょう！

いかがでしたでしょうか？

今回の記事で少しでもプログラミング初学者や、

Gitについてあまりわからない方のヒントになれば幸いです！

さいごに

最後まで読んでいただいてありがとうございました！

少しでも読んでくださった方の力になれたのなら幸いです。

本来なら自分のやっている情報商材の案内などをするところなのでしょうけど、私はやっていないのでYouTubeチャンネルとTwitterの紹介させてください！

YouTube：

Twitter：

これからも役立つような情報を発信していきますので

気に入って頂けたらスキやフォローをしていただけると嬉しいです！

コメントも大歓迎です！お待ちしています！

ではまた次の記事でお会いしましょう！