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.
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 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.
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.:
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.