How to back up private branches in git

GitMergeWorkflowRebaseDropbox

Git Problem Overview


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.

Git Solutions


Solution 1 - Git

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.

Solution 2 - Git

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.

Solution 3 - Git

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).

Solution 4 - Git

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.

Solution 5 - Git

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").

Solution 6 - Git

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. ;)

Solution 7 - Git

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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionArtView Question on Stackoverflow
Solution 1 - GitPat NotzView Answer on Stackoverflow
Solution 2 - GitFelipeCView Answer on Stackoverflow
Solution 3 - GitDan MouldingView Answer on Stackoverflow
Solution 4 - GitCebjyreView Answer on Stackoverflow
Solution 5 - GitDan MouldingView Answer on Stackoverflow
Solution 6 - GitDon BransonView Answer on Stackoverflow
Solution 7 - GitVonCView Answer on Stackoverflow