Use Git More Efficiently: A Simple Git Workflow
Tags: git, github, gitflow, workflow
Published: 2019-06-07 13:17:21

---
title: Use Git More Efficiently: A Simple Git Workflow
published: true
description: A simple and successful Git workflow for medium-sized companies
tags: git, github, gitflow, workflow
cover_image: https://thepracticaldev.s3.amazonaws.com/i/c4t7mhrhfto7hbs39qz0.jpg
---


Git without a doubt is one of the essential tools for every developer. As helpful as Git is, not following best practices will make it completely useless. That's why there are different standard workflows to make most out of Git and its awesome features.
For a long time, my inception of Git and GitHub was a tool that back-ups the codes and let us access them online; Which was not completely wrong, but there are so much more about them that I didn't know until I start my work as a developer in [YasnaTeam](https://yasna.team).
In our team, about 10 developers are actively working on the same repository. Having the same habit and so-called culture is necessary to avoid conflicts and chaos. With over 100 commits per day, things could get out of hand very soon. To avoid such problems we implement a modified version of [Gitflow](https://datasift.github.io/gitflow/IntroducingGitFlow.html).

_This post has been published on Medium, too._

{% medium https://medium.com/@negarjf/use-git-more-efficiently-a-simple-git-workflow-c4e650289ec8 %}


---

# How it works
Instead of having one single `master` branch, we have another extra branch named `dev`. These both branches are locked and no one can push directly into them.
`master` is reserved for production only. ‌After testing new features, the repository owner updates `master` before each release.
`dev` is the default branch that all of the developers create a branch from and merge back into. `dev` is always ahead of master and it's the only branch that will be merged into `master`, frequently.

# Naming Branches
We have a pattern for naming our branches.

```
[Module Name]-[Type]-[Detail]
// Example
users-fix-attach-roles-issue#765
```

## Module Name
Since we have a modular structure in our code base, changes related to each module should be committed on a separated branch with the module name. This part could be removed if you don't have such structure, in your project.

## Type
According to the type of task, developers should choose between one of these types:

- `feature`
- `enhance`
- `cleanup`
- `refactor`
- `fix`
- `hotfix`

Type `hotfix` is for urgent fixes on the master branch and won't be used that often.

## Detail
The detail is a short description of what is going to be delivered by the branch.

This branching rules force us to separate each task to meaningful chunks and merge frequently into dev and always have fresh branches. One great side-effect of this approach is to minimize conflicts.

## Commit Messages
In order to have clean and descriptive commit list, we also have a naming rule for commit messages (I love rules!).
```
[[Module Name]] [Commit Message]
// Example
[users] add fetch users endpoint
```
Having the module name in each commit message might seem redundant since we have the name in our branch, but the truth is after merging all branches into `dev` (or `master`), looking at the commits history you cannot say which branch each of the commits was belonged to. Because right now they are all belonged to the `dev` (or `master`) branch. In order to filter through all commits easily, we need to have the module name somewhere inside the commit message.

The commit message itself should complete the sentence "This commit will…" grammatically.

# Pull Requests
## Title
Title of the pull request is automatically filled with the branch name. In case the branch name is too generic, more details are expected to be added.

## Body
The body should contain details about the pull request. In our workflow pull requests are usually related to an existing issue. We create an issue for each bug or feature. So we link to the related issue inside the pull request body. We also mention highlights of the changes that are made inside the pull using bullet points. We have created a [template for our pull requests](https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository), to facilitate the process.

![A Pull Request Template](https://thepracticaldev.s3.amazonaws.com/i/j0wf7ulw3i1ew1ni2f6l.png)

# Review
Code review is one of the most important parts of our daily job. Once a pull request is created, the creator should choose two of peers to review the code based on some prespecified criteria.
Once the pull is approved by reviewers, the creator can merge into dev and delete the branch.


---

We have been using this workflow for more that one year and update frequently based on our needs. Do you use some other git workflows on your team? Let me know how they are.