Coworker just showed me how he avoids merge conflicts and I'm undecided on it. We use feature-branch workflow, so if a feature takes a long time to finish, it may mean merging master multiple times. He avoids it by stashing changes instead of committing them, then when he needs to merge master into the branch it's still clean. When the feature is done and he's ready to commit, he pops the changes and git diff shows all the changes before you push and you just change what you need instead of being forced to use the horrible merge software.

There must be problems with this, right? This seems too easy for it not to be the standard.

  • 2
    I do it that way sometimes as well.

    I'm on my feature branch, master gets updated, git stash save, git merge master, git stash apply, resolve conflicts, finish my work, commit, make pull request with no conflicts.
  • 1
    It's like the poor man's rebase.

    Similarly, rather than try to rebase a long historied feature branch against master, where fixes have been incorporated into each branch, I've on occasion just made a patch against the fork point and then apply the patch holus bolus.

    Sacrificing commit history for sanity.
  • 2
    You mean he does one mega commit at the end of the work?
  • 0
    The day you decide to make that big commit and machine crashes, stashes are gone too...

    Probably its better to keep rebasing and keep amending the commit and force pushing **as long as nobody else is using that feature branch and not going to be merged anywhere else until totally done**
  • 0
    @s4nju1 can't think of another way to accommodate 'on fire, commit, push and leave the building'
  • 0
    Feature takes a long time, changes are in stash only?

    If that's on the local machine, it means a lot of work with no backup because local machines aren't backed up in most companies.
Your Job Suck?
Get a Better Job
Add Comment