Git Workflow Best Practices for Your Team

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Run-through

“Trust but verify,” is sort of our cornerstone for everything. It helps to keep everything on track and to catch problems before the project derails. A lot of teams use Git, and nearly everything we do revolves around what you do on Git, too. However, not everyone who uses Git knows all of the ins-and-outs of using it and that can cause software engineering managers a headache or two. So, let’s get everyone aboard with Git workflow best practices and moving in the same direction with Git, regardless of the size of your development team!

One Project! 1,034 Features Long

Do you watch Snowpiercer? It’s a cool Netflix series. The gist of it is that the last of earth’s survivors live on and depend upon a train for survival. The survivors are divided by passenger class and by job function – each having a different understanding of how the train should work. The train, Snowpiercer, runs on perpetual energy. But, the people and parts that keep it running aren’t perpetual. Though, despite the strange Winter vibe, Sean Bean’s character is still alive.

It’s like a dramatic depiction of how a software project with different teams can fall apart for lacking a common framework.

Software development is complex and relies upon complex tools and processes. The way we develop software today would not be so easy without version control systems like Git. In a lot of ways, Git is our source of perpetual energy and motion enabling faster, more efficient and higher quality product releases. However, Git’s value is proportionate to everyone’s understanding of how to use it.

One Team, One Repository

In an ideal world, each team would work with its own repository. Complications can enter the picture when you have multiple teams working with a single repository. On a given project, it’s possible to have in-house developers, developers from staffing agencies, freelancers, even other development agencies involved. As we discussed in how to choose the best branching strategy for your team, it’s best to start simple and add complexity only as it’s needed.

Let’s keep that “ideal world” scenario by getting everyone on the same team. Though it may be semantic, everyone working on the project should be working together as one team according to one standard. Begin by establishing common standards for everyone in coding, branch naming, tagging, commenting, testing, workflow, and other processes. If something goes wrong, a common standard helps to isolate how, when, or where, without having to map out how each individual or segment of your team does things.

Transforming modern engineering at Microsoft sort of showcases its efforts to establish common standards in support of a “one team” approach. It’s applying to wide-ranging improvements in productivity, efficiency, improving quality, easier onboarding, and making it easier for developers to transition between projects. Leastwise, as Microsoft makes a point of sharing, though your company and team/s may have many projects, and likely use different workflows or branching strategies, you still want to keep the same taxonomy and most of the standards the same across all of them.

What is the best Git workflow?

Referring back to our previous discussion of Git Branching Strategies, it’s hard to define which is best because it depends on whether the software requires release support or continuous support, team composition, and experience. Everything considered we find the GitLab Flow strategy very flexible and a natural evolution should your GitHub Flow (or Trunk-Based Development or TBD) project become more complex. Adam Ruka’s OneFlow is a better fit for enterprise-level release-based projects if you have an experienced development team. The original GitFlow created by Vincent Driessen might be your best enterprise/release option if you’re working with a majority of junior developers.

No doubt that there are variants and you may need to adjust the workflow of any branching strategy to fit your particular project/team scenario. For quick reference, here’s a quick comparison of each branching strategy:

GitFlow GitHub Flow GitLab Flow OneFlow
Types of Projects Enterprise Startups All Enterprise
Branch Overhead Heavy Light Variable Light
Work Process Complexity Complex Simple Simple Medium
Merge Difficulty Hard Easy Easy Easy
Delivery Support Releases Continuous Both Releases
History Convoluted Clean Clean Variable
Feedback Slow Fast Fast Fast

How does Git work with a team?

One of the important differences between workflows concerns the number of different types of branches each uses, varying from 2 to 5. GitHub and TBD are the simplest with two branches (Master and Feature), while GitFlow and One Flow typically have five. Assuredly, if you look around you can find many other workflows, some with a Develop Branch for each development “team” (or sub-team).

Tips of the Day (or Week)

Best kept as a quick (15 second) mention and pinning on your Whiteboard, unless you find it too disruptive. This is a quick and easy way to share something useful, whether an inspirational quote, a short coding tip, reinforce a coding standard, company news, recognize birthdays, anniversary dates, graduations or certifications, links to short articles or videos related to the project, announcing pizza day or discounts on products of interested to your team.

Though this doesn’t serve the specific objectives of the standup meeting, it can be a small boost to team morale and reinforce a pleasant work environment.

Branching Strategy Comparison

Feature Develop Release Hotfix Master Production
GitFlow Yes Yes Yes Yes Yes No
GitHub Flow & TBD Yes No No No Yes No
GitLab Flow Yes No Yes No Yes Yes* (+preproduction)
OneFlow** Yes Yes Yes Yes Yes No

* In GitLab Flow the Production Branch reflects the version that is currently scheduled to be deployed pending regular office hours or validation by the App Store/Google Play, etc.
** OneFlow maintains Master as the only long-lived branch with all others eventually being merged and/or rebased to it to maintain a history that’s a lot easier to read.

Notably, there is only one Master branch that should always be deployable. Similarly Develop and Release are often singular long-lived branches used to reflect different stages of development common when working with large teams. Hotfix branches are short-lived, though there can be more than one in existence at any given time. There can be any number of short-lived Feature branches.

Branch Taxonomy and File Naming Conventions

Different teams may also use other names for their branches, like: Staging, Deploy, Stable, Trunk, Bug, etc. One of everyone’s favorites, of course, is the “Bug as a Feature” branch. 

While most developers are highly fluent in English, their local experience with naming conventions may vary. Leastwise, it can get confusing and it underscores the value of making sure everyone on your team is using the same taxonomy. Document your work process as part of your coding standards for each project. Discuss it with your developers to make sure they know who needs to do what, when, and how. This will also help bring any new developers up to speed faster

File Naming Conventions

After branches, everyone needs to know how they should name the files they create. Applying to a consistent and self-explanatory naming convention is helpful even if you are the only developer on the project. You might have to bring on other developers at some point or have to take a long break and forget what your mysterious-sounding file names were for. Again, with naming files, we want to keep it simple, easy to understand what the file is for, and minimize the chances of naming conflicts.

So, what’s the best file naming convention? You might want to stick with file naming conventions already standardized by the operating systems or services with which you’re already working. Here’s a list of naming conventions used by some of the companies that tend to set the standard:

Included in some, but just to highlight some additional best practices with naming conventions:

  1. Try to keep names short but descriptive.
  2. Try to avoid branch/folder – file name redundancy.
  3. Avoid using fancy (non-alphanumeric) characters, other than perhaps – OR _.
  4. Try to limit file names to one or the other (- or _) and be consistent with its usage.
  5. Use YYYYMM or YYYYMMDD per ISO 8601 for dates.
  6. Structure the elements of the file name so as to align with how it will be retrieved, like by date or description.
  7. If non-date related numbers are to be used, allow for growth by numbering from 00 to 99, or 000 to 999, etc.

Additional Reading on Best Git Practices for Teams:

If you’re looking to get everyone on your team up to FULL SPEED on the Best Git Practices, there’s a lot more to check out:

You might also want to check out our tips on reducing the size of your Git repository, and Top Ten Git Best practices.

Automate Your Software Development Metrics

Gitential makes it easy for you to automatically track critical performance metrics with four levels of visibility – company level, by project, team, or individual. You’ll have on-demand access to comprehensive statistics across the four main drivers of software development – productivity, efficiency, quality, and teamwork. With this data, you can begin measuring the benefits of teamwork in software development, identify what’s holding your team back, improve cycle time, and more. 

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates.
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates. All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.