Changes between Version 2 and Version 3 of Policy/GitMaster


Ignore:
Timestamp:
02/01/11 04:20:03 (8 years ago)
Author:
takkaria
Comment:

update with newer workflow info

Legend:

Unmodified
Added
Removed
Modified
  • Policy/GitMaster

    v2 v3  
    1 = Angband devteam policy = 
     1= Using Git and Angband = 
    22 
    3 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 git@github.com:angband/angband.git` (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.  
     3== Setting up == 
    44 
    5 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.  
     5Assuming 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 git@github.com:angband/angband.git` (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.  
    66 
    7 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.  
     7Make a local copy of the official/staging branch: `git checkout official/staging` followed by `git checkout -b staging`.  To keep this branch up-to-date, do `git fetch official` followed by `git checkout staging` and `git merge official/staging`.  You will want to do this whenever you want to commit to the remote repository. 
    88 
    9 Similarly, keep your local master up-to-date with the official master as well: `git checkout master` and `git merge official/master`.  
     9== Feature branches == 
    1010 
    11 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`. 
     11To work on a feature: 
     121. Branch from a stable commit (e.g. official/master) 
     132. Develop on that branch and don't worry about keeping up 
     143. Merge to staging when you're done 
    1215 
    13 Once this is done, send a pull request to the rest of team angband to ask somebody to test your latest changes in staging.  
     16Avoid continually merging in the latest changes from upstream, because it makes it a lot harder to follow the change history when it comes to merge, and you may end up fixing the same merge conflicts many times.  If you have a set of big changes to make, merge to staging after each one, rather than trying to merge staging into your branch after each one. 
    1417 
    15 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. 
     18== Merging == 
     19 
     20When you're done with your feature branch (we'll call it `mybranch`) and you're ready to merge, do: 
     21{{{ 
     22$ git checkout staging 
     23$ git pull official staging 
     24$ git merge --log -m "description of merge (e.g. Merge fizzix's vault refactor)" 
     25}}} 
     26 
     27The `--log` paramater appends a list of changes in that branch, which is useful when browsing history.  The `-m` paramater just avoids the ugly (and often meaningless) default merge messages. 
     28 
     29You may get merge conflicts, in which case, fix them and then commit.  Make sure your local staging branch compiles, and when it does, push to the official staging with 
     30{{{ 
     31$ git push official staging 
     32}}} 
     33 
     34If the official staging has changed since you checked out, you are unlucky and you should do the merge again or [http://book.git-scm.com/4_rebasing.html rebase].  This way, your local staging branch should always be strictly ahead of the official staging branch. 
     35 
     36== Pushing to master == 
     37 
     38Every now and again someone pushes from staging to master.  Ideally, this is after some amount of testing of the staging branch and ideally is not done by the person who pushed the changes to staging in the first place.  To propagate the changes (assuming your staging branch is up-to-date): 
     39{{{ 
     40$ git checkout staging 
     41$ git push official staging:master 
     42}}} 
     43 
     44The dev team is now big enough that we should resist propagating our own staged changes except in emergencies. 
    1645 
    1746N.B. When responding to a pull request, please check that the changes adhere to the CodingGuidelines before committing to master.