Gitについてまとめました

コマンド 意味
git init ディレクトリをGit管理下に置きたい時、実行すべきコマンド。リポジトリを作成することで、ディレクトリをGit管理できるようになる。このコマンドで.gitと言う隠しフォルダとGitに関連するファイルが作成される。
git add . カレントディレクトリ以下のすべての変更内容が追加
git add -all すべての変更内容がインデックスに追加
git add -A すべての変更内容がインデックスに追加
git commit -m ファイルをコミットする
git log コミットのログを確認
git log -p コミットのログだけでなくファイルの修正内容まで確認することが出来る
git branch -c 現在のブランチの複製
git branch ブランチ名 ブランチの作成
git branch -b ブランチ名 ブランチを作成し、そのあと当該ブランチに切り替える
git checkout 変更の取り消し
git checkout . 現在のワークツリーの修正を取り消す(破棄)git restore .でも同じことができる
git checkout ブランチ名 ブランチを切り替え
git switch ブランチ名 ブランチを切り替え
git diff ワークツリーでの修正内容の確認をすることが出来る
git diff –cached 「ステージングエリア」と「ローカルリポジトリ」の内容(直前のコミット)との差分を確認できる
git merge 別のブランチのコミットの変更内容を、現在のブランチに取り込む
git pull origin ブランチ名 ・リモートブランチをローカルブランチにマージする<br/>・リモートブランチを取ってきて、現在のブランチに取り込む(現在のローカルブランチに「ブランチ名」の変更を取り込む)<br/>git fetch、git mergeを同時に行うコマンド
git push ローカルブランチをリモートブランチに反映する
git fetch リモートブランチの最新情報をローカルに取ってくる。コマンドを実行するとgit branch -aなどのコマンドの結果に、リモートブランチの最新の情報が反映される。ソースコードの更新は行われないので、変更を反映させる場合は別途mergeやpullコマンドが必要
git rebase 過去のコミットを修正する※コミット履歴を改変することを嫌う人もいるので、使って良いかはチームのメンバーに確認する
git rebase -i 対話形式で過去のコミットを修正することが出来て、過去のコミットをまとめることも出来る
squash git rebaseコマンドを実行した後に出す命令として、squashが使用されることがある。記載したコミットがそれの前のコミットに統合される。
git reflog コミット履歴の確認。人為的ミスで、マージしてないブランチを削除してしまったり、git reset --hardコマンドで期待したコミットよりも過去のコミットまで戻ってしまった場合などに、HEADの動きの履歴をみることができる。
git remote -v リモートリポジトリのURL情報を確認する
git remote add リモートリポジトリの略称 リモートリポジトリのURL リモートリポジトリのURL情報を設定する。基本的にリモートリポジトリの略称の部分はoriginが使われるので、git remote add origin リモートリポジトリのURLの様な形になる。
git reset --hard HEAD^ 直近のコミットの記録と併せて変更内容ごと全て削除される
git reset --soft HEAD^ 直近のコミットは無くなり、直近のコミットでの修正内容はワークツリーに置かれる
git reset HEAD^ 直近のコミットを取り消す
git reset HEAD~n n個前のコミットを取り消す
git reset ファイル名 インデックスに追加したファイルを戻す
git restore –staged ステージングエリアの変更の取り消し
git restore --staged [ファイル名] インデックスへ追加したファイルの登録を取り消す
git restore --source=コミットハッシュ値 ファイル名 指定したコミットの内容を復元
git restore . 現在のワークツリーの修正内容を破棄。git checkout .でも同じことができる
git revert コミットID 対象のコミットで行われた変更を取り消す。間違えて行ったコミットをプッシュした場合に、その内容を打ち消すために使える。対象のコミット自体を削除するわけではない。
git rm git管理しているファイルの削除
git rm --cached Gitからは対象のファイルを削除するが、ワークツリーには対象のファイルは保持することができる。ファイルを残したままgit管理対象外になるため既に管理しているファイルなどをgit管理対象外にしたい場合に利用されやすい
git stash 現在の修正内容を一旦退避させる
git stash apply 退避した内容を元に戻す
git stash apply -u trackedになっていないファイル(git addしていない)ファイルを含めて退避する
git stash list 退避したものが確認できる
git stash pop また退避させたものを再度反映して、かつstashを削除
git tag 最新のコミットにタグを指定する
git tag -d タグを削除する
git ignore ファイルをGitで管理しない指定をする
  • Untrackedとはgitで管理ができてない状態

Git-flow

  • masterブランチとは別にdevelopブランチがあり、その他にfeature、release、hotfixというブランチがある
  • developブランチでの開発作業を進めた後に、releaseブランチを作成し、成果は最終的にmasterブランチへマージする

メリット

  • 比較的大きい規模の開発でも通用するフロー
  • 複数の権限を適切に扱える
  • ソフトウェア開発に向く

デメリット

  • 開発者がmasterブランチではなくdevelopブランチを利用しなくてはいけない →開発者が誤って変更をdevelopブランチではなくmasterブランチだけにマージするようなミスになる

github flow

  • featureブランチとmasterブランチしか使わない。

メリット

  • 小さい規模から大規模まで対応
  • SaaSwebサービス)のような常に機能アップし続けるようなプロジェクトに最適
  • コンフリクト(修正箇所の衝突)が少なくなる

デメリット

  • 権限はmasterへのコミット権限(コミッタ)と パッチ作成者(コントリビュータ)しかないため、組織体制によっては適用できない可能性がある
  • テスト環境、本番環境などの環境分けを行う仕組みもない

参考

https://www.youtube.com/watch?v=qerW4vBftNA

https://www.udemy.com/course/unscared_git/

https://backlog.com/ja/git-tutorial/stepup/31/

https://zenn.dev/ryo_4947123/books/497459787cb294/viewer/branchstrategy_githubflow