It's a merge conflict

Push your commits before anyone else, so you don't have to resolve any merge conflicts 😈

The best part of having lazy collaborators is that you never encounter merge conflicts.

Thank you dear mr. boss for fucking up our master branch by adding local changes to a 2 months outdated master branch (250 FUCKING COMMITS BEHIND), pull the remote and then just push without resolving any conflicts!!!1!!!

But thank you so much for sending me an email at 10pm asking me to resolve the conflicts.

It is 3 in the morning and it took 1 hour to get it clean.

Sometimes I want to break some necks...

!rant
!!git

Who here uses `master` for development?

My boss (api guy) tried to convince me that was normal practice. I gently told him that it sounded crazy and very very bad.

Here's the dev path I'm enforcing on my repos:

(feature branches) -> dev -> qa* -> master -> production*

*: the build server auto-pulls from these branches, and pushes any passing builds to staging/production.

Everyone works on their own feature branches, and when they're happy with their work, they merge it into `dev`. `dev`, therefore, is for feature integration testing. After everything is working well on `dev`, it gets merged into `qa` for the testers to fawn over and beat with sticks. Anything that passes QA gets merged into `master`, where it sits until we're ready to release it. When that time comes (it's usually right away, but not always), `master` gets merged into `production`.

This way, `master` is always stable and contains the newest code, so it's perfect for forking/etc. Is this standard practice, or should I be doing something different?

Also, api guy encourages something he calls "running a racetrack" -- each dev has their own branch (their initials) and they push to that throughout the day. everyone else pulls from it regularly and pushes to their own branch. When anyone's happy with their code, they push from their (updated) branch to `qa` (I insisted on `dev` instead.)

Supposedly this drastically reduces the number of merge conflicts when pushing to an upstream branch due to having a more recent ancestor node?

I don't quite follow that, but it seems to me that merging/pushing throughout the day would just make them happen sooner? idk.

What are your thoughts?

Me after a large Git merge, after expecting masses of merge conflicts and getting none. Life is good my friend.

Coworker: You've merged the wrong PR. It is broken.
Me: is it marked as broken? Is there a mail marking it as broken?
Coworker: yes. I wrote something in the chat.

Me: 🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕

I do NOT read and click every brain fart from the chat. I had the PR (as reviewer and dependent developer) open on my desk and waited for the coworker to fix his merge conflicts.

OK then, try to revert. Git reset hard. Push -f. Policy does not allow master modification. 🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕

Fuck this company. Fuck the policies. Fuck them all with a chainsaw. Forced me to work 2 weeks more. 17.04 should have been my last day at this circus. Let 3 other guys go to vacation while I have fix their management's mistakes. Fuck. You. All. Eat shit and suffocate in piss.

Fell like I can finally vent this now I've calmed down.

Me: You've fucked the tree again
Junior: No I haven't
Me: It says there "Fixing merge conflicts"
Junior: Well it wasn't me I wouldn't have done a merge
Me: It has your name next to it...
Junior: Well that commit wasn't there a second ago
Me: it's dated for Friday...
Junior: Well if you hadn't committed to master and blah blah blah
Me: We'll if you knew know to use git we wouldn't have this problem.

- Merging 300 files from one branch to another in TFS.
- No merge conflicts.

My first thought:
This can't be right. I must have done something wrong...

Resolving merge conflicts feels like defusing a bomb.

git commit at 5.50 pm
The winner doesn't have to worry about merge conflicts

What your file looks like when it has merge conflicts:

So this bunch of idiots made this huge iOS app using lots of global variables, lots of spaghetti code and basically no separation between logic and UI.
Another bunch of idiots were told to take that iOS app and basically port it to Android. And they ported that same code mess, almost line by line, and adding some weird shit.
Now the HQ of the first bunch of idiots realize that the second bunch of idiots were too slow/inefficient/whatever, and they're now asking US to solve that Android mess and add another shitload of features.
The worst part of it, is that both bunches of idiots are still working on it, so we're basically forced to follow the same shitty style until the first deadline, otherwise we'd die suffocated by stinky merge conflicts. Which will happen anyway because our changes are going to overlap.
Oh, and the PM refuses to understand the disaster coming and there's six hours of time zone difference.

Fuck this shit.

Resolving huge merge conflicts...

!rant

Just pushed commit #512 today.
Was a huge refactoring effort which went sooooo smoothly <3
Pull from parent branch without merge conflicts <33
No issues with deployment <333
AND i'm now on vacation 🏳️‍🌈❤️🏳️‍🌈❤️🏳️‍🌈
Things are perfect

Best : learning git

Worst : couldn't solve merge conflicts in git

What keeps me up at night?
Unresolved merge conflicts.

Holy shit balls it works (so far)

-
So I’ve been working on a project... well feature for the past year (yes 12 whole fucking months - anti agile I know)
And today I got to merge that bitch of a pull request into the current working branch and deploy it to UAT - no conflicts 😵I think I need to put the lottery on tonight!
And some how, by some stupid lucky roll of the dice it just works.

I have never felt so afraid and delighted in my life!

Merge Man!

The power to git merge without conflicts.

I wish there is such thing as branch in a relationship. So that whenever a couple are having a fight, they can create a branch and work their shit out in that branch and eventually merge to the master branch.

Wait
Merge....
That just costs.... more conflicts

Get assigned ticket.
Finish the most of the feature. Finish most of the specs.
Push.

Second dev wants to own accounting half of the ticket.
Rip out half my changes, rewrite specs.
Push.

Code review asks for minor changes.
Finish them.
Push.

Product creep creeps the scope.
Finish the feature again.
Push.

Product creep creep-creeps the scope.
Finish the feature again.
Push.

New release happens.
Merge in master; fix conflicts. Run specs; random unrelated specs fail, some fail intermittently. Rabbit holes of complicated, unexplored, obviously-flawed code.
Fuck that. Push.

First I wanna say how grateful I am that devRant exists, because my friends either don’t understand this vocab or don’t care lol.

Last week I worked on a pretty large ticket, opened a PR with 54 file changes. Just to follow standards I set the PR milestone to a future release version, but the truth is I didn’t care which version this work ended up in— I just needed it to go into the develop branch asap.

Since it was a large PR there was some expected discussion that prolonged its merging, but in the meantime I started a second branch that depended on some of the work from this branch. I set the new branch’s upstream to develop, fully expecting my PR to merge into develop, since that’s what I set the PR base to.

I completed all the work I could in the new branch, and got two colleagues to approve the initial PR so it would be merged into develop, I could add the finishing touch and get this work done seamlessly before the week was over. They approved, it got merged, I pulled develop, and… my work wasn’t there. I went to look at my PR and someone had changed the base branch to a release branch. It was my boss, who thought he was helping. (Our bosses don’t actually work on the same team as us, so he didn’t know. it’s weird. We have leads that keep track of our work instead.)

I messaged him and told him I really needed this in develop, knowing our release branch won’t be in develop for probably another week. I was very annoyed but didn’t wanna make him feel too bad so I said I’d just merge the release branch into my new branch. So many conflicts I couldn’t see straight. His response was “yeah and you’ll probably have a bunch of package manager conflicts too because that’s in that release.” He was right— I have so many package manager conflicts that I can’t even see how many compiler conflicts there are. I considered cherry picking my changes, but the whole reason I set develop as my upstream was to avoid having any conflicts since I’m working in the same functions, and this would create more.

So I could spend the next (?) days making educated guesses on possibly a thousand conflict resolutions, or I can revert my release branch merge and quietly step back and wait for the release branch to be merged into develop.

I’m sure cherry picking is the best option here but I’m genuinely too annoyed lol, and fortunately my team does not care to notice if I step back and work on something else to kill time until it’s fixed automatically. But I’m still in dire need of a rant because my entire plan was ruined by a well-meaning person who messed with my PR without asking, so here is that rant and I thank you for your time.

Greetings from Denmark! Thought I would join after a lot of lurking, and tell a little story, as to how I fucked up when I started in my company.

I've been there around 10 days and had never used git besides just add, commit, and push. I was told to work in feature branches, and I did, I was playing around trying to learn, and got some merge conflicts, made a lot of unnecessary commits etc. I was told to clean it up before I merged into dev. And as I didn't know git I asked how I could do that. I was told I could force push in my branch, and that it was okay as long as it was only inside my branch. I tried that and saw my command line force pushing to all branches including dev, and master. My heart skipped a couple of beats, and I went directly to my Lead developer and asked what happend. He got a bit mad at me for pushing in dev and master, and override all the commits there had been made. I tried to explain I didn't he did not really believe me, I was so nervous. Luckily everything came back to normal with people's local branches being pushed etc. But that day I learned about git's push matching config, and my lead was luckily only mad in the heat of the moment and even apologized for getting mad. Just one of my little fuck up's in my short time as a developer

*git push*

"There are 27 unresolved merge conflicts"

When you go to merge and there's conflicts.

Slack Boss: hey, could you check work of dev that is okey, we want this update fast.

Me: hey, just tell him to open PR and assign me, I will check and merge changes.

Slack notification: Dev: Hey, could you please merge Pull request on the project ?

Me thinking, hmm weird, I didn't get email.
Checking github, 0 pull request.

Me: hey, I don't see any pull request open, and when you make pr, just assign me I will merge it right away.

Dev: takes half a day

Dev: Makes pr and assign correctly me.

Dev on slack: HERE is PR open now @me.

I get 3 notification to see this PR, sure at least it is there.

I check this PR, 50 commits, X conflicts, cannot merge this.

Me: Hey, @dev please fix conflicts in your PR.

DEV: takes another 2 days to respond.

Boss in the meantime: hey, have you pushed those new changes ?
Me: I am waiting for conflicts to resolve.

Dev: I fixed the conflicts @me.
I check the PR conflicts are there.

Me: are you sure you pushed your changes @dev ? I don't see them resolved

Dev: takes another day and pushes changes to resolve conflicts.

Me: merges PR to master becaus he based it on master, I will sync the developer branch myself.

All good, everybody happy.

I write to dev: Next time base your changes on develop branch and resolve conflicts before making PR.

Two weeks later new PR From this dev.

Based on Master, conflicts everywhere.

Ran couple of interviews today I don't think I'm ever gonna forget this guy: He was explaining a time he worked in a team and used version control. I asked how he handled merge conflicts his response:
'If there are merge conflicts I delete their work and use mine, my code is probably better anyway'.

Today I was talking about merge conflicts with a group of devs. One of them asked if any of us had ever rushed to merge a PR before another dev could merge their PR, knowing there were going to be conflicts. Some were more ashamed to admit it than others, but in the end everyone was guilty of doing it at least once :)

