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
  • 1
  • 5
  • 1
    I'm voting to close this question as off-topic because it's already been answered on [Stack Overflow](http://stackoverflow.com/questions/1550378/is-it-possible-to-push-a-git-stash-to-a-remote-repository) – David Arno Jul 12 '16 at 15:28
  • 5
    @DavidArno: I don't think it is a cross site duplicate. The StackOverflow question is about "Can I do X" and this one is about "Is X a good practice". In the very least the root cause of the question is different. – Greg Burghardt Jul 12 '16 at 15:30
  • 7
    @DavidArno the last I checked, "Already answered on SO" isn't a reason to close a question. – RubberDuck Jul 12 '16 at 16:13

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
  • 34,276
  • 8
  • 63
  • 114
  • 6
    I'd even say it stronger: _never_ work on master branch, always use a topic branch. Commit to it as you see fit, push it fearlessly. When you're happy with the changes, merge it to master. – 9000 Jul 12 '16 at 16:15
  • Great advice! I think the big confusion might happen because we need to add a comment to a commit, and sometimes it will literally be something like "task in progress" or something like that. And yes, I am working alone in this branch so everything you said makes sense! – Leandro Jul 12 '16 at 21:27
  • 4
    This also gives you the option of squashing individual commits into one when merging your branch [git merge --squash bugfix](http://stackoverflow.com/questions/5308816/how-to-use-git-merge-squash) – snoopy Jul 12 '16 at 21:43
  • 2
    @Leandro commit messages should be as atomic and clear as makes sense. For example, even if it's WIP you can say for example "Adding controller to handle page requests - WIP". Commit messages also provide a searchable history of changes made tot he project. Ten commits of "WIP" wouldn't help anyone looking for a change surrounding handling users for example. – Ben Jul 13 '16 at 02:06
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
  • 146,727
  • 38
  • 279
  • 479
  • 1
    I wouldn't recommend getting used to `--amend` so it requires `--force` for the pushes, though. Better commit only to a throwaway branch. – leftaroundabout Jul 12 '16 at 21:31
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,557
  • 11
  • 12