Help us understand the problem. What is going on with this article?

Gitを触り始めてからGitHubにpushするまでの流れを誰よりも丁寧に説明する

前回は、そもそもGitでバージョン管理するメリットはなんなのかを説明しました。

おさらいはこちらから。
なぜ僕らはGitでバージョン管理をするのか

メリットはこうでしたね?

  • セーブ機能「コミット」により過去の状態に戻れる
  • 他人にコードの意図を伝えやすくする

なんとなーく理解できたのではないでしょうか。

じゃあ早速Gitを触ってみよう!
…と思ったはいいが、どうすればいいかわからない!!!

そもそもターミナルの使い方よくわからないし?
コマンドって何?

なんかGitHubってのも使うみたいじゃん!

初学者というのは、熟練者が当たり前と思っているところに疑問を持つものです。
この記事ではそれらを丁寧に潰していきます。

チュートリアルっぽくなってるので、是非手を動かしながら理解していってください。

忙しい人は、こちらに要点をまとめておきましたのでどうぞ。

前提

  • Macユーザーが対象です(Windowの人は多少読み替えてください)
  • Gitがインストールされているものとします(Macなら既にインストールされています)
  • GitHubアカウントを持っているものとします(ググって説明記事をなぞれば大丈夫です)
  • GitとGitHubを連携して使います(GitHubの説明はあとで)

この記事のゴール

  • GitGitHubを扱うためのターミナル操作ができるようになる
  • コミットできるようになる
  • GitHubと自分のコードとを同期することができる
  • 上記までのコマンドの意味を理解できる

たったここまでに達するにも、様々な記事では省略されている分かりにくい箇所がいくつもあります
それらを丁寧に説明していきますので、ゆっくりと進んでいきましょう!!!!

超ざっくりターミナルの使い方

Qiitaやブログなどでこんな表記を見たことがあると思います。

Qiitaでよくある表記
$ git commit -m 'first commit' 
先頭の$ってなに!?

いきなり出てくる$って何者!?

先頭の$は、ターミナルでこのコマンドを打つよ!という意味です。
$は実際にターミナルに打ちません!ややこしいですね。

実際にターミナルに打つべきコマンド
git commit -m 'first commit'
$ はつけないよ!!

$がついていたら、ターミナルで打つコマンドなんだなーと覚えておいてください。

さて、ターミナルでpwdと打って実行してみてください。
現在ターミナルが指しているフォルダ(カレントフォルダ)が表示されます。

現在のフォルダを出力する
$ pwd

どこのフォルダでコマンドを実行するか、がとても重要です。
後述しますが、gitコマンドを実行するには.gitがあるフォルダにいる必要があります。

カレントフォルダを変えるには、cd フォルダの場所を実行します。

カレントフォルダを変更する
$ cd フォルダの場所

フォルダの場所(パス)の指定方法はググってください!!!
このへんがとても参考になります。

コマンドとは

先ほどからコマンドという言葉が出てきています。
コマンドとはその名の通り、命令を出して何らかの処理をするものです。

コマンドの指定方法

1単語

lspwdのように1単語で指定できるものがあります。
OSの基本的な操作が多いですね。

複数の単語

git commitのように、複数の単語を繋いで使うこともあります。
この場合、ツール名 コマンド名という関係になっています。
つまり、gitというツールのcommitというコマンドを実行する、ということですね。

オプション

-a のように -(英字) を付与することで、コマンドにオプションを指定することができます。
具体例で言うと…

オプションなし
$ ls
カレントフォルダにあるファイルとフォルダを一覧表示する
オプションあり
ls -a
カレントフォルダにあるファイルとフォルダを一覧表示する(隠しファイルも表示する)

こんな感じに使います。

引数

プログラミングの引数と同じように、コマンドにも引数があります。
先ほどの例git commit -m 'first commit'で言うと、'first commit'が引数ですね。

$ git commit -m 'first commit'
ツール名 コマンド名 オプション 引数

