【Git基礎】インストールから使い方まで
この記事では、初心者の方が「Git(ギット)」の概要から、チーム体制で使えるようになるまでを分かりやすく解説しています。
Gitを使いこなすと、以前書いたソースコードの状態にカンタンに戻せたり、複数人のチームで共同作業をすることができるようになるぜ!
すごーい!でも、わかんない言葉がいっぱいで難しそう!
わかりやすく説明してよね!
Gitとは?
Gitとは、ファイルの変更履歴を記録できるバージョン管理システムです。
HTMLのほか、様々なプログラムコードの編集や変更履歴を管理するシステムとして、また、チーム体制による複数人による開発のためのシステムとして広く使われています。
バージョン管理システム? ちょっとイメージがわかないなぁ。
そうだなぁ、それじゃ、ちょっと実際の作業でイメージしてみようか。
例えば、あなたが以下のような流れで作業をしたとします。
初日 | HTMLファイルを作成 |
---|---|
2日目 | 半分程度HTMLコーディング |
3日目 | HTMLコーディングを完了 |
しかし、4日目にあなたは大きなバグがあることに気づきました。
修正するには、かなり時間がかかる。
2日目の状態に戻して、そこから修正した方が早い。
こんなことって、ありますよね?
うわぁ、想像しただけで胃がキリキリしちゃいそう。
ふっふっふ、でも大丈夫!そんな時こそGitの出番なんだぜ!
Gitはバージョン管理システムなので、変更履歴を管理することができます。
つまり、Gitを使っていれば、カンタンに2日目の状態にHTMLファイルを戻すことができるのです。
ふえ~これだけでも便利な気がするね~ 手動でバックアップファイルを作らなくていいんだもんね?
そうさ!しかもgitのメリットはそれだけじゃないぜ! !
Gitのメリットって?
複数人の修正・変更をまとめることができる
チームで制作、開発をするときは、同じファイルに複数人が手を加えることもあります。
例えば、同じHTMLファイルに対し、以下のような変更を同時に行ったとします。
- Aさんがお知らせを追加した
- Bさんがバナーを追加した
- Cさんがフッターの構成を変えた
Gitが無い場合、ひとりひとりのファイル変更箇所を確認し、手動で変更を反映しなければなりません。
ところがgitなら、それぞれの作業者が変更したソースコードをひとつにまとめてくれるのです。
へえ~これは楽だね~!
そうなんだよ、だからチーム開発で重宝されるってわけよ。
でもさ、同じ作業箇所がかぶっちゃったりすることもあるんじゃない?
例えば、同じバナーをAさんとBさんで別々のものに差し替えちゃったときとか。
そのときは「作業がかぶってるよ!」ってgitが教えてくれるよ。
AとBどっちの作業を残すか選べるから、作業場所が完全にかぶっても、勝手に消えることは基本的にないよ!
優しいんだね。Gitって。
さかしも優しくなりなよ。
お、おう。。。!
変更したときにコメントを残すことができる
Gitを使ってバージョン変更を保存するとき、コメントを残すことができます。
コメントを残すと
- どういう意図でHTMLに変更を加えたのか
- どういうところを変更したのか
など、後任者にとって参考になる情報を残せます。
チーム開発してる案件で、メインの開発担当者が抜けて、後任者がよくわかんなくなっちゃうパターン、よくあるよ。
その状態で「さかしさん助けて!」っていう案件依頼、いくつかあったしね。。。
それは困っちゃうね!
そう。そんなときにコメント履歴が残っていれば、後任者が多少安心できるってわけさ! !
間違った時にいつでもやり直せて、わかりやすくコメントを残すこともできて、他の人に手伝ってもらうこともできる…
って、そんなの、絶対今すぐGitを使ったほうがいいじゃん!
そのとおりだ!!
それじゃ、さっそくアカウントを作るところからはじめるぜ!!
Gitをはじめよう!
アカウントを作ろう
Gitを扱える代表的なWebサービスにはGithubとbitbucketという2つがあるんだ。
うん? Gitっていうのを使うんじゃないの?
Gitってのはバージョン管理システムのことで、GithubやbitbucketというのはそんなGitを使ったチーム開発をより便利に、使いやすくするためのサービスなんだ
要するに、Gitを使うならそのサービスを使えばいいってことね!
その通り! 他にも同じようなWebサービスはあるけど、とりあえず最初のうちはこの2つのどちらかを使えば問題ないぜ!
えー!!どっちがいいの?!
どちらも機能自体には大きな差はないよ。どちらもgitの仕組みを使ったWebサービスさ。
ただ、個人的にはWebhookという機能があるgithubをオススメするぜ!!
例えば、誰かがGithubのデータを更新した時にメール通知をする、といったことができます。
いきなりWebhookを理解するのは難しいので、ここではさらっと「Webhookっていうのがあるんだ」ぐらいに思っておけばOKです。
Githubアカウントの作り方
- まず、Githubの公式サイトにアクセスします。
- 画面右側にあるフォームにあるUsername、Email、Passwordを入力します。
Sign up for GitHubをクリックします。
- 実在の人物であることを証明するための簡単な質問に答えて「Next: Select a plan」をクリックします。
- 左側のFreeと書かれた無料プランを選択して「Choose Free」をクリックします。
- 任意の質問に回答して「Submit」を押すか、「skip this step」をクリックすると、アカウントが作成されます。
- 登録時に入力したメールアドレス宛にメールが届いているので、メール内にある「Verify email addrress」をクリックすると、アカウント登録完了です。
Bitbucketアカウントの作り方
- bitbucketのアカウント作成ページにアクセスします。
※Githubアカウントを作った人は、飛ばしてOKです。 - Eメールを入力して「Continue」をクリックすると、登録したメールアドレスにメールが届いているので、「Verify my email address」をクリックします。
- リンク先のページでユーザー名を入力して「続行」をクリックします。
- アカウント登録完了です。
リポジトリを作ろう
リポジトリとは、ひとことでいうなら過去の状態を記録できる貯蔵庫です。
例えば、
- A:10/1 バナーデザイン修正
- B:10/5 バナー追加
- C:10/7 バナーカラー変更
という履歴があって「やっぱり前のバナーの方が良かったな~」となった時に、リポジトリからBの状態を引っ張ってくることができるのです。
なんか名前を聞いただけで難しそうで「ウッ」ってなりそうな名前だよね。リポジトリリポジトリ…
履歴を保存するのに、最初に作るものって覚えておけばいいよ。
いきなりリポジトリって言われても、イメージできないからね。
僕も最初は、意味不明だったぜ!
Githubのリポジトリの作り方
- GitHubにログインし、ページの右上にある「+」の隣にあるドロップダウンメニューから「New repository」を選択します。
- リポジトリに好きな名前を付けます。(Repository name)また、必要であればリポジトリの説明を追加(Description)します。
- リポジトリの公開・非公開の設定をします。
Privateに設定すると、外部からソースコードを閲覧することができなくなります。
公開する必要がなければ、Privateで良いでしょう。 - Add a README fileにチェックを入れます。
- 「Create repository」ボタンを押すとリポジトリの作成完了です。
Bitbucketのリポジトリの作り方
- Bitbucketにログインし、左サイドにあるメニューから「+」を押し、「リポジトリ」を選択します。
- リポジトリ名にお好きな名前を入力して、「リポジトリの作成」をクリックします。
※リポジトリを非公開(Private)にしたい場合は、「これは非公開リポジトリです」にチェックを入れてリポジトリの作成完了です。
どっちも手順通りにやるだけだから、カンタンだね!
おう!ちなみに、今作ったWeb上(GithubまたはBitbucket)のリポジトリのことをリモートリポジトリっていうんだ。
自分のPCにもリポジトリを作れるの?
そう!
自分のPCの中に作るリポジトリのことをローカルリポジトリと言うぜ。
ローカルリポジトリを作ろう
ローカルにリポジトリを作成する方法は色々あります。
Githubやbitbucketに作ったリモートリポジトリをコピーしてしまうのがやりやすいでしょう。
クローンというコマンドを使うことで、リポジトリをローカルにコピーできます。
コマンドってまさか。。。あの黒い画面のやつ?
そう、こんなの。
画像引用元:https://i2.wp.com/confrage.jp/wp-content/uploads/2015/12/2015-12-18_150901-10.png
ぎゃああ~気持ち悪くて萎えるやつだぁ~~~
大丈夫、僕も最初は抵抗あったけど、意外と使ってるうちに慣れてくるよ! !
Visual Studio codeでクローンしてみよう(git clone)!
Visual Studio code(VS Code)は多くのプログラム言語に対応したソースコードエディタです。
Gitを勉強しているあなたは、おそらくすでに何らかのテキストエディタをお使いかと思いますが、ここではVS Codeでのクローン方法をお教えします。
Gitをインストール
VS Code単体ではGitが使えないので、まずはあなたのPCにGitをインストールしましょう。
プロゲートのGit環境構築記事が参考になります。
https://prog-8.com/docs/git-env-win
▼【Mac】Gitの環境構築をしよう!▼
https://prog-8.com/docs/git-env
VS Codeをインストール
ダウンロードページにて、VS Codeインストーラーをダウンロードしましょう。
VS Codeをインストール済みの方は、不要です。
ただ、Gitをインストールした時にVS Codeを開いていた場合、VS Codeを再起動しておきましょう。
でないと、VS Codeでgitを認識してくれません。
さぁ、git cloneだ
GithubのWebサイトにて、作ったリポジトリのURLを取得します。
Githubにログインして、あなたが作ったリポジトリをクリックしましょう。
リポジトリ画面に移動したら、緑色のボタン(Clone or download)をクリックします。
すると、あなたが作成したリポジトリのURLが表示されるのでコピーします。
以下の赤い四角で囲われているボタンを押すと、コピーした状態になります。
次にVS Codeを開いて、キーボードの「F1」を押します。
Git: クローンをクリックしましょう。
すると、リポジトリのURLを求められるのでペーストしてEnterを押します。
するとフォルダの選択を求められます。
ここで選択したフォルダにリポジトリが作られるので、あなたが保存したいフォルダを選びましょう。
(以下は、デスクトップにあるwebというフォルダを選択した時の例です)
「リポジトリの場所を選択」を押すと、ユーザー名とパスワード入力を求められます。
Githubに登録したアカウントのユーザー名・パスワードを入力しましょう。
これでGithubに作成したリポジトリが、あなたのPCにクローン(コピー)されました。
VS Code右下に以下のようなダイアログが出るので、「ワークスペースに追加」をクリックしておくと良いでしょう。
ワークスペースに追加しておくと、VS Codeでワークスペースにあるファイルをすぐに開けるようになります。
※間違えてダイアログを閉じても、後で追加することもできるので気にせずで大丈夫です。
SourceTreeでクローン!
SourceTreeとは、グラフィカルな画面でgitを直感的に操作できるソフトです。
どうしてもコマンド操作がやりたくない、わからないという人はSourceTreeを使ってみると良いでしょう。
SourceTreeのインストールや使い方は、以下が参考になります。
▼Gitクライアント! SourceTree の使い方 ~GUIでGitを使おう~▼
https://tracpath.com/bootcamp/learning_git_sourcetree.html
▼Gitなんて怖くない!超初心者向け、SourceTreeの使い方はじめの一歩!▼
https://prog-8.com/blogs/how_to_use_sourcetree
変更を記録しよう(git commit)
変更を記録するための流れは、以下の通りです。
- 作業してファイルを保存する
- ステージする
- コミットする
ステージ??コミット??
コミットっていうのは変更したり追加した作業内容をリポジトリに保存すること。
ゲームのセーブみたなものだと思えばいいよ。
じゃあステージは?
セーブする前に一時的に保存しておく場所のことだぜ!
言葉だけで説明されても意味わからんだろうから、実際に操作してみよう!
ファイルを追加する
先ほどクローンしてきたフォルダの中にファイルを追加してみましょう。
まずは、VS Codeのサイドバーから「エクスプローラー」をクリックします。
リポジトリ名の所にマウスカーソルを合わせて右クリックを押します。
その中にある「新しいファイル」をクリックしましょう。
ファイル名入力が求められるので、入力しましょう。
ここでは、text.txtというファイル名にしました。
すると、ファイル名が緑色になります。
これは、VS Codeが「Git管理下にファイルが新規追加されているぜ!」と知らせてくれているのです。
ステージする
変更したファイルをステージしましょう。
サイドバーの「ソース管理」をクリックします。
更新ファイルの一覧が表示されます。
「▼変更」と書いてある右側の「+」をクリックすると、ステージできます(「−」をクリックすると取り消すことができます)。
ステージする前に変更したファイルの保存を忘れないようにしましょう。
コミットできるのはステージされたファイルが対象となるので、バージョンを作りたいファイルは必ずステージする必要がある、ということを覚えておきましょう。
コミットする
次にコミットです。
コミットをすることで、新しいバージョンが作られます。
メッセージ欄に「編集内容」や「編集した理由」などを入力して、Ctrl + Enterを押します。
これでコミット完了です!
コミットした時は、上記のように、メッセージを残すことができるぜ。
何をしたのか?なぜ変更したのか、などを残しておくと管理しやすくなるんだ。
ほぉ~、じゃあ「編集した姿を君に見せたくて」みたいなわけわかんないメッセージはNGじゃん。
このメッセージを使って、キャバコに想いを伝えたくてさ。
キモいわ。普通に告れし。
あっさりふられたぜ。
じゃあ次は、コミットした内容をリモートリポジトリにも反映してみよう。
今の段階だと、作業したPC(ローカルリポジトリ)にだけ変更が保存されているだけだからね。
あなたのPC→バージョン2
リモートリポジトリ(Github)→バージョン1
という状態なのさ。
このままだと、他の人にバージョン2を共有できないの?
そう。リモートリポジトリもバージョン2にする必要があるってことさ。早速やってみよう!
変更内容をリモートリポジトリにも反映してみよう(git push)
ローカルリポジトリの変更内容をリモートリポジトリにアップロードして共有することをpush(プッシュ)と言います。
コミットした段階では、ソース管理プロバイダーは以下のように「1↑」と表示されている状態になっています。
この「1↑」って何なの?
これは、リモートリポジトリにプッシュされてないバージョンがひとつあるよ!ってこと。
コミットが重なれば、この1という数値が増えていくって形さ。
左の「0↓」はリモートリポジトリからダウンロードされてないバージョンの数を示してるんだ。
誰か他の人がmasterにプッシュしていたら、この数字が増える。
じゃあ、プッシュしたら「1↑」が「0↑」になるってこと?
そういうこっちゃ。早速プッシュしてみよう。
サイドバーから「ソース管理」をクリックして、リポジトリ名の部分にカーソルを合わせます。
すると、以下画像のように「・・・」が表示されるので、クリックします。
クリックすると、様々な選択肢が表示されます。
「プッシュ」をクリックしましょう。
これでプッシュ完了です。
リモートリポジトリ(GithubのWebサイト)で見てみると、ローカルリポジトリでの変更が反映されているのが確認できます。
プッシュすることで、ローカルでの作業や変更履歴を他のチームメンバーと共有したり、出先での作業などに引き継ぐことができるようになるんだぜ!
リモートリポジトリにpushしてしまったコミットは、物理的に消すのが超大変です。
ゆえに、機密データや個人情報は絶対にpushしないようにしましょう。
▼機密データをリポジトリから削除する(Github)▼
https://help.github.com/ja/github/authenticating-to-github/removing-sensitive-data-from-a-repository
ブランチを作って作業してみよう
ブランチとは?
ブランチって何?王様のブランチぐらいしか、イメージ出てこないよ?
いや、そっちのブランチじゃねえわ。
「枝」って意味な。
うん、枝って言われてもイメージわかないし!
だよね。
チーム開発ってさ、同時進行することがほとんどなのね。
例えば、AさんがPHPのコーディングをやって、BさんはHTML/CSSコーディングをする、みたいにね。
同じ日にAさんとBさんが同じファイルを触っちゃうとさ、作業が重なっちゃうでしょ?
そうすると、Gitは「AさんとBさんのファイル、どっちが正しいの?」ってわかんなくなっちゃうのよ。
確かに、Gitの気持ちになって考えたら、超困るよね。
そこで、AさんもBさんも同時に作業しても良いように、ブランチ(枝)ってのを作るんだ。
ブランチを作ると、Aさんの作業とBさんの作業それぞれを、独立した物として扱うことができるぜ。
ん~~~~
まだイメージ湧いてないけど、例えばAさんがindex.htmlに「こんにちは」って書いてプッシュしても、Bさんのindex.htmlには何の変化もないってこと?
そうそう、その認識で合ってるぜ!
実はリポジトリを作成した時点で、ブランチができてるんだ。
それがmasterブランチ!
あ、VS Codeの左下に表示されてるmasterって、ブランチの名前だったのね!
そういうこと。
実際の開発では、masterブランチを本番環境と紐づけることが多いぜ。
だから、masterブランチをプッシュするのは、本番環境に反映する責任者だけって形が取られる。
もちろん、会社やプロジェクトによって、管理方法は違うけどね。
おお、masterブランチへのプッシュが何か怖くなってきたね!
まぁ、今は練習の段階だから、好きなだけプッシュして大丈夫ぜ。
おし、じゃあブランチを作ってみようか。
ブランチを作る
画面左下の「master」と書かれているところをクリックします。
(現在はmasterブランチが選択されているという意味です)
上部に表示されたウィンドウから、「新しい分岐の作成」をクリック。
任意のブランチ名を付けてEnterを押します。
これでmasterがコピーされたブランチが作成されました。
リモートリポジトリにも反映する
「master」と表記されていた部分が、入力したブランチ名に変わりましたよね。
今の段階だとローカルリポジトリにのみブランチが作成されている状態なので、以下の雲のマークをクリックしましょう。
これで、リモートリポジトリにもブランチが作成されます。
新しく作ったブランチでファイルを更新する
新しく作ったブランチで、何か変更を加えて保存、ステージしてコミット、プッシュしてみましょう。
ここでは、text.txtの内容を変更してプッシュしてみます。
text.txtの内容が気持ち悪くなってる。
まぁ、これは練習だから!あんまり気にすんなって!
で、このキモいのをプッシュすると、Githubのmatsuzaki_wataruブランチにキモいのが反映されたってことになるよね?キモいのが。
そう、反映されてる!
でも、matsuzaki_wataruブランチだけに反映されてるから、masterブランチには何の影響もないんだ。
じゃあ、masterブランチに切り替えたら、このキモいのは見なくて済むってこと?
そう!あんまりキモいって言わないで。繊細なんだから。
ブランチを切り替える
ブランチを切り替えることをチェックアウトといいます。
用語が多くて大変ですが、チェックアウトという用語もよく出てくるので、覚えておくと良いでしょう。
チェックアウトしたい時は、同じように画面左下の、現在選択されているブランチ名をクリックします。
そうすると、ブランチの一覧がリストとして表示されるので、切り替えたいブランチを選択してクリックすれば、そのブランチの状態に切り替わります。
masterってのと、origin/masterってのは何が違うの?
masterはローカルリポジトリのブランチ。
つまり、自分のPCにあるブランチさ。
「origin/」が付いてるのは、リモートリポジトリのブランチね。
masterに切り替えたら、text.txtのキモい内容が見えなくなったよ。良かったぁ。
見たくなったら、またmatsuzaki_wataruブランチに切り替えれば良いんだからね!
プル(git pull)してみよう
例えばだけど、Aさんがバージョン50ぐらいまでプッシュしたとして、それをBさんがダウンロードするにはどうしたらいいの?
そんな時は、git pull(プル)の出番だぜ!
ダウンロードしたいブランチをチェックアウトしたら、ソース管理 → 「…」をクリックします(プッシュのときと同じです)。
クリックして表示されたプルダウンメニューの中から、「プル」をクリックしましょう。
これで、リモートリポジトリに保存されている最新バージョンを、ローカルリポジトリに反映することができます。
その時は、変更中のファイルを破棄するか、一時退避してから、プルをおこないましょう。
マージ(git merge)してみよう
マージとは?
また、新しい言葉…もう覚えられないよ。
新しい用語がたくさん出てくるとしんどいよね。
でも、マージもメッチャ使うから覚えとこ。
マージは「合流する」という意味の言葉で、その名の通り、分岐したブランチを合流させる時に使うんだ。
はい、イメージわかない。
まぁ、そうだよね。
マージは理解しづらいから、図で説明していくぜ!
例えば、AさんとBさんが共同で作業をしているとします。
Aさんがmasterブランチを、Bさんが途中のコミットから分岐したBブランチでそれぞれ開発を行っていたとします。
この時、AさんはBさんの開発した内容を現在のmasterブランチに取り込みたいと考えたとする。
ええっ、そんなことができるの?
それが「マージ」さ!最新のmasterブランチにいる状態で、Bブランチのマージをすると…
お、くっついたの?
そう。Bブランチの内容をmasterブランチに取り込めたってことになるのさ!
これがあるから、複数名での同時開発が進められるわけね。
マージの方法
対象のブランチを選ぶ
どのブランチとどのブランチを合体させるのかを決めます。
今回はmasterにmatsuzaki_wataruをマージする例でお見せしていきます。
masterをチェックアウトしましょう。
コマンドパレットを開く
VS Codeの上部メニューから「表示」 > 「コマンドパレット」をクリックするか、Ctrl+Shift+Pを押すと、コマンドパレットを開けます。
マージを選択する
コマンドパレットで「gitm」もしくは「m」と入力すると、「Git: ブランチをマージ…」というメニューが表示されるので、クリックします。
対象のリポジトリを選択後、マージしたいブランチ(ここではmatsuzaki_wataru)を選択します。
これでマージ完了です。
matsuzaki_wataruブランチでの編集内容がmasterにも反映されていることが、確認できるはずです。
マージした段階でコミットはされていますが、プッシュはされていません。
リモートリポジトリにも反映する際は、プッシュも忘れずにおこないましょう。
すんごい、めっちゃ便利じゃん!
そう、ここまではめっちゃ便利なんだが…….
なによー、もったいぶっちゃって
コンフリクト(衝突)が起きると面倒なんだよね。最初パニくるぜ。
コンフリクト???
コンフリクトを解消しよう
コンフリクトとは?
例えばさ、Aさんがdevelopブランチでtext.txtの文字を「愛してる」にして、Bさんがmasterブランチでtext.txtの文字を「恋してる」にしたとするじゃん?
この状態でマージすると、どうなると思う?
え、最後に更新された方が残る???
それだと、大事な情報が上書きされちゃうよね。
もしかしたら、Aさんが作業したdevelopブランチの更新が正しいものかもしれないじゃない?
あ、そうか…。じゃあ、どうなるの?
コンフリクトが発生して、コミットがいったん中断されるんだ。
正しい情報を手動で作業することが求められる状態になる。
コンフリクトが起こると、以下のようなエラーが表示されます。
コンフリクト解消のための作業
上記画面は、
- Aさんがdevelopブランチでtext.txtの文字を「愛してる」にした
- Bさんがmasterブランチでtext.txtの文字を「恋してる」にした
という条件下で、masterブランチをチェックアウトして、developブランチをマージした状態です。
現在の変更(masterの変更)部分が緑色に、入力側の変更(developの変更)が青色で表示されていますので、どちらを取り込むのか、あるいは全部を取り込むのか、選択して正しい状態にしましょう。
手動で編集することも可能です。
編集が終わったらファイルを保存してステージ、コミットすればコンフリクトが解消された状態でマージ・コミット完了です。
エラーが出たときはパニックになりそうだったけど、対処法は簡単なんだね。
ひと目でファイルが比較できるから、落ち着いて対処すれば楽勝さ!
ただ、実際の開発現場では、様々なファイルが複雑に絡み合うから、コンフリクト解消が大変だぜ!
そういうチーム開発の現場に飛び込む新人は、プロジェクトのリーダーや上司などが対応してくれると思うから、指示に従いながらチーム開発の流れをつかんでいこう!
まとめ
ふい~~~ようやく終わりかぁ~
基礎だけでも、かな~り濃いし、理解が大変だわ。
そうだぜ!
ステージ・コミット・プッシュ・プル・マージは、基本中の基本だからね。
繰り返し操作しとかないと忘れるから、この記事を読んで満足すんなよ?
ちゃんと、PHPとかHTMLを勉強するときも、Gitで保存して基本を血肉化させよう!