Changes between Version 6 and Version 7 of Policy/GitMaster


Ignore:
Timestamp:
09/14/11 16:58:19 (9 years ago)
Author:
magnate
Comment:

Removed references to staging branch

Legend:

Unmodified
Added
Removed
Modified

  • Policy/GitMaster

    v6 v7  
    1 = Using Git and Angband = 
     1= Using Git and Angband - a guide for the devteam = 
    22 
    33== Setting up == 
    44 
    5 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.  
     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/3.3-release and official/AngbandBase branches, as well as all the origin/ branches of your own github repo.  
    66 
    7 Make a local copy of the official/staging branch: 
     7Make a local copy of the official/master branch (we'll call it master2, because your local "master" branch is tracking your origin/master): 
    88{{{ 
    9 $ git checkout official/staging 
    10 $ git checkout -b staging 
     9$ git checkout official/master 
     10$ git checkout -b master2 
    1111}}} 
    1212 
    … …  
    1414{{{ 
    1515$ git fetch official 
    16 $ git checkout staging 
    17 $ git merge official/staging 
     16$ git checkout master2 
     17$ git merge official/master 
    1818}}} 
    1919 
    … …  
    23231. Branch from a stable commit (e.g. official/master) 
    24242. Develop on that branch and don't worry about keeping up 
    25 3. Merge to staging when you're done 
     253. When you're done, try to rebase your work on the latest master - if it doesn't work, don't worry, just back out 
     264. Merge back into master 
    2627 
    27 Avoid 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. 
     28Avoid 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 master after each one, rather than trying to merge master into your branch after each one. 
    2829 
    2930== Merging == 
    … …  
    3132When you're done with your feature branch (we'll call it `mybranch`) and you're ready to merge, do: 
    3233{{{ 
    33 $ git checkout staging 
    34 $ git pull official staging 
     34$ git checkout master2 
     35$ git pull official master 
    3536$ git merge --log -m "description of merge (e.g. Merge fizzix's vault refactor)" mybranch 
    3637}}} 
    … …  
    3839The `--log` parameter appends a list of changes in that branch, which is useful when browsing history.  The `-m` parameter just avoids the ugly (and often meaningless) default merge messages. 
    3940 
    40 You 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 
     41You may get merge conflicts, in which case, fix them and then commit.  Make sure your local master2 branch compiles, and when it does, push to the official master with 
    4142{{{ 
    42 $ git push official staging 
     43$ git push official master 
    4344}}} 
    4445 
    45 If 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. 
    46  
    47 == Pushing to master == 
    48  
    49 Every 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): 
    50 {{{ 
    51 $ git checkout staging 
    52 $ git push official staging:master 
    53 }}} 
    54  
    55 The dev team is now big enough that we should resist propagating our own staged changes except in emergencies. 
     46If the official master 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 master2 branch should always be strictly ahead of the official master branch. 
    5647 
    5748N.B. When responding to a pull request, please check that the changes adhere to the CodingGuidelines before committing to master.