19

I very often work on some features of my project that I need to take a break before it is good enough for a commit. However, I use daily two different computers to code (my laptop and my research lab desktop). E.g.: I am working on a feature at home, then I stop and go to my lab.

I don't want to mix cloud syncing (e.g. Dropbox) with GitHub remote tracking.

I've simply committed unfinished (and messy) states of my code before (and pushed it) only for the purpose of pulling that in the other computer to continue the work. I am pretty sure this a bad practice.

Today, though, I came across git stash after Googling a little bit. It seems as the perfect solution for what I need.

However, the documentation doesn't say if it goes to github once I push my changes. Besides that, I want to know if there's a more efficient way to accomplish the mobility that I need.

Thanks in advance!

Leandro
  • 301

3 Answers3

29

I've simply committed unfinished (and messy) states of my code before (and pushed it) only for the purpose of pulling that in the other computer to continue the work. I am pretty sure this a bad practice.

It's OK to commit messy unfinished work. Do your work in a topic branch. Commit early, and commit often. Read up on When to commit code? for some guidelines on when to make a commit. Specifically for Git, commit to a topic branch and push it as often as you want.

If this topic branch is just meant for you, commit and push broken code. You should only defer from pushing broken code to a branch that is used by other people. Feel free to break your own code.

Community
  • 1
Greg Burghardt
  • 45,304
7

Stashes are intended for local use, as a temporary place to put things while you mess around with branches.

If you're the only one working on a branch, there's no problem with committing broken code. What I do when in similar situations is do a broken commit, then after pulling it at the other location, do a git reset HEAD~1 to undo it. Of course, this requires using --force on your pulls and pushes when you change locations.

Or I just wait until my first commit and do a git commit --amend. Or I just squash all the broken commits out when I commit the feature branch. Or I just don't worry about a few clearly-marked broken commits in my history, because I tend not to leave until I'm at a good stopping place. There are a lot of options.

Karl Bielefeldt
  • 148,830
1

stash is not really satisfying for anything but cleaning your work directory to “unjam your branch”; if you don't immediately stash pop the state back then things will get very confusing.

If there's actual work to be saved, even if it's not good for a permanent repo entry, it should still be a commit. In fact, I never leave my working directory in a state that's not under version control – I use some very simple Python scripts to save every change as a temporary commit. If you want to give that a try, here's what to do:

  1. When you've done some unfinished work and are about to leave the workplace, execute git-tmp-commit. It will automatically commit all changes to a new, unique branch.
  2. Push this branch to remote.
  3. Leave.
  4. When you want to continue, clone that branch again from the remote. I do this with the ccd script, which actually checks out everything from scratch to a temporary folder, automatically choosing the most recent branch... but you can also just manually fetch and checkout the branch temporary-commits/original-branch/YYYY-MM-DD... from an existing clone of the repo.
  5. Finally, “un-commit” the changes with git-tmp-commit -r. This will get you back to the original branch† (e.g. master) and leave the changes of the temporary commit in the work directory, so you can continue here until it's time for a proper commit (or temporary, if you have to leave again).

†The way the script is written right now, this only works if there is no branch master in the checkout repo. So in doubt, you'd have to git branch -d master; this obviously isn't really ideal...

leftaroundabout
  • 1,603