Changes between Version 10 and Version 11 of GitUsage


Ignore:
Timestamp:
09/14/11 16:32:04 (6 years ago)
Author:
magnate
Comment:

Removed references to staging branch

Legend:

Unmodified
Added
Removed
Modified
  • GitUsage

    v10 v11  
    33To create a local copy of the official angband repository, use `git clone git://github.com/angband/angband.git`. But if you want to participate in development, it is best not to do this straight away. Instead, get an account at http://github.com, go to the official angband/angband repository and click Fork. This will create a new repository called git://github.com/yourlogin/angband. This is the one you should clone locally using `git clone git://github.com/yourlogin/angband.git`. 
    44 
    5 This will create a local repository with four branches. Use `git branch -a` to see them: 
     5This will create a local repository with several branches. Use `git branch -a` to see them: 
    66  * master 
    77  * origin/master 
    8   * origin/staging 
     8  * origin/AngbandBase 
    99  * origin/integration 
     10  * origin/3.3-release 
    1011 
    1112Do NOT do your work in your master branch: this is asking for trouble. Create a new branch using `git checkout -b newbranch`, and do your work there. Use `git commit -a` to commit your changes to your new branch and then autogen/configure/make to test them.  
     
    2728{{{ 
    2829To git@github.com:angband/angband.git 
    29  ! [rejected]        staging -> staging (non-fast-forward) 
     30 ! [rejected]        master -> master (non-fast-forward) 
    3031error: failed to push some refs to 'git@github.com:angband/angband.git' 
    3132To prevent you from losing history, non-fast-forward updates were rejected 
     
    5051Don't be afraid to create and delete lots of branches. They're totally expendable, and a new branch is a fresh start. 
    5152 
    52 Always update your local copy of the official repository (git fetch official) before pushing your work. If possible, use "git rebase official/staging" to ensure that your changes are on top of the very latest commits from the staging branch - that will make them easier to merge, and is much neater than merging official branches into your branches and having the devteam merge them back again. If you are nervous about trying rebase on a branch with lots of your hard work in it, create a new copy of that branch first - so if the rebase goes horribly wrong, your original branch is untouched. 
     53Always update your local copy of the official repository (git fetch official) before pushing your work. If possible, use "git rebase official/master" to ensure that your changes are on top of the very latest commits from the official repo - that will make them easier to merge, and is much neater than merging official branches into your branches and having the devteam merge them back again. If you are nervous about trying rebase on a branch with lots of your hard work in it, create a new copy of that branch first - so if the rebase goes horribly wrong, your original branch is untouched. Do ''not'' use rebase if you have published your branch on github though, as this will mess up anyone who is tracking it. 
    5354 
    5455When submitting pull requests on github, please ensure that you choose only the commits relevant to this request - try and avoid choosing merge commits or commits which are part of another pull request.