はじめに
僕が個人でgithubにソースコードをあげる際に、よく利用するgitコマンドまとめてみました。
説明の際には、結構個人的な解釈が入っているかもなので悪しからず。。
まだgitに対する知識が浅い状態ではあるので、自身の認識に対しての整合性を確かめるために見てもらえると嬉しいです！もちろん実践していただいてもありがたい限りです。
あまりにも「ここおかしくね？」っていう説明があればコメントいただけると大変助かります！！
コマンド解説(設定編）
gitを操作する前に行うコマンドです。
git --version
gitのバージョンを確認するコマンドです。
git --verison
// 実行結果例（powershell)
git version 2.35.1.windows.2
何よりもまずは、gitが入っているか確認しましょう！（笑）
こちらでgitがインストールされているか及びバージョンを確認します。
git init
git init
こちらはローカルにgitレポジトリ(.gitってやつ)を作成するためのコマンドという風に認識してます。
英語をそのまま訳せば「初期化」ってことなので、このコマンドを行うことで、
- ローカルレポジトリを作成して、ファイル・ソースコードをgitでバージョン管理することができる
という形になっていて、このコマンドをはじめに実施しないと、
- github（のリモートレポジトリ）にファイル・ソースコードをあげる
こともできません。
git init 流れ
まず、開発を行なっていくプロジェクトディレクトリを作成します。
その後、ターミナルなどでそのプロジェクト配下まで移動して、git initコマンドを実施します。
例えば、my_projectというディレクトリ配下で開発を行う場合、
xxx@xxxxx my_project % git init
とすることで、my_project配下にgitレポジトリが作成されて、ソースコードをgitで管理する準備ができます。
git initコマンドを入力し、Enterを押して、、
xxx@xxxxx my_project % git init
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /Users/xxx/my_project/.git/
xxx@xxxxx my_project %
となれば、OKです。gitでのレポジトリが作成されました。
試しに、Finderやエクスプローラーなどで該当プロジェクトディレクトまでアクセスして、隠しフォルダ/ファイルの表示をオンにしてみましょう！（Macなら「command」＋「shift」＋「.」）
上記写真のように、「.git」というディレクトリが作成されているはずです！
git remote
こちらは端的に言うと、ローカルレポジトリとリモートレポジトリとをリンクさせるコマンドです。
使い方は２種類あります。
1. リモートレポジトリを設定する : git remote add
はじめにリンクさせるリモートレポジトリを設定する場合は以下です。
git remote add <設定する名前> <リモートレポジトリのURL>
例) git remote add origin https://user@github.com/myaccount/my-project.git
無事成功したら、ローカルとリモートのレポジトリがつながり後述するgit pushコマンドなどでGitHub上にソースコードを管理することができるようになります！
<設定する名前>の部分は何でもいいとは思うのですが、originとするのが当たり前になっています。
2. 設定先リモートレポジトリを変更する : git remote set-url
リモートレポジトリを設定後に、変更したい場合は以下です。
git remote set-url <設定する名前> <リモートレポジトリのURL>
例) git remote set-url origin https://user@github.com/myaccount/my-project.git
設定先リモートレポジトリを確認する : git remote -v
git remote -v
こちらで設定したリモートレポジトリを確認することができます。
コマンド解説（操作編）
gitの設定完了後はソースコードを編集していき、githubなどにソースを共有する作業になります。
git add
git add コマンドは編集したファイルをステージングさせるコマンドです。
//ファイルを個々でステージングさせる
git add <ファイルパス>
//現在のディレクトリ配下における、作成・編集したファイルをステージングさせる
git add .
//現在のディレクトリ場所に関わらず、git initしたプロジェクト配下の作成・編集したファイルをステージングさせる
git add -A
個人のみで開発している場合は、基本「git add .」か「git add -A」で作成・編集したファイルをステージングしています。
ステージングてなんぞや？
「ステージング」とはステージエリアにファイルを乗せる（移動させる）作業のことを言うそうです。
ステージエリア： コミットできるファイルがまとめられている場所
ファイルをコミット（後ほど解説）させる前に行わなければなりません。
イメージとしては、車を出発（コミット）させる前に、シートベルトを装着（ステージング）する感じでしょう
（超個人的解釈です）
git commit
このコマンドでgit add によりステージングしたファイルをコミットします。
「commit」にはいろいろな意味がありますが、gitにおけるケースでは「登録する、アップする」のような認識で大丈夫かと！
つまりは、ステージングであげたファイルをgit commit により一つの履歴として登録するといった解釈でいます。
こういった機能のおかげで、いわゆるバソースコードのバージョン管理ができているのでしょう。
git commit -m "コミット名"
こちらコミットします。
オプションの-mはコミット名を付与するためのもので、定型文として覚えておきましょう！
git status
git status
こちらは該当プロジェクトディレクトリ配下における、gitの管理状態を教えてくれるコマンドです。この管理状態とは、ファイルを作成/編集していく中で、ステージングがされているか、コミットが完了しているかを指します。
以下ケースごとの詳細です。
git status ケースごとの表示
1.ステージングされていないファイルがある
xxx@xxxxx my_project % git status
On branch main
Changes not staged for commit: //「ステージングしていない編集ファイルがありますよ」的な
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
// ⛔ここにステージングされていないファイルが列挙される
modified: index.php
no changes added to commit (use "git add" and/or "git commit -a")
2.ステージングされているファイルとされていないファイルがある
xxx@xxxxx my_project % git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
// ✅ステージングされたファイル
modified: index.php
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
// ⛔ステージングされていないファイル
modified: practice.php
3.ステージングされているが、コミットされていない
xxx@xxxxx my_project % git status
On branch main
Changes to be committed: //「コミットできるステージング済みのファイルがありますよ」的な
(use "git restore --staged <file>..." to unstage)
// ✅ステージングされたファイル
modified: index.php
modified: practice.php
4.ステージング/コミットともに完了している or 何も編集していない
xxx@xxxxx my_project % git status
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean //「コミットするものはなにもありません」的な
git push
こちらはローカル上でコミットしたファイルをリモートのレポジトリにあげる（登録させる）コマンドです。
リモートレポジトリとはインターネット上にあるレポジトリで、例えばGitHubのレポジトリがこれにあたります。
ですのでこのコマンドによって、GitHubにソースコードをあげることができます。
//初回の定型的なコマンド
git push -u origin main
こちらが初回で行うgit pushの定型的なコマンドです。
分解して解説してみます。（ちょっとわかりにくいかも）
git push
コマンドです。
-u
オプションです。pushする上流ブランチ（リモートレポジトリのブランチ）を設定するというものです。今回であればのちのが上流ブランチ名になります。
初回のリモートレポジトリでは、ブランチが一つも作成されていない状態ですので、初めてpushする際はこのオプションを付けずに実行するとエラーになってしまいます。
このオプションを行うことで現ローカルブランチと同じ上流ブランチ先にpushした場合は、
git push
このコマンドだけで実行できます！
origin
pushするリモートレポジトリ先を指します。
後述するレモートレポジトリ先を設定するコマンドを実行することで、このorigin(元)として設定されるというイメージです。
main
push先のブランチ名を指します。
初回は-uオプションを付けたうえで記述します。注意してほしいことは、現ローカルブランチ名と同名にするということです。
git push -u origin mainの意味
改めて訳してみると、
「push時に、現ローカルブランチ名と同一の上流ブランチ名（リモートレポジトリ先のブランチ名）を設定したうえでpushする」
といった形になります。
ケースとして、
- 初回に-uオプションを付けてpushした
→次回から同じローカルブランチでpushする場合は、"git push"コマンドだけでpushできる。 - 初回に-uオプションをつけない（"git push origin main")
→毎回pushするブランチ名を指定してpushする。
といったイメージで問題ないかと。なのでどちらでもそんなに不憫はないですね（笑）
git pull
git pull
このコマンドはgit push の反対で、GitHubなどのリモートレポジトリのファイルをローカルに反映してくれます。
例えば...
例えば、複数人で開発をしていてgithubにてコードを共有していたとします。
あなたは機能A、そしてXさんは機能Bを作っていたとして、
機能Bを作成していた人がgithubにコードをあげた際に、このgit pullコマンドを行うことで、Xさんの書いたコードを自分のローカルレポジトリに反映させることができるといった認識です。
ですので、こちらのコマンドはチーム開発行う際に多用するコマンドです。
個人開発の場合は、そこまで利用する頻度は多くないと思われますが、ブランチをこまめに分けていた際に、リモートレポジトリの違うブランチ（差分のあるブランチ）のコードをローカルブランチに反映させるみたいな時に使ったりします。
git push の反対は git pull だよ！と覚えてくだされば問題ないかと！
git clone
git clone <新規でローカルに落としたいリモートレポジトリのURL>
例) git clone https://github.com/myaccount/my-project.git
こちらのコマンドでは、GitHubなどのリモートレポジトリを新規で落としてくる際に利用します。
例えば...
例えば、私の場合は業務用のPC（Windows）と個人用のPC（Mac）を持っていて、それぞれのPC内に同一のレポジトリを置き、２つのPC内でコードを実装/編集していきたいといったことがあります。
- 業務用PCにてローカルレポジトリを作成して、コーディング
- githubにてレポジトリを作成して、1.のコードをあげる
- 個人用のPCにてローカルレポジトリなどなにも作成していない状態で、プロジェクト用ディレクトリを作成
- ターミナルなどで該当ディレクトリ配下までいき、git cloneコマンドを実施
- 個人用のPCにてgithubの該当コードが落とされ、ローカルレポジトリも作成される
といった流れです。
業務用PCと個人用PCの両方で、GitHub上を通じてソースコードを管理することができます。
git diff
git diff
こちらは、ブランチ間におけるソースの差分を確認してくれるコマンドです。
ただこのgit diffコマンドはいろんな条件下でつかうことができるので、ここでは僕が認識している範囲内で解説します。
1. ステージング前の変更内容を確認できる
git addコマンドでステージングする前に、git diffコマンドを実施することで、前ステージング後からの修正差分を確認することができます。
//前ステージング後、修正していた場合に差分を表示してくれる
git diff
xxx@xxxxx my_project % git diff
diff --git a/index.php b/index.php
index 0274b9d..cf3ecd5 100644
--- a/index.php
+++ b/index.php
@@ -7,4 +7,6 @@ git add
git diff
git diff2
-git diff3
\ No newline at end of file //↓追加された差分表示
+git diff3
+
+git diff4
\ No newline at end of file
2. ローカルブランチ間の差分
ローカルのブランチ間の差分を確認することもできます。
僕は割と「あのブランチとどのぐらい差分あったっけ？」というときに使ったりします。
//現在のブランチとの他のブランチの差分を確認したい場合
git diff <確認対象のブランチ名>
//ブランチAとブランチBの差分を確信したい場合
git diff <ブランチA> <ブランチB>
xxx@xxxxx my_project % git diff main //mainブランチとの比較をしたい場合
diff --git a/index.php b/index.php
index 8913442..cf3ecd5 100644
--- a/index.php
+++ b/index.php
@@ -1 +1,12 @@
index2
//↓緑色のハイライト部分が、現在のブランチで追加された差分
+git diff
+git diff2
+git diff3
+
+git diff4
\ No newline at end of file
xxx@xxxxx my_project % git diff dev
diff --git a/index.php b/index.php
index cf3ecd5..8913442 100644
--- a/index.php
+++ b/index.php
@@ -1,12 +1 @@
index2
// ↓赤色ハイライト部分が、devブランチ側に追加差分があった場合
-git diff
-git diff2
-git diff3
-
-git diff4
\ No newline at end of file
xxx@xxxxx my_project % git diff branchA branchB
diff --git a/index.php b/index.php
index 8913442..cf3ecd5 100644
--- a/index.php
+++ b/index.php
@@ -1 +1,12 @@
index2
//↓緑色のハイライト部分がbranchA側から見た、branchBとの差分
+git diff
+git diff2
+git diff3
+
+git diff4
\ No newline at end of file
3. リモートブランチとのリモートトラッキングブランチとの差分
githubなどにコードをあげていた場合、ローカルブランチとリモートブランチ リモートトラッキングブランチの差分を確認することもできます。
リモートトラッキングブランチとは
リモートトラッキングブランチとは別名「追跡ブランチ」とも呼ばれています。
- リモートブランチを追跡（トラッキング）しているブランチ
というものなのですが、イメージとしては、
ローカルブランチ ー 追跡ブランチ ー リモートブランチ
という中間にあたるブランチです。
リモートトラッキングブランチ（追跡ブランチ） ≠ リモートブランチ
ではないので注意してください。
僕もこのあたりは最近学んだので、詳しくは以下のサイトを参考にしてください。
git diff <ローカルブランチ名> <origin/リモートブランチ名>
例) git diff main origin/main
ローカルブランチとリモートトラッキングブランチの順番が逆でも確認できます。
git diff origin/main main
上記の確認方法のいずれにしても、差分がない場合はなにも表示されません。
git branch
こちらのコマンドは、ローカル上のブランチを作成/削除/更新/確認することができます。
git branch //作成したブランチの一覧を表示
git branch --sort=authordate //作成した順で一覧を表示（昇順）
git branch --sort=-authordate //作成した順で一覧を表示（降順）
git branch <作成ブランチ名>
git branch -d <削除するブランチ名>
//現在のブランチ名を変更することができます
git branch -m <変更するするブランチ名>
リモートブランチの一覧も確認できる
一応、リモートブランチも含めたブランチの一覧を確認することができます。
git branch -a //リモートブランチも含めて一覧を確認
xxx@xxxxx my_project % git branch -a
dev
feature/a
feature/b
* main //現在のローカルブランチ
remotes/origin/dev //リモートブランチ
git switch
こちらのコマンドは、ローカルブランチの切り替えを行ってくれます。
git switch <移動したいブランチ名>
//オプション"-c"を付けることでブランチ名を新規作成したうえで、そのブランチに移動
git switch -c <ブランチ名>
git checkoutについて
以前はブランチ間の切り替えを行うのでgit checkoutというコマンドを利用していましたが、そこからgitのバージョン更新により新しくgit switchコマンドが登場しました。
現在もgit checkoutは使えますが、今後はブランチ間の切り替えにはこのgit switchコマンドを使用してくのが一般的かと思います。
時代はswitchですね。ゲーム機買いたいなあ。。。
git log
git logコマンドは、コミットログを表示してくれます。
コミットログとは
コミットの履歴のことです。
gitはコミットを行うごとに、そのコミットのログ（履歴）を残してくれます。git logコマンドを利用することで、これまでコミットした履歴を確認することができます。
git log
git log --graph //ちょっと装飾してくれる
まとめ
最後に、僕の会社ではソースコードのバージョン管理にgitを採用していません（笑）
SVNというサブバージョン管理を利用しています。
ただ、世界的な割合だと、gitを利用している企業が圧倒的に多いので、個人学習も兼ねてこの記事を書かせていただきました。
書いてみると改めてまだ知識の浅さを感じましたが、
- 学生の方
- 未経験の方
- 勤め先の企業にてgitを利用していないが、今後のキャリアの為に学んでおきたいといったエンジニアの方々
の助力になれれば幸いです