If you have never used Git before, you need to do some setup first. Run the following commands so that Git knows your name and email.
Setup line endings preferences :
For Unix/Mac users :
For Windows users :
You can also define the following extras :
- master is the development branch of next release, at anytime. For example it's currently v2.8-SNAPSHOT, while v2.7 is still under testing. It can be considered as the "integration branch" when developers use their own Git repository.
- releases is the production branch. Commits are pushed in this branch only for releases. It contains also the release tags. It's similar of the master branch in the nvie model.
- release-xxx (for example release-2.7) prepares the next release. It's used during pre-releasing testing periods, usually during first RC and final release. Release branches are merged back into "releases" and "master" when releasing, so they can be deleted.
Commits must relate to a JIRA issue. Convention for messages inspired by http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html :
- The first line must be short (50 chars or less) and auto-descriptive in a format "<JIRA KEY> <DESCRIPTION>", for example "SONAR-1937 Code review"
- Write your commit message in the present tense: "Fix bug" and not "Fixed bug".
- The second line is blank.
- Next lines optionally define a short summary of changes (wrap them to about 72 chars or so).
It's recommended to use your own feature branches (sometimes called "topic branches") when fixing JIRA issues. It allows to on work on multiple isolated features.
The first time the Sonar repository must be forked into your own GitHub workspace. Simply log in GitHub, browse to Sonar reference repository and click on the "Fork" button. Then download sources on your box :
Create the branch when starting to work on a JIRA issue
The branch name is usually the JIRA key and a short auto-descriptive name, for example "SONAR-237_review" :
Code and test (or the inverse) and regularly update with changes committed into SonarSource codebase :
Switch between feature branches
To switch between feature branches, check that all your local files are committed into local repository (git status). If you don't want to commit them, you can move them when switching :
If you don't have any pending changes, then simply execute "git checkout <branch name>"
Push commits to personal GitHub repository
For example to backup your local branch or to benefit from continuous integration :
Push commits to SonarSource repository
Get your master up to date with SonarSource repo
Rebase your branch so that we have a linear history
Merge your branch into your master
And finally push your linear-history master to SonarSource repo and delete the feature branch
Edit commit during interactive rebasing (see http://book.git-scm.com/4_interactive_rebasing.html)