【GitとGitHab】基本的なコマンド

GitとGithub

前回の記事で3/1~3/31に学習したことをカテゴリ分けいたしました。

その中にGitとGitHubについて学習したことを記載しましたが、

今回は具体的な学習内容についてまとめたいと思います。

※前回記事

【独学エンジニア】2022年3/1~3/31で勉強したことのカテゴリ分け - m1tamaのブログ

 

基本的なGitの仕組み

GitとGitHubとは何か？

Gitというのはファイルのバージョンを管理するためのツールです。

そのGitを用いて、チーム開発においてさらにバージョン管理を容易に

するためのツールがGitHubです。

GitHubについてもう少しちゃんというと、

gitのコードをオンライン上で扱うためのツールです。

 

Gitのデータ保存の方法 --差分ではなくスナップショット

Gitはデータを差分ではなくスナップショットを記録しています。

デート以前との差分で保存するのではなく、

データ丸々保存することによって、

複数人で開発する場合などでそれぞれで作成したものを

瞬時に統合することができます。

また、以前のバージョンに戻すことも容易です。

 

GitとGitHubへの保存の段階

まずGitはローカルで利用するものです。

それをGitHubを使ってリモートに上げます。

 

Gitではローカルでどんなことが行われているか

もう少し話すと

ワークツリーのデータをローカルリポジトリに記録していきます。

このローカルリポジトリの記録を元にバージョンの復元などが行われます。

 

Gitでは今話した、ワークツリーとローカルリポジトリ

の間にステージというエリアがあります。

 

Gitでは「ワークツリー」「ステージ」「ローカルリポジトリ」

という3つのエリアをイメージすることが大切です。

 

ワークツリーが手元の作業場ですね。

その作業で変更したファイルをまず「ステージ」に記録します。

ローカルリポジトリに上げる前の準備だと思ってください。

 

そして、変更がひと段落し

「よしこれで次のバージョンとするぞ」

というタイミングで「ローカルリポジトリ」へ

スナップショットを保存します。

 

ステージの存在理由をもう少し補足すると

ファイルAとファイルBを並行して編集していたとして

ファイルAは変更が完了しファイルBは変更が未完了だとします。

 

このときファイルBは変更前の状態で

ファイルAは変更した状態を次のバージョンとしたいとき、

ファイルAだけを「ステージ」に上げると

「ステージ」ではまだファイルBは変更されていないことになります。

その状態で「ローカルリポジトリ」にスナップショットを保存するわけです。

よくできています。

 

そして、そのローカルリポジトリに保存した内容で

「問題ないでしょうか？あれば教えてください」

とお伺いを立てたり

「問題なければ、自分のワークツリーに取り込んでねー！」

とデータを共有するために

GitHubの「リモートリポジトリ」に「ローカルリポジトリ」

の内容をアップします。

 

基本的なコマンド

ここではGitで使うコマンドを列挙していきたいと思います。

詳しい内容は割愛します。

ローカルでの操作
  • git init　.git/が作成される。gitで必要なファイルが保存される。例えばcommitしたときのスナップショットや設定ファイルなど
  • git clone リモートリポジトリ名 すでにリモートリポジトリ上にあるプロジェクトをコピーする。ファイルと.git/が保存される。
  • git add ファイル名
  • git commit -m "コミットメッセージ"
  • git status  変更されたファイルを確認できる
  • git diff addする前の差分を確認
  • git diff --staged ステージとリポジトリの差分を確認
  • git log 変更履歴を確認
リモートリポジトリとの操作
  • git remote add origin リモートリポジトリのURL リモリポジトリの登録
  • git push origin ブランチ名　プッシュ  
  • git fech リモート名　ブランチ名　リモートからローカルリポジトリに落とす。追跡ブランチに保存される
  • git merge　追跡ブランチからワークツリーに落とす。
  • git pull　fechとmergeを一気にやる

基本的な機能としてbranchというものもあります。

branchについてはissuesと紐付けて行う

branch作成についても記述してたく、

少し長くなるので別記事に記載いたします。

 

各段階での注意点や補足

ちゃんと確認しよう　git status　git diff

個人で開発を行う場合は、そこまで必要ないように

思えるが、チーム開発でアップすべきではないファイルまで

コミットしてしまうとチームに迷惑がかかってしまう。

そうならないために、git statusでcommitする前に

確認する癖をつけよう！

commitメーセージ

commitする際に記載するメッセージですが、

メッセージの書き方のスタンダードを記載します。

1行目　変更点

2行目　空行

3行目　変更した理由

 

個人で開発するなど簡単に書くときは

1行目に変更点と変更した理由を書くこともあります。

 

fech+merge と pull の使い分け

pullはfechとmergeをいっぺんにやってしまうことで、

思わぬ挙動をすることがあるので注意です。

 

例えば、ローカルリポジトリの方でmasterとhogeというブランチ

があったとします。

自分がmasterで操作しているとして、

masterのリモートブランチからpullしたいのに

間違ってgit pull origin hoge を実行したとします。

このとき

hogeブランチの方にpullしてくれたらいいのですが

残念ながらhogeの内容でmasterを上書きすることになります。