Git Workflow

If you are completely new to Git, start from reading the Git Basics and A Simple Guide.

Basics

The main idea is to keep a step-by-step history of the code you write, so that you can easily keep track of what's going on and make bug-fixes if problems arise. Typical steps are:

1. git pull will fetch the most recent version of the code
2. Add, modify and delete files as you wish (changes will remain local)
3. When you're happy, git add what you modified to "stash" your changes for the commit
4. git commit the stashed changes (see below)
5. git push when you want to send your changes upstream

Branching

On a bigger scale, changes to the code can be made on different branches, which are different versions of the same project that can be merged into each other.

Ideally, branches should be divided in these categories:

• master branch: is the final one: everything's that here has been tested and it's all working.
• testing branch: is where development takes places: when a new feature is ready, it has to work with the rest of the code and then, only when everything's working, it can be merged with the master.
• feature branches: they exist for a limited amount of time for developing a specific feature. When the feature is ready, a Pull Request will be opened to merge the feature branch with the testing one, where it will be tested with all the other features that maybe were added in the meantime. If the Request is accepted, you can cancel the feature brench.
• hotfix branches: normally, when a bug is found on the master, a branch is created to find a fix to that bug. When the problem is solved, the branch will be merged with the master and the testing branch before being cancelled.

If you want to see a nice branching model example take a look at http://nvie.com/posts/a-successful-git-branching-model/.

Commits

Commits are the core of your team work, because they are the way in which you change the code.

For this reason, you have to think before you commit, and try to write good commit messages.

Some simple rules:

1. Write meaninful commit messages, with a short explanation on the top and a more specific one under:

[Topic] short message
*Blank line*
Long explanation

For example

[Wiki] Add Git Workflow page

The page contains the description of our workflow with git, in particular:
- Basics(pull, add, commit, push)
- Branching(master, testing, features and hotfixes)
- Commits(how to write commit messages and when to commit)

Do this, and everyone will love you - including yourself, when you'll read your code after a month from when you last wrote it..

2. One commit = One task. Not less, not more.

Group together in the same commit the changes that were made for the same task: if you're about to write something like

Fixed bug in Class.cpp and Added something else in another Class.cpp

Think twice! Probably you should do two separate commits.