Anyone ever do that to avoid being the one who has to resolve a conflict?

I had a nightmare once about git commits and merge conflicts.

forgetting to fix your conflict before production :) technopolis.bg

Finished my project early today. I assumed it would take another day or two since it's primarily research and I had no idea how to progress, but I caught a break and finished it early. I also finished another surprise ticket! yay! I had the rest of the day to myself!

... had!

But then I noticed I had been working on the wrong branch. Fuck. Moving my work over was tedious, as was the cleanup. I kicked myself for good measure. Also, every time I switch branches, I need to run a bloody slow script that runs all the migrations, data tasks, backfills, etc. for the branch. It takes 12-18 minutes. There's a faster version, but it usually breaks things.

Turns out the branch I was supposed to be working on wasn't up to date with master. So I merged that in, leading to....

merge conflicts. Because of course there are conflicts. To make matters worse, I had (and have) no idea which changes were correct because idfk what those 248 new commits are doing. So I guessed at them, ran the script, and (after more waiting) ran a few related specs. Yet more waiting. Sense a pattern here? Eventually they finished, and all the specs passed. H'ray. So I committed the changes, and told Jenkins to kick off a full spec suite, which takes 45+ minutes.

La de da, I go back to cleaning up the previous ticket, pushing reversion commits, etc. Later, I notice the ticket number, look at the branch number I've been working on.... and. Fuuuck. I realize I had put everything on the wrong freaking branch AGAIN. I'm such an idiot. Cue more cleanup, more reversions, running the bloody script again and again. More wasted time, more kicking. ugh.

All of this took well over three hours. So instead of finishing at a leisurely 5:00 like a normal person, I finally stopped around 9pm. and I won't know the Jenkins spec results until morning.

A nice early day?
I should know better.

Ready to finally deploy and... merge conflict :/

Not usually a person to rant about spacing and conventions but this is great.

4 devs, all using IntelliJ. Now IntelliJ auto-changes tabs to spaces which is nice, and GitHub doesn’t really care as long as the spacing is consistent. Now here is the fun part: 2 devs have 4 spaces per tab, 1 has 3 spaces, 1 has 5 spaces.
GitHub merge conflicts everyWHERE.

And yes it isn’t the old 2 vs 4 spaces. It’s 3 vs 4 vs 5 somehow

Wow there are conflicts, please git merge first

Merge conflicts in git I guess 😄

Summary of my week

Day:
Fix merge conflicts at work

Night:
Fix merge conflicts in Skyrim mod scripts

Tunes throughout the work day...

Someone's interrupting:
Queen, Don't Stop Me Now

Working on same bug for hours:
Muse, Supermassive Black Hole

Merge Conflicts:
Jay Z, 99 problems

In the zone coding:
xzibit, Concentrate

All bugs squashed, deployed, going home:
Louis Armstrong, What a Wonderful World

Those pesky merge conflicts

Unresolvable merge conflicts

> make a merge request
> it gets reviewed one month later
> "I can't accept it there's too many conflicts"

Well wouldn't you say that, maybe next time try accepting the MR when I make it and see how that goes

oh, it got better!

One year ago I got fed up with my daily chores at work and decided to build a robot that does them, and does them better and with higher accuracy than I could ever do (or either of my teammates). So I did it. And since it was my personal initiative, I wasn't given any spare time to work on it. So that leaves gaps between my BAU tasks and personal time after working hours.

Regardless, I spent countless hours building the thing. It's not very large, ~50k LoC, but for a single person with very little time, it's quite a project to make.

The result is a pure-Java slack-bot and a REST API that's utilized by the bot. The bot knows how to parse natural language, how to reply responses in human-friendly format and how to shout out errors in human-friendly manner. Also supports conversation contexts (e.g. asks for additional details if needed before starting some task), and some other bells and whistles. It's a pretty cool automaton with a human-friendly human-like UI.

A year goes by. Management decides that another team should take this project over. Well okay, they are the client, the code is technically theirs.

