A Guide to Branching

How to Branch

For this project, we will be strictly enforcing branching using our version control system, Git.

What is branching?

Branching is a way to contain your current work in a separate “environment” so that anything you code will not directly affect someone else’s work. This way, many different people can work concurrently on different features without potentially breaking each other’s code.

How will branching work for Sistema?

The developers will not be directly committing to the master branch. The master branch will only contain the version of the application most stable and ready for deployment.

Instead, everyone will be developing on feature branches that stem off of the master (main) branch. All pull requests (PRs) will be made to merge feature/local branches into the main branch.

How do I branch?

It’s important to know which branch you’re branching off of. You can check which branch you’re on by doing:

$ git branch
  * main
  feature/SIS-22333
  feature/SIS-33344

From the example above, you are currently on the master branch. All feature branches are to be branched off from main, so let’s make a new branch.

$ git branch <your branch name here>

Now you’re all set to work!

How do I switch branches?

Before you switch branches, you must commit or git stash all of your uncommitted work. After that, you can run:

$ git checkout feature/SIS-33344

What are feature branches?

Feature branches are where you will be doing your work. They will be named off of the feature that you will be working on, which is indicated by your ticket number, such as feature/SIS-20334.

Once you’re done developing the feature, you may send the PR in the #team-sistema-prs Slack channel, and then create a PR and tag two devs to do a code review.

Once the code review passes, please tag Ramy or Emily in the Slack thread for that PR and we'll merge it.

What happens if I’m not done with my work, but someone else pushes new changes to the develop branch?

In order to keep your branch up-to-date to have a seamless merge into the develop branch, you have to periodically pull from main. Here’s the command to do it:

$ git pull origin main

You may encounter some code conflicts along the way. Here is what you should do in that situation: Look at where the code conflicts with your code. Chances are, your code will be the “older” version.

For simpler conflicts, you can merge it yourself. Here’s an example in python:

<Your Local Version>

def func(num):
    pass

<Remote Version>

def func(num):
    sum = num + num

    return sum

In this case, you can see that the only thing that changed was that a placeholder function body was replaced with actual functional code. This is a “simple” conflict, and you can merge it yourself.

For more advanced conflicts that may conflict with parts of code you’re currently working on, asking the other person to come on a quick call with you and doing pair programming to solve the conflict is the best way to go about it.

Lastly, please check that the new code does not break the WIP feature you’re working on. This includes if all buttons are working, if information is still being passed from page to page, and if things are rendering properly.

I’m not done with my feature, but can I push my branch to remote?

Yes, absolutely! Please do this often so we don’t have to ask you of your progress with your feature. You can mark your PR as a Draft PR so that everyone else will know it's a work-in-progress.