How to back up private branches in git

Question

I have a local branch for day-to-day dev work in git. My workflow is:

1. Do stuff on local_branch, commit
2. Fetch origin/master
3. Rebase local_branch to catch up with new stuff from origin/master

It all works fine, however most of the recommendations I encountered say that one should not "push" private branches, on which rebase is regularly performed.

The problem here is that in this case local branch is not backed up to a server and the only way to save the work is to merge it back to "pushable" branch (i.e. origin/master)

What would be your recommendations on the workflow in this case?

Thanks!

UPDATE: I realised that one of the original requirements I had (avoiding usage of external utilities) is unnecessary limiting.

My current solution is to store all my repositories in a cloud-synchronised folder - this way I get backup for free.

Answer 1

I use the --mirror option and push to a personal backup repository:

Add it as a remote:

git remote add bak server:/path/to/backup/repo

Do the backup:

git push --mirror bak

This will automatically make your backup repository look like your active one -- branches will be created, deleted, updated (even forced/non-fastforwards) as needed. You can make an alias for this too:

git config alias.bak "push --mirror bak"

Then, it's just a matter of running "git bak" when you want to do a backup. You could also throw this into a cron job.

Answer 2

There's nothing wrong with pushing personal branches. It is generally discouraged because people might start work based on your branch, and when you rebase, their changes are left floating.

What I do is use a prefix to denote "this is my branch, use it on your own risk", like: fc-general-cleanup.

Answer 3

Another option would be to push "local_branch" to the "origin" repo, but to it's own branch in that repo (not "master"), i.e.:

git push origin local_branch:local_backup

Then when you are ready to make another backup (and after you've been doing some work and rebasing) just delete the backup branch from the origin repo before you push it out again:

git push origin :local_backup <=== deletes the branch from origin

git push origin local_branch:local_backup

This way you won't run into problems pushing "local_branch" after it has been rebased from "origin/master".

And if deleting your backup branches makes you nervous (until after you've finally committed your work to "master"), you could always keep pushing to a new branch with a new name (e.g. "local_backup1", "local_backup2", etc).

Answer 4

Can you set up another remote repository that you do push all of your branches to? The other thing to consider is just backing up everything (important) on your local machine, including the git repo.

Answer 5

There is nothing wrong with pushing to the same branch that you are rebasing from. These diagrams should illustrate why this works fine:

Lets say this is what the commit graph looks like after you've branched local_branch and made a couple of commits to it (C and D). Someone else has made one commit (E) to origin/master since you branched local_branch:

A -- B -- E  [origin/master]
      \
       \    
        \-- C -- D  [local_branch]

Then after running "git rebase origin/master", the commit graph will look like the next diagram. "origin/master" is still the same, but "local_branch" has been rebased:

A -- B -- E  [origin/master]
           \
            \
             \-- C -- D  [local_branch]

At this stage, if you do "git push origin local_branch:master", then it will result in a simple fast-forward. "origin/master" and "local_branch" will be identical:

A -- B -- E -- C -- D  [origin/master],[local_branch]

Now you are free to do more work on "local_branch". Eventually you might get something like this:

A -- B -- E -- C -- D -- G -- I [origin/master]
                     \
                      \
                       \-- F -- H [local_branch]

Notice this looks a lot like the starting graph. You can keep repeating this process over and over.

You should avoid pushing to some other branch, one that you are not rebasing from. That is where you will run into trouble (to the other branch, it will look like your "local_branch's" history has suddenly been re-written, after you've rebased from "origin/master").

Answer 6

Rather than relying on Dropbox to synchronize all the files of a git repo, I would rather use git bundle, which produces only one file (including all your private branches), and sync that file with DropBox.
See "Git with Dropbox"

In "Backup a Local Git Repository", Yars mentioned having sync errors with Dropbox.

Answer 7

Here's what I do. But - this isn't private. I do this so that I can collaborate with myself (so to speak). It lets me work on the same branch on two or more boxes. if other people had access to the shared repo, they could see the work I'm doing on the branch. Of course, on my home repos, nobody else has access, so it's still private. On github, all the world could see my stuff. Like they really care. ;)