2015-09-28

Git Push Only When You Have Something to Share

Git is a source control version system that encourages you to commit changes often. Since you have your own local repository it is not that important that everything that is committed is of premium quality. You can always amend, squach, reword, and even remove commits later before you make your changes public to your team.

Why you should commit often

It is actually a good practice to commit as soon as you get something right. Even the smallest change that works is best put into history. To commit often brings a few advantages that you would not have anyway:

You never need to worry that any changes (and even temporary such) are lost if you screw up.
If you try something out, and it shows that it does not work, you can reset the branch instead of changing back the code manually.
If you later on realize that a commit is not needed you can rebase and remove that commit from history.
If you fix something important that someone else in your team suddenly needs, then that person can cherry pick your commit instead of making the change manually.
? need I go on?

Another good practice is that every branch that is public should only contain work that is complete, done, and if you will done-done. For example, one should at any time be able to do a pull request of that work and have it merged into master.

This makes it super easy for your team members to know what branches they can use to build features of their own upon. Obviously all public branches!

When using the distributed workflow that git allows, with lots of branches that are often merged all over the place, it?s easy to pick a wrong branch by mistake. The risk of that happening is lower if there are no junk cloading the things that are actually important.

In other words, invoke the git push only when you have something to share. And that something should be the kind that is worth sharing! Please keep your public repository tidy.

The fear of hardware failure

One disadvantage of having lots of changes on your local machine is that they can go up in smoke if your computer dies on you. Instead of pushing commits to your public repository you need to address this in another manner.

You could set up a remote repository and push your changes there to backup. But I would not recommend it. Having more than one remote really is a hazzle! Especially when doing it for backup reasons only.

One more direct way is to simply do regular copies of your local repositories to a remote location, say a network share, or why not OneDrive? You do not need to copy your checked out branch with binaries and what not. All that is needed is the .git folder.

PowerShell to the rescue

My approach is to schedule the following PowerShell to run once each hour. Problem solved!

[CmdletBinding()]
Param(
    [Parameter(Mandatory=$True)]
    [string]$Source,
    [Parameter(Mandatory=$True)]
    [string]$Target
)

gci $Source -Recurse -Filter ".git" -Force -Directory | %{
    $dir = Join-Path (Join-Path $target $_.Parent.Name) ".git"
    robocopy $_.FullName $dir /MIR | Out-Null
    if ($LASTEXITCODE -gt 7) {
        Write-Error "RoboCopy exited with code $($LASTEXITCODE). Something bad happended when taking backup of $($_.Parent.FullName)!"
    }
    else {
        Write-Output "Mirrored content of $($_.FullName) to $dir"
    }
}

For example, I invoke it by .\Backup-Git.ps1 -Source C:\Dev -Target C:\OneDrive\Backup\Git\Rusty.

I have many computers, and I keep a separate backup folder for each. (One of them is called Rusty?)

My dev folder contains lots of clones of other people’s repositories which I am not interested in backupping. If you make it a habit to remove their .git folders then they will not get mirrored to your backup destination.

You can surely think of something else that suites your workflow better! :)

Why you should commit often

Git push only when you have something to share

The fear of hardware failure

PowerShell to the rescue