Contributing to MMC with git¶
MMC source code is hosted on github: https://github.com/mandriva-management-console/mmc
- Setup an account on github and fork https://github.com/mandriva-management-console/mmc.
Then checkout your fork:git clone firstname.lastname@example.org:<USER>/mmc.git
- Add a remote on mandriva-management-console/mmc
git remote add mmc email@example.com:mandriva-management-console/mmc.git git remote update
- Create a local branch that is tracking the main repository
git branch master-mmc --track mmc/master
- Change the default behavior of git push (if no ref is specified, use the tracked branch by default)
git config --global push.default tracking
Using pull requests¶
We use github pull requests to review fixes and new features.
For each bugfix or new feature you will propose a pull request which can be merge directly in the MMC repository trough the github interface.
This means that you need to create and publish a branch for every fix or feature then ask a pull of these branches. Thanks to git, this is very easy.
The pull request commits must be clean and atomic.
Fixing a bug or developping a new feature in master¶
- Update the master-mmc branch to make sure we are working with an up-to-date installation.
git checkout master-mmc git pull
- Create a local branch based on master-mmc
git checkout -b fix-blah-blah (or feature-blah-blah)
- Fix the bug with one or two commits (each commit must be atomic)
- Publish the branch to your github account
- Test your fix or feature ! (others can also test it by merging your branch since its public now)
- If everything is fine, in the github interface, select the fix-blah-blah (or feature-blah-blah) branch and click on pull request.
Github will try to create a pull request on the master branch by default
In the pull request you can explain what your commit is fixing and how to reproduce the bug if needed.r
You should type in the commit title the name of the module that is concerned by the commit. A commit usually fix or add a feature in a specific module (inventory, samba, etc...). If the commit target is not a single module you can use the project name (pulse2, core, mds).
<module|project>: <title> (70 chars max) <blank line> <detailed description>
If the commit is releated to an reported issue on http://projects.mandriva.org reference the issue number in the commit title or the commit body like this:
Will close the issue #1000 and make a relation between the commit and the issue in Redmine.
Will just make a relation between the commit and the issue. The issue state won’t be changed.
Commit directly in master¶
If you have the rights to commit to the main repository and you are sure of your fix, you might want to commit directly in the main repo directly instead of creating a pull request.
Use the following procedure to keep a clean history on the main branch (ie: no merge commits)
- Always create a branch for working on your fix
git checkout master-mmc git pull git checkout -b fix-foo
- Fix what you want to fix, test etc. When ready go to 3.
- Update master-mmc to get latests commits
git checkout master-mmc git pull
- Rebase your branch on top of master-mmc
git checkout fix-foo git rebase master-mmc
This will apply all the commits you have made in fix-foo on top of the latest master-mmc history
- Then merge your branch on master-mmc and push the changes to the main repository
git checkout master-mmc git merge fix-foo git push
Since all commits in fix-foo are on top of the master-mmc commits thanks to rebase, the merge will be done in fast forward mode and there will be no merge commit.