Git and Github

Branch structure

The branch structure of our project follows a simple structure:

• the main contains only the versions for the official releases
  • All commits in main are tagged with the version of the release
  • hotfix branches may be created from the commits of main in the rare case that old major versions need maintainance
• the dev branch is the contains the most up to date version of the sources
• many short lived feature/fix branches that branch (merge) from (to) dev

The following schema shows the idea of the structure

         
 unmerged-fix              *--*--* (work in progress)
                          /  
 merged-feat     *--*--*  |
                /       \/
 dev           *---------*
                \ v10.1   \ v10.2
 main          --*---------*
                  \
v10.1-hotfix       *

Typical workflow on Github

Note that this is a typical workflow, some steps may vary, skipped or done in another way

• Create an issue describing the feature, bug of refactoring to be worked on
• In the issue page in the right information bar, on the Development section click Create branch
  • The new branch will branch from dev as it is the default one
• Fetch the branch (git fetch) from Github to your local copy of the repo
  • Github proposes you how to do it in the previous step
• Switch to your branch (git switch branch-name), code and commit changes
• Upon finishing, push your commits to Github (git push on your branch)
• In Github create a pull request for your branch and request the review of at least one other member of the team
• Discuss possible changes and fixes, then push them
  • The discuss/fix/push cycle may be repeated many times
• Once the discussion is resolved the reviewer approves the PR and you merge the changes into dev

Variations

• The branch may be created beforehand and then associated to an issue
• Many issues may be closed with one MR
  • This is to encourage opportunistic fixes

Commit Guidelines

Commits should be as atomic as possible