Git基礎まとめ【全体の流れ復習/なぜステージするのか?】

プログラミング

YouTubeやブログで発信している会社員💻

東京男子ブログ@yutofieldblog)です。

記事をご覧いただきありがとうございます!!

ブログ運営者情報
パグ夫さん
東京男子ブログ

YouTubeとブログで発信している会社員
24歳 / 東京 / SE / ☕🚲📷🍷🍚
現在は「商業高校」と「バターコーヒー」に特化したメディアを作ってます。

東京男子ブログをフォローする

ワークツリーとインデックス

ワークツリー⇛ステージ⇛インデックス⇛コミット⇛ローカルリポジトリ

ブランチ

枝のようにメインとサブで分け、マスター・セカンド、サードというようにそれぞれの枝で作業を行い、マージする←このタイミングでレビューを行い、どの枝を選ぶか決める。

Gitの流れ

①git init :ディレクトリにリポジトリ作成

コマンド時のディレクトリをGitのバージョン管理下に置く

⇛「Initialized empty Git repository in /Users/abcxyz/commit-tutorial/.git/」

↑意味は、空のGitリポジトリを /Users/abcxyz/commit-tutorial/.git/ に初期化しました

↓ワークツリー内で作業

①’index.htmlファイルの作成

・git status

②git add  index.html:ステージング

・git status

③git commit -m “first commit”:コミット(メッセージ付き)

③’さらに更新する場合

git diff :ファイルを更新した際に、前回のコミット分との差異を表示してくれる

git add . :ファイル名の代わりに「.」を使うことで、前回のコミットから変化のあったファイルを全てステージできる

git log にて過去のコミット履歴の確認ができる

④ローカルリポジトリに反映

ブラウザでGithubへログインし、new repositoryからリモートリポジトリを作成

git remote add originhttps://github.com/ユーザ名/リモートリポジトリ名.git

④’リモートリポジトリの登録状況確認

git remote -v

・ローカルリポジトリのブランチ名(master)をリモートリポジトリのデフォルト(main)と合わせる

git branch -M main

⑤リモートへアップロード

git push origin main

↑自分のローカルリポジトリと同じリモートリポジトリをoriginという名前にするのが監修となっている。

理由としては、逆にgit cloneコマンドを使い、リモート⇛ローカルにコピーした際に、自動的にリモートの名前がoriginとつけられるから

⑤’その他gitコマンド

git pull :リモートの更新分をローカルに取り込むコマンド

git fetch:リモートの更新分を取得するのみでローカルへの取り込みまでは実行しないコマンド

 詳細説明:git pull = git fetch+git mergeとなる。詳しく説明すると、git fetchはリモートのmasterブランチからローカルへorigin/masterブランチを作るコマンド、ローカルにmasterブランチ+origin/masterブランチを存在させる事ができる。そこからマージさせる方法として、git mergeがあり、ローカルでもmasterを最新情報へ更新できる。

⇛いきなりgit pullすると、リモートとローカルの両方でファイル更新が合った際の、コンフリクトが発生してしまうリスクが有る。

↓プルリクエストでコードレビュー依頼⇛マージ

originのURL変更方法

git remote -v:でURL確認

git remote remove origin:originを削除

git remote add origin リモートリポジトリURL:再設定

or

git remote set-url origin リモートリポジトリURL:でURL変更もできる

↓Githubのsettingsタブでリモートリポジトリのリポジトリ名変更も可能

 

Gitの管理下にしたくない(外部公開したくない)ファイルの設定方法

.gitignoreで指定

一行ずつステージしたくないファイルを追加していく

例)echo “sample.html” >> .gitignore

.gitignoreをコミットして終了

なぜステージするのか?まとめ

良いコミットを行なうため(TeckAcademy説明)=コミットするファイルを選別

良いコミットとは:関連性のあるまとまりとしてコミットを行なうこと

⇛例:ランディングページの作成」と「とあるページの文言修正」という2つの無関係な変更を同時に行って、一つのバージョンにするのは扱いづらいコミットとなる

⇛まずは「ランディングページの作成」部分をインデックスにステージしてコミットし、次に「とあるページの文言修正」をステージしてコミットするという対応を取る。

実ファイルをGitの管理下に置くことで編集内容を保護(ブログ参照:https://www.ninton.co.jp/archives/3218#toc3)

編集〜コミットまでの時間が空く場合、もし朝の編集後から夕方のコミットの間までに変更ができてしまう⇛変更の確認方法は朝の編集直後の状態に戻さなければいけないなど不便⇛変更に気づけないと間違った内容でコミットするリスクが有る。

ステージに移動することで変更があった場合も、git diffで簡単に確認ができる

この記事が気に入ったら
いいね! しよう

Twitter で
タイトルとURLをコピーしました