Git Workflow

Workflow

• The model is very similar to ​the one used by the Invenio guys (only with slight changes);
  • Please, pay special attention to the sections S1, S4, W1, W2, W3, W4, W5, W6 and W7.
• The access to the git repo is granted by the 'gatekeepers' - they're the only ones who can push code into it;
  • As of now, they're Jose and Pedro;

Just to remark some hot topics:

• Things you should do:
  • before creating a branch, pull all the modifications from the origin;
  • create topic branches for your developments and please name them sensibly (use dash rather than underscore);
  • rebase before pushing the branch into your public repo, but never again rebase that branch (unless you don't care that references will change and no-one will be able to pull from it);
  • push to your public repo, just when you have finished and tested the feature you have developed;

• Things you should never do:
  • do not work on the master branch, create always a new branch for your developments;
  • do not rebase or squash on your public repo;
  • do not rebase a branch in your private repo when that branch was already pushed into your public;

Naming conventions (branches)

• refactor-* for feature/code refactorings;
• fix-* for fixes;
• new-* for new features;
• exp-* for experimental developments;
• prov-* for provisional branches that will be deleted;
• v*-series for releases (i.e. v0.97-series);

Things you should know

• Git takes care of trailing white spaces for you. Inside your .git/hooks Just rename pre-commit.sample to pre-commit (make sure it has execution privileges too) - git will now remove them for you;

• You can close a Trac ticket from a commit. Just add fixes #<ticket_number> somewhere in your commit message. I usually do it as part of a list:

[FIXED] Some silly bug
 - changed something in order to fix the silly bug;
 - deleted some useless code;
 - fixes #42

Example: #14

Check the ​GitPlugin trac-hacks page for more on syntax (check the post-receive hook's source code).