Changes between Version 6 and Version 7 of Policy/GitMaster
- Timestamp:
- 09/14/11 16:58:19 (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Policy/GitMaster
v6 v7 1 = Using Git and Angband =1 = Using Git and Angband - a guide for the devteam = 2 2 3 3 == Setting up == 4 4 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/integrationbranches, as well as all the origin/ branches of your own github repo.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/3.3-release and official/AngbandBase branches, as well as all the origin/ branches of your own github repo. 6 6 7 Make a local copy of the official/ staging branch:7 Make a local copy of the official/master branch (we'll call it master2, because your local "master" branch is tracking your origin/master): 8 8 {{{ 9 $ git checkout official/ staging10 $ git checkout -b staging9 $ git checkout official/master 10 $ git checkout -b master2 11 11 }}} 12 12 … … 14 14 {{{ 15 15 $ git fetch official 16 $ git checkout staging17 $ git merge official/ staging16 $ git checkout master2 17 $ git merge official/master 18 18 }}} 19 19 … … 23 23 1. Branch from a stable commit (e.g. official/master) 24 24 2. Develop on that branch and don't worry about keeping up 25 3. Merge to staging when you're done 25 3. When you're done, try to rebase your work on the latest master - if it doesn't work, don't worry, just back out 26 4. Merge back into master 26 27 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 staginginto your branch after each one.28 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 master after each one, rather than trying to merge master into your branch after each one. 28 29 29 30 == Merging == … … 31 32 When you're done with your feature branch (we'll call it `mybranch`) and you're ready to merge, do: 32 33 {{{ 33 $ git checkout staging34 $ git pull official staging34 $ git checkout master2 35 $ git pull official master 35 36 $ git merge --log -m "description of merge (e.g. Merge fizzix's vault refactor)" mybranch 36 37 }}} … … 38 39 The `--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. 39 40 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 stagingwith41 You 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 41 42 {{{ 42 $ git push official staging43 $ git push official master 43 44 }}} 44 45 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. 46 If 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. 56 47 57 48 N.B. When responding to a pull request, please check that the changes adhere to the CodingGuidelines before committing to master.