Joining the Bluewave Labs has been a fantastic experience. Working with talented developers from around the world who each bring a wealth of experience and different points of view has been an inspiration. In this post I would like to explain how my team uses Git and Github to collaborate and build together. By following this workflow you’ll be able to build awesome projects together without stepping on your teammates’ toes, all the while reaping the benefits of robust version control.
As with any team, everyone is going to have a different level of collaboration that they are used to. Some developers are going to be used to working in large teams, some in small, tight knit teams, and some are going to be solo devs working in a team for the first time!
Building a project of any size benefits greatly from version control, and Git is the gold standard here. As our team started work on our project at Bluewave Labs it immediately became clear that everyone had some exposure to Git, though everyone had a slightly different workflow.
Git is like any other tool, there are many different ways to use it, and using it effectively often comes down to setting up standards and conventions. The tool itself doesn’t provide or enforce these standards and conventions, so it was up to us as a team to develop and enforce our own. If everyone uses the tool in their own way there is at best confusion, at worst conflict which reduces time spent productively working on the project.
Here are a couple of the more common ways that teams use Git.
No version control
The project has no version control at all. I’ve rarely seen this strategy even with solo developers. The benefits of having even basic version control are so great and the overhead costs so low that it makes no sense to have no version control.
The only time I ever see this is with very new developers who haven’t been exposed to Git or some other form of version control.
Centralized workflow
In this workflow, a single repository with a single Master branch is used. All developers commit directly to the repository’s master branch. This can be sufficient for solo developers or small teams that work closely together and are in constant communication.
The biggest issue that comes up with this workflow is conflict. If developer A and developer B are both working on the same piece of code, and A commits and pushes their changes before B, B will almost certainly now face a merge conflict when they try to commit and push their changes.
Feature branch workflow
This is a great workflow for anyone using Git, I highly recommend even solo developers follow this as a minimum. It adds a great degree of safety and flexibility to your projects and will help you work with teammates effectively.
In this strategy rather than working on Master directly a developer creates and checks out a new branch for each feature or fix that they want to work on. When they are done working they merge their branch back into the Master branch.
This approach helps to ensure that the Master branch is always in a functional state and that conflicts can be caught early.
The challenge with this approach is that developers must be proficient enough with Git to handle multiple branches, rebasing, and merging. Juggling many feature branches can be difficult and if not handled correctly can result in merge conflicts that are a headache to resolve.
It is my opinion that the benefits outweigh the costs, especially as team size increases and merge conflicts become more prevalent.
Github fork and branch workflow
The last workflow that I want to discuss is the fork and branch workflow. This is tied tightly to Github so I like to call it the “Github fork and branch workflow”. It combines the benefits of the feature branch workflow with the collaborative tools that Github provides.
Everything in the workflow can be done without Github, but Github adds some nice tools like forking and pull requests that make things easier.
This workflow begins by developers forking the main repository. Developers then follow the feature branch workflow. This workflow keeps the main repository clean and functioning while allowing many developers to work on the project at their own speed and skill levels.
This is the approach that our team at Bluewave Labs is using, so I’d like to go into it in a bit more detail than the other approaches. The workflow looks like this:
1. Forking the original repository (handled on GitHub)
2. Setting up the original repository as a remote of the forked repository
git remote add <original_repo>
3. Creating and checking out a branch for new features
git branch <branch_name>
git checkout <branch_name>
4. Adding and committing code to the feature branch
git add <files_or_path_to_add>
git commit -m “<commit_message>”
5. Pushing the branch to the original repository
- git push <original_repo_remote> <branch_name>
6. Creating a pull request on the original repository and merging after review (handled on Github)
Following this workflow has helped us avoid unnecessary merge conflicts and catch issues with code before it is merged. Here is a link to a much more detailed walkthrough of this workflow.
Ultimately, Git is a tool like any other; it’s often more important how you wield the tool than how new and shiny the tool is, or how many features it has.
Working in a team gives us so many opportunities to learn and grow, the less time we spend on technical conflicts the more time we can spend on building. I hope this Git workflow helps your team stay out of the weeds and focus on building amazing new things!
Bonus Discord webhooks!
Our team handles communication through Discord, which happens to have a great Webhooks tool that integrates really nicely with Github. Once you connect the two services you can receive updates on your Github repository’s activity directly on your Discord channel.
All you have to do is:
- Right click on the channel you want to receive notifications on and select Edit Channel
- Click on Integrations -> Create Webhook
- Click on the newly created Webhook and select Copy Webhook URL
- Head over to Github, go to your repository, and go to Settings -> Webhooks and click on Add Webhook
- Paste the Webhook URL from Discord into the Payload URL field and add /github to the end of it.
- Change the content type dropdown to application/json
- Select the events you want, and click Add Webhook
That’s it, you’re done! Make sure you don’t skip 5th and 6th steps. You should now receive notifications on your Discord channel.
This is a great way to keep up to date on what’s happening with your team and your repository.