さて、そろそろGitの使い方に入っていきたいのですが、
その前にGitとGitHubの違いについて軽く説明をしておきます。

GitとGitHubとの違い

Git

前回の記事で説明した通りのバージョン管理ツールです。便利
ローカル(各自のPC)でバージョンを管理するもの。

GitHub

Gitをみんなで共有するためのツール。便利
各自がローカルで管理しているGitをオンラインで結びつける(hub)役割をする。
リモート(GitHubのサーバー)でバージョンを管理する。

各自がローカルで行った変更をGitHubに反映することで、開発チーム全員が同じコードを共有できるようになります。
その他、デプロイ(本番サーバにソースコードを反映すること)をGitHubと連携して出来たりなんだり、素敵なメリットがいっぱいあります。
とりあえずGitとセットで使っておこう!!

リポジトリとは

リポジトリ

ソースコードが入っていてGitで管理しているフォルダのことです。
なぜかかっこよくこう呼びます。こわがらないで。

リモートリポジトリ

GitHub上のリポジトリを、リモートリポジトリと呼びます。
リモート(remote: 遠くの、遠隔の)なので、オンラインのリポジトリという意味ですね。
リモートリポジトリを複数人で共有することで、全員が同じバージョンのコードを扱えます。

ローカルリポジトリ

反対に自分のPC上のリポジトリを、ローカルリポジトリと呼びます。
ローカル(local: 地元の、現地の)なので、自分個人のリポジトリという意味ですね。
基本的にコミットなどのGitコマンドは、カレントフォルダをこのローカルリポジトリに設定しないと実行できません

Gitを始めよう!!!

よーーーーやく、Gitを触っていきます!!!!

ローカルリポジトリを作成しよう

ローカルリポジトリとは、自分のPC上の(ローカル)ソースコードが入っているフォルダ(リポジトリ)でしたね。
みなさん、ある一つのシステムごとにソースコードをフォルダ分けしているかと思います。
それらをリポジトリにしていきましょう。

え?もうフォルダでまとめているからリポジトリじゃないの?

そう思いますよね。でも違うんです。
Git管理をしてはじめてリポジトリとなります。
このフォルダをGitで管理しろ!という命令をGitに出さなければなりません。
そう、コマンドを使います。

まずはターミナルでのカレントフォルダをソースコードが入っているフォルダに移動してください。

カレントフォルダの移動
$ cd ソースコードが入っているフォルダのパス

次にカレントフォルダをGit管理する命令を出します。
初めてのGitコマンド!やったね!

ローカルリポジトリ作成
$ git init

gitツールのinit (initialize: 初期化する)コマンドを使いました!!!!
このフォルダはGit管理され、ローカルリポジトリとなることができました。

このコマンドで何が起こったのでしょうか?
lsコマンドを使ってリポジトリの中身を見てみましょう。

ls…カレントフォルダの中身をリストで表示する
$ ls

(ファイル名がずらーっと並ぶ)

何も変わったことは無いように見えます。
それではls -aと、 -a オプションをつけてもう一度。
このオプションをつけると隠しファイルも表示します。

-aオプションをつけると隠しファイルも表示する
$ ls -a

.git (ファイル名がずらーっと並ぶ)

.gitというファイルが表示されたと思います。
.gitがあるフォルダをGitは管理します。これでフォルダがリポジトリとなることができたのです。
つまり、git init とは.gitを生成するコマンドということです!!

ローカルリポジトリとなったので、他のGitコマンドを使えるようになりました!
早速バージョン管理していきましょう!

コミットしてみよう

今は、Git管理はしているけどもまだ何もコミット(セーブ)していない状態です。
いよいよコミットするときがきました!!git commit!!!!!

$ git commit

(色々表示される)
nothing added to commit but untracked files present

なんか表示されましたね。これ、コミットできていません
nothing added to commit but untracked files present
何もコミットするために追加されてないよ。でも未追跡ファイルがあるよ。

なんのこっちゃ…と思いますが、実はコミットする前に「何をコミットするのか」を指定する必要があります。
そのコマンドがこちら、git add ちゃんです。

