Git

【画像40枚で解説】SourceTreeではじめるGit入門【実務目線】

悩む人
悩む人

Gitを使ってみたいけど、プログラマーが使うものでしょ?

黒い画面は触りたくないから、簡単にバージョン管理する方法があれば知りたいな

 

今回は、初心者でもGitを簡単に使う方法を解説していきます。

 

この記事を書いている僕は、Web制作会社に務める現役のWebコーダーです。

実務ではバリバリGitを使っているので、プログラマーだけが使うという訳ではなく、Web制作の現場では当たり前のように使われています。

 

プログラミングを学び始めた初心者でもGitの基本的な使い方を学んでおけば、転職後の業務でも苦労せずに済むと思いますので、今のうちにマスターしちゃいましょう!!

 

初心者でも簡単にGit管理する方法について「実務で使う知識」に絞って解説していきます!

 

そもそもGitって何?

Gitは「バージョン管理システム」です。

プログラマーだけじゃなく、Web制作の現場でも現役で使われていて、効率的に開発するには必須になっています。

 

例えば、

  • 変更ごとのセーブポイントを作れる
  • いつでも好きな時点に戻すことができる
  • 複数人で修正した箇所を合体できる

こんなメリットがあるので、めちゃくちゃ便利です。

とはいえ、黒い画面でやろうとすると、挫折するかもしませんので、初めはSourceTreeというツールを使うといいですよ。

 

SourceTreeで簡単にGit入門してみよう

sourcetree

SourceTreeは「黒い画面が苦手」という初心者にも愛されるツールですが、とても直感的に操作ができるので、ベテランの人でも使っている人は多いです。

特徴は以下の通り。

  • 日本語対応
  • 無料
  • Bitbucket、Githubと連携

 

まずは、SourceTreeを使いつつ、Gitの仕組みを理解することから始めましょう。

SourceTreeのダウンロード、セットアップについては、Progateの記事がわかりやすかったので、当記事では割愛します。

 

SourceTreeでGit管理してみよう

SourceTreeをインストールし、セットアップができましたか?

まずはGitを個人で使ってみましょう!

 

Gitの基本

  • リポジトリを作る(セーブポイントを入れる倉庫を作る)
  • コミットする(セーブポイントを作る)
  • チェックアウトする(特定のセーブポイントに戻る)

セーブポイントを作り、チェックアウトして特定のポイントに戻ることで「いつでも好きな状態に戻す」ことができます。

 

この知識を知っておくことで、バージョン管理の基本は抑えることができますね。

では、一つずつ解説していきましょう

 

リポジトリを作る

リポジトリとは「セーブポイントを入れておく倉庫」のようなものです。

バージョン管理する情報は、全てこのリポジトリに格納されていきます。

 

自分のパソコン内にあるリポジトリは、「ローカルリポジトリ」と呼ばれます。

 

まず、バージョン管理を行いたいディレクトリ(フォルダ)を作成しておきましょう。

SourceTreeを起動します。

 

以下のような画面が表示されるので、「新規…」をクリックし、「ローカルリポジトリを作成」をクリックします。

 

Git管理したいディレクトリを選択し、作成ボタンを押します。

 

すると、リポジトリが作成され、バージョン管理ができるようになりました。

  • 画面中央:バージョン管理履歴
  • 画面下左側:変更したファイル一覧
  • 画面下右側:ファイルの変更内容

 

 

コミットする

ここで試しに、 テストデータを入れてみました。

すると、Gitがファイルに変更があったことを察知し、左上に18箇所の変更があると教えてくれています。

変更したのに画面へ反映されていないときは、ブラウザと同様に更新すれば反映されます。(Macであれば⌘+R)

 

 

コミットするためには、ステージする必要があります。

ステージは、コミットするためのステージングエリアに移動する処理で、これをしないとコミットができません。

 

「ステージングに未登録のファイル」にチェックを入れれば、変更したファイルを全てステージすることができますが、個別で指定することも可能です。

ステージングエリアは、以下の場合なんかに個別でファイル指定できます。

必要があれば、ファイルを小分けにしてコミットした方が「戻るポイント」が多くて良さそうですね。

  • 複数のファイルを小分けにしてコミットしたい
  • コミットしないでおきたい変更がある

 

 

 

はい、これでステージングエリアに移動できました。

左上のコミットボタンを押して、コミット画面に進みましょう。

 

画面下のテキストボックスに、コミット内容を表すメッセージを入力し、コミットボタンをクリックすればオッケーです。

 

 

はい、これで初めてのコミットが完了しました!

 

 

練習のため、フォルダに入れたファイルを適当に修正し、コミットしてみよう!

はい、いくつか履歴を登録できましたね、。

 

コミット(セーブポイント)は細かく作ろう

