Skip to content

CTA Git Workflow

Git Configuration

Git should be configured to use your CERN email and username using the following commands:

git config --global user.email "<YOUR CERN EMAIL>"
git config --global user.name "<YOUR CERN USERNAME>"

Issues

  • Any development work should have an associated issue on CTA GitLab. These issues should be labeled appropriately to make filtering easy.
  • After creating the issue in Gitlab, you can click on the arrow next to Create merge request to create the feature branch (and, optionaly, to create merge request for the same branch).
  • The following workflow labels should be used used, on every issue, to mark the development stage:
label description
no workflow label Issues that have not been accepted yet. Also, some issues are allowed not to have a workflow label, such as the release issues.
Workflow: Accepted Task has been accepted as "must be done" but has not yet been assigned.
Workflow: Assigned Task has been assigned to a developer, but work has not started yet.
Workflow: In Progress Task is assigned and is actively being worked on.
If work has been stopped for move than 2 weeks, more task back to Assigned or to Blocked.
Workflow: Blocked Task is unable to progress, blocked by another issue or pending action by an external stakeholder.
Workflow: Done Development work has been completed, awaiting review and testing before the ticket can be closed.
In general, it indicates that there is no more work to do, but the issue is not ready to be closed
  • Assign each issue to a milestone, once it is decided which release version will contain it.
  • Developers should regularly review their open tickets to ensure that the Workflow tag accurately reflects the state of the issue, and that the issue is closed after it has been deployed in production.

Pushing changes

  • When work on an issue is finished, ReleaseNotes.md should be updated with a reference to the issue in the Feature or Bug Fix subsection of the next Release section.
  • When merging the changes back into main, the feature branch may need to be rebased on top of main (git rebase main). The changes should then be retested, and any conflicts resolved (see git rebase documentation).
  • Where the branch has diverged significantly from master, it may be advisable to do the rebase in a new branch (e.g. when rebasing branch 1020-restore-deleted-files-in-eos, create from it branch rb_1020-restore-deleted-files-in-eos, setup to track the same remote branch, and perform the rebase there).
  • If needed, push the rebased feature branch with git push --force. No pushing is allowed directly to main.
  • Mark the issue as Workflow: Done.

Review and merge to main

The branch main is protected. Therefore, it's not possible to directly push new commits (as expected).

The only way to merge the changes is with a Merge request (MR):

Before a feature branch is merged into the main branch, it should be reviewed and approved by one other member of the development team. The developer who created the Merge Request (MR) should:

  • Review the MR title. Ususally, the title will become the commit comment on main.
  • Fill the description:
  • Add a short summary of the MR.
  • Clarify if the MR requires any tests on preproduction, before deploying to prod:
  • [Important] Provide a link to the corresponding issue. No code changes should be merged without a corresponding issue!
  • Assign a reviewer:
  • Usually, the reviewer is simply the next name on a "round robin" list of CTA developers, so code reviews are spread evenly around the team.
  • The developer can choose a specific reviewer if they want, for example because they want the opinion of someone with a particular expertise. In the case of trivial changes (for example, minor updates to ReleaseNotes.md), the developer can approve their own changes.

Afterwards, the reviewer should:

  • Confirm that the MR description has been properly filled.
  • Look at the code changes, in a timely way, and make comments.
  • The developer should resolve any issues raised by the reviewer.
  • When all issues raised by the reviewer have been addressed, the reviewer should approve the MR.

When the MR has been approved, the developer can merge the branch to main. They should squash commits when merging, so that only a single commit is merged.

Squasing Intermediate Changes

Squashing commits can also be done on the git command line. For example, during the fix of issue cta/#1028, I made two commits in the feature branch:

[cta@ctadevmiguel CTA]$ git log --pretty=format:'%h : %s' --graph > log.log
[cta@ctadevmiguel CTA]$ head -2 log.log
* 8089249 : Update ReleaseNotes.md
* 342b9c1 : Do not remove tape if there is a repack ungoing (#1028)

However, ideally these two commits would appear as only one commit in the master branch. To do this, I run the command git rebase -i HEAD~2, which opens a text editor with the following file:

pick 342b9c1 Do not remove tape if there is a repack ungoing (#1028)
pick 8089249 Update ReleaseNotes.md

# Rebase 01b88b4..8089249 onto 01b88b4
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#

I then fixup all but the top commit, save the file and exit the text editor:

pick 342b9c1 Do not remove tape if there is a repack ungoing (#1028)
fixup 8089249 Update ReleaseNotes.md

# Rebase 01b88b4..8089249 onto 01b88b4
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#

Both changes are now contained in the same commit: 

[cta@ctadevmiguel CTA]$ git log --pretty=format:'%h : %s' --graph > log.log
[cta@ctadevmiguel CTA]$ head -2 log.log
* 908a96c : Do not remove tape if there is a repack ungoing (#1028)
* 01b88b4 : Fix segmentatin fault when list repacks with a tape that has been deleted (#1029)