GitHub 101: Branching model and workflows

If you are new to Git/GitHub make sure you read our Introduction to GitHub blog post here. Now we are going to dive deeper into the branching model & workflows.

Branching model

Almost every project has main branches and supporting branches:

Main branches:

• main
• develop

Supporting branches:

• features
• fix
• release
• hotfix

Let’s look at the main branches first:

• main branch is used as a production branch where it should always be working and not broken
• develop branch, is used as a development branch where the supporting features (features, fix, and release) are checked out from

How can developers manage features in a team?

Imagine this scenario: We have three developers and their names are dev-1, dev-2, and dev-3. This team is planning to build React components, Button, Header, and Footer. So what would they be doing? How can they make sure the collaboration goes as smoothly as possible?

First of all, they need to work on different branches, and that's where the supporting branches come in handy.

As we already know we have two main branches; main and develop and develop is for development so it means that they need to create a supporting branch from develop.

The 3 developers will make sure that they are in the develop branch and then they would start creating feature branches as such:

‍

// dev-1 would create his own branch to build the button component $ git checkout -b feature/button-component

‍

// dev-2 would create his own branch to build the header component $ git checkout -b feature/header-component

‍

// dev-3 would create his own branch to build the footer component $ git checkout -b feature/footer-component

‍

At this moment the 3 developers have 3 different branches, where they work independently and without worrying about what the others are doing.

What's next?

When the developers finish their work, they would open a PR (Pull Request) against the develop branch, which means that they are asking for their work to be merged into develop.

What does this mean?

1. Your feature is complete from your perspective
2. Your teammates will go thru your code and review it
3. Then merge your code if they approve it
4. At this point, your feature is now part of the develop branch and other developers can start using your feature component

As a developer who builds features or implements fixes, you will have to repeat this flow over and over again.

Workflows

Imagine this scenario: you would like to clone an open source GitHub repo so you could run it on your machine or contribute.

There are two ways to get a remote repo to your local machine:

1. Clone the repo
2. Fork then Clone

Let's have a look and then you decide what you would do 😄

Workflow 1 (Clone the repo):

When you clone a repo directly (Integrify in the screenshot below is the remote repo, and in our example, it would be the open-source repo that we would like to run on our machine or contribute to.) Integrify will be considered as the origin where the cloned repo on your machine is a local copy of a repository, not your own copy.

So if you create branches or other commands related to git, it will affect Integrify's repo.

‍

Workflow 2 (Fork then Clone):

What are the steps?

1. Fork Integrify repo (now Integrify's repo is considered upstream)
2. When you fork you will have an exact copy but it's now a new repo in your GitHub repository.
3. Clone it (this is now considered as the origin)
4. You can now pull the latest from upstream to stay up-to-date
5. You can push changes to your origin
6. And if you would like to propose your changes to the upstream repo you can easily open a PR against it

Now, did you notice the difference? Forking would create your own copy of a repository!

‍

Interested to learn more about Integrify Academy? Join us for our next Info Session to get more insights into what and how we teach, and learn more about our career support. Sign up for one of the upcoming Info Sessions here.

‍