できるだけ細かくコミットした方が、あとで「戻れるポイント」がたくさんあるので便利です。

以下のような感じで、こまめにコミットしていきましょう。

 

すみません。このコミットメッセージはあまり良くない例かもです。

具体的には、下記の書き方がいいでしょう。

 

例えば、

1行目の頭に変更内容の種別と要約を書きます。

2行目に改行

3行目に変更した理由を記入すると、あとで確認しやすくなります。

 

例えば、こんな感じ。

[fix]IEで表示が崩れるバグの修正

(改行)

flexboxが原因だったので、CSSハックでスタイルをあてました

 

変更内容の種別[fix]とか

  • fix:バグ修正
  • add:新規(ファイル)機能追加
  • update:機能修正(バグではない)
  • remove:削除(ファイル)

 

こちらの記事を参考にさせていただきました。

とても参考になるので読んでみてください!

 

チェックアウトでコミットを移動する

ファイルをセーブした時点に戻す方法として「チェックアウト」があります。

簡単に言うと、コミットを移動しているだけなので、変更内容を削除するには「リバート」を使わないといけません。

当記事ではリバートについての解説は割愛しますので、参考記事を読んでみてください。

 

実際にチェックアウトの操作をした動画がこちらです。

コミットログは、下に行くほど過去のものになります。

 

今回、index.htmlの中身を空にしたので、初めのコミットに戻って復元してみたいと思います。

方法は簡単で「戻したいコミットをダブルクリックするだけ」

 

index.htmlの中身が変わっているのがわかりますか?

これが、チェックアウトです。

 

Gitの基本は理解できたでしょうか?

もう一度おさらいです。

  • リポジトリを作る(セーブポイントを入れる倉庫を作る)
  • コミットする(セーブポイントを作る)
  • チェックアウトする(特定のセーブポイントに戻る)

 

おめでとうございます!

これができると、「個人でGitが使える」レベルです。

 

続いては、チームでGitを使うための知識Githubを使ってみましょう。

 

Githubを使ってみよう

github

GithubはGitホスティングサービスです。

GitホスティングサービスにはGithubとBitbucketがありますが、今回はGithubを使用していきます。

 

簡単に言うと、「ネット上に自分のリポジトリを持ち、世界中に公開できる」ということです。

これを使えば、チームでGitを使うことが可能になります!

 

GithubでGit管理する手順は以下の通りです。

  1. Githubのアカウントを作る
  2. リモートリポジトリをクローンする
  3. ローカルの変更をリモートにプッシュする

 

一つずつ解説していきましょう!

 

Githubのアカウントを作る

まず、Githubの公式ページにアクセスし、右上の「サインアップ」ボタンをクリックします。

github

 

アカウント作成画面に進むので、必要事項を入力してプラン選択画面に進みます。

 

 

 

個人で使うなら、Freeでオッケーです。

 

画面が切り替わります。

登録したメールアドレスに確認メールが届いているはずなので、認証しましょう。

 

トップ画面に戻ると、マイページが表示されましたでしょうか?

それではリポジトリを作成していきましょう。

 

右上にある「+」ボタンをクリックするとメニューが表示されるので、

「New Repository」をクリックしましょう。

 

 

リポジトリ作成画面に切り替わりますので、必要事項を入力します。

 

  • Repository name:リポジトリの名前
  • Description:説明
  • Public:公開
  • Private:非公開

「Initialize this repository with a README」という項目がありますが、これは「README」という説明書を作成するためのものです。

READMEにリポジトリの詳細な説明などを記載しておけば、チームで必要な情報を簡単に共有することができます。

今回は一応、チェックを入れておきましょう。

 

リポジトリを作成したら、リポジトリ画面に切り替わります。

これで無事作成が完了しました!

 

では次にリポジトリをローカルにクローンしていきましょう。

 

 

リモートリポジトリをクローンする

クローンとは

リモートリポジトリをローカルリポジトリにコピーすることです。

 

クローンすることで、ローカルにもリポジトリが作成されるので、

自分のパソコンでもGit管理できます。

 

クローンをしていきましょう。

Githubのリポジトリ画面から「Clone or download」をクリックし、URLをコピーします。

 

SourceTreeのメニュー画面から

「新規…」ボタンをクリックし、URLからクローンをクリックします。

 

 

ソースURLにコピーしてきたURLを貼り付け、

保存先のパスを指定します。ここではデスクトップを指定していますが、作業用のディレクトリを予め作成しておいた方がいいですね。

 

クローンボタンを押すと、リモートリポジトリがコピーされました。

実際にローカルに作成されたディレクトリを見ると、

リポジトリを作った時に生成したREADMEファイルがあることがわかります。

 

ここまでで、リモートリポジトリのクローンが完了しました。

では実際に、ファイルを追加修正し、Githubに反映させてみましょう。

 

