Git学習基礎まとめ

Gitを使った開発に慣れるまでの学習方法にとてもよくまとまっています。 上記記事/便利なサイトや書籍のgitをはじめからていねいにを一巡します。手を動かしながら読み進めるとgitの概要をつかみます。 gitコマンド まと … “Git学習基礎まとめ” の続きを読む

Gitを使った開発に慣れるまでの学習方法にとてもよくまとまっています。

上記記事/便利なサイトや書籍のgitをはじめからていねいにを一巡します。
手を動かしながら読み進めるとgitの概要をつかみます。

gitコマンド まとめ

基本

リッポジトリの作成

$ git init

ステージング

変更したファイルをstageする

$ git add ファイル名

全てのファイルをstageする

$ git add .

初回コミット前の git add を取り消す

$ git rm --cached [ファイル名]

最新のコミットの状態に戻す

$ git reset HEAD [ファイル名]

rm –cacheとresetの違い
https://proengineer.internous.co.jp/content/columnfeature/6969#53

staging areaにある変更内容がコミットメッセージとともにリポジトリに反映

このとき、stage されていたファイルの内容とコミットメッセージは「コミットオブジェクト」としてリポジトリ内に保存される。

コミット

コミットメッセージ付きコミット

$ git commit -m 'コミットメッセージ'

直前のコミットメッセージの修正

$ git commit --amend

変更したファイルを全てコミットする

$ git commit .

直前のコミットを現在stagingした内容で「やりなおし」

git commit --amend

間違ったコミットを取り消す

コミットだけを取り消す(ローカルのワークディレクトリの内容は変更しない)

$ git reset --soft

特定のコミットまで戻す

$ git log //戻す対象のハッシュ値を調べる
commit ************************

$ git reset --hard ハッシュ値
revert

revertは、不要なコミットログを残したまま戻るため、メンバーを混乱させてしまう可能性があります。

git revert [コミットid]

ローカルのワークディレクトリの内容も含め、コミットを取り消す

$ git reset --hard

直前の間違ったコミットを取り消す

$ git reset --soft HEAD^

「HEAD^」は、直前のコミットという意味を表すオプション

ファイルへの変更の取り消し

$ git checkout --

https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-%E4%BD%9C%E6%A5%AD%E3%81%AE%E3%82%84%E3%82%8A%E7%9B%B4%E3%81%97#_%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%B8%E3%81%AE%E5%A4%89%E6%9B%B4%E3%81%AE%E5%8F%96%E3%82%8A%E6%B6%88%E3%81%97

ここで理解しておくべきなのが、`git checkout — [file]`は危険なコマンドだ、ということです。 あなたがファイルに加えた変更はすべて消えてしまいます。変更した内容を、別のファイルで上書きしたのと同じことになります。そのファイルが不要であることが確実にわかっているとき以外は、このコマンドを使わないようにしましょう。

ファイルの削除+「ファイルを削除したよ」という情報を stage

$ git rm [ファイル名]

ログの確認

$ git log

qで抜け出す

ファイルの移動とその変更内容をstage

$ git mv [ファイル名] [移動先Dir/ファイル名]

ブランチ

新規ブランチ作成

$ git branch [ブランチ名]

分岐元を指定して新規ブランチを作成

$ git branch [新規ブランチ名] [分岐元ブランチ名]

ブランチを切り替える

$ git checkout [ブランチ名]

ログフォーマット化 (git graphで表示)

$ git config --global alias.graph "log --graph --date-order --all --pretty=format:'%h %Cred%d %Cgreen%ad %Cblue%cn %Creset%s' --date=short"

ブランチを削除

$ git branch -d [ブランチ名]

ブランチの確認

$ git branch

ブランチを切ってそこにチェックアウト

$ git checkout -b [ファイル名]

ブランチを戻りたいコミットに移動

$ git reset --hard [移動先コミットid]

マージ

マージ

$ git merge [ブランチ名]

Fast-foward以外でマージ

$ git merge --no-ff [ブランチ名]

マージしたときに競合が発生した場合には、手動でマージする

  1. ファイルを手動で修正
  2. git add <修正したファイル>として「競合を直したよ」と Git に伝える
  3. 全部直したら git commit でマージコミットを完成させる

今いるブランチが「履歴上のどこから分岐したのか」という過去を改変する

リモートリポジトリに新しいブランチを複製

$ git push [リモートリポジトリの名前] [手元のブランチ]:[リモートに作りたいブランチ]

手元のリポジトリでのブランチの名前とリモートリポジトリのブランチの名前が同一の場合

git push [リモートリポジトリの名前] [ブランチの名前]

リモートのブランチの削除

git push [リモートリポジトリの名前] (ここになにも書いてない):[リモートのブランチ]

fetch してマージ

git pull

分岐元から今までに行ったコミットの変更内容を、新しい分岐元からひとつずつイチから適用しなおしてくれる。

git rebase [ブランチ名]

bare repositoryを作る

作業ディレクトリなしで、リポジトリだけを複製する

git clone --bare [複製元] [複製される先]

作業ディレクトリ付きでリポジトリを複製

$ git clone [複製元] [複製される先]

追跡する ブランチを、ローカルに作成

$ git branch [手元のブランチの名前] [追跡したいリモートブランチの名前]

remote リポジトリを設定

$ git remote add [リモートリポジトリの名前] [リモートリポジトリの場所]

リモートリポジトリに存在するコミットやブランチを手元に持てくる

git fetch [リモートリポジトリの名前]

ブランチの追跡設定

$ git branch --set-upstream-to=[リモートリポジトリの名前]/[追跡したいリモートブランチ] [手元のブランチ]

リモートリポジトリーの確認

方法1
$ git remote -v
方法2
$ git remote show -n origin

git push の取り消し

運用ポリシー

master ブランチにコミットするものは「リリースするもの」だけ、ということにしましょう。開発途中のものをコミットするのは、「development」というブランチにします。そして、作業は development からトピックブランチを切って行います。

言い方を変えると、なにか作業をするときには development ブランチから topic ブランチを切って行います。そして、その作業が終わったら、develop ブランチでそのトピックブランチを merge します。これを繰り返して、development ブランチの状態が「リリースできるもの」になったら、master ブランチから development ブランチを merge します。

  • master が指してるコミットは、必ず 「最新のリリース」 である
  • development が指しているコミットは、「最新の開発版」である
  • 各トピックブランチが指しているコミットは、「作業途中の状態」である

すでにリリースしてしまったものに不具合が見つかったときにそれを緊急で修正しなければならないときには、master ブランチから hotfix ブランチを切って、ここで修正した内容を master ブランチに merge すること
そして、この緊急対応が無事にリリースされたなら、hotfix が取り込まれた master ブランチを development にマージすることにしましょう。このように運用することで、開発版にも、リリース版での修正を反映することができます。