2018/01/31
2017/12/27
Gitの主要コマンド
Vanです。
引き続き勉強会で学んだことを紹介します。
今回はLuiさんの調べたGitの主要コマンドです。
コマンド | 解説・詳細 |
git config --global user.name "<ユーザ名>" git config --global user.email "<メールアドレス>" | 設定 |
git config --global color.ui auto git config --global alias.co checkout | gitの出力をカラーリング エイリアス設定(checkoutをcoに) |
git branch <NAME> git checkout -b <新ブランチ名> git branch -d <ブランチ名> | ブランチ作成 ブランチの作成とチェックアウトをまとめて行う ブランチ削除 |
git remote add <NAME> <URL> | リモート化・・・インデックス(ファイルの変更点などのリスト?)をGitHubに作成 リモートリポジトリのアドレスを名前付け(普通は<NAME>はorigin) |
git status : 確認 git add -A : 追加削除情報をインデックス登録 git commit -m "add event" : コメント git push -u <リポジトリ名> <ブランチ名> : 反映 | git status : 確認 git add -A : 追加削除情報をインデックス登録 git commit -m "add event" : コメント git push -u <リポジトリ名:origin> <ブランチ名> : 反映 クローンしたリポジトリでは、pushのパラメータのorigin masterは省略可 プッシュやプルは実行時にリモートリポジトリ名を省略すると、originという名前のリモートリポジトリを使用 |
git log git log --graph --oneline git log --decorate | リポジトリの変更履歴を表示 可視化 タグ情報も見れる |
stash | まだコミットしてないファイルがインデックスやワークツリーに残したまま他ブランチへチェックアウトすると、その変更内容は元のブランチから移動先のブランチに対して移動する。 移動先のブランチで同じファイルが既に変更されている場合チェックアウトに失敗。 このような場合は、変更内容を一度コミットするかstashで一時的に変更内容を退避させてからチェックアウトしなければならない 退避させた変更は後から取り出して、元のブランチや別のブランチに反映可 |
rebase | merge : 変更内容の履歴はそのまま残るが、履歴が複雑になる rebase : 履歴は単純になるが、元のコミットから変更内容が変更される(元のコミットを動かない状態にしてしまうことがある) rebaseしただけだとmasterの先頭の位置はそのままなので、masterブランチからNEWブランチをマージして、NEWの先頭まで移動 (例:統合ブランチにトピックブランチを取り込む場合は、まずrebaseしてからmerge) rebaseにiオプションを指定すると、コミットの書き換え、入れ替え、削除、統合を行うことができる → pushする前にコミットコメントをきれいに書きなおす、意味的に同じ内容のコミットをわかりやすいように一つにまとめる、コミット漏れしたファイルを後から追加する |
git fetch | pullを実行するとリモートリポジトリの内容のマージが自動的に行われる。(pull = fetch + merge) 単にリモートリポジトリの内容を確認したい場合はfetch 取得したコミットは名前の無いブランチとして取り込まれ、FETCH_HEADという名前でチェックアウト |
git tag <tagname> git tag -am "注釈" <tagname> git tag -d <tagname> | タグ名を指定してcheckoutしたり「コミットの書き換え」で説明するresetをすることで、簡単に過去の特定の状態に戻せる -aで注釈つきタグ、-mでコメント タグ削除 |
git commit --amend | 指定してコミットを行うと、同じブランチの直前のコミットに対して内容を追加やコメントの修正 |
git revert HEAD | 指定したコミットの内容を打ち消すコミットを作り出す。rebase -iやresetによるコミット削除は、そのコミットが既に公開済みだと削除できない。 |
reset | 要らなくなったコミットを捨てる モード名 soft ・・・ HEAD位置変更する + インデックス変更しない + ワークツリー変更しない → コミットだけを無かったことにする mixed ・・・ HEAD位置変更する + インデックス変更する + ワークツリー変更しない → 変更したインデックスの状態を元に戻す hard ・・・ HEAD位置変更する + インデックス変更する + ワークツリー変更する → 最近のコミットを完全に無かったことにする |
cherry-pick | cherry-pickでは、別のブランチから指定したコミットをコピーして、現在のブランチに取り込む (ブランチを間違えて追加したコミットを正しい場所に移す、別ブランチのコミットを現在のブランチにも追加する) |
squash | このオプションを指定してブランチをマージすると、そのブランチのコミット全てをまとめたコミットが追加される |
rm -rf ディレクトリ名 | gitディレクトリごと削除 |
git pull origin develop | developブランチのものを取ってくる(pull = fetch + merge) |
git add -A 1.Xと2.Xの違い | (1.X) git add . と git add -u を足したもの(削除と追加ファイル全部反映) git add . ・・・ ワーキングツリーに新規作成、あるいは変更されたファイル対象(削除されたファイルはaddされない) git add -u ・・・ 一つ前と最新のステージを比較して、変更があった部分のみをadd(新しく作られたファイルはaddされない) (2.X) git add -A : ツリー全体を対象とする git add . : カレントディレクトリ以下のツリーを対象とする Git 1.x では対象に削除されたファイルを含むかが違い、Git 2.0からはその違いはない。 |
git checkout master git merge(rebase) develop git add myfile.txt(競合修正後) git rebase --continue | まず取り込み先の別のブランチに移動 developブランチの内容を持ってくる(競合しなければdevelopにブランチ切り替わって統合) rebaseの場合、競合箇所を修正した後はコミットではなくrebaseコマンドに --continue オプションを指定実行。もしrebase自体を取り消す場合は --abort オプションを指定 最後にgit push origin master |
git checkout . git reset --hard HEAD~ | 変更を打ち消す マージを取り消し |
今回は初心者の自分にもわかりやすい内容ですね。
今回の勉強会で学んだことの紹介は以上です。
また次回の勉強会をお楽しみに(?)
2017/12/27
git diffについて
Vanです。
前回に引き続いて勉強会で学んだことを紹介していきます。
今回はS丼さんの調べたGit diffについてです。
ブログの使い方がつかめないのですが、コピーしたものが黒字になってしまう・・・書式スタイルのクリア押してもなんで変わらないんだろう?
というわけで我慢して見てください(ぁ
“git diff”の基本動作
⇨ワーキングツリーに行われた変更の表示
[インデックス] → [ワーキングツリー] の差分を見る場合
$ git diff
引数に「比較元」を指定できるので、引数を変更することにより、比較対象を変更できる。
// [最新コミット] → [ワーキングツリー] の差分を見る場合
// HEADは現在のブランチの先頭のコミットへの参照
$ git diff HEAD
指定したコミットとの差分を見たい場合
// <commit> → [ワーキングツリー] の差分を見る
git diff <commit>
——————
[参考]commitの識別子
$git log
commit 0162e65afed22b9fbd4ef915d77f9f67a223f7ec
Author: naoyashiga
Date: Sun Jun 2 18:57:30 2013 +0900
change README.md
commit 57228b29d976075bdf47eb9ea7ead44c8b867632
Author: naoyashiga
Date: Sun Jun 2 18:55:15 2013 +0900
change README.md
——————
他の差分についても見てみる
「--cached」オプションを利用することで、インデックスを変更を見ることができるようになる。
//インデックスとHEADの差分を確認したい場合
$ git diff --cached HEAD
$ git diff --cached //こっちでもok
特定のコミット間を比較したい場合はこちら
// コミット同士を比較する
git diff [比較元のコミット] [比較先のコミット]
*コミットの指定は、コミットのID、ブランチ名、HEADのどれでもOK
こういうこともできるらしい。比較対象を限定したい場合
// パスやファイル同士を比較する
git diff <コミット名>:<ファイル名> <コミット名>:<ファイル名>
ん?いつ使うべきなのか書いてる自分がわからないぞ?(あーあ
次回はGitの主要コマンドについてです。
2017/12/27
Gitでよく起こる問題と解決方法
Vanです。
luftelliメンバー内で勉強会を行ったので、今回はその内容についてまとめたいと思います。
実は自分であるVanは忘年会の影響で今回の勉強会に参加できなかったので、書いてる自分自身で分かっていない部分だらけですが・・・・・。
今回はCincさんが調査したGitでよく起こる問題と解決方法についてです。
- リポジトリのクローンに時間がかかる
Shallow Cloneにより最新のファイルのみをクローンする
git clone --depth 1 [URL] 作業する前にブランチを切り替え忘れた
まだコミットはしてない
stashコマンドを使うgit stash #現在されている変更を退避する
git checkout [目的のブランチ名]
git stash pop #退避していた変更を元に戻す
コミットしてしまった
git reset --soft HEAD^ #直前のコミットを取り消す
まだコミットしていない場合と同じ手順
他の人がすでにpushしていた/作業前にpullし忘れた状態でローカルに変更を行ってしまい、pushできない
pullを行い、必要なら競合の解決をしてから改めてpushするgit pull origin [現在のブランチ名]
競合が起きたら競合の解決
git push -u origin [現在のブランチ名]
競合が起きてしまった
競合が起き得る状況
同じファイルを変更していても可能な場合は自動でマージしてくれるが、自動マージが不可能な場合は競合部分にマークがつけられるので、自分で解決しなければならないローカルとリモート上がともに変更されているときにpullする
同じファイルが変更されているブランチをマージする
競合の解決
競合を解決する場合は、競合が起きたファイルに変更を加えた人とも相談するのがいいと思うどちらか片方のブランチのファイルを優先する
現在いるブランチを優先させる場合
git checkout --ours [ファイル名]
ファイル名に”.”を指定することで、全てのファイルに対して適用できるマージ相手やリモートブランチを優先させる場合
git checkout --theirs [ファイル名]
ファイル名に”.”を指定することで、全てのファイルに対して適用できるファイルを直接編集する
競合の起きている部分にはマークがつけられている。その部分を自分で修正する。VisualStudioやVIsualStudioCodeではファイルの競合が起きている部分を強調表示してくれたり、どちらを残すか選択すれば自動で書き換えてくれる機能がついている編集が終わったら、コミットして作業を再開
なんか色々試したらpushもpullもできなくなってしまった
下に行くほどめんどくさい方法。-fオプションによる強制pushはリポジトリを壊すことになりかねないのでやめよう新しい派生ブランチを作り、そこでpullとpushを試してみる
変更したファイルをリポジトリ外にコピーして正常なブランチに移動、そこから新しいブランチを作ってコピーしたファイルを元に戻し、pushする
諦める
むむ?このブログの箇条書きの使い方がつかめず見づらくなってるぞ?
よくわからなかったらコメント欄で質問してください(そもそもこのブログを見ている人などいないとか言ってはいけない)
次回の記事ではGit diffについて紹介します。