The team asks me to do the knowledge transfer. Sounds reasonable. Okay.. I'll do it. It's my baby, you are taking it over - sure, I'll teach you how to have fun with it.

Then they announce they will want to port this codebase to use an excessive, completely rudimentary framework (in this project) and hog of resources - Spring. I was startled... They have a perfectly running lightweight pure-java solution, suitable for lambdas (starts up in 0.3sec), having complete control over all the parts of the machinery. And they want to turn it into a clunky, slow monster, riddled with Reflection, limited by the framework, allowing (and often encouraging) bad coding practices.

When I asked "what problem does this codebase have that Spring is going to solve" they replied me with "none, it's just that we're more used to maintaining Spring projects"

sure... why not... My baby is too pretty and too powerful for you - make it disgusting first thing in the morning! You own it anyway..

Then I am asked to consult them on how is it best to make the port. How to destroy my perfectly isolated handlers and merge them into monstrous @Controller classes with shared contexts and stuff. So you not only want to kill my baby - you want me to advise you on how to do it best.

sure... why not...

I did what I was asked until they ran into classloader conflicts (Spring context has its own classloaders). A few months later the port is not yet complete - the Spring version does not boot up. And they accidentally mention that a demo is coming. They'll be demoing that degenerate abomination to the VP.
The port was far from ready, so they were going to use my original version. And once again they asked me "what do you think we should show in the demo?"

You took my baby. You want to mutilate it. You want me to advise on how to do that best. And now you want me to advise on "which angle would it be best to look at it".

I wasn't invited to the demo, but my colleagues were. After the demo they told me mgmt asked those devs "why are you porting it to Spring?" and they answered with "because Spring will open us lots of possibilities for maintenance and extension of this project"

That hurts.
I can take a lot. But man, that hurts.

I wonder what else have they planned for me...

"four million dollars"

TL;DR. Seriously, It's way too long.

That's all the management really cares about, apparently.

It all started when there were heated, war faced discussions with a major client this weekend (coonts, I tell ye) and it was decided that a stupid, out of context customisation POC had that was hacked together by the "customisation and delivery " (they know to do neither) team needed to be merged with the product (a hot, lumpy cluster fuck, made in a technology so old that even the great creators (namely Goo-fucking-gle) decided that it was their worst mistake ever and stopped supporting it (or even considering its existence at this point)).

Today morning, I my manager calls me and announces that I'm the lucky fuck who gets to do this shit.

Now being the defacto got admin to our team (after the last lead left, I was the only one with adequate experience), I suggested to my manager "boss, here's a light bulb. Why don't we just create a new branch for the fuckers and ask them to merge their shite with our shite and then all we'll have to do it build the mixed up shite to create an even smellier pile of shite and feed it to the customer".

"I agree with you mahaDev (when haven't you said that, coont), but the thing is <insert random manger talk here> so we're the ones who'll have to do it (again, when haven't you said that, coont)"

I said fine. Send me the details. He forwarded me a mail, which contained context not amounting to half a syllable of the word "context". I pinged the guy who developed the hack. He gave me nothing but a link to his code repo. I said give me details. He simply said "I've sent the repo details, what else do you require?"

1st motherfucker.

Dafuq? Dude, gimme some spice. Dafuq you done? Dafuq libraries you used? Dafuq APIs you used? Where Dafuq did you get this old ass checkout on which you've made these changes? AND DAFUQ IS THIS TOOL SUPPOSED TO DO AND HOW DOES IT AFFECT MY PRODUCT?

Anyway, since I didn't get a lot of info, I set about trying to just merge the code blindly and fix all conflicts, assuming that no new libraries/APIs have been used and the code is compatible with our master code base.

Enter delivery head. 2nd motherfucker.

This coont neither has technical knowledge nor the common sense to ask someone who knows his shit to help out with the technical stuff.

I find out that this was the half assed moron who agreed to a 3 day timeline (and our build takes around 13 hours to complete, end to end). Because fuck testing. They validated the their tool, we've tested our product. There's no way it can fail when we make a hybrid cocktail that will make the elephants foot look like a frikkin mojito!

Anywho, he comes by every half-mother fucking-hour and asks whether the build has been triggered.

Bitch. I have no clue what is going on and your people apparently don't have the time to give a fuck. How in the world do you expect me to finish this in 5 minutes?

Anyway, after I compile for the first time after merging, I see enough compilations to last a frikkin life time. I kid you not, I scrolled for a complete minute before reaching the last one.

Again, my assumption was that there are no library or dependency changes, neither did I know the fact that the dude implemented using completely different libraries altogether in some places.

Now I know it's my fault for not checking myself, but I was already having a bad day.

I then proceeded to have a little tantrum. In the middle of the floor, because I DIDN'T HAVE A CLUE WHAT CHANGES WERE MADE AND NOBODY CARED ENOUGH TO GIVE A FUCKING FUCK ABOUT THE DAMN FUCK.

Lo and behold, everyone's at my service now. I get all things clarified, takes around an hour and a half of my time (could have been done in 20 minutes had someone given me the complete info) to find out all I need to know and proceed to remove all compilation problems.

Hurrah. In my frustration, I forgot to push some changes, and because of some weird shit in our build framework, the build failed in Jenkins. Multiple times. Even though the exact same code was working on my local setup (cliche, I know).

In any case, it was sometime during sorting out this mess did I come to know that the reason why the 2nd motherfucker accepted the 3 day deadline was because the total bill being slapped to the customer is four fucking million USD.

Greed. Wow. The fucker just sacrificed everyone's day and night (his team and the next) for 4mil. And my manager and director agreed. Four fucking million dollars. I don't get to see a penny of it, I work for peanut shells, for 15 hours, you'll get bonuses and commissions, the fucking junior Dev earns more than me, but my manager says I'm the MVP of the team, all I get is a thanks and a bad rating for this hike cycle.

4mil usd, I learnt today, is enough to make you lick the smelly, hairy balls of a Neanderthal even though the money isn't truly yours.

I experienced merge conflicts for the first time.

I. Hate. Them.

Other Dev: I worked really hard over the weekend to get the issue fixed, I raised a PR but it has a zillion merge conflicts. Would you mind taking a look at it?

Me: Ok. *Changes base branch away from Master.*

Other Dev: Whoa! How’d you fix them that so fast???

Me: Experience.

Treat yourself to an early weekend

