ブランチを操作しよう
# 現在登録されているブランチの一覧を表示[-a:非表示branchも全て表示する]
$ git branch -a
# 新規ブランチを作成
$ git brahch %new-branch%
# ブランチを切り替える※切り替えた後は、git branchで確認しよう
$ git checkout %new-branch%
ブランチは、機能ごとに、作っておき、全ての機能をmasterにmergeしておくことも
ルール化することをオススメする。
コミットした履歴の確認
# まとめて見る※1行単位で確認できるので、閲覧に便利
$ git log --oneline
# 詳細を見る
$ git log
# format表示する
$ git log
tagを付けてラベル管理
$ git tag ***
細かな作業を記録しておくcommitとは違い、開発ツールのバージョンの切り替わりタイミングや、
作業のfixしたタイミングとしてタグ付けしておくと、製品管理のエビデンスとして使用できるので、
こういった作業で、ドキュメント構築を別途行わなくてよくなり、作業効率化に繋がります。
branchはmasterに集約しよう
$ git merge %branch%
コンフリクトに気をつけよう！
merge時に"conflict"という文字があれば、対象のファイルに下記のような状態になっていると思います。
Auto-merging hoge.txt
CONFLICT (content): Merge conflict in hoge.txt
Automatic merge failed; fix conflicts and then commit the result.
1.aaa
<<<<<<< HEAD
2.bbb
=======
1.1.bbb
2.ccc
>>>>>>> %branch%
"======="を境に、上の部分が、元状態で、下がmerge先の状態ということで、どっちが正しいか
gitが判断できなかったという事です。
だいたいの場合、上か下のどちらかの記述を削除する事で解決しますが、
ここの書き方を根本的に書きなおさないといけないとすると、
開発工程を見なおしたほうがいいと思います。
基本的には、いかにコンフリクトを出さないmergeを行うかが、gitの使い方のポイントでしょう。
そもそも、差分履歴を自動してくれるツールのはずなのに・・・
と、僕も考えたんですが、やはりこういった頭を使う工程は人間の頭でしか判別できないんで、
全自動などと甘い考えは捨てて、こうならないために、仕組みを作ることをオススメします。
巻き戻し
# 間違えて消してしまったファイルの復旧
$ git reset %file-name%
# 何もなかったように戻す
$ git reset --hard
# 前回commitまで戻す
$ git reset %commit%
# 数回前のcommitまで戻す
$ git reset –hard HEAD~1
$ git reset –hard “HEAD@{7}”
# 打ち込んだコマンドの履歴を表示
$ git reflog -n 10
確認作業
# 今回変更ファイル一覧
$ git diff %commit-id-1% %commit-id-2% --stat
# 任意ファイルの変更履歴（差分）
$ git diff %file-1% %file-2%
0 件のコメント:
コメントを投稿