As LavaLamp is growing larger, and more and more people are working on the same projects, I thought it would be useful to discuss the Git Workflow when multiple people are working on the same projects. I have experience working in larger teams, and I know how frustrating it could be if you encounter a merge conflict or your work is overwritten. Using the below Workflow should help.

Git Pull

A “git pull” should be your first step. You might not be in constant communication with your teammates so they can notify you of any changes. You might be working remotely. You may not even have touched the code yourself in months.

In any case, making sure you have the latest code now can save you many headaches down the line. You could run into merge conflicts otherwise.

Create your own Branch

Depending on the changes you have to make, it may be safer to create your own branch. Ideally, you’d want to base it off of the Develop/Staging branch as it would have the latest iteration of code, and when it comes time to deploy you could merge it directly into that branch for testing.

It’s also useful for testing purposes. (See below)

Pull Requests

When you create a Pull Request, you can assign/ask one of your teammates to review the code change you made. If you’ve created your own branch, they could just pull that specific branch and test your code change.

Merge into Develop

If you’ve created your own branch based off develop (or staging), and the testing of your Pull Request has passed, it’s time to merge your code back into the branch you based it on.

Once the code has been merged, you can deploy it to the testing environment for more testing.

Merge Conflicts

Merge conflicts happen when you and someone else work on the same file. They can occur for multiple reasons. You could be working on the same line number as someone else. Someone else could have pushed their changes to the file before you, so the file is no longer the same (this is where “git pull” comes in handy).

In any case, if you encounter one, it is your responsibility to fix the conflict. You can usually do this by adding your changes to the file while maintaining the conflicting changes. For example, if A and B are having a conflict with A and C, add C after A and B.

Are your Branches Synced?

This is the next question to ask after all the testing has been completed.

If they are…

Then it’s time to merge the Develop branch into Master, create a Pull Request, Test, Deploy then have the client test on the Production environment.

If they’re not…

They might not be synced because you have multiple new features on the develop branch that are still undergoing development or testing. In this case,  you have to create a hotfix branch.

In essence, you’re just restarting the cycle. You pull down your Master branch, create your own branch off of it, and make the change directly on your new branch. You create a Pull Request, have a teammate test it, and deploy directly to the Production environment once testing has passed.

Conclusion

I’ve used the above cycle in a fairly large team, and it has worked well. Hopefully it will work well for you and save you some headaches, as well.