#git Branch
(freakin awesome http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging)
Also, see JadedEvan's gist about branching. In particular, 'Create a new branch and have it track remote commits'
To create a new branch and switch to that branch:
$ git checkout -b my_new_branch
This is short hand for:
$ git branch my_new_branch
$ git checkout my_new_branch
Do your work in new branch, and commit.
Push your changes to the remote repo:
$ git push -u origin my_new_branch
The -u sets tracking of remote branch to the new local branch. This is good.
To merge, switch back to master.
$ git checkout master
and now merge
$ git merge --squash my_new_branch -m "merge message"
$ git commit -a -m "commit message"
This pulls and merges all changes from your local my_new_branch branch into your local master branch, squashing them into one commit.
If you want to, you can now delete my_new_branch branch since master is the same:
$ git branch -d my_new_branch
If you also setup a remote branch on origin and you want to delete it as well, do this:
$ git push origin --delete my_new_branch
or
$ git push origin :my_new_branch
List all branches, local and remote:
$ git branch -a
master
todd_mod
remotes/origing/v1.0
remotes/origin/api_tests
remotes/origin/master
Checkout remote branch locally by creating a local branch, -b creates and switches to the new branch:
$ git checkout -b my_local_branch_name remotes/origin/v1.0
Make your changes and commit.
To push your new branch to the remote repo:
$ git push origin new_branch_name
Lets say you started working on master branch. You've come a ways and realize you should have started a new branch with your changes. You haven't committed anything yet. Let create a new branch containing our changes. We'll leave master alone.
$ git checkout -b new_branch_name
All of your uncommitted changes are now in new_branch_name. To add and commit those changes:
$ git add .
$ git commit -a -m "my changes"
Push changes up to github.
$ git push origin new_branch_name
Ok, cool. We now have our changes committed, safe in their own branch, and pushed to the repo.
What happens if master is updated by someone else and you want those changes updated in your new_branch_name? Simple. Make sure you are still in you working branch, new_branch_name
$ git checkout new_branch_name
Then:
$ git pull origin master
This merges any changes from master branch into whatever branch you are in, which is currently new_branch_name
git diff between two branches:
$ git diff master..branch
git diff between two branches, name of files only:
$ git diff --name-status master..branch
git diff between two branches, and two files:
$ git diff branch:path/to/file1 master:path/to/file2
For pull git-pull - Fetch from and merge with another repository or a local branch
git pull [options] [<repository> [<refspec>...]]
Example
git pull origin v1.1
Will merge the contents of origin/v1.1 in your current branch.
from http://stackoverflow.com/a/2304106
HEAD is the current branch's commit. It's where you are now.
You can think of the HEAD as the "current branch". When you switch branches with git checkout, the HEAD revision changes to point to the tip of the new branch. It is possible for HEAD to refer to a specific revision that is not associated with a branch name. This situation is called a detached HEAD.
Lets say you and another dev pull a branch at the same time. The other dev removed a commit from the branch. They then force pushed their changes back to origin. If you pull that branch, you will merge, like normal, those changes back into your local branch, since you local copy contains that bad commit. If you were to push your local branch back to origin, the code would look like nothing had changed.
To avoid this, if chances are anyone may have pulled the sha with the bad commit, they will will need to reset hard their branch.
git fetch --all
git reset --hard origin/master
Of course this could be avoided by not commiting unless you are REALLY sure. But then you couldn't commit early, commit often. But since you are using branches, you wouldn't be commiting bad commits to master, would you?
-m Move/rename a branch and the corresponding reflog.
-M Move/rename a branch even if the new branch name already exists.
-d Delete a branch. The branch must be fully merged in its upstream branch, or in HEAD if no upstream was set with --track or --set-upstream.
-D Delete a branch irrespective of its merged status.
Merge working branch into development, favoring working branch changes over that of development. Removes the need for most of, if not all of, those fix conflicts, or merged into... messages.
$ git checkout development
$ git merge --no-commit -s recursive -X ours working_branch
Try this, removing the empty merge commit message:
$ git fetch origin
$ git rebase origin/{your-branch}
Better yet, this one-liner
$ git pull --rebase origin branch