A Guide to Branching - uoftblueprint/the-period-purse GitHub Wiki

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 TPP?

TPP will be following a version of the model shown below.

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 Develop (dev) branch. All pull requests (PRs) will be made on the dev 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
  * master
  develop
  feature/TPP-22333
  feature/TPP-33344

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

$ git checkout develop
$ git branch
  master
  * develop
  feature/TPP-22333
  feature/TPP-33344

Now, we want to 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/TPP-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 JIRA ticket number, such as feature/TPP-20334.

Once you’re done developing the feature, you may proceed to demo it to Jing, our designer, and then create a PR and ask a senior dev to do a code review.

Once the code review passes, you can go ahead and merge it into the develop branch.

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 dev. Here’s the command to do it:

$ git pull origin develop

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.