Originally published on Dev.to.
In a previous post, we talked about the process of submitting changes to a remote Git repository. We've seen that this process is done in three steps: 1) stage. 2) commit. 3) push.
In a small project with a solo contributor, it's not uncommon that these changes are pushed directly into master. But when multiple developers need to work in the same Git repository, it is important to define a process that leverages parallel collaboration. That's when branches become essential.
Not all trees are the same, but they all start small. In a typical Git repository, code grows as a tree. Features are implemented in development branches that are eventually merged into a master branch.
Whenever working on a team, whether if it's in an open source project or a corporate setting, it's always a good practice to create a new branch (usually based on master) and start from there.
Once you're finished with your changes, you can then push your branch to the remote repository and create a new pull request. A pull request is a formal request for merging your branch into master.
Although it is possible to push and merge a branch directly into "master", creating a pull request is usually the way to go when suggesting changes in a codebase.
Opening a pull request creates an opportunity for code review and actionable feedback; that's why it became a standard procedure for collaborating in most open source projects.
For a more in-depth understanding of Git branches, please check these docs or have a look at this quick reference guide.
Any Git topic you'd like to understand better? Leave your suggestion for my next comic in the comments :)