最初に
自身で学習してきた内容を書き出していきます。
基本的には自分自身でわかるような内容になりますので、ご容赦ください。
また、誤っている点がありましたら、コメントにてご指摘ください。
**(要確認)**マークがあるものは、「実行前に必ずググる」べき内容。
#index
- 全体構造
- 各種コマンド
- 確認系
- 実行系
- 戻し・取り消し系
- git hub登録
- コマンド以外の情報
全体構造
リモートリポジトリ(githubなど)
↓ ↑
リモートリポジトリのコピー(読み取り専用)
↓ ↑
ローカルリポジトリ
↓ ↑
インデックス
↓ ↑
ワークツリー
各種コマンド
##確認系
###ファイルの追加/変更/削除を確認する (git status)
$ git status
###差分を確認する (git diff)
$ git diff
###変更履歴を確認する (git log)
$ git log
commitの後に書かれている英数字 : コミットの識別番号
Author : コミットを作成したユーザーの名前とメールアドレス
Date : コミットを作成した日時
さらにその下 : コミットするときに入力したコミットメッセージ
現在のブランチを確認する(git branch)
$ git branch # 現在いるブランチには※がつく
*master
##実行系
###ローカルでGitを使えるようにする (git init)
$ git init
変更履歴を残す準備 (git add)
$ git add [file名] # file名のみ
$ git add -A # git add . + git add -u = 新規作成/編集/削除したファイルをaddする
$ git add -p # 対話モードになり、コード単位でadd指定ができる、addしたいならy(yes),したくないならn(no),コードの塊を分割したいならs(split)でEnterを押していく
$ git add . # すべてのファイル・ディレクトリ
$ git add *.css # すべてのCSSファイル
$ git add -n # 追加されるファイルを調べる
$ git add -u # 変更されたファイルを追加する
$ git rm --cached # addしてしまったファイルを除外(要確認)
変更履歴を保存する (git commit)
$ git commit
$ git commit -m "Initial commit 1" # メッセージを加える場合
$ git commit --allow-empty -m "empty commit" # 空コミット
$ git commit -a # 変更のあったファイルすべて
$ git commit -v # 変更点を表示してコミット
リモートリポジトリに登録してpush
$ git remote add origin [https://リモートリポジトリのURL]
$ git push -u origin master
-u : origin masterが登録され、次回以降git pushのみでorigin masterにpushされる
リモートリポジトリをローカルに複製する (git clone)
$ git clone [URL] # Use SSH か Use HTTPSでコピーしてくる
ブランチを作成/切り替え (git branch / git checkout)
$ git checkout -b [新規branch名] # ブランチを新規作成し、そのまま切り替える
$ git branch [新規branch名] # ブランチを新規作成する
$ git checkout [指定branch名] # 指定ブランチへ切り替える
ローカルの変更をリモートリポジトリにアップロードする (git push)
$ git push origin [指定branch名]
$ git push origin master # 一例
origin : リモートリポジトリにデフォルトで付けられている名前
HTPPSの場合はgithubアカウント名とパスワードを入力する必要がある
リモートリポジトリからダウンロードする (git fetch)
$ git fetch origin # masterがダウンロードされる
ローカルブランチに反映する (git merge/git pull)
$ git merge [統合したいブランチ名]
$ git merge origin/master
$ git pull origin master # git fetch origin と git merge origin/masterをまとめて実行できるコマンド
git logで、mergeの履歴も確認できるはず。
戻し・取り消し系
git add 取り消し
・git init 直後のgit addを取り消す(要確認)
$ git rm --cached -r . # 全てのファイルを取り消し
$ git rm --cached -r file_name # 特定のファイルのみ取り消し
--cached : このオプションをつけ忘れると、インデックスと、ファイル実体を削除してしまう
・2回目以降のgit add を取り消す(要確認)
$ git reset HEAD # 全てのファイルを取り消し
$ git reset HEAD file_name # 特定のファイルのみ取り消し
git comit 取り消し(pushしていない状態)
$ git reset --soft HEAD^ # 直前のcommit実行を取り消す
$ git reset --hard HEAD^ # 過去のコミットの直後に戻す(要確認)
$ git revert HEAD # 変更内容の取り消すような反対の変更を含んだ新しいコミットを作成する(要確認)
$ git commit --amend # 直前のコミットを修正する(要確認)
--soft : 作業ツリーとインデックスをそのままにして、ブランチの先頭のみを変更
--hard : HEADのみでなく、インデックス、および作業ツリー上の変更もすべて取り消し
--amend : 直接的に直前のコミットを修正(「古いコミットを破棄し、新しいコミットで置き換えた」という扱いのため、古いコミットをすでにPushしていたらコンフリクトが必ず起こる)
履歴をもとに前の状態に戻す (git reset)
$ git reset [commit]
$ git reset HEAD^ # 1つ前の状態に戻す
ローカルリポジトリの履歴は1つ前の状態に戻っていますが、手元のファイルは戻っていないことに注意。
resetは、リポジトリのコミット状態を戻すコマンドであり、ファイルを元の状態に戻すコマンドではない!
git hub登録
わからなくなったら、git config --globalで検索。
$ git config --global user.email "xxx@xxx.com"
$ git config --global user.name "xxx xxx"
コマンド以外の情報
.gitignoreの記述
.gitignore(ぎっといぐのあ)ファイルに記述することで、管理の管轄外にすることができる。
git initをした際に作成されているか、自身で作成するかでOK。
また初期の方で作成するのが好ましい。
$ rails new [アプリケーション名]
↓
$ git init
↓
.gitignore に記述!!
↓
コントローラなど記述したりルーティングを指定したりする
↓
push
↓
他メンバーがcloneして開発していく
↓
・・・
おすすめ記述
/db/*.splite3 # db系は記述を推奨。コンフリクト(記述衝突)の原因になる。
.DS_Store # macユーザーは自動生成されてしまう.DS_Storeファイルでよくコンフリクトが起きる。
コミットメッセージの書き方
後から読み直したときや第三者が見たときでも一目でわかるように、要点を記載すること。
"動詞 目的語"の順で書くとわかりやすいらしい。
開始 … Start
終了 … Finish
追加 … Add
更新 … Update
削除 … Remove
不具合修正 … Fix
git commit -m "[Finish] Blog投稿機能のコントローラ"
git commit -m "[Add] Featureのレイアウト"
git commit -m "[Update] blogsで投稿内容をeach化"
"" 投稿者は、日本語でも良いことを後から知ってしまったのであった・・・😭 ""
######英語例
・[転載] gitにおけるコミットログ/メッセージ例文集100
・ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
######日本語例
・Gitのコミットメッセージの書き方
〜戒め〜
「コミットメッセージをもっとわかりやすく丁寧に記述すればよかった・・・」という後悔をしないようにする。
branch名の命名について
・中央リポジトリ
master : 現在の製品バージョン(基本的にUPDATEのみ)
develop : 次回リリースの開発用ブランチ
・開発者リポジトリ
feature : 新規機能の開発用。developから分岐して、developにマージする
release : 次回リリース用の準備用。developから分岐して、developとmasterにマージする。
hotfix : 現在の製品バージョンのバグフィックス用。masterから分岐して、developとmasterにマージする。
などなど
git flowなどで管理すると理解が捗る。
ブランチ名の命名規則
・Gitブランチの名前の付け方
・バージョン管理システム入門(初心者向け)
「github ブランチ名 命名規則」で検索すると良い。
READMEの編集方法
・stackedit
「マークダウン記法」で調べると良い。
追加あれば、どんどん更新していきます。
駆け出しとして頑張ります。