index is the same as staged area.
git merge and git rebase

Git branching and rebasing.
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

merge can split to fast-forward merge(no split commit), or 3-way merge(combine and append a new commit).
git branch -d branch_name to delete branch.
Squash commit by git rebase -i HEAD~4 to squash previous 4 commit, don't do this in external repo.

http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

Use git merge --abort if you want to rollback the merge during confliction. If you merge and find that is the wrong operation, then use git reset --hard HEAD~1 instead.

Reset the staging area and the working directory to match the most recent commit. In addition to unstaging changes, the --hard flag tells Git to overwrite all changes in the working directory, too.

git status

git status
# use to check unstaged or modified files.

git commit

gt commit --ammend usually use to modify commit message or add modification of current commit.

git commit -m 'add message'
# commit all files and set modified message.

git commit -a 
# commit only staged area(by git add) tracked files.

git commit --amend 
# add staged area to previous commit instead create new one.

git commit --amend --no-edit
# no edit told git the commit message dont needs to modified.

git reflog

git reflog
# check the `HEAD`'s history of changed behavior.

git reflog some_branch_or_tag_name
# check that branch's history of changed behavior.

git revert VS git reset

git revert which only undo for Given one or more existing commits in history. It is safe because it generate new commit for those undoes, but keep the undo commit in history.

git reset which start commit deletions from current commit backwardly. It is not safe because you cannot keep track of deleted commits in future.

#####Never use git reset in public repository. #####git reset is designed to undo for local branches

git revert <commit_ref>
# generate new commit for the undoes of that commit.

git revert HEAD~1 HEAD~2
# 2 reverts

git reset <commit_ref>
# remove all the commits from current commint point to coomit_ref point.
# reset only do backward deletion.

git reset --hard HEAD~2
# remove files in working dir and staged files. 
# Set HEAD back to the second-to-last commit.

git reset --soft HEAD^^^
# only move HEAD back to the third-to-last parent commit
# ^ means switch to first parent, ^^ = ^2 means switch to second parent, not grand parent.
# only move HEAD back to the third-to-last commit
# It does not change stage area files to untracked, and working dir files.
# http://stackoverflow.com/questions/6091827/git-show-head-doesnt-seem-to-be-working-is-this-normal
# git 'head^' if you in zsh, ^ has special meaning

git reset HEAD^^^
git reset --mixed HEAD~3
# the default one.

mode	HEAD pos.	staged files	working dir.
soft	backed	unchanged	unchanged
mixed	backed	set untracked	unchangeed
hard	backed	set untracked	files removed

git clean

like rm in working history, git clean can remove unstaged(untracked) files. It is cannot undo as well as the rm command.
git clean usually used after git reset --hard because git reset --hard only remove tracked files, and git clean will help to clean all untracked files as well. This leads you to back for the exact state of a particular commit point.

git clean -i
# remove untrakced files by interactive mode

git clean -f
# force to remove untracked files

git clean 0n
# dry run for git clean

git rebase

git reabse will move current brnach from split point to another branch. It left a liner history.
git rebase --onto master next topic means, move the commits range from next to topic branch and rebase them to master branch.

 					   H---I---J topicB
                      /
             E---F---G  topicA
            /
A---B---C---D  master
    
# git rebase --onto master topicA topicB

             H'--I'--J'  topicB
            /
            | E---F---G  topicA
            |/
A---B---C---D  master

A range of commits could also be removed with rebase:

E---F---G---H---I---J  topicA

# git rebase --onto topicA~5 topicA~3 topicA

E---H'---I'---J'  topicA

We can abort if reabse has unresolvable confliction.

git checkout bugFix
git rebase master
# may need to manage confliction

git rebase -i master
git rebase --abort

git rebase --onto
We can use git rebase --onto to delete a range of commits.
git pull --rebase vs git pull. git pull --rebase will not keep original local commit, but git pull will copy original local commit to remote.

# Assume remote branch name now is the same as current branch.
git pull --rebase
# the same as:
git fetch
git rebase <remote>/<branch>
git push

git pull
# the same as:
git fetch
git merge <remote>/<branch>
git push

git rebase -i <commit_point> start from that commit point, pick, drop or reorder subsequence commits from that commit point.

git rebase -i HEAD~3 will reabse from previous 4rd commit.
rebase -i <commit_point>

git cherry-pick

pick a single commit from another branch and applied it to current branch. It will then generate new commit.
we can apply multiple cherry-pick by orders.
If we need to copy a range of commits, then we can use git rebase --onto master <start_commit_ref> instead.

git cherry-pick <commit_ref1> <commit_ref2> <commit_ref3>


#                   branch1
#   76543 - 456ds - 1235j
#                              master
#   yiuy11 - ag2355 - gtr24e - ohjg32
git checkout branch1
git rebase --onto master 76543^
# this will rebase 76543 to 1235j to master branch

git merge

git merge --squash
# this combine all merged commits into one commit,
# then append it to current checkout branch.

