$ git status
Changes to be committed:
deleted: file
Unstage file
$ git reset -- file
Checkout the copy in the index
$ git checkout -- file
$ git rm --cached file
$ git checkout origin/develop file
$ git log
3abc - HEAD -> feature-Z
2abc
1abc
0abc - develop
$ git rebase -i HEAD~4
# or equivalent
$ git rebase -i 0abc
git log MERGE commit c1 c2
git reset HEAD^1 reset two commits. HEAD points to c2. why?
ancestery references difference?
HEAD~ tilda vs. HEAD^ caret
$ git log
3abc - HEAD -> feature-Z
2abc
1abc
0abc - develop
$ git rebase -i HEAD~4
# or equivalent
$ git rebase -i 0abc
$ git stash show
$ git stash show -p stash@{3}
Show the entire history of file
$ git log -p [file]
See what's changed with the specific commit
$ git show HEAD~2
$ git branch -vv
Without specifying remote and remote-branch, git pushes whatever branch is tracking to. This can be controlled with push.default
config.
$ git checkout -b feature -x
# do some commits inbetween
# initially set up remote tracking branch and push there
$ git push -u origin feature -x
# use tracking branch
$ git push
$ git pull
How to create branch to auto-track branch with same name but not yet created?
$ git push origin --delete foo
or what syntax is this?
$ git push origin :foo
A feature may take several days or even weeks to complete which then causes the feature branch to stay way behind from develop and commits to be scattered around in the history. For the purpose of keeping a clean history, first get latest develop and move the complete feature branch on top of it.
(develop) $ git pull origin develop
(develop) $ git checkout feature
(feature) $ git rebase develop
After updating the feature branch, squash all feature commits into one and then create a PR.
(feature) $ git rebase -i develop
(feature) $ git push origin feature
It's always commits that gets tagged, not branches. As long as a commit identifier is not changed, the tag is kept in the target branch. See how commits are changed after a branch merge. Merge strategies definitely matter here.
(release/1.2) $ git log
3abc - HEAD -> release/1.2, tag: v1.2
2abc
1abc
...
(master) $ git merge -no-ff release/1.2
With no fast-forward merge, tag is forwarded to target branch but MERGE_HEAD stays one commit behind due to the new merge commit.
(master) $ git log
4def - Merge commit, HEAD -> master
3abc - tag: v1.2
2abc
1abc
For fast-forward merges, tag is forwarded then there will be no merge commit and exact revision and tag coming from release branch will stay. However, it's not always possible to avoid merge commits if branches differ.
For squash strategy, tags are not merged as the commit has changed in the target branch. merge will not merge tags because a new commit is born in the target branch. However, tag still stays where it is in the release branch. Remember it's always the commits that are tagged. If a commit from a branch itself cannot be merged, then its tag cannot be merged, too.
Checking out to a tag results with a detach state because a tag can be reachable by multiple branches (say develop, master etc.) Git has no way to know which branch you are in so it's detached.
$ git checkout version-0.3
HEAD detached at version-0.3
Clean working directory by removing untracked files
$ git clean -n
$ git clean -f -d
:Git
is akin to :git!
but with improvements. :Git
can be shortened as :G
. :Git blame
can be written as :Gblame
.
:G
- |:Git| add
- |:Git| reset (staged files)
cc |:Gcommit|
D |:Gdiff|
ds |:Gsdiff|
:Glog
:Gclog
:0Glog
:{range}Glog
:0Glog
:Gdiff
:Gread
[n
]n