Harnessing the power of git: Being productive

This is the second email in the series I sent out to the developers team I worked with some time ago. You can find the first in the series here.

Hello everybody,

…

The last time we looked into git and its “promise” to make awesome developers ship out awesome software. Now let’s explore a little bit of the awesomeness we can use git to achieve by exploring one of the core features of git, branching.

Workflows

In essence, a git workflow is a collaboration practice that tries to make contributing to the code base simpler using branches[or forks]. It helps put in place a productive and effective process of making improvements to the code base. Properly adopting an appropriate workflow increases efficiency.

The workflow we’re using is the per developer branching where each developer has a branch to work on before integrating changes back into the central branch. This is cool as it makes every developer responsible for his set of changes also makes his work visible. A drawback with this workflow is that every new feature, bug-fix, and improvement to an old feature is done on the same branch which could cause issues if a previous unit of work needs modifying while a new uncompleted unit is already in progress on the same branch.

An alternative workflow is the feature branching, which is quite popular (in different formations) amongst software teams including Atlassian. In this workflow, branches are created for every feature to be implemented. The cool thing about this workflow is that every feature is “isolated” on a branch which could be integrated into the main branch and modified by a different developer without affecting his ongoing work on a different branch. But the problem with this workflow is there could be a lot of branches in the repo but ideally, for every approved merge request, the feature branch is delete.

These are not the only workflows and a mixture or alteration of aspects from any workflow could be adapted to best fit a project’s needs and our processes. Remember, workflows are designed as guidelines rather than concrete rules .

In the next, we’ll take a look at how to use git workflow, to deliver and ensure code quality by utilising pull request. I’ll really appreciate reviews, comments and suggestions. Remember, this is meant to get a conversation ongoing. If there’s need, we could have a KDS[knowledge sharing session] to make this discussion practical and interactive.

Enjoy the rest of the week.