1

I would be interested in both general case and more specific answers, but some relevant factors in my particular case are:

  • I'm currently the lone developer on this project, but might be collaborating with another in the near future
  • I'm attempting to follow this workflow, more-or-less.
  • In particular regard to the previous point, two branches (master and develop) have remotes, other branches created for hotfixes, bugs, and features are local-only
  • The repo is easy to clone and run/develop/test multiple instances of locally

On a day-to-day basis, I'm frequently working on several branches concurrently. Much of this work isn't immediately committable, so I'm currently using git stash to save work between branch switches. However, I'm finding working with stashes a bit fiddly and wondering if a clone-per-branch approach might be easier to keep track of. What are the advantages/disadvantages of each, and does anyone strongly recommending one approach over the other?

UPDATE: I should add that my reluctance to keep all branches constantly committed is because of an aversion to having broken or really bad code in the repo. I realise, however, that it might be wise to revise this principle, especially if I gain familiarity with the git tools to mitigate any negative side-effects.

Bobby Jack
  • 15,689
  • 15
  • 65
  • 97
  • 1
    not an exact duplicate, but I think this answer is relevant: http://stackoverflow.com/a/25588087/2541573 – jub0bs Jan 28 '15 at 10:40
  • I recommend against both stashing and multiple clones as a solution to the problem you describe. If something might ever be useful again, it is committable. Use `git commit --amend` , interactive reabsing and `git reset` to keep your history clean, if you are so inclined, or just keep the history as it actually happened. – Sven Marnach Jan 28 '15 at 11:36
  • Great suggestion, sven. I might have a play around with --amend, which looks like a potential solution. – Bobby Jack Jan 28 '15 at 13:15
  • This answer by torek is also of interest, especially regarding the dangers of automating stash save and pop: http://stackoverflow.com/a/27698341/2541573 – jub0bs Jan 28 '15 at 17:09

1 Answers1

0

Don't use git stash. It's hard to sort back which stash belongs to which branch.

Instead, do a git commit --all -m "stash" and a git reset HEAD~ when I continue working.

This leaves all stashes where they belong (i.e. on their branches).

Even better: leave all the stashes where they are. Once you finish your feature, use git rebase -i in order to clean up your history.

eckes
  • 64,417
  • 29
  • 168
  • 201
  • Actually, the default stash messages make it pretty straightforward to identify which branch a stash belongs to - at least, as far as I've gone yet. However, my problem is remembering to constantly apply the relevant stash after switching branch, and remembering to drop the relevant stash again afterwards. – Bobby Jack Jan 28 '15 at 13:17