Git Workflow

Basics

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

These are some of the terms you'll need to know:

1. pull: fetch the most recent version of the code (after you cloned the repository).
2. git add: "stage" your changes for the commit.
3. commit: group together changes to make them final (see below).
4. push: send your changes on the Github repo (the origin).

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.

5. checkout: change working branch.
6. merge: add all the changes in a branch to another branch (can produce merge conflicts when the same file has been modified in different ways: you have to resolve them in order to merge).
7. pull request: ask for your branch to be merged with the original branch (it's better if you add some reviewers to check that everything's ok before merging).

Branching

In Boardcore there are two main branches:

• The master branch: is the main branch, everything's that here has been tested and it's working (or at least it should).
• The development 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.

⚠️ WARNING: You should NEVER commit directly to the master

To make changes to the software you should use:

• feature branches: are branched off from development and exist for a limited amount of time for developing a specific feature. When the feature is ready, the developer should open a Pull Request to merge the feature branch back to the developing branch.
• hotfix branches: 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 development 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, development, 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 be doing two separate commits.

What's Next

Now that you know how to work on this repository, you can read the Coding Guidelines.