Git is a popular open source tool for version control. It allows developers to collaborate and make changes to a centralized code base without interfering or breaking the production code. While Git makes it possible for developers to simultaneously manage different features of a project, things can still get messy when a generalized workflow isn't established among team members. In this article, we discuss the different types of Git workflows and best practices for using Git with your development team.
Git is a form of version control, which is really just a fancy term for keeping code organized. When you have a group of developers working on the same project, things can get messy fast. Let's say developer A makes changes to the same file as developer B. If both devs overwrite the same file then how do we know which file to use? What if we need both the changes from dev A and dev B in production but they are conflicting with one another?
These are the issues Git protects against. Git allows developers to have their own local copy of a central repository. With Git, developers "check out " versions of a master branch and then merge their changes back into the central repository.
By encapsulating developers' work into separate branches, devs can work on the same code base without constantly overwriting/conflicting other contributions.
While branching off of a central repository prevents conflicts, there are specific strategies development teams can follow for knowing when to merge or sync up with the central repo. Below, we define four popular methods for Git workflow used today.
A centralized workflow is the simplest form of Git workflow. Developers check out their own local copy of a centralized master branch. As the developer makes changes, he/she logs progress via commits (or a historical snapshot of the files changed on the local branch). Whenever a developer finishes a feature, he/she sim ply merges local work with the master branch.
Like a centralized workflow, feature branch workflow involves working off a single master branch. The key difference is the use of branches to define separate "features" for developers to work on. With feature branch workflow, a developer creates a new branch for each feature / issue he/she works on. He/she then submits a pull request so team members can approve the feature and then merge it with the master branch.
The main advantage of this work flow is separating the different features from the main code base. Unlike the centralized workflow (where devs push and pull from the same master branch), developers aren't pushing and pulling from the same repo. Rather, they independently make changes in a "sandboxed" feature branch that is then reviewed and merged into the master branch. This makes things like continuous integration easier as devs can work on prototypes and new development without compromising the central working master branch.
This takes feature branch workflow a bit farther, using a develop branch. This branch serves as a buffer between features and the master branch. Team's will typically fork the develop branch to manage different releases. These forked branches are then merged into master as necessary. This creates more of a separation between local dev activity and the central master repo.
The forking workflow is fundamentally different in that each developer has their own centralized repo saved server side. This gives each contributor their own master repo. While devs can easily push/pull from their own repo, it's more difficult to integrate/overwrite another working branch. This allows developers to more securely collaborate, however relies on a product owner or team lead to aggregate and manage all the different independent "projects floating around.
Only your team knows what works best for them. While a centralized workflow may be most appropriate for a few developers looking to generate a quick MVP, feature branch workflow makes more sense for larger teams working on the same code base. Whatever strategy you decide, be sure every developer is on the same page. This will maximize dev time and efficiency and reduce the headaches experienced with merge conflicts, etc.
At the end of the day, all the aforementioned Git work flows are incorporating the same benefits of Git (feature branching, etc.) into version control. While a centralized workflow simply allows developers to pull / push copies of the same master branch, a feature branch workflow simply adds more buffers between local work and the central repo. Forking workflow takes this a step further, designating only one project manager to merge separate code bases with an "official" repo. Whatever strategy you choose, be sure to commit early and often. The more you can cherry-pick and rollback the mistakes, the easier it will be to keep your code base moving in the right direction.