Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
ltlian21966yI 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. -
s4nNan1156yThe 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** -
s4nNan1156y@s4nju1 can't think of another way to accommodate 'on fire, commit, push and leave the building'
-
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.
Related Rants
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.
rant
git
merge conflicts
java