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.0 \ v10.2.0
 main          --*---------*
                  \
v10.1.x-hotfix     *

Typical workflow on Github

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

Note 2: See the Common Git Commands

• 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 from Github to your local copy of the repo: git fetch
  • Github proposes you how to do it in the previous step
• Switch to your branch: git switch branch-name. Then 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, make new commits if necessary and push them
  • The discuss/fix/push cycle may be repeated many times
  • The discussion cycle must be short and effective, focusing on resolving the issue at hand
  • Create new issues if necessary for related problems arised in the discussion
• 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