Hot fixes go straight onto master. Everything else should be done in a feature branch that will get merged into master.
Set autosetuprebase to avoid lots of little merges in new branches:
git config --global branch.autosetuprebase always
If a repo was cloned before enabling the above, set each of its branches to use rebase. E.g. for master:
git config branch.master.rebase true
Check all branches in a repo are set to use rebase (each ouput line should end with true):
$ git config --local --get-regexp "branch.*rebase"
branch.master.rebase true
branch.branch_name.rebase true
Create a new branch:
git checkout -b [branch_name_with_bug_num_if_one]
Make and commit your changes on that branch.
Oops, I've already started editing files on master! No problem, run the same command.
Oops, I've already committed changes to master that should be on a branch! If you have not done a git push try this: http://stackoverflow.com/a/1628584/1777662
Oops, I've already committed and pushed changes to master that should be on a branch! This can't be undone, so don't do it.
First, make sure you have the latest version of master:
git checkout master
git pull
Then make sure your changes can be applied cleanly onto master:
git checkout [branch_name]
git rebase master
If you hit a conflict at this stage, git will give you handy hints on how to proceed. Generally the process will be to edit the conflicting file (the two conflicting bits will be marked between <<<<<<<, =======, and >>>>>>>), then
git add [conflicting_file]
git rebase --continue
git push --set-upstream origin [branch_name]
(Or, on older versions of git: git push -u origin [branch_name])
If your branch already existed on the remote (e.g. additional changes were needed), git push may fail with a message saying your local branch is behind its remote counterpart (e.g. after a rebase, or after altering an already-pushed commit). If you know nobody else has been committing to your branch, ignore git's suggestion to pull before pushing again, and instead force the push:
git push --force origin [branch_name]
However, never use --force when pushing branch master.
Email Mike to say your branch is ready to merge into master and deploy, use subject:
"Merge Branch [branch_name] in [product] [- URGENT?]"
If you are making a large change-set, rebase your branch regularly on master as you go. To rebase while you have unstaged changes:
git stash
git rebase master
git stash pop
git status tells you where you are.
git branch lists local branches.
git show-branch lists local branches and their commit status.
git show-branch master [branch_name] to compare your branch to master.
git checkout [branch_name] to switch branches.
If you don't want it hanging around, delete it locally:
git branch -d [branch_name]
Having a tidy change history makes it easier to understand what's going on.
If, after doing a commit, you spot a mistake in file a.php and have not done a git push you can amend the commit. Fix a.php, then:
git add a.php
git commit --amend
If you have a bunch of commits that have not been pushed and want to flatten some, re-order some, do pretty much anything... There's a good change you'll find an answer on stackoverflow.com telling you exactly how to do it. Just an example: http://stackoverflow.com/q/5189560/1777662
To view the change history:
git log --graph --oneline --all
git fetch
git checkout --track origin/[branch_name]
This creates a tracking branch, so you can then edit/commit/push as needed for multiple people to work on one feature branch.
Preserving all commits from a branch in master:
git checkout master
git merge --no-ff [branch_name]
Flattening all commits in a branch into one commit on master (probably not to be used very often):
git checkout master
git merge --squash [branch_name]
git commit -a -m "Merging [branch_name] in one commit: fixes blah blah... "
Feature branches should generally be deleted once merged into master:
git push origin --delete [branch_name]