何をコミットするのか決めよう

以下のように、git addで何をコミットするのかを指定します。
その後にgit commitでコミットします。

$ git add コミットしたいファイル名

ファイル名を全て指定するのは面倒なので、全てをコミットするファイルと指定する場合はgit add .と書けます。
今回は全てをコミットしたいので、このコマンドを打ってみてください。

$ git add .

そして、git statusを実行してください。

$ git status

On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
     new file:   (ファイル名)
     new file:   (ファイル名)
     ...

色々とファイル名が表示されましたね?
これらのファイルをコミットする準備ができた、ということです。
git statusは何をgit addしたかを確認するコマンドです。必ずしも実行する必要はないです。

ちなみに、git addでコミットの準備をすることを「ステージング」と呼びます。

実際にコミットしてみよう

待ちに待ったgit commit!!!!!!

$ git commit

なんか妙な画面が出てきたと思います。こんなの。

コミットメッセージ入力画面
(ここにコミットメッセージを入力します)
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Your branch is up to date with 'origin/master'.
#
# Changes to be committed:
#       new file:   ~~~~
#

これはコミットメッセージをする画面です。
ターミナル上で、viまたはvimというエディタが起動しています。
ここでコミットメッセージを入力し、エディタのコマンドで保存すると、コミットが完了します。
わかりにくいですね。

とりあえずやってみましょう。手順はこんな感じです。
(vi、vim以外のエディタの方は何とかしてください)

  1. キーボードのiを押して入力モードに変更
  2. first commit と入力(これがコミットメッセージになります)
  3. キーボードのescを押してコマンドモードに変更
  4. :wq と入力してエンターキー(保存して閉じるコマンドです)

vimの操作の詳細に関してはこのへんを参照ください。

実際の画面はこんな感じ。この画面でエンターを押すと保存され閉じられます。
スクリーンショット 2020-06-26 8.48.05.png

はいこれでようやくコミットが完了しました!!おめでとうございます!!
あとは編集したら都度git add git commitをしていきます。

ちなみに…git commit -m コミットメッセージとすれば、エディタを開くことなくコミットメッセージを書くことができます。お好きな方をどうぞ。

なぜコミットの前に git add を挟むのか?

こんな疑問を持った方もいるのではないでしょうか?
僕は持ちました。直接コミットすりゃいいじゃん

前回ちょろっと説明したとおり、コミットを細かくして他人にコードの意図を伝えるためです。
仮にgit addがなく、編集してあるものをすべてgit commitするしかない仕様を考えてみましょう。


あなたは2つの新規機能を開発しています。それぞれ新規ファイルが1つずつ必要です。
順調に実装が進み、無事2機能・2ファイルを書き終えました!
ここまでコミットをしていなかったのでコミットしとこう…


git addが無いと、2ファイルを同時にコミットすることになります。
つまり、git add .しかできないということと同じです。

$ git add .
$ git commit -m '新機能1と2を実装' 

1コミットに意味の違う2ファイルが含まれます
どちらのファイルがどちらの機能なのか、分かりにくいですよね?

git addがある場合だとこうできます。

$ git add (1ファイル目)
$ git commit -m '新機能1実装'

$ git add (2ファイル目)
$ git commit -m '新機能2実装'

編集済みのファイルが複数あっても、このようにコミットを分けることが可能です。

編集しながら適切な単位でコミットできれば理想なのですが、実際はそういきません。
ある程度編集して、後からコミットすることが日常茶飯事です。

コミットの目的の一つは「人にコードの意図を伝えること」でした。
git addでコミットの単位を適度に分割することでその目的を達成できます。

git add -pを使えばファイル単位でなく行単位でコミットする箇所を選択できます。詳しくはググってみてください。)

GitHubと連携しよう!

Gitの真価を発揮するには、GitHubと連携すべきです。(異論は認めます)
連携していきましょう!!

リモートリポジトリを作る

