Main branch
You can think about the main branch as a snapshot of your application that at any moment can be used for:
- deployment to production (which often occurs automatically) – you do not want to deploy broken code by accident.
- developing new features with multiple collaborators – your teammates need a stable version of your project to start implementing changes.
Therefore the main branch should always be stable code that actually works and can be safely used. Any changes required in the application should be introduced in feature branches and approved before merging them to the main branch.
NOTE: The main branch is a rather new name. Previously it was called the master branch. GitHub has changed it for good reasons, but you can still see some references to the master in many articles. Do not let that confuse you.
Feature branches
Before you start working on a new feature, you should create a new feature branch that is based on the main branch. You will use this branch for all your work. In order to get a deeper understanding of feature branches, watch this video about creating new branches
Remember that your branch name should be descriptive (e.g.: refactor-authentication, user-content-cache-key, make-retina-avatars), so that others can see what is being worked on.
Opening pull requests
Once you start working on any project, initialize its main branch. Then, add changes in a feature branch(es). You will need to create a pull request to compare your feature branch with the main branch and submit the link to that pull request via your Dashboard. After you submit the link to your pull request you will get a code review from one of our code reviewers.
You should not merge your pull requests to the main branch of your project without a code review that approves your changes.
Watch this 4 min long video with a simple example of GitHub flow and opening a pull request.