My First Pull Request in Github

This post is mainly in the interest of new user in the usage of Git in a business context.

At my job, about 6 months ago, we did want to use MongoDB instead of MySQL for new feature. I did a small evaluation of all the php client for mongo that have been develop and listed on their site. We finally go with our custom solution (I will not explain here why) but Mandango did come first in the ORM comparison we’ve made. We are now going to use Symfony2 for the new phase of development of our platform (our platform is currently base on Symfony1) and at the same time I check the evolution of Mandango. I did find that they made a Bundle for Symfony2 so I tried it (I’m new at Symfony2 and Git and Mandango). Since I’m always trying to customize everything for my needs I try to make a extension for Mandango in Symfony2 using the proper way. I found a bug in the Mangango Bundle and I would really want it to be fix so I can use it properly and also, knowing that it could take a while if I submit a patch to the administrator of the project, I want it asap for our project. So I did make a fork of the Bundle and commit my change to my own repo. After I did a Pull Request using those simple steps.

The first impression it’s that it gave me control of the code even in a Open Source environment for my professional context (this is due to forking not the Pull Request). A lot of time using Open Source project come with a down side of not being “Owner” of your code and at some point you need to do some adjustment to better fit your needs and Git/Github help a lot for that. And since we are mainly in a Open Source technology environment (LAMP, Varnish, Java, etc.) we want to contribute to the community but with the minimum impact on our daily more corporate need and the simple way that Pull Request are handle help a lot with that (not counting that in less than 6 hours the administrator of the bundle did accept my request).

So I finally fork also Symfony since I’m pretty sure I’ll cross the same kind of issue along the path of “redoing” our platform.

Source Control Commit Convention (SVN, GIT, etc.)

Witch ever source control software you are using (SVN, GIT or anything else) you must do “commit” to your repository. Normally people write a comment on commit (some don’t but they should), but event commit must have convention to be efficiant. So here are some rules that I’ve learn from other coworkers that I’ve push a bit farther:

  • One comment per line
  • One comment per change (a change can touch more than one file)
  • Separate you commit per feature
  • Commit for format/indentation should be done alone (hard to see a real code change in a full reformated file)

Here is a list of prefix that can be use for each of your comment line:

  • [+] new feature
  • [-] feature removed
  • [r] refactoring of existing code
  • [c] configuration change
  • [t] unit test (or any other kind of test
  • [d] documentation
  • [b] or [b#999] bug fix and add the bug number from your bugtracking tool (if any)
  • [t#999] the task number realated to your task tracking system (if any)
  • [i] any other information (like if the commit is a merge or for formattage purpose)

Of course you could have your own convention, but this one cover enough and is easy to remember.

This convention allow also to have script parsing your history log and be able to generate a release note about task implemented and bug fixed.

I’ll probably post something soon about a parser that we will do at my job to help QA team to know witch bug fix have been deploy on the server they are testing on.