We use the pull-request model, see GitHub's help on pull-request.
In brief, you will:
Most activity repositories can be found in our GitHub
A few activity repositories are somewhere else; read the
activity/activity.info file, check the metadata on the
store, or the Activity page on
wiki.sugarlabs.org, or our
deprecated gitorious instance.
For new activities, see Write your own Sugar desktop
activity, or Write your own Sugar web
activity, then make a new repository in your
GitHub account, put the source code in it, then ask the systems@
list to move it to the
Sugar repositories can be found in our GitHub
organization. Sugar desktop
environment repositories are:
We track issues in http://bugs.sugarlabs.org/ or in the GitHub Issues tab of activity repositories.
Each improvement to Sugar should start with an issue discussion, to build consensus and ensure that work isn't wasted.
Navigate to the sugar repository, press Fork button, then on your computer
git clone firstname.lastname@example.org:YOUR-NAME/sugar.git cd sugar git remote add upstream https://github.com/sugarlabs/sugar.git git fetch upstream
Create a branch per set of changes; e.g. to fix a problem or add a feature;
git checkout -b BRANCH-NAME
Your BRANCH-NAME can be anything, other than master. The scope is your forked repository. The branch name will be shown on pull-requests.
Change files, and commit. When writing a commit message;
Make one or more commits and push the branch to your repository;
git push origin BRANCH-NAME
Send a pull-request for your branch. Navigate to your repository page in GitHub, switch to the branch you made, and then press the Pull Request button.
When writing a pull-request message;
A review will happen in the pull-request, and a reviewer will either;
When they ask you for changes, you may have to change both files, commits or commit messages.
When squashing commits to different files, use interactive rebase.
git rebase -i master
After resolving any conflicts, push the changes to the same branch;
git push --force origin
Then respond on the pull-request.
When there have been upstream commits while your pull-request was open, you should rebase your pull-request;
git pull --rebase upstream
Then push the changes to the same branch;
git push --force origin
The pull-request will be updated.
When there have been upstream commits since your fork was made, you should bring these into your fork:
git checkout master git pull upstream git checkout BRANCH-NAME
We encourage testing before merging a pull-request.
So instead of merging directly with the "merge" button on GitHub, we may do a local merge, then test, then push.
The GitHub page for the pull-request will provide you the right commands to do the local merge, similar to the following.
Get the changes from that branch to a new local branch:
git checkout -b SOME-USER-topic1 master git pull https://github.com/SOME-USER/sugar.git topic1
Test! If everything is fine, merge:
git checkout master git rebase SOME-USER-topic1 git push origin master
Once your pull-request is merged, you should close any issue or ticket. GitHub issues named as "Fixes" in a commit message may be automatically closed.
Be sure to thank everyone who helped you out along the way.
Make a local clone of your GitHub repository, use
git commit --amend or the other advanced CLI features, then
git push back to GitHub.
Most likely you have cloned someone else's repository, and you should instead fork their repository, clone your own repository, make your changes, then push. See Getting error 403 while submitting PR and D. Joe's reply.