Git+Github入門講座へようこそ！プログラミングYoutuberのせお丸です。
この講座は、Git未経験の方、
または、gitをなんとなく使ってるけどもよくわかってない・・
という方に向けて解説した入門講座です。
なお、この記事の内容はYoutubeでも公開しています。
記事よりもYoutubeの方が分かりやすいのでオススメです！
フル字幕なので、音を消しても動画学習できます
Gitについてのご質問は、このYoutubeのコメント欄で受付していますので、わからない所があったら質問してください♪
なお、このYoutubeチャンネルでは「未経験から年収1000万円を目指すプログラマー養成講座」を配信していますので、ぜひチャンネル登録をお願いします♪
それではGit入門講座スタートです！
Gitとは
gitはバージョン管理ツールです。
・いつ誰が
・どのファイルに対して
・どのような変更を行ったのか？
という履歴を記録しておくためのツールです
詳しくは、このあと解説していくので、今の段階でわからなくても大丈夫です
Gitリポジトリ
gitではリポジトリという場所でファイルを管理します。
リポジトリは通常、プロジェクトの単位になります。
上記画像がリポジトリ、つまりプロジェクトの単位になります。
プロジェクトと言ってピンとこない方は、システムの単位と考えてもらっても構いません。
この場合はEC-cubeという一つのシステムにつき１つのリポジトリ、
ec-cube2というまた別のシステムに対して1つのリポジトリを割り当てています。
ではリポジトリの中身を見てみましょう！
これがEC-cube2というシステムのリポジトリの中身です。
このように、このシステムのソースコードが、ずらーっとここに並んでいます。
フォルダをクリックするとこのフォルダの中にもファイルが並んでいます。
そしてこのように、いつ、誰が、どのような変更したのか？
という履歴をみることができます。
また、そのファイルをどのように変更したのか？という差分も見れます
ローカルとリモート
gitを使って複数人で共同開発をする場合は、
gitが用意してくれているサーバーに対してアップロードやダウンロードを行うことでファイルの共有を行います。
このサーバーのことをgitではリモートと呼びます。
一方で個人個人の作業端末のことをgitではローカルと呼びます。
リモートサーバーの中身を見たい時は、githubというツールを使うと便利です。
先ほどからお見せしていた画面がgithubです。
どんなリポジトリがあるのかな？とか
リポジトリの中にはどんなファイルがあるのかな？というのは、githubを使って見ていきます。
ちなみにgitとgithubは別物なので一緒にしないように注意しましょう。
ですのでgithubを使わずにgitだけで使うということもできます。
リポジトリの作成
では実際にリポジトリを作ってみます。
今回はgithubを使ってリポジトリを作ります。
まずはgithubにアカウントを登録しましょう。
そして、右上のプラスのボタン押して「new repository」で新しいリポジトリを作ります。
次にリポジトリの名前を入力するところがありますので、
今回はhello_gitという名前でリポジトリを作ることにします。
次にアクセス権の設定ですが、
publicを選択した場合は全世界にこのリポジトリの中身が見られます。
リポジトリの中身を見られたくない時は、privateを選択します。
このリポジトリにアクセスできるようになります
create repositoryという緑色のボタンを押すと、hello_gitという名前の新しいリポジトリが
リモート側に作成されます。
次にこのリポジトリを使って作業を進めていくためには、
リモートからローカルの端末上に、このリポジトリをコピーします。
リモートからローカル側に、リポジトリをコピーする時は、
git cloneというコマンドを使います。
リポジトリを作成すると、git cloneをするためのURLのような文字が表示されますので、
これをコピペして、ターミナルで
を実行します。
これでリモート上にあったリポジトリが、Aさんのローカル端末上にcloneをしてコピーされました。
エンジニアが使っている黒い画面のことです
この後の開発の流れとしては、Aさんはこのローカル端末上のリポジトリに、
Aさんのファイルの変更を色々していって、
それをまたリモートにアップロードする、という流れになります。
CUIとGUI
さて先ほど
git cloneというコマンドを使いましたが、
gitではこのようにコマンドを打って操作をしていくのが基本です。
ですが、コマンドがよくわからない、という方は
Sourcetreeというアプリを使うと、コマンドではなくマウス操作でgitが使えるようになります。
コマンドでも、Sourcetreeを使う場合でも、基本は一緒です。
gitの勉強する時は、
コマンドでどう打つのか？とか
Sourcetreeでどこを右クリックするのか？とか、
そういった目先の操作方法よりも、むしろ全体の概念だったり、gitの用語を理解するのが大事になりますので、
まずは最後までこの講座をみてgitを理解しましょう
Gitコミット
ステージング
ファイルに変更を加えて、その内容をgitに保存してみましょう！
まずはファイルを二つ用意しました。
左側はファイル1で、中身はfile1ですと書いてあります。
右側はファイル2で、中身はfile2ですと書いてあります。
この状態で、ターミナルに
というコマンドを打ってみます。
するとこのようにファイル1とファイル2が赤字で表示されました。
git statusは、gitの状態を見るためのコマンドです
ファイル1とファイル2という新規ファイルを作成したので、
gitが「なにやら新しいファイルがある」というのを検知して、
ファイル1とファイル2を赤字で表示しているわけです。
このようにgitが２つのファイルを見つけた状態になったのですが、
この段階ではまだこれらのファイルはgitに管理されていません。
ファイルをgitに管理させたい場合は、
というコマンドを使います。
では、
を実行してからgit statusを実行してみます。
するとファイル1がgitの管理下に入ったため、緑色で表示されるようになりました。
このようにgitでは、
このファイルはgitで管理する
このファイルはgitで管理しない
という管理を、git addコマンドで選択をすることができます。
そしてgitで管理されている状態(つまり緑色になってる状態)のことをステージングと言います。
今ファイル1はステージングされている状態なわけです。
つまりgitで管理されている状態です。
一方ファイル2はまだ赤色なので、ステージングされていない状態です。
一括でgit add
先ほど
のようにファイル名を指定しましたが、
ファイル名ではなくてドットを指定してみます。
と指定すると、
すべてのファイルをステージングするという意味になります。
つまり全てのファイルを一括で管理対象にする
という指定です。
このコマンドを実行して、file1とfile2、両方が緑色(ステージング状態)になりました。
コミット
次はこの状態をgitに保存してみます。
gitで保存を行う場合は
コマンドを使います。
コミットメッセージの部分には好きなコメントメッセージを残しておくことができます。
今回は、「初めてのコミットです」と、コミットメッセージを残して、コマンドを実行します。
これで2つのファイルがgitに保存されました。
続けて編集する
では1回目の保存が終わりましたが、続けてファイルを編集してみようと思います。
ファイル1の中身を「2回目の編集です」という内容に書き換えました。
もう一度git statusを実行してみます。
するとファイル1を編集したのでgit statusの結果には
と表示されます。
つまりファイル1を編集したことを、gitが検知してるわけです。
一方ファイル2の方は、先ほど保存した後に何も変更していません。
ですのでgitは、変更してないね！ということで、file2は何も表示していません。
この2回目の編集を保存するには、またgit addを行います。
そして
を打つと、ファイル1が緑色になって
またgitにステージングされた状態になりました。
つまりコミット待ちの状態になっているわけです。
ではここで先程と同様にコミットを行います。
これで2回目の保存が終わりました。
git log
ではここでgit logというコマンドを打ってみます。
するとこのように、
何時何分に誰がコミットしたという記録が表示されます。
Gitプッシュ
これで、Aさんのローカル端末上に２つのコミットが行われました。
ですが、この変更をまだアップロードしていないので、
リモート側には、この2個のコミットはまだ来ていません。
ではAさんのコミットをリモートに対してアップロードしてみましょう！
gitでアップロードを行うときは
というコマンドを使います。
これでアップロードが完了しました。
ではリモート側の状態を確認するために、githubを見てみましょう！
するとこのように
初めてのコミットです
2回目のコミットです、という変更履歴がgithubに届いています。
そしてそのリモートの内容を今githubで見ているという状態になってます。
githubではこのように、ファイルの変更差分も確認することができます。
このように、gitのコミットはゲームのセーブポイントのようなものです。
自分の作業のキリのいいところで、ここで一回セーブしておこうかなという時に
gitコミットを使ってセーブを行います。
Gitプル
git pullについて解説します。
先程Aさんはリモートに対して、いくつかのコミットをプッシュしました。
この状態でBさんという新入社員のプログラマーがやってきて、
今日から開発に参加する事になりました。
今日からプロジェクトに参加するBさんが一番最初にやることは、
Bさんのローカル端末上にリモートのリポジトリをcloneしてくることです。
それではBさんのターミナルで
を実行します。
するとBさんの手元に最新のリポジトリがcloneされます。
ではBさん側でgit logを打ってみましょう。
すると、以下のように、これまでAさんがリポジトリにプッシュしてきた内容がBさんの手元にもダウンロードできました。
では3個目のコミットまで終わっている状態で、
次はBさんが4回目のコミットを行ってみます。
Bさん側でファイル1コミットを行います。
次にgit push originを行います。
すると、Bさんの4回目の変更がリモートに対してプッシュされましたので、
Bさんとリモートはどちらも4回目のコミットまで情報を持っています。
ですがAさんはまだ3回目のコミットまでしか情報を持っていません。
何故かと言うと、リポジトリにある最新情報を、Aさんはまだダウンロードしてないからです。
ではAさんがリポジトリにある最新の情報を取り込むには、どうしたらよいのでしょう？
これまではgit cloneというコマンドを使ってダウンロードしてきました。
ですがgit cloneというのは、新規にリポジトリをローカル側にコピーする場合に使うコマンドです。
今Aさんの手元にはリポジトリが存在しますので、こういう時はgit cloneではなくて
git pullというコマンドを使います。
このコマンドを実行します。
するとAさんの手元に、最新のリポジトリ情報がダウンロードされました。
ブランチ
ブランチというのは、gitの変更履歴を枝分かれさせる機能です。
例えば、コミット1、コミット2、コミット3とコミット履歴が伸びているとします。
これらのコミットは、
Aさんが新規にリポジトリを作ってから行ってきた変更履歴です。
gitではこの元祖変更履歴のことをmasterと呼びます。
Gitでは、このmasterから枝分かれをした歴史を作ることができます。
このように枝分かれをさせることをgitではブランチと呼びます。
masterで誰かがコミットしていくので、どんどん育っていきます。
そしてブランチはブランチでまた別のコミットを積んでいくことになります。
そしてこのブランチは、とある時点でmasterに合流することができます。
この合流によって、枝分かれしていたmasterでの歴史と
ブランチ側での歴史が全て合流するわけです。
なぜブランチが必要なのか？
ベテランプログラマーのAさんは
駆け出しプログラマーのBさんに対して、開発を依頼しました。
ですがこのシステムは
既に本番稼働している大事なシステムですので、
駆け出しのプログラマーBさんが作った、バグってるかもしれない修正を
そのままリモートにプッシュされてしまっては本番が壊れてしまう可能性があります。
そういう時はmaster側の歴史とは
また別の歴史を枝分かれさせて、ブランチで開発をしてもらいます。
ブランチは、masterにマージするまではmaster側には影響を与えません。
ですのでブランチでBさんが開発をして、それがバグっててもmasterの歴史には一切影響しないわけです。
またブランチはリモートにプッシュしても大丈夫です。
masterにマージしない限りはmasterは安全なままです。
では実際にやってみましょう！
まずはBさん側でmasterから新しいブランチを作ります。
ブランチを作るときは次のように入力します。
というコマンドを使って、developという名前のブランチを作ります。
という意味になります。
ここでgit branchと入力してみると、masterとdevelopの2つが表示されます。
そして今はdevelop側が緑色になってます。
またmasterに戻りたい場合は
を実行します。
このようにgit checkoutというコマンドを使って、作業するブランチの切り替えを行います。
そしてBさんがdevelopブランチ上で、5回目のコミットを行って、リモートにPUSHします。
新しいブランチをプッシュするので、
コマンドは
と打ちます。
するとBさんの手元で作ったdevelopブランチが、リモートにプッシュされました。
ではこのリモートにあるdevelopブランチをAさんの手元に持ってきます。
Aさんの手元にdevelopブランチを持ってくるには、
コマンドを実行します。
これでAさんの手元にもdevelopブランチがダウンロードできました。
ではAさんもdevelopブランチにcheckoutしてみます。
これでBさんの行ったdevelopブランチの変更が、Aさんの手元でも見れるようになりました。
先輩のAさんはこのdevelopブランチで、コードに問題がないかレビューを行います。
そして何も問題がなければ、このdevelopブランチをmasterへと合流させます。
このようにブランチの歴史を合流させることをgitではマージと言います。
Gitマージ
マージする時はマージ先のブランチに移動します。
これでマージ先であるmasterへcheckoutすることができました。
今はmasterにcheckoutした状態です。
そしてこのmasterに対してdevelopをマージしたいので、
というコマンドを打ちます。
これでmasterに対してdevelopがマージされました。
そして今Aさんの手元でdevelopをmasterにマージしたので、
このmasterの変更をリモートに対してプッシュを行います。
一つのブランチを切って開発をすることで安全に開発が進められます。
プルリクエスト
プルリクエストについて解説します。
先ほどはAさんの手元でマージコマンドを打ってdevelopをmasterにマージしましたが、
このやり方ではなく、githubを使うともっといい感じに運用できます。
それではBさんの立場で、次の新しい機能を開発していきましょう！
developブランチで、file1の6回目の編集を行って、これをコミットします。
次にgit pushします。
ここでgithubをみてみると新しいブランチができたよ、という意味の通知が来ています。
そしてこの画面に、「プルリクエストを作る」というようなボタンがありますので、これを押します。
すると、プルリクエストと言われるものができます。
プルリクエストとは、開発を行ったBさんからAさんに対して「このブランチをmasterにマージして下さい」という依頼のことです。
プルリクエストで依頼を受けたAさんは、github上でプルリクエストをレビューします。
プルリクエストではgithub上でファイルの変更差分が見れるようなっています。
レビューをする立場であるAさんは、このプルリクエストに対して色々と指摘コメントを書き込むことができます。
そして最終的にブランチが問題ない状態になったら、merge pull requestというボタンを押せば、マージが完了します。
コメントを残したりなどできるのでとても便利です。
github上でプルリクエストを作ってレビューをしてもらうというのが今は主流になりつつあります。
コメント