リモートリポジトリとは、GitHubにあるリポジトリのことでしたね。
みなさん自分のGitHubアカウントを持っていると思います。ない人は作っといてください。

自分のGitHubアカウントにリモートリポジトリを作り、ローカルリポジトリと紐付けていきます。

スクリーンショット 2020-06-24 18.59.44.png

右側のNewを押してください。
そうすると、↓の画面になります。

スクリーンショット 2020-06-24 19.21.36.png

リポジトリの名前、説明を入力。
Public(誰でもアクセスできる)かPrivate(自分しかアクセスできない)かはお好みで。
今回、Initialize this repository with a READMEチェックはつけないでください。

(チェックをつけるとReadme.mdというファイルがリモートリポジトリに生成されます。この記事の一番最後に行うgit pushの時に不都合が起こるので、チェックはしないでください。)

スクリーンショット 2020-06-24 19.23.20.png

こんな画面が出てきたと思います。
これだけでリモートリポジトリが作成できました!しかし、中身はまだ何もありません。

これからすることは、上記画像の一番下...or Push an existing repository from the command lineの対応と同じです。
まずはリモートリポジトリとローカルリポジトリを紐づけていきます。

リモートリポジトリとローカルリポジトリを紐づける

ローカルリポジトリにリモートリポジトリのURLを教えてあげます。

そのためのコマンドはgit remote add リモート名 リモートURLです。
「リモートリポジトリを追加するよ! その名前はリモート名で URLは リモートURLだよ! 」ってことですね。
実際のコマンドはこうなります。

$ git remote add origin git@github.com:(GitHubユーザー名)/(Repository name).git
(originについては後述)

補足:(Repository name) はここ↓で指定したものです

スクリーンショット 2020-06-24 19.25.08.png


リモート名? なんでoriginにするの?と思いますよねー
リモート名とは、リモートURLのリポジトリの別名です。上記のRepository nameとは違うので注意してください。
これをoriginにするのがGitHubのデフォルトなのです。そうしておくと、様々なコマンドでリモート名を省略することができます。
大人しくoriginにしておきましょう

さて、コマンドを改めて載せておきます。(さっきと同じコマンドです)

$ git remote add origin git@github.com:(GitHubユーザー名)/(Repository name).git

ターミナルで実行してください。
何も表示されず、何も起こっていないように見えます。

git remote -vを実行してみましょう。
これは、ローカルリポジトリに紐づいているリモートリポジトリのURLを表示するコマンドです。

$ git remote -v

origin  git@github.com:(GitHubユーザー名)/(Repository name).git (fetch)
origin  git@github.com:(GitHubユーザー名)/(Repository name).git (push)

このように表示されればリモートリポジトリが紐づいています。

リモートリポジトリにローカルリポジトリの内容を反映する

ようやくここまできました。長かった…
今の状況を整理するとこうです。

  • リモートリポジトリ
    • 作成したが、
  • ローカルリポジトリ
    • 作成済み
    • ファイルがある
    • コミットしたファイルもある
    • リモートリポジトリと紐づいている

ローカルリポジトリでコミット(セーブ)したファイルを、リモートリポジトリに反映してあげましょう。
そのコマンドは git push -u origin head !!!!!!!!!

$ git push -u origin head

To github.com:(ユーザー名)/(Repository name).git
 * [new branch]      head -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

「コミットした変更をリモートリポジトリにpush(反映)するよ!
宛先はリモート名がoriginのリモートリポジトリね!
pushするのはhead、つまり最新のコミットまでを頼むね!」

git push -u origin master でも「今は」同じ結果になります。ブランチを理解してから使い分けましょう。)
headについては別の記事で詳しく解説します。今は丸暗記でOKです。)
-uオプションをつける意味については、この記事などを参照ください。このことを今は理解できなくていいです。)

これでリモートリポジトリに反映されました!!!
確認してみましょう。

GitHubの右上にある自分のアイコンをクリックし、your repositoriesを選択してください。
スクリーンショット 2020-06-24 23.41.06.png

