Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
204
Help us understand the problem. What is going on with this article?
@moonbass630

【備忘録】GitとGithubの基本知識

本記事は上から読んでいくだけで、GitとGithubの基本知識が学べるようになっています!
少しでもお役に立てれば幸いです!

また本記事ではGitとGithubを使用するので、「Gitのインストール」と「Githubのアカウント作成」を事前にしていただく必要があります。是非以下の記事も参考にしてみてください!
https://qiita.com/moonbass630/items/2084edb250feef88f15f

1.ひとりで開発編!

まずはGithubでリモートリポジトリを作成しましょう!
今回は「git-test」という名前で作成したいと思います。
image.png

ちなみに「リモートリポジトリはGithubで管理」、「ローカルリポジトリはGitで管理」というイメージです。
image.png

保存したら以下のようにリモートリポジトリのURLをコピーしましょう。
image.png

ではまず、以下のコマンドを実行し、リモートリポジトリをコピーしてローカルに同じリポジトリを作成してみましょう。「git clone」の後ろには先ほどコピーしたリモートリポジトリのURLを貼り付けてください。
(今回はデスクトップ上にフォルダを作成したいので、デスクトップまで移動してからコマンドを実行します。)

$ git clone https://github.com/moonbass630/git-test.git

image.png

以下のように「git-test」というフォルダが作成されていればOKです!
image.png

次にcloneしたフォルダ内で「file1.txt」、「file2.txt」を作成します。
今回はVSCodeを使用していきます。
image.png

保存した後に以下のコマンドを実行してみましょう。
こちらはGitの状態を見るためのコマンドです。

$ git status

赤字のファイル名が見えますが、
これは作成したファイルがまだGitに管理されていない状態を表しています。
要はローカルリポジトリに保存されていない状態です。
image.png

そんな時はまず以下のコマンドを実行します。

$ git add ファイル名

以下のコマンドを実行することで、作成した「file1.txt」がGitの管理下に移ります。
これをステージングと言います!
image.png

実際にステージングされたファイルは緑色で表示されます。
image.png

またカレントディレクトリの全てのファイルをGitの管理対象にするのが以下のコマンドになります。
便利なので覚えておきましょう。

$ git add .

実行すると「file2.txt」もステージングされたのが分かると思います。
image.png

いよいよファイルをリポジトリに保存したいと思います。
以下のコミットコマンドを実行すると保存できます。「メッセージ」にはメモ感覚で、コミットの内容をメモすることができます。今回は「初めてのコミット」としておきます。

$ git commit -m "メッセージ"

image.png

以下のようなメッセージが出ればOKです!
「git status」で確認してみてもファイル名が表示されていないことが分かるかと思います。
image.png

では次に「file1.txt」を修正し、「git status」で確認してみましょう。
image.png

「file1.txt」が修正されていることをgitが検知していることが分かると思います。
これはgitが以前にコミットしたファイルの履歴をコミットしたタイミングで保存しているからです。
image.png

では続けてステージングとコミットを実施します。
image.png

ちなみに以下のコマンドでgitの履歴を確認することができます。

$ git log

image.png

では次に「リモートリポジトリ」にローカルリポジトリでコミットした内容をアップロードしましょう。
image.png

ご覧のようにgithubを確認しても、まだ何も起きておりません。
空のリモートリポジトリ「git-test」があるだけでです。
image.png

アップロードするコマンドは以下になります。
「origin」はリモートサーバーを意味します。

$ git push origin

以下のようなメッセージが出ればOKです!
image.png

ではgithubを確認してみましょう!
image.png

「2commits」をクリックするとコミットの履歴が見れます。
色々自分で確認してみてください!
image.png

ちなみに今、こういう状態になっています。
image.png

2.共同開発編!

では次に以下のように他のデベロッパー「B子」も作業するために、「git clone」を実行しましょう。
image.png

今回はパソコンが2台ないので、同じパソコンにB子のローカルリポジトリを作成します。
ローカルリポジトリの名前は変更も可能なので、分かりやすいように「git-b」にしようと思います。
コマンドは以下のようになります。

$ git clone https://github.com/moonbass630/git-test.git git-b

image.png

以下のように「git-b」のフォルダができていればOK!
image.png

ちなみに今、こういう状態になっています。
image.png

ではB子で「git log」を実行してみましょう。
(※「git-b」フォルダに移動して、gitコマンドを実行してください。)
以下のようにB子からでもA太郎のコミット履歴を見ることができます。
image.png

次にB子から「file1.txt」を編集してコミットしてみましょう。
image.png

「file1.txt」には「3回目の編集です。」と追記して保存しておきます。
image.png

「git add」と「git commit」を実行します。
image.png

「git push」もしてあげましょう。
image.png

コマンドはこんな感じです。

$ git add .
$ git commit -m "3回目のコミット"
$ git push origin

では次にA太郎もリモートリポジトリにある最新のファイルを手に入れましょう。
前回はローカルリポジトリを作成する際に「git clone」を使用しましたが、
こちらは新規にリポジトリを作成する場合に使用します。
今回は既に「git-test」リポジトリはあるので、別のコマンドになります。

$ git pull origin

image.png

「git pull」実行前
image.png

「git pull」実行後
image.png

試しに「git log」で確認してみたいと思います。
B子の3回目のコミットが確認できるかと思います。
image.png

3.共同開発編!(応用)

ここからはケーススタディ形式を少し取り入れて考えていきましょう!

A太郎は「システムG」を運用している。ある日「システムG」の修正が必要になり、
B子に依頼したとしましょう!
image.png

しかしこれまでのようにB子が本番環境で使われるソースファイルを「git clone」して修正し、「git push」してしまうとA太郎が確認できないまま本番環境で使われるソースファイルが書き変わってしまいます。もしB子の修正に誤りがあるとかなり危険です。
image.png

そこで「ブランチ」という機能を使用します!
ブランチの説明ですが、まずこれまでにリモートリポジトリへ「git push」した時のコミット履歴を見てみましょう。
image.png

「初めてのコミット」から「3回目のコミット」まで枝のように繋がっていますね!
そうこれがブランチなんです!そして左上にある「master」と記載されいるのがブランチ名となります。
「ブランチ」を一言で表現すると、「コミットの履歴を管理しているもの」って感じでしょうか。

以上を踏まえた上で、以下の流れに沿ってB子には作業を進めてもらいましょう。
image.png

①まず本番環境で使われるソースファイルが入っているリモートリポジトリをmasterブランチから「git clone」コマンドを実行し、ローカルリポジトリを作成しましょう。
②次にローカルリポジトリ内で「git checkout」というコマンドを実行し、
図のように新しく「develop」と言うブランチを開発用として作成します。
③これによりB子は修正、コミットを繰り返しても「master」ブランチの中身は書き変わらず、
「develop」の中で修正とコミット履歴を管理することができます。
④修正した「develop」ブランチにあるソースファイルを「git push」します。
⑤するとリモートリポジトリには「develop」ブランチと修正したファイルが保存されます。

では①「git clone」はもう実行したとして、②の「git checkout」からやっていきましょう!
image.png

まず以下のコマンドで自分が今どのブランチで作業しているか確認しましょう。

$ git branch

「master」ブランチにいることが確認できたと思います。
image.png

次に以下のコマンドでブランチ「develop」ブランチの作成と、作業する場所を「develop」ブランチに変更しましょう。

これは「git checkout -b」で「develop」というブランチ名で「master」ブランチからブランチを切るという意味になります。

$ git checkout -b develop master

「git branch」で確認し、以下のようになっていればOKです!
image.png

また「master」ブランチに作業場所を変えたい場合は、以下のコマンドで戻れます。

$ git checkout master

以下のようになればOKです!
では「git checkout develop」を実行し「develop」ブランチに戻っておきましょう。
image.png

次に③「修正」、「コミット」と④「git push」を実施してみましょう!
image.png

「file1.txt」に修正を加えます。
image.png

次に「ステージング」と「コミット」をしましょう。

$ git add .
$ git commit -m "4回目のコミット"

image.png

そして次に以下の「git push」コマンドでローカルリポジトリにある「develop」ブランチをリモートリポジトリにアップロードしてあげましょう。

$ git push origin develop

このようなメッセージが出ればOKです!
image.png

これで以下のように、現在リモートリポジトリもローカルリポジトリのような状態になっているはずです。
ではGithubから⑤リモートリポジトリを確認してみましょう!
image.png

「develop」が作成されていることが確認できます!
image.png

以下のようにB子の修正「4回目のコミット」が確認できます!
image.png

では次にA太郎の作業を確認していきましょう!

image.png

①A太郎はB子が修正したソースファイルを確認しなければならない、言わばViewer(ビューワー)なので、「git pull」でローカルリポジトリに「develop」ブランチをダウンロードします。
②もし修正に問題がなければ、ローカルリポジトリ内で「master」と「develop」を統合します。これをmerge(マージ)すると言います。
③最後にmergeした「master」を「git push」でリモートリポジトリにアップロードして、このプロジェクトは完了になります!

ではまず①「git pull」を実行しローカルリポジトリに「develop」ブランチをダウンロードしましょう。
その後に「git log」で中身を確認したいので「git checkout」で「develop」ブランチに移動しましょう。
image.png

$ git pull origin
$ git checkout develop

以下のように最終的に「develop」ブランチに移動できればOKです!
(※実は「git pull」した時はまだローカルリポジトリには「develop」ブランチはできていません。今回は深く説明はしないので、「追跡ブランチ」で調べてみてください!)
image.png

「git log」で確認すると、B子さんの修正「4回目のコミット」が確認できます。
image.png

いよいよ、②「git merge」の作業に移ります。
image.png

マージする時は、マージ先(master)のブランチに移動しないいけないので、「git checkout」で移動しておきましょう。
image.png

そして以下の「git merge」コマンドを実行してください。

$ git merge develop

これでマージ完了です!
image.png

念のために「git log」で確認してみましょう。
「master」ブランチも4回目のコミットができていることが確認できます。
image.png

補足ですが、以下赤枠のブランチは「4回目のコミット」までの履歴があることを意味しています。
HEAD -> master : 「master」ブランチ(HEADは今いるブランチを示している)
origin/develop : リモートでポジトリの「develop」ブランチ
develop : 「develop」ブランチ

そして青枠のリモートリポジトリの「master」ブランチのみまだ「3回目のコミット」で履歴が止まっています。

なのでローカルの最新の「master」ブランチをリモートリポジトリの「master」ブランチへ③「git push」してあげましょう!
image.png

$ git push origin master

image.png

Githubで確認してみましょう!
image.png

これで一連の流れは終わりです!!
お疲れ様でした!!

204
Help us understand the problem. What is going on with this article?
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.
Sign Up
If you already have a Qiita account Login
204
Help us understand the problem. What is going on with this article?