Changes between Version 1 and Version 2 of GitUsage/PullRequest


Ignore:
Timestamp:
12/24/11 05:33:15 (7 years ago)
Author:
magnate
Comment:

Added notes re v4 and rebase -i

Legend:

Unmodified
Added
Removed
Modified
  • GitUsage/PullRequest

    v1 v2  
    11= Offering your contribution to Angband = 
    22 
    3 When you've fixed a bug or implemented a new feature, please let us know. The preferred way to do this is to submit a pull request on github. To do this, you will need to have a github account and a repository "forked" from the offical angband repository, as described on the GitUsage page. We will call the repository "yourfork" and the branch with the bugfix or new feature "yourbranch". 
     3When you've fixed a bug or implemented a new feature, please let us know. The preferred way to do this is to submit a pull request on github. To do this, you will need to have a github account and a repository "forked" from the offical angband repository, as described on the GitUsage page. We will call the repository "yourfork" and the branch with the bugfix or new feature "yourbranch". We assume that you have called your remote of the official repo "official", but if you are offering a contribution to v4 rather than V, you have probably called it something sensible like "v4". 
    44 
    5 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.  
     51. 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. 
    66 
    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.) 
     7N.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. 
    88 
    992. 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.