Enumerate your local branches:
Switching from one branch to another: Example: Switching from branch 'branch1' to branch 'branch2'.
We normally do our feature work in branches to keep changes isolated from each other. The recommended workflow is to make local branches off the server master, referred to as the origin/master branch. The
git new-branch branch_nameNote that this is equivalent to the following:
git checkout -b new_branch origin/master
If you have dependent changes, a very productive workflow is to have a branch off a branch. Notably, this means that your patch sets (in Rietveld) will show the separate changes, and be easy to review, rather than showing the merged changes (including irrelevant changes), and means you can commit downstream CLs without having to rebase them after the upstream has landed. Do this as follows:
Now when you update the first branch, you can simply git pull on the second branch as normal to pull in your changes:
Note that these incremental patch sets are easy to review, but cannot be applied to HEAD (because they are based off another branch), so you cannot test them on try bots. To test these, upload the diff from HEAD to a different (test-only) issue and test there:
TEST_ISSUE=$(git cl issue | sed -r 's/[^0-9]*([0-9]*).*/\1/') # Save test issue
To open the test issue in Rietveld:
To try again:
git cl upload -t 'Try again' -f origin/master
...and then when finished, delete the CL to clean up (via Rietveld):
Lastly, when an upstream branch has landed, and you've rebased it so it agrees with master, you can set the downstream branch's upstream branch to be origin/master, which means you can now forget about the earlier branch:
A common variant of "branch off a branch" is splitting up a large CL into pieces. Given a local branch
One way to do this is to split off
This can be done manually, particularly if the files don't overlap, by making a new branch
However, this can be done more cleanly via git. The main points are
You generally want to delete local branches after the changes have been committed to master. It is safest to check that your work has, in fact, been committed before deleting it.
Remember that you can always apply a CL that has been posted via:
git checkout -b myworkfrompatch
...so as long as your CL has been posted, you can easily recover your work. Otherwise, you'll need to dig through the git repository, so be careful.
Simply, if master (remote or local) is up-to-date and your branch has been rebased, git branch -d will delete the branch. If not, it will refuse; to force deletion, use git branch -D. So make sure master is up-to-date, rebase branch, and then try deleting (optionally check manually before).
Beware that if your local branch has many revisions (instead of always amending a single revision), rebasing to master may fail, since it will try to apply the patches incrementally. You can avoid this by squashing your local revisions into a single revision (see 6.4 Git Tools - Rewriting History, or more simply squashing commits with rebase). This may be more trouble than it's worth, but it's the safest way.
To check that the branch has been committed upstream:
git checkout mywork
If there are no differences, delete the branch:
git checkout origin/master
NOTE: If you haven't waited long enough after your commit, it is possible that 'git fetch' did not get your commit and git will continue to believe that you have local changes, which will prevent "git branch -d" from succeeding. It's best to redo the steps later, (The repo is updated every 3 minutes) but you can also instruct git to force-delete your branch.
Note that when you delete your branch, it will give you the SHA-1 hash for its tip:
Deleted branch mywork (was 123abc0).
You can then recover the branch via:
git checkout -b mywork 123abc0
If you forget the hash, you can find it via git reflog. (Reference: Can I recover branch after the deletion in git?)
If you commit to master, updating will be messy. (This is a good reason to simply delete master entirely, as noted near the top of this document. You only need to read the remainder of this section if you don't do this.)
You can prevent this by adding a pre-commit hook that checks if you're in master and stops you from doing this. Create a file named chromium/src/.git/hooks/pre-commit and add the below to it, then mark executable. (Blink developers: add in blink directory as well.)
If you've accidentally uploaded a change list from master, you can clear the association of an issue number with master via:
git cl issue 0
If you've accidentally committed to master, then, after copying your work to a new branch (e.g., make patch and then apply to new branch), you can clean up master by deleting your accidental commit as per this answer to How to undo the last Git commit? -- see more details there.
git reset --hard HEAD~1