Symfony 2 is hosted at a public GitHub repository: http://github.com/symfony/symfony
Basic information about working with Git can be found in the book Pro Git.
After installing Git, make sure Git knows your username and your email address:
$ git config --global user.name "Fabien Potencier"
$ git config --global user.email "foo@gmail.com"
You will probably also want to enable colorization in the shell:
$ git config --global color.diff auto
$ git config --global color.status auto
$ git config --global color.branch auto
$ git config --global color.interactive auto
Each developer works in his own public fork of the Symfony 2 repository. Developers should not work on their "master" branch, but on several feature branches named after the feature developed in them. These branches should all be based off the symfony/master branch.
First of all, make sure the symfony remote is available under the name symfony:
$ git remote add symfony git://github.com/symfony/symfony.git
Then you can create a new branch:
$ git checkout symfony/master
$ git checkout -b my-branch-name
Some branch name examples:
- doctrine-bundle describes the branch where the DoctrineBundle is being worked on
- ticket101 describes the branch fixing ticket #101
- routing-performance describes a branch where the routing performance is being worked on
When the development on a branch is finished, it should be rebased on the symfony master branch:
$ git rebase symfony/master
You can also squash all the commits of your branch if you want them to appear as a single commit in the Symfony 2 timeline:
$ git rebase -i symfony/master
In the appearing editor you have to replace every occurence of "pick" with "squash" (or short "s"). All these commits will then be squashed into the first of them. You can read more about squashing in the ProGit book.
NOTE If your branch is already published, don't rebase it, but merge the master into your branch instead:
$ git merge symfony/master
Finally, you can push your work to the server:
$ git push origin my-branch-name
Once the branch is published, a pull request for this branch should be sent to fabpot, who can then integrate it into the Symfony 2 trunk.
Before you commit, make sure you don't commit any whitespace errors. The following command lists all possible whitespace errors:
$ git diff --check
Next, try to make each commit a logically separate changeset. If you can, try to make your changes digestible — don’t code for a whole weekend on five different issues and then submit them all as one massive commit on Monday. This approach makes it easier to pull out or revert one of the changesets if you need to later.
Use imperative present tense to formulate your messages. In other words, use commands. Instead of "I added tests for" or "Adding tests for," use "Add tests for."
The following template should be used for commit messages (originally written by Tim Pope at tpope.net):
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
- Use a hanging indent