そして、先ほど作成したリモートリポジトリを開いてみると…
スクリーンショット 2020-06-24 23.43.31.png
ファイルが追加されているはずです!
(僕は test と test2 というファイルをpushしました)

これでローカルリポジトリの変更をリモートリポジトリに反映する、つまり同期することができるようになりました!!!

これでようやくGit/GitHubを使うスタートラインです。
この記事での説明はこれでおしまい。(長いし…)

次の記事では、逆にリモートブランチの内容をローカルリポジトリに反映する方法ブランチについて書こうと考えています。

まとめましょう

これまでに学んだことをざっくりと。

Gitを始めてからリモートリポジトリに同期させるまでの流れ

こんな感じ。

  1. コードが格納されているフォルダを用意する
  2. git init でローカルリポジトリを作る
  3. git add でコミットするファイルを指定する
  4. git commit でコミット(セーブ)
  5. GitHub上にリモートリポジトリを作る
  6. git remote add でローカルリポジトリとリモートリポジトリを紐づける
  7. git push -u origin head でローカルリポジトリでコミットしたものをリモートリポジトリに反映して同期

用語とコマンド

  • Git
    • バージョン管理をするためのツール
  • GitHub
    • Gitをオンラインで共有するためのツール
  • リポジトリ
    • Gitで管理されているフォルダ
  • リモートリポジトリ
    • オンライン(GitHubとか)にあるリポジトリ
  • ローカルリポジトリ
    • 個人のPCにあるリポジトリ
  • git init
    • 自分のPCにある(ローカル)フォルダをGit管理するためのコマンド
    • このコマンドによりフォルダがリポジトリとなる
    • .gitが生成される
  • git add
    • コミット(git commit)するものを選択するコマンド
    • git addすることを「ステージング」と呼ぶ
    • git add .で全ての変更を選択できる
  • git status
    • 何をステージングしたかを確認できるコマンド
    • 確認なので、このコマンドを実行しなくても可
  • git commit
    • git addした変更をセーブするコマンド
    • gitの主役
    • コミット単位で過去の状態に戻ったりできる
  • git remote add
    • ローカルリポジトリとリモートリポジトリを紐づけるコマンド
    • ローカルリポジトリにリモートリポジトリのURLを登録する
    • このコマンドを実行してからGitHubと連携ができるようになる
  • git push
    • ローカルリポジトリでコミットした変更をリモートリポジトリに反映するコマンド
    • このコマンドによりローカルとリモートが同期できる

さいごに

いろんな説明記事を見て、それらをなぞればpushまでたどり着くことは簡単にできます。
しかし実行している内容を細かく体系立てて説明していた記事は見当たりませんでした。
僕は実際にGit/GitHubを使っているとき「いつも打っているこのコマンドは何をしているんだろう?」という疑問がよく出てきました。
この記事では自分が辿ってきた疑問を全て潰してきたつもりです。
これからGitを触る人・Gitを使ってるが実はよく分かっていない人にとって参考になれば幸いです。

例によりこの記事は初心者向けなので、厳密には違う説明の箇所もあります。
しかし初心者としてはこの理解で十分です。疑問に思う時が来たその時は、自分で調べてより正確に理解してみましょう。

あれ?ブランチの説明はないの? と思った方もいるかと思います。
ブランチを理解するには、まずこの記事の内容の理解が必要と感じているので、前段階としてこれを説明しました。
次の記事ではブランチも説明していくつもりです!!!!!

そもそもなんでGitを使うの?バージョン管理をするの?って人は、まさにこの記事を参照下さい。
なぜ僕らはGitでバージョン管理をするのか

よかったらTwitterもフォローしてね。

gakisan8273
33歳でITエンジニアに転職しました。 グンマーから都内に通ってます。つらい。 元々は空調システムの設計をしてました。 熱力学はいいぞ。
https://gakisan8273.com/
sencorp
幼稚園・保育園向けインターネット写真サービス「はいチーズ!」を提供しています。
https://sencorp.co.jp/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした