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.
Mian Labs 