Changes between Version 2 and Version 3 of GitUsage

11/02/10 17:43:46 (10 years ago)

Moved devteam policy to separate page


  • GitUsage

    v2 v3  
    1717Keep your thinking clear: separate your work into different branches for different things. Create a branch called 'docs' if you want to work on some docs. Create one called 'stores' if you want to make changes to stores. Etc. There is no limit to the number of branches you can have, and you can use `git checkout branchname` to switch between branches at any time. (Ideally you should commit any changes in the current branch before switching branches, but git does not like people undoing things so read up on `git stash` if you need to switch branches and don't want to either commit or lose the current changes.) 
    19 = Angband devteam policy = 
    21 If you are part of "team angband" on github, please read this bit 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.  
    23 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.  
    25 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.  
    27 Similarly, keep your local master up-to-date with the official master as well: `git checkout master` and `git merge official/master`.  
    29 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`. 
    31 Once this is done, send a pull request to the rest of team angband to ask somebody to test your latest changes in staging.  
    33 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. 
     19If you are a member of "team angband" on github, please read [[Policy/GitMaster]] before making changes to the official angband repo.