11
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 100:
Line 139: − Forking a repository is simple, just go to the repository page and click the fork icon and that is it! Now you can see the repository in the list of your own repositories.+ + + + + + + + Line 106:
Line 152: − + − + − + − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 122:
Line 204: − + − − When you fork a project in order to propose changes to the original repository, you can configure Git to pull changes from the original, or upstream, repository into the local clone of your fork. − − Navigate to your repository folder from the terminal and then type, − git remote -v − and press Enter. You'll now see the current configured remote repository for your fork. − − Next, Type − git remote add upstream − and then paste the URL of the main repository (from where you made your fork) and press Enter. It will look like `git remote add upstream https://github.com/Someone/something-anything.git` − To verify the new upstream repository you've specified for your fork, type + − git remote -v − again. You should see the URL for your fork as origin, and the URL for the original repository as upstream. − Now in order to sync with the upstream URL that you added above, you will have to fetch the branches and their respective commits from the upstream repository. Commits to master will be stored in a local branch, upstream/master. − − Check out your fork's local master branch. − git checkout master − − Merge the changes from upstream/master into your local master branch. This brings your fork's master branch into sync with the upstream repository, without losing your local changes. Line 242:
Line 306: + + + + + + + + + + + + + + + + + + + + Line 251:
Line 335: − + − In order to request the repository's owner to consider the changes that you made in your repository and include them in the main code, you will need to make a pull request. In order to do this, just open up your repository page, `https://github.com/yourUserName/RepoName`, now you will a line just above the contents saying something like `This branch is 1 commit ahead of walterbender:master.` and you will also thus be able to see a button to create a New Pull Request for the same, then you can review the changes made and the commits to be added in that request and also a message box for the message you would want others to read, describing the changes you made. Then you can proceed to successfully creating a pull request, which will then be reviewed by others. And you can discuss on the very same page regarding whatever needs to be done. And if all is perfect, your pull request will be merged into the main code!+
Activity Team/Git Tutorial (view source)
Revision as of 00:44, 6 December 2016
, 00:44, 6 December 2016no edit summary
<noinclude>{{TeamHeader|Activity Team}}</noinclude>
<noinclude>{{TeamHeader|Activity Team}}</noinclude>
== Contributing ==
We use the pull-request model, see [https://help.github.com/articles/about-pull-requests/ github's help on pull-request].
In short, you will:
* file an issue about what you plan to change
* do your changes in a new branch
* push your branch and submit a pull-request for it
* go through the review process until your pull-request is merged
* close your issue
== Activity Repositories ==
To request a new activity repo, email the http://lists.sugarlabs.org/listinfo/systems list with the name of the repo and the github usernames who should have access.
We recommend using the same process as below to develop your own Activities.
== Modifying Sugar ==
Before going through the details on how to submit changes, let's look at the useful tools we provide to assist contributors in the process of modifying Sugar.
If you are hacking on sugar-web, run the testsuit with the karma command inside a osbuild shell:
karma start sugar-web/test/karma.conf.js
We encourage writing new unit tests for new features.
After you do the changes, run:
check
It will run all the code checks and the unit tests making sure you won't break the build when your changes are pushed. If the checks doesn't succeed because of coding style, see the coding style guide [https://developer.sugarlabs.org/web-style.md.html for web] or [https://developer.sugarlabs.org/python-style.md.html for Python]. If a test doesn't pass either your code needs to be fixed or the test need to be adapted.
== Open an Issue ==
We track issues in http://bugs.sugarlabs.org
Generally, each improvement to Sugar should start with an issue discussion, to ensure that work to fix a bug isn't wasted.
== GitHub ==
== GitHub ==
Most commonly, forks are used to either propose changes to someone else's project or to use someone else's project as a starting point for your own idea.
Most commonly, forks are used to either propose changes to someone else's project or to use someone else's project as a starting point for your own idea.
You should fork the repository first. This step is needed only once. See [https://help.github.com/articles/fork-a-repo/ complete help in github]. Brief instructions follow using [https://github.com/sugarlabs/sugar/ sugar component] as example.
Navigate to the sugar repository, press Fork button, then
git clone https://github.com/YOUR-NAME/sugar.git
cd sugar
git remote add upstream https://github.com/sugarlabs/sugar.git
git fetch upstream
==== Propose changes to someone else's project ====
==== Propose changes to someone else's project ====
A great example of using forks to propose changes is for bug fixes. Rather than logging an issue for a bug you've found, you can:
A great example of using forks to propose changes is for bug fixes. Rather than logging an issue for a bug you've found, you can:
Fork the repository.
1. Fork the repository.
Make the fix.
Submit a pull request to the project owner.
2. Make the fix.
If the project owner likes your work, they might pull your fix into the original repository!
3. Submit a pull request to the project owner.
4. If the project owner likes your work, they might pull your fix into the original repository!
== Sending a pull-request ==
In order to request the repository's owner to consider the changes that you made in your repository and include them in the main code, you will need to make a pull request. In order to do this, just open up your repository page, `https://github.com/yourUserName/RepoName`, now you will a line just above the contents saying something like `This branch is 1 commit ahead of walterbender:master.` and you will also thus be able to see a button to create a New Pull Request for the same, then you can review the changes made and the commits to be added in that request and also a message box for the message you would want others to read, describing the changes you made. Then you can proceed to successfully creating a pull request, which will then be reviewed by others. And you can discuss on the very same page regarding whatever needs to be done. And if all is perfect, your pull request will be merged into the main code!
Create one branch per topic
git checkout -b topic1
Make one or more commits and push the branch
git push origin topic1
Submit a pull request for the branch. Navigate to your repository page in github, switch to the branch you made, and then press the Pull Request button.
After that, the review process will happen in the pull-request page on github. The process ends with one of this:
1. A reviewer merges your request.
2. A reviewer rejects your request providing reasons (and closes the request)
3. A reviewer requires changes (and closes the request)
In case they ask you for changes, make them using [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages interactive rebase]
git rebase -i master
Submit the changes to another remote branch
git push origin topic1:topic1-try2
Finally submit the new pull request through the github site as you did before.
Make sure to add "Fixes #1234" to the commit message, being #1234 the number of the issue ticket related to your changes. This way, the ticket will be closed automatically.
=== Create Local Repository (Clone) ===
=== Create Local Repository (Clone) ===
=== Keep your fork synced ===
=== Keep your fork synced ===
You might fork a project in order to propose changes to the upstream, or original, repository. In this case, it's good practice to regularly sync your fork with the upstream repository. To do this, you'll need to use Git on the command line.
You might fork a project in order to propose changes to the upstream, or original, repository. In this case, it's good practice to regularly sync your fork with the upstream repository.
Don't forget to pull in changes from the master repository that is 'upstream.' To pull in upstream changes:
git fetch upstream
git fetch upstream
git merge upstream/master
git merge upstream/master
You may do this for every set of changes you make.
You may do this for every set of changes you make.
=== Testing ===
We encourage testing before merging a pull-request.
So instead of merging directly with the "merge" button on github UI, we do a local merge, then test, then push.
See [https://help.github.com/articles/merging-a-pull-request/ github help on merging a pull-request]
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
=== Push Changes ===
=== Push Changes ===
You must do this for every set of changes you make, when you want to synchronise with other developers or prepare for a release.
You must do this for every set of changes you make, when you want to synchronise with other developers or prepare for a release.
=== Pull Request ===
=== Close Issue ===
Once your changes are merged, you should close your issue. Be sure to thank everyone who helped you out along the way :)
== Other Notes ==
== Other Notes ==