Project merging and branching within a team

Developing can be one of the funnest fields to get into because a huge premise of this discipline lies in creativity and creation. If you find yourself in a group of developers working on the same repo for a project, then here are some general guidelines that may help you prevent conflicts and bugs. Specifically we’ll talk about branching and merging. How this may be setup and what sort of benefits or drawbacks different styles carry.

Branches

After creating your initial project on whichever framework you are using (react, vue, rails, etc) and you set up the initial structure (file system, empty components, gems/packages/dependencies, seed data, etc) you should always work on your separate branch. Never work on the master because not only do you finalize the repo everyone sees and pulls from, but it makes it much harder to debug or sift through the code to find something specific you may end up looking for.

git checkout -b BRANCH_NAME

This makes a new branch and switches you automatically to that branch. Make sure to commit and push what you currently have (if you already aren’t up-to-date with the master branch) before doing this.

git checkout BRANCH_NAME

This simply switches you to an existing branch with that same name. Again, make sure you are up-to-date with the master branch OR you’ve committed and pushed the current branch’s content before switching over.

Merges

Typically, in a team project, you’ll have a game plan of how you want to divide the work or even how you want to work on certain tasks in pairs or as a whole a group. One example might be having a list of tasks divided by components or files so that only each file is ever worked on by a single person at a time. Sometimes a task is more complex that demands two or more people to work on a single task, page, or file at the same time.

Merging in the former instance is pretty straightforward. Simply push your changes whenever you change/add/delete a method or piece of code of a reasonable size. Then have the team lead look over the merge and approve it or ask for different changes.

The latter case is a little more complex because it depends on the team dynamic. Does the team leader simply have the most ‘say’ and therefore handles the merges by him/herself? Or maybe you want to include everyone who worked on that file/page to be present in the merge to resolve conflicts together so that you stay on the same page? There are pros and cons to either option that either save, keeps everyone informed, or other factors such as task/project progress.

Simply be settling on a system for these two categories, you will prevent many bugs and merge conflicts. Remember to keep everyone on the same page from the beginning and you will save yourself many headaches and keep a team well oiled and functioning.