Before merging your branch to master…
By: Software Sisterz
Tags: Tech, Git, Version Control, Jenkins, Github

When you have a pull request, there’s a number of steps you need to go through before merging it into master. Here’s a list of key steps I like to follow:

Merging branches

1. Ensure that your ticket passes the definition of done

Each tech team will have their own version of the definition of done. It usually involves sign off by the Product Owner and QA, and requires all acceptance criteria to have passed and tests made. It should also include code being peer reviewed for any mistakes or improvements to be found.

2. Check that you’ve added the necessary tests

Some code bases that you will work on will have a required coverage percentage for tests; this means that a certain amount of the code must be covered with testing. This can be unit tests, functional tests, integration tests, accessibility tests, nighty tests etc. You should also run them to make sure they will pass (particularly if they are not run in the pipeline of your feature branch).

3. Rebase your branch onto the latest master branch

If you have a master branch named “master”, and a feature branch named “feature-branch”, you can use the following git commands to rebase onto the latest master branch:

git checkout master

git pull master

git checkout feature-branch

then either:

git rebase master

or

git merge master

This makes sure that the feature branch is based off of the latest code released into master. There may be changes that affect your code and these can cause conflicts.

4. Resolve conflicts

Conflicts are where changes have been made in the master branch that are in the same place as you have made your changes. To resolve them, you can use the “resolve conflicts” tool that most IDEs have.

5. Check that your branch has a green pipeline

Each continuous integration/continuous delivery (CI/CD) pipeline has “checkboxes” that must be passed in order for a build to be successful. If one of these checkboxes has not been ticked, the branch should not be merged. A green pipeline is where all of these checkboxes have been ticked; there is no blockage in the pipe.

CI/CD Pipeline

6. Check that master has a green pipeline

If the master build has failed, you should not merge your branch. It makes it a lot harder to see where an error has occurred if you add in another change (particularly if yours causes an error too!).

7. Merge to master

Version control managers (such as GitHub) will integrate will the CI/CD pipeline that is assessing your branch’s build. Depending on your project settings and admin rights, you may be able to merge your branch without a green build or review, but this is not good practice to do so. On your branch you will have an option to either “squash merge to master” or just “merge to master”. Squashing the merge pulls all of your commits into one. It can make it cleaner to see what changes have been made to master.

8. Check that the master build is green after merging

You need to make sure that no changes you have made break the master branch; if this happens, it may cause a blocker for people merging in the future.

By Sarah Littlejohn