Category: git

The Four Commandments for Keeping Your Team Out of Integration Hell

git

“Michael: There’s nothing here to fear.
Lucifer: Well, there’s always the truth.”

-Mike Carey

Source control can be hard. Source control can be terrifying. And worst of all, source control can be a real Biblical hell.

For those beautiful souls fortunate enough to have never touched upon the issue, allow me to briefly explain:

Integration Hell refers to the point in production when members on a delivery team integrate their individual code.

In traditional software development environments, this integration process is rarely smooth and seamless, instead resulting in hours or perhaps days of fixing the code so that it can finally integrate.

Source

By now, Git and Git-Flow (if you’re not using it, you undeniably deserve to burn) are probably the most popular source control tools on the planet. You’re likely at least familiar with them.

But tools and workflows can only be as good as the people using them.

And if it’s true that C can make it easy to shoot yourself in the foot, Git can sometimes make suicide seem like a more appealing proposition than your last three failed relationships.

So, in order to fulfill my divine duty and save you from the lake of fire, I bring you four commandments that will keep you and your team on the pathway to Heaven and good Fortune:

I. Commit Early, and Commit Often

Each developer should be able to break down his work into simple, logical chunks suited to a small commit; and should commit those changes as soon as possible.

II. If It’s Not Pushed, It’s Not Done

Each commit should be pushed into the remote repository.

Hard drives can fail, programs can crash, IT can be presumed to be incompetent, and mistakes will be made.

If your work hasn’t been pushed, it hasn’t been done. Period.

III. Use It or Lose It

Each unit of work should be defined as an individual feature branch diverging from a main development branch.

Your work should be integrated within the main development branch or branches in no longer than a certain time period. It is up to you and your team to determine that time period based on the scale of work that your repository usually handles.

But normally I’d recommend as frequently as each day and as infrequently as each week.

This means that each development task should be intelligently designed and broken down into many small features (branches) in order to keep the work continually integrated with the main codebase.

If one of the features needs to exceed this given amount of time, especially see the next commandment.

IV. Do the Pull, or Be a Fool

As a developer, it’s your responsibility to make sure your work not just works, but also plays nice with everyone else’s work.

That means that if your feature branch has been isolated from the main branches for longer than reasonable, you have to pull changes from the development branches via a merge or a rebase in order to make your branch usable.

Failing to do so can only guarantee that things will break down the line, and make using the codebase a foolish thing to do.

Don’t be that person.

Introducing Delobra – Git Branch Deletion for the Opinionated

command-line, git, scripting

Delobra [delete local branches] is a simple shell script for the opinionated Git user that takes care of doing some seasonal branch removal in your repository.

Solving the Problem

It was born out of distaste with the current Git-flow methodology, especially when dealing with the integration of a high volume of branches with multiple developers and development teams.

Under this workflow, once you are finished with a feature branch you are expected to merge it back into develop and delete the branch. Keeping the branch, however, might prove useful if you later want to revisit your code in the same exact context or work out breaking changes that were introduced in one of many recent merges.

In this case, being able to switch over to the branch to view your work without having to search through commit messages or merge commits might feel like a blessing.

One downside to this, however, is that the number of branches in your repo will skyrocket over time, and having to delete them one by one is a notable pain.

This is where Delobra comes in and helps you safely remove your finished work with ease, letting you keep your branches for an easier workflow until it’s time to clean out the house.

What It Does

Delobra’s job is to compile a list of branches to queue for deletion, check in with you, and (with your approval) delete the branches from your repository.

Delobra on the Command-Line

It is based on this one Git command:

git branch --merged develop

It lets Git know that you want to retrieve a list of local branches that have been merged into the develop branch, which you can change if you want to use a different branch as a “merging filter”.

Building upon this command, Delobra then excludes any other named branches in the list via the use of grep:

| grep -v -e develop -e master

You can remove these exclusions by simply removing any of the command segments beginning with the -e option and ending with a name, or add your own exclusions by adding the -e option followed by the name contained by any of your branches.

If you’re using a Git-flow methodology, then Delobra will work for you as you can exclude different branches based on their shared naming structure (i.e. feature, release, hotfix).

Even if you aren’t, you can still delete similarly named groups of branches or customize Delobra to fit your needs.

How To Use It

To run Delobra on your Git repositories:

  1. Copy over the delobra.sh file to your home directory ~.
  2. Open a terminal window (or Git Bash if you’re on Windows) in your Git repository directory.
  3. Run the command ~/delobra.sh.

You can find the delobra.sh file on GitHub.