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
-
atheist99003yPush your current branch before you try to mess with rebasing, maybe rebase onto a new branch.
So many stories (including me) of people messing up their branch/losing work. -
Voxera115853y@atheist no, do not push a conflict to develop, either resolve it directly or if you want to be careful, create a new clone locally and rebase that, then merge.
-
atheist99003y@Voxera yes I meant push your working branch to a remote. "Local clone" is a remote.
-
Nice. now: Solve the conflict, and make sure you did not break anything before you open the MR.
-
I've been at this for a while and they still get me sometimes. I lost a few hours work the other day
-
asgs115633yMerge conflicts are straightforward
You just choose whose code goes where after doing some thinking and discussing with the people involved in the conflict
But conflicts on a lot of files are a headache -
@asgs conflicts are also a headache when you gotta read someone else's code and it's crap
-
Voxera115853y@NoToJavaScript still better than the alternatives I have used before.
Most of the problems come from bad code or bad organization and not really from git ;) -
I guess, you just cancelled, rebased, and then merged and pushed without even needing to edit anything.
It is GIT after all - not Subversion... -
hjk10157313y@NoToJavaScript I fully disagree with you. Works fine in daily usage.
Conflicts are things that cannot be resolved without analysing two sets of changes. Solving that should be out of the scope of git, perhaps something for autopilot kind of solution.
Related Rants
Got my first merge conflict today 🎉 (haven't worked much with git)
So yay.. I guess 🤔
random
conflict
git