Legend:

1. When you've finished and tested your work, publish it to github using {{{git push origin yourbranch}}}. Don't forget to rebase and fix any conflicts before pushing if necessary ({{{git fetch official; git rebase official/master}}}) - incorporating your work is ''much'' easier if it applies cleanly to the official/master branch. Note that you must rebase before pushing, as rebase changes the commit IDs - this doesn't matter at all if the only place they exist is in your local repo.

6

6

7

N.B. Please make sure that yourbranch contains only commits you want merged to the official repository. If you have not kept your branches separate and there are commits relating to local changes or other work in yourbranch, things will get messy. To solve this, create a copy of master ({{{git checkout official/master; git checkout -b yourbranch2}}}) and cherry-pick the commits you actually want to offer up. (This method can also be used to avoid rebase conflicts, or at least isolate which commits are causing them.) From official/master you can use {{{git rebase -i yourbranch}}} as a sort of batch cherry-pick mechanism: it offers you a list of all the commits which are in yourbranch but not in master, and you can choose the ones to add. Note that rebase will say "nothing to do" if yourbranch will apply cleanly (i.e. fast-forward merge) to master - so this is a good test.

7

N.B. Please make sure that yourbranch contains only commits you want merged to the official repository. If you have not kept your branches separate and there are commits relating to local changes or other work in yourbranch, things will get messy. To solve this, create a copy of master ({{{git checkout official/master; git checkout -b yourbranch2}}}) and cherry-pick the commits you actually want to offer up. (This method can also be used to avoid rebase conflicts, or at least isolate which commits are causing them.) From yourbranch2 you can use {{{git rebase -i yourbranch}}} as a sort of batch cherry-pick mechanism: it offers you a list of all the commits which are in yourbranch but not in master, and you can choose the ones to add. Note that rebase will say "nothing to do" if yourbranch will apply cleanly (i.e. fast-forward merge) to master - so this is a good test.

8

8

9

9

2. Go to your github account in your browser and click on your fork. Don't forget to click the Branches tab and make sure you're looking at the right branch (github will always default to the master branch). Note that if you created yourbranch2 as described above, in order to tidy it up and offer only the right commits, then this is the one you need to look at.

Please note, though, that you cannot rebase after submitting a pull request. But that's not really your problem - once you've submitted the request, it's the devteam's job to review and merge it as soon as we can. If we merge something else first, we'll fix any merge conflicts when we merge yours.

21

22

After your work is merged, please don't continue working on that branch. Even if you're continuing development of the same feature, please fetch from official/master and start a new branch from there for your next pull request (there is no limit to the number of branches you can make). If for any reason you don't want to do this, then you must rebase your branch on official/master before pushing and offering up your next pull request. You should use rebase instead of merging from official/master, to avoid a proliferation of merge commits.

23

24

So the ideal loop is:

25

{{{1. git fetch official/master

26

2. git checkout official/master

27

3. git checkout -b newbranch

28

4. ... do your work in newbranch ...

29

5. git fetch official/master again (to see if it has updated while you were working)

30

5b. (if it has) git rebase official/master (and fix any conflicts)

31

6. git push origin newbranch

32

7. Go to github and open pull request

33

8. Go to trac and update any tickets

34

9. Wait for pull request to be merged (you can push more commits while waiting)