Hacker News Reader

Comment by teekert | Hacker News Reader

I'm a git noob. I realy mis an option to simply backup my current work situation to Git and work further on it on another machine, or simply later with the knowledge that everything is safe on the server. Currently I have a big list of commits called "Backup" which I always push immediately. It's ugly. Is there a way to save to the git server your current situation with bothering others working on the project with your commits?

Maybe this is simply not what Git is made for and I should use Git from my NextCloud folder to have my data safe on a server?

View on HN

What you could do is commit half-finished work with the name “Backup”, and then commit --amend over the top of it once that piece of work has completed. This ensures your for-sync-only commits won’t get in the way of the other commits.

However, I recommend you use a separate tool for backups and syncing than the tool you use for version control. For example, you could use Rsync to push the files -- both the .git folder and your source code files -- to a remote server, and then pull them down on another computer. Not only will you only be committing for actual commits, but you can also save the state of your repository and continue working on it later; you could stage certain files and not commit them, sync your .git folder to another machine, then have those same files staged but not committed.

Sounds like you want to work on a separate branch. Also sounds like you'd want to rebase onto the correct branch when done, so that you can reorganize commits

I do work on my own branches indeed. But something like "git sync" would be nice, no commits, no mess for your collaborators or in your Git history, just my current work, safe on the server, to be synced elsewhere without formally committing anything so that commits can be real improvements that require a commit message. Git sync would be the equivalent of hitting ctrl-S working on a doc in a Dropbox folder. You hit ctrl-S, boom it's safe on the server. I'd setup git sync to sync regularly and allow you to go back in time, or if you want, completely back to the last formal commit.

Git feels so local and thus vulnerable to theft, breakage, power outages etc.

> I do work on my own branches indeed. But something like "git sync" would be nice, no commits, no mess for your collaborators or in your Git history, just my current work, safe on the server, to be synced elsewhere without formally committing anything so that commits can be real improvements that require a commit message.

You seem to be hung-up on commits or have an inexplicable aversion (IMO) to committing to a private, expendable branch. Git made branching cheap and easy by design - you can go crazy on your private 'backup' branches without having to add detailed commit messages. When you are happy, you can rebase or squash merge into the 'real' branch with proper commit messages and delete the backup branch. This will not create a mess for collaborators or your Git history (after you've deleted the ephemeral branches).

As a matter of fact, you could create an alias for 'git sync' that does the above in the background, if you find the individual steps too tedious to manually type in.

I do basically what the parent suggested for all my git work, i.e. it's my workflow. Call your branches wip-* to signal that you'll be using it haphazardly, don't bother doing "clean" commits while working (just commit stuff whenever you feel like it or when you might want to backtrack an experimental change, use the message "wip" or whatever). Push to branch whenever you want a "backup", e.g. when moving to a different machine.

When done, clean up the history[1], push to a different "real" branch for review. Delete wip-* branch.

Unless people have actively checked out your branch locally they shouldn't have any "mess" on their end. (They'll have a remote branch listed by "git branch -r", but all of those can be cleaned up periodically with a "git prune ...".)

I haven't heard any complaints so far. (I've been doing it this way for 4+ years, I think.)

[1] I usually find that it's easier to split/clean up after the feature is almost completely done and ready for review. When I'm "in the zone" I don't want to have to suddenly switch to the "cleaning up history" mode.

The workflow is entirely up to you and your collaborators. "commit" does not have be literally a commitment. Try branching on your branches so that you have the freedom to experiment.

You could push to a private git repo or server, that way you don't bother anyone, and then when you're in a clean state push to the origin

This is the best method in my opinion. Back up simply by

    git push backup my-new-branch

Reply on news.ycombinator.com