Version 2 (modified by magnate, 9 years ago) (diff)

added note about coding guidelines when actioning pull requests

Angband devteam policy

If you are part of "team angband" on github, please read this carefully before making any changes to the official angband/angband repo. Assuming your local repo has as its "origin" your own github repo, you'll need to add a new remote to track the official one: git remote add official (this url assumes you are using ssh access and have configured your local ssh config accordingly). After a git fetch official you will then see the official/master, official/staging and official/integration branches, as well as all the origin/ branches of your own github repo.

Ignore the official/integration branch - this is used by github to action things from the "Fork queue", so we should not confuse those activities with our manual commits.

Make a local copy of the official/staging branch: git checkout official/staging followed by git checkout -b staging. Keep this branch up-to-date: every time you see that the official repo has been updated, do git fetch official followed by git checkout staging and then git merge official/master. This will ensure that your local staging branch is in sync with the official master.

Similarly, keep your local master up-to-date with the official master as well: git checkout master and git merge official/master.

If you are ready to push a tested set of your changes to the official repo (let's say you're working in "mybranch" locally), first push them to staging by using git checkout staging followed by git merge mybranch. This will bring the changes from mybranch into your local copy of staging. Depending on when you last merged official changes into mybranch, you may wish to compile and test again in staging. When you're happy that nothing is broken, push from your local staging branch into the offical repo's staging branch with git push official staging.

Once this is done, send a pull request to the rest of team angband to ask somebody to test your latest changes in staging.

If you are the one to action a pull request and are satisfied that these changes work, you can then propagate them to the official master: git checkout master, git merge staging and git push official master. The dev team is now big enough that we should resist propagating our own staged changes except in emergencies.

N.B. When responding to a pull request, please check that the changes adhere to the CodingGuidelines before committing to master.