ローカルの変更をリモートにプッシュする

クローンしたリポジトリとはいえ、ただコミットするだけではGithubに反映されません。リモートに反映させる処理が別で必要になってきます。

そこで、リモートリポジトリに反映するには「プッシュ」を使います。

 

実際にファイルを追加してみて、プッシュしてみましょう。

 

今回は、

Git管理しているリポジトリに、予め作っておいたindex.htmlファイルを入れました。

 

ファイルの追加を検知していますね。

まだコミットしてないのに、コミットログがあるのは、リモートリポジトリで READMEを作った履歴です。

 

ここはおさらいですね。

変更内容をコミットしましょう。

 

 

念のため、Githubを確認してみると、やはり反映されていません。

 

ここでコミットログをみてみると、「1コミット先行」と書かれています。

ローカルリポジトリがリモートリポジトリよりも1コミット先に進んでるよ!という意味です。

この変更内容をプッシュして、リモートの状態を最新にしてあげましょう。

 

 

プッシュ先のリポジトリはoriginブランチはmasterを選択してOKをクリックします。

※GithubのIDを聞かれた場合は、登録したユーザー情報を入力してください。

 

これで「1コミット先行」の文字が消えて、最新の状態に反映されました。

実際にGithubの画面を見てみましょう。index.htmlが反映されてますか?

 

コミットログを見てみると、

[master][origin/master]というマークがありますが、これはローカルとリモートを表しています。

これらが同じコミットに並んでいる状態=リモートとローカルが同じ状態

と覚えておきましょう。

 

さて、ここからはもう少し踏み込んだ機能「ブランチ」と「マージ」について解説していきましょう。

 

ブランチとマージを覚えよう

ブランチは、チームでの同時作業に必要な機能です。

以下のイメージでブランチを作っていくことで、「本番環境に影響のない世界」を作ることができ、しっかりテストを行なってから本番環境に反映させることができます。

 

 

ブランチの難しい概念についてはめちゃくちゃ省略しているので、もっと詳しく知りたいって人は調べてみてください。

 

実際にブランチを作っていきましょう。

 

ブランチを切る

ブランチを作ることを「ブランチを切る」とも言います。

 

ブランチを切りたい場所のコミットログを選んだ状態で、「ブランチ」をクリック

 

ブランチの名前をつけて作成します

 

すると、左のメニューにmasterとtestが作成されました。

masterブランチは最初から存在しているブランチで「本流」と言う意味。masterは本番用のソースコードが保たれるようにしましょう。

 

ブランチを切り替えるには、左メニューのブランチ名をダブルクリックするだけでオッケーです。

ブランチを切り替えてみると、データの内容が変わっているのがわかりますか?

 

 

ここまでで、ブランチを切る作業はオッケーです。

マージする

ブランチで修正した内容を、masterにマージしてみましょう。

 

 

マージとは、枝分かれしたブランチを結合することで、修正内容を反映することです。

 

今回は、わかりやすくindex.htmlの内容を削除、style.cssを追加しました。

変更内容をコミットしたら、masterブランチに切り替えます。

 

マージしたいブランチを右クリックし、testをmasterへマージをクリックします。

一覧の作業を行なっている動画が下記になります。

 

 

 

これで、ブランチを切って作業環境を作り、テストした上で本番環境にマージすることが可能になりましたね。

 

基本を押さえて少しずつ慣れていこう

もう一度おさらいです。

  • リポジトリを作る(セーブポイントを入れる倉庫を作る)
  • コミットする(セーブポイントを作る)
  • チェックアウトする(特定のセーブポイントに戻る)
  • ブランチを切る(本番環境に影響を与えない環境を作る)
  • マージする(ブランチの変更を本番環境に反映させる)
  • プッシュ(ローカルの変更をリモートリポジトリに反映させる)

最低限、上記の仕組みは必ず抑えておきましょう!

 

ぶっちゃけて、実務では黒い画面は不要です。

ベテランになってくると、黒い画面じゃないと対応できないことも増えてくるかもですが、少なくとも初めのうちはいらないと考えています。

 

SourceTreeで十分Gitは使えるので、初めは背伸びしないでゆっくり慣れていきましょう。

今回はGit管理するための基本的な知識のみを解説しましたが、

  • コンフリクト
  • リバート
  • プルリクエスト

など、必要な知識はまだまだあります。

 

今回学んだ知識に加えて、少しずつ理解していきましょう。

今回は以上です!

 

「よくわからん」って人は、当ブログのお問い合わせフォームまたはTwitterのDMまで連絡いただければ、わかる範囲で回答させていただきます〜!

 

最後に、参考サイトとおすすめ書籍だけリンク貼っておきますので、要チェックです。

 

参考サイト

 

 

おすすめ書籍