git pull

git pull is shorthand for git fetch followed by git merge FETCH_HEAD.
If local branch has new commits which is not in remote branch as well as remote branch has new commits too, then it will first solve the confliction of new commits between remote and local branches. Once the confliction is resolved, it will merge remote's new commits to local branch together.
What fetch did is to update new commits from remote, and .

git fetch

Update new commits from remote repo. and set a commit ref. FETCH_HEAD.
If local branch has new commits too, then we checkout local branch, merge FETCH_HEAD. The above operations it the same as git pull.

git push

Merge local branch to remote branch. It must be fast forward move, if not so, then we need to git pull to get updated remote branch first, then push again.

Misc

# create a new commit combine with bugFix, 
#  the commit point is after masters' current commit.
git branch bugFix    
git checkout bugFix    
git commit    
git checkout master    
git commit    
git merge bugFix
# merge bugFix to master's commit
git checkout bugFix
git merge master

git branch bugFix    
git checkout bugFix    
git commit    
git checkout master
git commit    
git checkout bugFix
git rebase master
# move master's HEAD to bugFix, fast forward.
git checkout master
git merge bugFix

git log --all --graph --pretty
# show git work tree

git checkout

git checkout <commit_point> use to detached HEAD from a branch to that commit point.

HEAD Position

When we submit new commit, then new commit will push after the commit which HEAD point to.
When we checkout an branch, HEAD will automatically point to the same commit that branch point to.

HEAD always points to the most recent commit which is reflected in the working tree.

^ (caret) refer to the previous commit from a particular commit point.

git checkout HEAD^ point HEAD to previous commit from cuurent HEAD.

A caret sign will forward a previous commit

git checkout HEAD^^^ point to the commit from three commits before current HEAD.

Instead create more caret signs to few steps before, use ^ with count number to step commit in numbers of before.

git checkout HEAD~3 is the same as git checkout HEAD^^^.

git branch

git branch -f <branch_name> <commit_point> use to move branch to some commit point.

git branch -f master HEAD~3 is move to the third to last(4th of last) commit.

git reset

git reset <commit_point> will move a branch backwards to commit point and delete afterward commits in project history.

git reset. Dont's reset public history.

In order to reverse changes and share those reversed changes with others, we need to use git revert.

git revert <commit_point>
git revert.

git cherry-pick <commit_points> copy one or more commits to after your current HEAD.
git commit --amend do slightly modification of current commit, it will parallel to current commit rather than fast forward to it.
git commit --amend
git tag <tag_name> <commit_point> will tag a commit, if commit_point not specified, then will point to where HEAD is at.
git describe <ref> here <ref> is anything git can resolve into a commit. If ref not specified, it will point to HEAD. git describe output information about that ref.

Output format: <tag>_<numCommits>_g<Hash_value>.

Similar as Caret sign, (^) with numbers will move HEAD to ith parents forward. Directly parent will be first parent.

git caret and tilde.

git checkout master
git branch second

# commit 1
git commit    

git checkout second

# commit 2
git commit

# commit 3
git commit

git checkout master
git merge second

# move to first parent, which is commit 2.
git checkout HEAD^1

git checkout master
# move to second parent, which is commit 1.
git checkout HEAD^2

git checkout <remote_name>/<branch> to checkout a remote branch. After commits will not move remote branch forward and it updates only when remote updates.
git pull do the same thing as git fetch then git merge <remote>/<branch>.
git fakeTeamwork <branch> <num_fake_commits>.

When we need to essentially "pretend" that the remote was updated by one of your coworkers / friends / collaborators, sometimes on a specific branch or a certain number of commits.

use git checkout -b <arbitrary_branch> <remote>/<branch> to set that branch to a remote branch. During a clone, git creates a remote branch for every branch on the remote. You can make any arbitrary branch track on remote by this command.
Another way to set remote tracking on a branch is to simply use the git branch -u <remote>/<branch> <arbitrary_branch> to set branch to track that remote branck
If HEAD is detached, git push need to specify its remote and branch name ex: git push <remote> <branch>, otherwise push operation will failed.
Advancely, we can decide to push part of commits to remote branch: git push <remote> <commit_point>:<remote_branch>. If remote_branch not existed, git will create in both remote system and remote branch in local machine.

git push origin HEAD~2:master will push previous second commit to remote master branch.

Similar as previous example, git fetch origin foo~1:bar fetch remote commit point foo~1 to local destination bar.
git push <remote> :<remote_brnach> push "nothing" to a remote branch which delete branch in remote system and remote branch in local machine.
git fetch <remote> :<branch> fetch "nothing" to a place locally actually makes a new branch in local machine.
git pull origin bar~1:bugFix is equivalent to git fetch origin bar~1:bugFix; git merge bugFix.
git pull origin foo is equivalent to git fetch origin foo; git merge o/foo.

jamesyang124/git_resources.md

Select an option

No results found