Release strategy - GIT & TCS

Please see SvnGit for git description.

We will keep the current model - the master code is pulled into LBTO repository from personal repositories and will have to be confirmed.

Conventions

We assume yours GitHub username is gituser - this needs to be replaced with your correct username.

To verify your configuration, compare the following with your\x92s output of \x93git remote -v show\x94:

%CODE{ lang="bash" }% [gituser@gituser-dev tcs]$ git remote -v show origin git@github.com:LBTO/tcs.git (fetch) origin git@github.com:LBTO/tcs.git (push) %ENDCODE%

YYYY refers to the current year, MM and DD to current month and day (as 0 prefixed 2 digit numbers).

Personal development

Please develop your code either on an IT branch, named ITxxxx (where xxxx stands for IT number), or feature branch, named ??FB-TBD??. To create an IT branch, decide if you want to develop a bug-fix (no changes to shared memory), or you need change to shared memory or you development is supposed to last longer. For bug fixes not requiring change to reflective memory, branch from the last release branch (2018A is assumed in the following text, and IT8000 as the name of the branch):

%CODE{ lang="bash" }% # clone TCS Git repository git clone git@github.com:LBTO/tcs.git cd tcs # Change branch to release branch git checkout 2018A

# create your new branch git checkout -b IT8000 %ENDCODE%

When developing your code, you are encouraged to make frequent commits - after you achieved a milestone, or have code which partly works or fix the bug. To do commit, do:

%CODE{ lang="bash" }% # add files for commit git add TestClass.cpp

# commits changes git commit . %ENDCODE%

Only if you want others to see your progress, or you fear your changes might get lost (remember, when you commit, you commit only to the machine you are developing the software), push changes back to GitHub:

%CODE{ lang="bash" }% # push local changes git push %ENDCODE%

You can periodically rebase changes from parent branch, to stay in sync with the branch:

%CODE{ lang="bash" }% # Rebase from 2018A branch git rebase 2018A %ENDCODE%

This also allows you to change target, e.g. if you are late and your changes will go to 2018B, just rebase to 2018B:

%CODE{ lang="bash" }% # Rebase from 2018B branch git rebase 2018B %ENDCODE%

With changes done, merge back to the original branch. First, make sure all your changes are on GitHub:

%CODE{ lang="bash" }% # Commit everything git commit -a %ENDCODE%

You should use "Pull request" feature on your GitHub to propose a merge. Navigate to your branch from https://github.com/LBTO/tcs.git, and hit "Pull request" button. Once pull request is approved, 2018A release can be checked from GitHub, and build on tcs-test machine:

%CODE{ lang="bash" }% ssh tcs@tcs-test cd tcs/2018A git pull %ENDCODE%

You will see \x93Pull request\x94 on top of the code tree. Push that to create a new pull request. That will be accepted/rejected/commented on by a review, and if once accepted, merged to the release or master branch.

Release

Once a while, a new release will be made. First release code (from LBTO master repository) will be built and tested on the test machine, then a release branch will be created in LBTO git. Release branch will be named after release - e.g. *YYYY*A, *YYYY*B etc.. Tag with release name will be created (to allow for any changes on release branch discovered before release branch is used on the mountain or when the release branch is first executed on the mountain).

Patch merge

Release branches will be merged back to master branch before a new release is created. Shall we continue patching old release before finally roll the new one, merges will be made first to master and the new release branch will be rebased to master.

Patch release

After the patch is successfully built on the test machine, it is tagged in release branch with YYYYMMDD, describing suffix that is used on the mountain.

Development/release as a graph

The following graph depicts development sequence:

2018A release branch was created. IT8000 branch is created from the master (wrongly assuming its priority), and two commits are made:

The above is the result of

%CODE{ lang="bash" }% git checkout master git checkout -b IT8000 # another user pushes changes to master git commit -a && git push git commit -a && git push %ENDCODE%

Then the priority of IT8000 changed, and it is scheduled to be included in 2018A. So rebase is made (while on IT8000 branch):

This is achieved by rebasing command:

%CODE{ lang="bash" }% # we are on IT8000 branch git rebase 2018A

# push to GitHub git push %ENDCODE%

Pull request is made from IT8000. By approving the pull request, IT8000 is back merged into 2018A:

Lastly, 20180604 tag is created (so we know the code which was used to build a mountain binary):

Then, by creating and approving pull request from 2018A into master, master is updated to include changes in 2018A (and hence IT8000):

Reverting changes (if some patch turned out to be not worth the progress) can be best done by reverting them (or - if not pushed, it is matter of a few branch and reset commands). Getting the source code for tagged version is done simply by checking out the given tag.