Look at that. The very fucking smart colleague spent 40 days implementing a repository pattern (WHEN WE'RE USING AN ACTIVE RECORD ORM), breaking stuff left and right. Does he use that fucking pattern at the very least?

Of course he doesn't. And along the way he's making sure to create conflicts with the stuff he broke (and I'm fixing). By the time I fix the merge conflicts of one commit, he pushed 6 of them.

When some one at the company decides to branch off from the main codebase and end up with several outdated and separetely modified branches for two years.

Yeah nice work genius and good luck with resolving over 250 files of merge conflicts.

Just kill me now 😭

When you upstream your android kernel without any merge conflicts

I wish my classmates didn’t know that I’m good at programming.

Recently, more and more often I am being reached out to by my classmates (and especially by one individual) about the problems they’re having issues with. For example yesterday, a guy fucked up his Git commit and made a bunch of merge conflicts, so I helped him fix this, which then lead to WinForms having multiple declarations of same objects.

And I really don’t wanna be rude, and I always try to help, for the love of god - stop bothering me every 5 minutes while I code, or at 10 PM while I wanna chill out.

Most of the things they have problems with can be solved by 2 minute Googling and I strongly believe that at the university level, you should be able to find solutions for your problems yourself - especially when you’re a programmer.

Current work project: Ok where is the master branch?
Coworker: Oh we lost that one a few months ago due to some merge conflicts...

When a co-worker casually tells another co-worker "We're going to have so many merge conflicts"

I panic like I'm fucking drowning when going through git merge conflicts via command line

I just broke out of merge-hell.... It was a mere 2 and a half hours... But my migraine says it was eternity.... 😶

There is this project where the develop branch is "discontinued" because this moron "finished" a feature that is all fucking broken and I could not figure out how to solve all those merge conflicts...

I just gave up and told my stupid boss who just nods and laughs at everything... If it ever comes up I'm gonna tell them to get the fucker to solve it.

Me:
* Builds Project and Hosts it *
* thinking * : * ' I don't really need to push to Master, I'll just push it to the deployed branch *

Me: * tests project from host *

Me: * sees a bug, fixes it and rebuilds the project, hosts it and pushes code to deployed branch *

4Hrs Later:

Colleague: Dude did you see the Typos you made? Fix them!

Me: In my defence, I wrote this at 4am in the morning, did not sleep for 2 days.

Colleague: Don't Care, fix it.

Me: *Creates Hotfix Branch from Master*
* INSTALLS DEPENDANCIES AND FINDS OUT A NEW VERSION IS OUT AND UPDATES THAT AS WELL *
* Runs Project and finds out it's not the hosted version. *
* Merges Deployed Brunch to Hotfix Brunch and this happens *

Error Message: Unexpected token

620 Merge Conflicts

🤦🏽‍♂️🤦🏽‍♂️🤦🏽‍♂️

From a Dev at my old place: Don't use git for such a small project, I think we should use email to send our code to each other.
Turned out that this "small project" was a piece for a larger project.

Also turns out there's such a thing as merge conflicts outside of git.
Our code was broken for 3 days once because of his shitty advice.

Yesterday I had to merge new features. As these have been developed by one developer, I thought "hey, that'll be no problem". Little did I know that every one of the 6 branches had merge conflicts *sigh*. These merge conflicts were so severe, that there where sometimes two methods in the same class with the same name doing different stuff in each branch... Normally I would tell her to fix her stuff but as she is on vacation right now, I had all the fun resolving the conflicts of code I hadn't written and repairing the failing unit tests she wrote.

The best thing is that our software will be featured in one of the most renowned business magazines at the end of the week while simultaneously being presented at a congress in Berlin in front of over thousand of potential new customers. So these knew features have to be running stable in production by then... Needless to say I had a great day yesterday and will have an amazing upcoming week 🎉

Today is a great day ! Deadline is tomorrow, fixed all the issues, looks like everything works...

...

CONFLICT (content): Merge conflict in xyz
CONFLICT (content): Merge conflict in abc
CONFLICT.....
...
Automatic merging failed; fix conflicts and then commit the result.

I hate my life :)

Merge conflicts are such a pain in the ass 😥

Conflicts, conflicts everywhere.

Merge VS Rebase:
- Did you pick a side?
- Practical tips? Like dealing with merge conflicts
- Have you ever regretted using either?

My answer
* My team squash-merges all branches to master so we don't really care what the branch history looks like. Master history should be pretty - but a branch history can be ugly and filled with a dozen commits.
* Practical tip 1: use `git config rerere.enabled true`. rerere stands for "reuse recorded resolution" and this means if you rebase often you don't have to resolve the same merge conflict twice.
* Practical tip 2: use `git commit --fixup oldcommithash` and then rebase with `--autosquash`
* I like using Rebase. But I have regretted the amount of time I've spent on trying to rebase old branches with many commits only to give up and to `git rebase --abort` since I realised I couldn't handle trying to reapply all the commits chronogically as the changes in the 1st commit were no longer relevant.

INTELLIJ YOU PIECE OF SH*T, I CLICKED "SMART CHECKOUT" NOT MERGE 2 UNRELATED BRANCHES, SCREW UP MY MASTER AND DON'T LET ME RETURN UNTIL I FIX ALL MERGE CONFLICTS.

We're having a mini-hackathon at our school last Saturday as a final exam of our Web Engineering course, showcasing what we learned throughout. The theme is all about helping university students gain their productivity and improve their interaction with technology.

Me and my team tried to create a note-sharing platform for students. We loved the idea and we're so excited to create it. But excitement turned into shit hole during development.

A fuckton of merge conflicts, divisive code conventions, and usage of god-awful Bootstrap for front-end came in. 😱😬😣

Despite these things, we are able to win the hackathon (i still can't believe we won). but he worst part of winning is that the prize is not cash nor the internship (the judges are from the company who somehow looks for interns), but fucking useless GIFT CARDS!!

But in the end, we're proud of it. I thought that it will be just a concept but in the end, it became real and it turned out to be great. ☺

The one skill I know that I am really proud of is GIT.

Put me into trouble with merge conflicts.
Saved my life with its version control.
Always had an adventurous ride with Git. Hope to have many more such rides and get to learn more about you.

We had 1 Android app to be developed for charity org for data collection for ground water level increase competition among villages.

Initial scope was very small & feasible. Around 10 forms with 3-4 fields in each to be developed in 2 months (1 for dev, 1 for testing). There was a prod version which had similar forms with no validations etc.

We had received prod source, which was total junk. No KT was given.

In existing source, spelling mistakes were there in the era of spell/grammar checking tools.

There were rural names of classes, variables in regional language in English letters & that regional language is somewhat known to some developers but even they don't know those rural names' meanings. This costed us at great length in visualizing data flow between entities. Even Google translate wasn't reliable for this language due to low Internet penetration in that language region.

OOP wasn't followed, so at 10 places exact same code exists. If error or bug needed to be fixed it had to be fixed at all those 10 places.

No foreign key relationships was there in database while actually there were logical relations among different entites.

No created, updated timestamps in records at app side to have audit trail.

Small part of that existing source was quite good with Fragments, MVP etc. while other part was ancient Activities with business logic.

We have to support Android 4.0 to 9.0 of many screen sizes & resolutions without any target devices issued to us by the client.

Then Corona lockdown happened & during that suddenly client side professionals became over efficient.

Client started adding requirements like very complex validation which has inter-entity dependencies. Then they started filing bugs from prod version on us.

Let's come to the developers' expertise,
2 developers with 8+ years of experience & they're not knowing how to resolve conflicts in git merge which were created by them only due to not following git best practice for coding like only appending new implementation in existing classes for easy auto merge etc.

They are thinking like handling click events is called development.

They don't want to think about OOP, well structured code. They don't want to re-use code mostly & when they copy paste, they think it's called re-use.

They wanted to follow old school Java development in memory scarce Android app life cycle in end user phone. They don't understand memory leaks, even though it's pin pointed by memory leak detection tools (Leak canary etc.).

Now 3.5 months are over, that competition was called off for this year due to Corona & development is still ongoing.

We are nowhere close to completion even for initial internal QA round.

On top of this, nothing is billable so it's like financial suicide.

Remember whatever said here is only 10% of what is faced.

- An Engineering lead in a half billion dollar company.

Trying to resolve merge conflicts and you cant remember which changes are the ones you want to keep. Lesson learned, make sure your pull requests dont sit waiting for weeks while master is happily being worked on.

So there is a 50/50 chance I am getting flamed af tomorrow during code review because of my branching/merging actions on thursday and friday... Merge conflicts... We all love them...

*working at a project, currently creating commits and pushing to remote

I created an early PR with a title [UNFINISHED] and [NOT YET DONE]. I'm really not finished yet. lots of stuff still need to be committed and pushed to repo

And suddenly, I find out that my team mate - just out of the blue without any prior warning - MERGES THE PULL REQUEST

"oh hey there are conflicts in the pr you made"

YEAH WELL MAYBE TRY GETTING YOUR HEAD OUT OF YOUR ASS WHAT IS WRONG WITH YOU ARE YOU EVEN SANE

So now what happened is half of my commits are merged, he didn't tell me, i pushed more commits, branch recreated, and then he reverts the merge. so now everything is really messed up :)AS)D(F)AEF)SDF)AW)sfdjsigkl;zfghlkkj ghaslkj;gabsd;lkgjabslkfgh GET YOUR HEAD OUT OF YOUR ASS I WANT A PROMOTION

Take your time with merge conflicts, and put the entire file in another editor in case you really mess up.

When you offer to help out a fellow coworker on the top priority feature he is developing and he just sends you the branch and stops working on it.

So my colleagues don't proactively do PR reviews, even when they're assigned to them, unless asked for the n-th time by me or the PM.
In the meantime other PRs get merged, I need to merge master in my branch, and solve conflicts every time so that it is eligible for merging.
Additionally, while reviewing, the requierements engineer realizes that there were corner cases not initially covered in the ticket description, so I get review findings about covering these.

The day we had to have an app ready for an upcoming demo. Management said everything needed to be done by the end of the day. My change was done, but was dependant on another change being merged first. I had been in the office since 8am. It didnt get merged until 5pm. I was in the office until 8pm trying to fix the insane merge conflicts. In the end i gave up and went home. The next day we discovered that the "deadline" was made up anyway so we still had time. I wanted to flip every single table in that office.

I have a co-worker who won’t stop “refactoring” our codebase. He will go on a long tangent — under the guise of working on a proper story — and then reveal proudly after a few days that he now introduced a new middle-layer into the code which will help us such and such.

I have never seen any benefit from this. I think sometimes cleaning up variable names is nice, but a lot of the things just add noise and complexity. He’s a junior dev, I’m a senior dev. My progressional opinion is that he is doing a bad job. Management doesn’t know the full extent and the lead programmer scolds him every now and then but in the end let’s the code changes pass code review. “It has already been implemented so what’s the harm”.

Then the rest of us are stuck with horrible merge conflicts. I recently noticed that some new business-important unit tests that I wrote were mysteriously gone. Oops — lost in some misguided refactoring I guess. I’m assuming they were failing after the refactor, so clearly they had to go... Fortunately the underlying logic still works I think.

His main tactic in all of this seems to be to just use argumentative stamina. He will lose discussion after discussion but doesn’t seem to care. He’ll just talk and talk. And the in the end the lead tech gives in. And/or doesn’t have the energy to catch the error introduced.

I swear, the company would be better off without him. Maybe even better if we keep paying him but he just cleans the toilets instead. Sometimes I almost believes he gets up in the morning to come to work and just fuck with people all day.

Typical Git work flow on a feature branch:

Commit#1 : The silly feature itself that took 10 minutes to code
Commit#2 : Added unsaved files
Commit#3 : Fix unit tests
Commit#4 : Fix
Commit#5 : Fix
Commit#6 : Fix
Commit#7 : Various Fix
Commit#8 : Added unsaved files
Commit#9 : Merge
Commit#10 : Fixed unit tests
Commit#11 : Code Review tasks
Commit#12 : Revert- Code Review tasks
Commit#13: Refactor part 1
Commit#14: Refactor part 2
Commit#15: Deleted unit tests
Commit#16: Added checking for null
Commit#17: Completely different feature's bugfix
Commit#18: Code review spacing corrections
*Approved*

Trying to merge, then merge conflicts.....

I was minding my own business, fixing merge conflicts for my project lead when it struck.
There, in the middle of a React.js component, was a table, used not for displaying data, no, but for styling a form, which was not a form, but a series of table rows.
I feel sick

The pain of merging the conflicts of code on which you never worked on ... ahhh omfg ..

Sample Merge Conflict 🤣

Whenever i see a door with Push sign, I Pull first to avoid conflicts...

Git, conflicts

Story of my day
<<<<Head
code
=======
my code
>>>>>>>

Had a nasty day

Me on getting a huge bunch of merge conflicts!! 😵

Have to follow same coding conventions of colleagues just to avoid merge conflicts.

half of my career has gone into resolving merge conflicts...

I just hate merge conflicts in big PR!

Okay, seriously, who invented merge conflicts? I want names! It's like playing Jenga with code, hoping your masterpiece doesn't topple over. I've seen more ">>>>>> HEAD" blocks than actual code lately.

Can we all agree to commit more frequently and save my sanity, please?

My "senior developer" colleague just committed 300Mbs worth of node modules in addition to static files bundle. So not only I have to wait 20mins for the changeset to download on this god damned internet over barrels connection but also resolve merge conflicts on 100+ files. You think that was a mistake? Oh no I've asked him about it and it was intentional ...

Since gitkraken is turning into such a bitch, I've searched for alternatives once again, as usual none of the competitors still implemented a fraction of it, after so much time.

Sublime Merge looked promising, but then half the time fucks the history graph, fails to remove remotes and more funny stuff I don't want to mess with.

Github Desktop I didn't even try because it didn't seem to have any proper history graph to begin with.

For now ended up on sourcetree, though I really do miss having commit message and description be two separate inputs, have done the most basic merge for now, so it's a to be continued experience.

Mostly afraid of how it'll show merge conflicts and commit view, as from what I gathered it doesn't fullscreen when you click a commit, but instead shows an awkward small screen at the bottom of the graph split further in half with the avatar and commit message.

Edit: oh for fucks sake, just noticed it doesn't even have linux support, god damn it.

When you work with people who don't understand git merge conflicts yet...

Just happened today!

So since this morning we've been trying to get our website ready for UAT deployment Monday next week, even though we only were told of it yesterday. Since we had some critical merge conflicts to unscrew on our dev branch for promoting to UAT, we sent a warning to everyone on our hipchat group

Dev team: @all please don't commit anything to the repo for an hour or so while we get the branch good for dev and uat build

Tech lead: ok

That should be enough warning, right? Surely our tech lead, who has been piling up our scope creep trying to please our stakeholders, understands well enough not to do a single goddamn thing on our repo until we sort it out, right?

Nope.

10 minutes later our tech lead pushes several changes that not only break our builds but also remove all our configuration transformations. I just stormed out of the office to avoid sending her on a one-way ticket to slapsville and fuckyoutown. Geez goddamn louise.

Why do some developers rebase or resolve merge conflicts when you can just email each other changes and force push?

Ever tried explaining GitHub to someone? I swear it's like trying to teach a dog to ride a bike. You can try, but it's probably not going to end well.
Okay, rant over. Back to coding... and dealing with merge conflicts... and pull requests... and GitHub issues... sigh.

"No merge conflicts, ready to commit."

Such sweet words from TortoiseHg, and it's not even valentine's day!

One of many merge conflicts...

How to deal with merge-conflicts:

1. You don't
2. Just clone the whole repo anew again and start over dude

Pffft. How did you manage to guide the intern to cause merge conflicts with his own code? Genius

today:
Committed my code for Code review
solved 23 Merged Conflicts
Fixed 65 Load project Error.
Fixed another 8 Compiler errors because of mistake made in Merge conflict.

I wanted to do coding today... I really do..

I just love how XCode handles git merge conflicts. Especially in project meta files. ❤️

So I thought I knew source tree, apparently I do not... Lost a week's worth of work, went to history, saw someone removed it with a commit, and now I'm getting blamed for my own work 'disappearing'. The reason I am being told I am to blame is how I control my branches... So how I do it is that I keep a local copy of the master branch, I keep it updated and monitor it for changes regularly (meaning fetch and pull cause double tap..) before I do a merge, I check for any new code on master again, then using the local copy of master, which I just updated, I pull the master changes into my branch, deal with any conflicts, build and done. Then I request my changes into master once I am happy everything is good.

My question is, clearly there is something wrong with the way I do things, so please source tree users, what is the most fool proof way to pull latest from master so that I don't loose code? 😔

git rebase > git merge

I'm honestly tired of colleagues completely fucking up the git history along with creating conflicts for no reason at all.
How do you even manage to "recommit" changes when merging?

I can't even squash properly because there are 5 merge commits on the feature branch. Fuck off

When you try to merge branches :D

Created a merge request for a big issue last week. Some dumbass co-workers merged several other stuff for tiny shit issues that lead to many merge conflicts now because they didn't pull before..
Nevermind.. will be merging develop into my branch for the third time now.. Got already 20h of extra work because no one minds to merge my request because it's so big and someone might have to check the commit messages what really happened..
Conflicts suck! Co-Workers suck!

Questions/best practises for git?

For example:
- use present tense in commit messages. (why though?)

A friend of mine also starts his commit messages with either [Task] or [Cleanup]. Useful for finding Commits in Gitlab etc, because only the first line is shown from the message.

Also, one teacher recommended the usage of branches and the other didn't because of alot of potential merge conflicts when working in a Team or a larger Collaboration. What are your thoughts?

Sorry for the messy post, have a hangover

My pull request has several merge conflicts but I don't cry. How strong am I?

Got through 4 hours of merge conflicts before pushing to prod... I imagine this is how doctors feel during an operation... #ef

My little brother started college this year. He hasn't decided what he wants to do, so he took classes in finance and computer science. During finals week, he comes to me ranting about GitHub. "It has to be the most useless tool ever made", he said.

His teachers made him use it without any explanation on HOW to use it. His whole team was working out of a single branch, downloading the zip every time, and struggling to fix merge conflicts. At no point was this ever corrected. This has been going on for an entire year!!!

Safe to say, I spent the afternoon walking him through more productive ways to use GitHub and showing him why it's not "the most useless tool ever made". I don't get why teachers for students to use tools but fail to ever explain how. All that is going to do is deter kids from using tools that could save them when they get a real job.

Merging one git branch into another when it conflicts an added line or function.

Like really? You can't handle ONE LINE being added?

Love it when the maintainer of an open source project you contribute to runs a linter over the whole codebase and force pushes the changes to origin master so now all the Pull Requests in the queue have to be rewritten and have tons of merge conflicts to resolve. Awesome! 😠

What if all devs worked together to create a programmed God which only obeys devs? And hates bosses....
I think we can do it guys!

Ps. Bagsie not dealing with merge conflicts.

Your life's fucked up if you get several merge conflicts, and you are using Eclipse IDE! 🤯

Made lots of features to a side project that I was gonna publish in uni. There was some merge conflicts. And I tried to fix by copying files from a backup of the repo I was using.

Accidentally deleted the latest repo instead of the backup. All additions were uncommitted.

That was when I started taking special care with VCS

Just found out that something like this would actually work in Java:

int a = 2;
switch(a) {
case 1:
int b = 1;
break;
case 2:
b = 2;
}

I know about the variable scoping part, but that doesn't means if the language allows this kind of shitty code you should use it.. Fuck took me 15 mins to resolve the merge conflicts. As during merge the 1st case was partially removed. And the code was filled with these kinds of logic. This could have been done in a minute without the shitty code..

Somehow I don't like merge conflicts 🤕

My work product: Or why I learned to get twitchy around Java...

I maintain a Java based test system, that tests a raster image processor. The client is a Java swing project that contains CORBA bindings to the internal API of the raster image processor. It also has custom written UI elements and duplicated functionality that became available in later versions of Java, but because some of the third party tools we use don't work with later versions of Java for some reason, it's not possible to upgrade Java to gain things as simple as recursive directory deletion, yes the version of Java we have to use does not support something as simple as that and custom code had to be written to support it.

Because of the requirement to build the API bindings along with the client the whole application must be built with the raster image processor build chain, which is a heavily customised jam build system. So an ant task calls out to execute a jam task and jam does about 90% of the heavy lifting.

In addition to the Java code there's code for interpreting PostScript files, as these can be used to alter the behaviour of the raster image processor during testing.

As if that weren't enough, there's a beanshell interface to allow users to script the test system, but none of the users know Java well enough to feel confident writing interpreted Java scripts (and that's too close to JavaScript for my comfort). I once tried swapping this out for the Rhino JavaScript interpreter and got all the verbal support in the world but no developer time to design an API that'd work for all the departments.

The server isn't much better though. It's a tomcat based application that was written by someone who had never built a tomcat application before, or any web application for that matter and uses raw SQL strings instead of an orm, it doesn't use MVC in any way, and insane amount of functionality is dumped into the jsp files.

It too interacts with a raster image processor to create difference masks of the output, running PostScript as needed. It spawns off multiple threads and can spend days processing hundreds of gigabytes of image output (depending on the size of the tests).

We're stuck on Tomcat seven because we can't upgrade beyond Java 6, which brings a whole manner of security issues, but that eager little Java updated will break the tool chain if it gets its way.

Between these two components we have the Java RMI server (sometimes) working to help generate image data on the client side before all images are pulled across a UNC network path onto the server that processes test jobs (in PDF format), by reading into the xref table of said PDF, finding the embedded image data (for our server consumed test files are just flate encoded TIFF files wrapped around just enough PDF to make them valid) and uses a tool to create a difference mask of two images.

This tool is very error prone, it can't difference images of different sizes, colour spaces, orientations or pixel depths, but it's the best we have.

The tool is installed in both the client and server if the client can generate images it'll query from the server which ones it needs to and if it can't the server will use the tool itself.

Our shells have custom profiles for linking to a whole manner of third party tools and libraries, including a link to visual studio 2005 (more indirectly related build dependencies), the whole profile has to ensure that absolutely no operating system pollution gets into the shell, most of our apps are installed in our home directories and we have to ensure our paths are correct for every single application we add.

And... Fucking and!

Most of the tools are stored as source bundles in a version control system... Not got or mercurial, not perforce or svn, not even CVS... They use a custom built version control system that is built on top of RCS, it keeps a central database of locked files (using soft and hard locks along with write protecting the files in the file system) to ensure users can't get merge conflicts by preventing other users from writing to the files at all.

Branching is heavy weight and can take the best part of a day to create a new branch and populate the history.

Gathering the tools alone to build the Dev environment to build my project takes the best part of a week.

What should be a joy come hardware refresh year becomes a curse ("Well fuck, now I loose a week spending it setting up the Dev environment on ANOTHER machine").

Needless to say, I enjoy NOT working with Java. A lot of this isn't Javas fault, but there's a lot of things that Java (specifically the Java 6 version we're stuck on) does not make easy.

This is why I prefer to build my web apps in python or node, hell, I'd even take Lua... Just... Compiling web pages into executable Java classes, why? I mean I understand the implementation of how this happens, but why did my predecessor have to choose this? Why?

Yesterday i went coding, tired as hell. I told myself “Atleast i get smth done“ i was wrong. Redid everything and now expect many merge conflicts when i get home

Waiting to merge the rest of the team’s new code because you don’t want to deal with migrating your test account to a new backend until your feature’s ready, finally finishing your feature (!) and then seeing 100+ merge conflicts and realizing you‘re better off just re-implementing all your feature code into a new branch, & deleting every trace of your old branch so nobody sees the 1000+ merged commit mess you’ve made -_- today was supposed to be easy...

WHY WOULD ANYONE NEED THREE DEPENDENT SUBMODULES ANYWAY?!?! 😩

My worst nightmare, merge development into master and resolve conflicts

Management wanted all features finished by close of business yesterday to start testing before a demo next week.
I started work at 8am to get my task out of the way early. Unfortunately there was another persons task that mine was dependant on. I kept telling people it needed to be merged so i could integrate it with my changes.
It was merged at 5pm.
I was still fixing merge conflicts at 8pm. 😑

That awesome moment when there are no merge conflicts.

Ever encountered merge conflicts because of spaces and indentations :-|

When you git pull and there are merge conflicts and you commit without resolving conflicts and you push 😂😂

Nooo.. merge conflicts that not can be resolved automatically.. on a friday afternoon :(

That moment when you go to merge a branch and realize no one rebased for 3 weeks and your whole day will be merge conflicts...

npm has to be the single worst package manager on the planet... Trusting devs to use semantic versioning properly and forcing devs to trust authors of dependencies to use it properly is nothing short of insane. The package-lock that is "supposed to be version controlled" causes *constant* merge conflicts. Using shrinkwrap in its place is borderline useless because it Doesn't. Lock. High. Level. Dependencies.

I don't know who designed this, but I want to give them a very bad day for every hour I've spent trying to lock versions correctly on a live project.

Not to mention requiring root by default to install things that can just run whatever they want is ludicrous.

about 12 hours, from 8am - 8pm
We were working on an iOS build for a demo and were told that day was the deadline for having code merged. I got kinda shafted cos I needed someone elses code merged before I could finish mine. It got merged at like 5pm and then everyone went home leaving me with a ton of merge conflicts to deal with. I gave up at 8pm and went home. Found out the next day that the deadline was horse crap anyway....

when you don't recall changing anything (after resolving merge conflicts on other branches) but when you change back to your feature branch you were debugging

the page doesn't work so you can't even debug it

so now you have to figure out why the page doesn't even load

fml

After working in this godforsaken clusterfuck for half a decade, where no one knows what the fuck git is, and they just use a single git branch like SVN…

Ive oddly come to like resolving merge conflicts. It’s strangely calming, almost like playing games.

Do let me know how fucked in the head I am, my emotional compass is probably buried 4 feet deep under a pile of retarded commits.

Had a branch that I was ready to push to a remote and open a PR tp this big open source project.

I was making a git pull from their master in order to not have merge conflicts on remote... and then I see that their master branch already had the feature that I was trying to implement, merged 10 days ago.

A lot of work... for nothing.

Because I had to wait on some old ass company policy process bs on open source software to give me permission to push to a codebase we're using in their internal product.

Well in today's meeting I made a reference to this... they still insisted on intellecxual preperty bs. Im questioning their ability to think.

Im pushing fixes and enhancements to that without permission, idgaf

I just picked up a hobby project which I hadn't worked on in a while and started doing some major refactoring. However, I forgot to pull before I started and didn't realize that I made some updates on a different pc. Then as I wanted to push a ton of changes I noticed... I didn't even attempt to merge because it was one giant pile of shit conflicts - and I didn't remember what changes I had made earlier. So I decided to say fuck it and
$ git force --push

Feels *so* much better than pulling my hair out over conflicts :P

Things I have come to expect in my future since being on DevRant: shitty timelines, both funny and cruel office pranks, PMs who have no idea what they are actually managing, clients and some coworkers not knowing what my time and work is worth, merge conflicts for reasons unknown

I need some help. I have a 1 months old MR in gitlab with 5 commits of a feature that I have to revert.

I have hard time understanding how to solve git revert conflicts and frankly this three windows GUI on intellij idea is very confusing to me. I am like afraid that I will accept a bad change or miss something.

Is there any other way to make this merge conflict solving easier? I was thinking maybe I could just rebase to head where I added my commits, revert them without conflicts and then rebase that branch on latest develop?

In that case I would be solving merge conflict by adding stuff instead of removing old stuff and being afraid that I will mess up something. Goal is to create a revert feature MR.

Merge conflicts. Still have no idea where they're coming from.

'git pull --rebase' a day
Keeps the merge conflicts away

One thing I absolutely hate is resolving merge conflicts but if Git wouldn't have been there, I would have not liked that..

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.

Slowly I'm learning not to give a shit anymore. This project I'm on can burn. I'll make progress and help out my fellow devs, but if it takes me longer than estimated to complete my tasks because of the unforeseen technical debt arising from this piss-poor excuse of an application design (plus we're 13 devs working on like 5 different feature branches - God help us with our merge conflicts) then so be it. If my tech lead complains, he can find someone else to take the wheel.

Recently i switched from using git with gui tools to just console, and love the speed and reliability increase, but guys do you really resolve merge conflicts in console? Is it effective/worth getting used to?

Waiting for code reviews from the lead dev. Often it ends with a branch sitting untouched for weeks and becomes a pain of merge conflicts.

When a junior developer forks new feature branch from his old feature branch and not from develop branch causing merge conflicts later!

If i have 2 branches on git
- main
- infra

You cannot push directly to main. It is forbidden. You can only merge to main

Now. Once i push to infra branch. Assuming all the shit went good pipeline passed tests passed etc. Then i merge it to main.

Now

Locally while im on infra branch. I have to pull latest changes from main otherwise ill fuck up everything and cause conflicts.

After trial and error i realized i just have to do:
git fetch

This fetches all shits from main (defaukt branch) into infra branch. And now it works. No rebase. No pull. Wtf?

Is this the correct way to do it?

Also i need someone to explain this to me like im 5:
- git pull
- git pull --rebase
- git fetch

What is the difference between those 3 commands? I tried googling and chatgpting but i cant seem to understand any explanation. Explain it to me in simple terms with examples

I have a git feature branch with my commits but also have merged the changes from the main branch to resolve merge conflicts before PR.

But now need to create a special release with just my changes.

So I think have to cherry pick all my commits on my branch some the last Release. How can I do that?

Develop (others) + Feature => Develop

Want to create new branch

Last Release + Feature (but only my commits since last Release)

Had a new dev take us to merge conflict hell due to rebasing... we have meeting saying we are going to do git flow.....

manager who agreed makes branch project/releaseName based off of develop only to have us mr to that branch to then mr back to develop....

Had massive conflicts mr into that branch (i kept up to develop) and then had conflicts mr that branch to develop........ on a sunday night... great

The Code Abyss Beckons! 🤯

Hey fellow devs, brace yourselves for a wild ride into the chaotic realm of code confessions and debugging dramas! 🎢💻

So, here I am, standing at the precipice of my latest coding adventure, armed with a keyboard and a questionable amount of caffeine. 🚨☕

Today's quest involves unraveling the mysteries of a legacy code that seems to have been written in a language only decipherable by ancient coding sages. 😱📜

As I navigate through the nested loops of confusion and dance with the dragons of runtime errors, I can't help but wonder: Is this what the Matrix feels like for developers? 🕵️‍♂️💊

In the midst of my debugging odyssey, I stumbled upon a comment in the code that simply said, "// Abandon hope, all ye who enter here." 🏴‍☠️📛 Well, isn't that reassuring?

And then there's the moment when you finally fix that elusive bug, and you feel like you've just tamed a mythical creature. 🦄✨ Victory dance, anyone? 💃🕺

But let's not forget the rubber duck sitting on my desk, patiently listening to my monologues about algorithms and existential coding crises. 🦆🗣️

So, dear coding comrades, how's your journey through the code abyss going? Any epic wins or facepalming fails to share? Let the rants flow like a river of improperly closed tags! 🌊🚫

May your semicolons be where they should and your documentation be ever truthful. Happy coding, and may your merge conflicts be swift and painless! 🌈🤞

#CodeOdyssey #DebuggingDrama #DevRantChronicles

There are xxx merge conflicts, deadline is tomorrow

This is so fucking stupid. Fuck. When they log defects on jira for different issues on the same page but in different tickets I end up having merge conflicts with myself. Like are you fucking kidding me?

Or company banned DourceTree so everyone had to switch to just using git shell.

Except me... I installed GitExtensions which is allowed.

I can't decide if I'm a git noob, better at being lazy, or more efficient.

I do use she'll for certain things like deleting, listing branches but for commits and resolving merge conflicts... still prefer gui

Have a question about git rebase with android studio.

So I have a feature branch which I finished working on, I made a pull request to develop branch and now I see many conflicts because develop is few commits ahead.

In android studio I switched to my feature branch, then did a git rebase develop and resolved all conflicts. After conflicted files were fixed I did a git add conflicted_file and continued with git rebase --continue until the end.

Now everything is finished. I have a local feature branch that was rebased to current develop, and I resolved all conflicts.

Problem is when I do a git push to my remote feature branch, I get a merge conflict error conflict from android studio and now I have to solve all merge conflicts yet again for some reason.

What I am doing wrong?

Tfw 1395 conflicts after ‘git merge develop master’, three days before deadline

I have been fixing tests all day and some other dev managed to cause merge conflicts, now my branch is in a permanent state of merge after I pushed with force.. I'm done...
This crisis is also hitting our company and don't know what that's means of me as I just joined...

I'm glad it's weekend

Question about scrum in terms of developer/QA workflow. We have a problem in our team: basically when a dev submits an MR it needs to get 2 approvals from devs and then task is marked ready for qa. Now problem here is that qa takes 2-3 weeks to get to the task and when they do usually MR has merge conflicts and since QA are quite new-ish they have to wait for dev for conflicts to be resolved, ergo rendering the MR unable to be tested until dev resolves the conflicts.

Our teamlead proposes to solve this by forcing devs to rebase everyday (even if QA will get to working on the task 3-4 weeks later). Problem with that approach is that each conflict resolve removes approvals. So I had a situation where in 3 weeks I rebased like 15 times and 5 times I had resolve coflicts and because approvals were lost I had to annoy all devs and ask for reapprovals. And this is only with 1 MR. Now imagine all devs doing rebasing daily and spamming each other for reapprovals. Its not efficient.

Anyone could advice how to solve this issue?

git rebase >>> git pull/git merge

Git Question:

Semiunusual state here. Have a branch I'm trying to merge into develop and there are a LOT of merge conflicts, some head way has been made in this merge branch..

HOWEVER

I'm wondering is there a way to "suspend" the branch/merge progress and go back to develop?

getting tons of fucking merge conflicts on rebasing remote branch with current master because that mockerfucking code review is still pending

when you merge changes from other branch, made by other team, and see that huuuuge old project is now basing on dependency injection instead of one singleton- manager approach. Even merge conflicts look beautiful!

2 weeks+ ago I made a PR into our codebase containing sample refactor that streamlined a significant portion of code. Also, I did refactor only on two handler packages (for MVC folks, that's Controller) as proof of concept, to figure out how convinient / logical the part would be for everyone.

We have rule of 2 approvals for merge (for 5 team members)

While writing refactor, it obviously blown up a lot of unit tests, but still coverage was fairly poor (that stuff was rushed, there was back than no time for unit tests). After my refactor I spent couple of days writing tests that hit fairly sweet (comparatively) coverage. (I managed to bump coverage from low 20s to high 80s, and have less code for tests)

I got first approve pretty much immidietely, other team member was on vacations, and 2 of them forgot.

We generally try to close PRs fairly quickly (usually same day kind of deal), but that one was just.. hanging in there. So I pinged everyone to re-check it to greenlight it but of course, loo and behold, merge conflicts arised. I ended up fixing actual logic (just some method signatures changed, not a big deal) and ran the units.

So, one of that handlers got quite a few of edits, and guess who is pretty much rewriting unit tests for second time now...

Dude, sometimes I question why tf I even bother with these tests... Feels like sabotaging my productivity, especially with bullshit like that

git merge "conflicts"

(not really an issue, but still a waste of time and concentration, when every now and then, using more than one branch, small edits, merge, and rebase, git diff complains about "conflicts" that are obvious to solve for a human but still not for a machine, despite the hype about the age of AI, coding co-pilots and the like...)

Hello World! Question, what do your team usually do on the last day of work? We prefer push and merge our project branches and resolve conflicts, because nobody wants to write code 🤣

PR done and dusted. Welp! Somehow all permissions on files have been changed. I didnt change it. Wtf happened? Log search turns up I did change it while resolving merge conflicts. I don't know how. Anyway now I am spending my afternoon working on the vaguest fucking issue and reverting back all file permissions. Might have somehow fucked up two repos and will have to fix them all. Kill me. Now

I use GitKraken to only to resolve merge conflicts. Recently, they decided to make app unavailable for private repos.

Suggestions?

Can someone tell me how to properly rebase changes from main branch

I always fuck myself over. Fucking merge conflicts i caused by myself. Since the CD pipeline creates a commit or i merge into main from a side branch, i often forget to pull those changes locally from main branch

What happens then is i just create a new branch to start working on the next feature

git checkout -b feature/shit

Totally forgetting to first do

git pull --rebase

From main branch. Because of this when i push shitload of features to feature/shit branch and then try to merge that shit into main. CD pipeline gets fucked. There are merge conflicts now because i havent rebased

Question -- if i switch to a new branch, make a shitload of changes and forget to rebase from main branch First, what command do i type to rebase right there (on the new branch) but rebase from main branch so these conflicts dont appear?

Just rebase a merge conflicts with LFS enable. What a fucking nightmare. And bitbucket, please eat a dick you useless cunt.