Git Merge VS. Git Rebase - What's the difference?

Follow for more Android & Kotlin tips 🙌

[@maximooze3196]

git reset --hard 🎉

[@qweqwe1]

rebase is always a problem, one day the team lead just cut out a huge changes that I worked on for a week. had to restore all the lost files, while the packages created by me were preserved, it was very strange

[@cursedfunction]

Since rebase will rewrite the commit history, a good rule of thumb is to only rebase on branches that are fully in your control - ie. No one else is using that branch. Use merge if others are also working within the same branch. If you do use rebase on a branch that other people are working with, make sure to communicate that to them so they know they will need to pull down and fix any merge conflicts. I like to stash my changes, pull the changes down and then unstash my previous changes so that I can minimize any conflicts.

[@whimahwhe]

Was looking for this comment

[@jpettys]

This is an excellent description of the context for using each. In software engineering, "Always do X" is almost always over-simplified, regardless of the context.

[@SoyAmurita]

I would simply merge 😂. rebasing and fixing conflicts in each commit is a suicide 😂😂

[@abhimanyu.n14]

For both merge and rebase, conflicts have to be resolved.

[@leonardooliveira2829]

​@@abhimanyu.n14Exactly! There's no free lunch!

[@ravikanttiwari1757]

​@@abhimanyu.n14 while doing rebase it erases commit history then all the changes looks like you made them and PR becomes, don't even need to mention you will be flagged for code comments that you never made

[@whimahwhe]

You should get used to rebase on opportunity that you can, that's how your conflicts are more sparse and contextual

[@vibovitold]

​@@abhimanyu.n14of course, but rebase produces more conflicts on average

[@StealerSlain]

If the goal is to have a really clean commit history, one should consider using squash and learning interactive rebases

[@jonghunpark4453]

Work with a lot of people in a short period of time and are more likely to conflict -> Merge Relatively few conflicts, and the commit history must be managed well. -> Rebase

[@TokyoXtreme]

Use the one that fits the situation. Merge when you want two branches merged into one, otherwise rebase or cherry-pick. Once a branch becomes public and collaborative, consider it locked to future rebasing. From that point on, anyone who branched off of that feature should be merging back into it, maybe by pull request. I almost never have people branching off my public branches anyway, but there is --force-with-lease anyway.

[@_0_o_924]

Git rebase is a powerful feature 🔥🔥

[@kelvinyelyen]

Whether to use rebasing or merging hinges on preferences and project requirements. Rebasing is favored by some for its cleaner commit history, while others find merging more straightforward. To smoothly integrate either method with your team, it’s crucial to establish a workflow that suits your team’s needs and project specifics. I’d always opt for a simple merge though.

[@yatishraja3998]

I simply like merge but my team lead always says to rebase and create problems

[@abhimanyu.n14]

Single commit per MR/PR. Always rebase.

[@chimezieorji-unegbu7110]

Merge is always easier. Rebase most times generate more complex issues

[@adamgardner7279]

Most teams I have worked on go with merge as its simpler and safer. I do not trust myself and hard pass on deleting commit history. Seen people f up stuff with rebase.

[@dharamveergupta1305]

Rebase is always the best way to go.

[@huseynbabarzaquliyev4282]

Hey there, I recommend to have both branches in the remote before rebasing them, because you cannot reset the rebase when there is a problem with your branches and rebase operation

[@daruiraikage]

git rebase --abort if you mess up in between. use git tag or git reflog to reset to that point in time before you started rebase operation. have a backup branch just in case.

[@huseynbabarzaquliyev4282]

@@daruiraikage thanks for informing, I will check it ASAP

[@daruiraikage]

@@huseynbabarzaquliyev4282 no prob, let me know if you want more explanation.

[@ibrahimkhalilshakir2414]

Hey. Make a git tutorial. If you make it. It will be best tutorial 😊

[@LaBoots]

rebase is OP when used correctly

[@manshalkhatri9289]

I have seen rebase option many times but never used it

[@ruskiikoshka]

Rebase is more flexible but it must be used with extra care.

[@techkyguy]

Rebase is what my team uses and is ok. You just need to know when to merge

[@nik91potter]

Rebase is the best!

[@vitalijuskolinko9011]

Merge

[@bbeniful]

I vote for rebase :D

[@vectoralphaAI]

Neither. I dont use version control.

[@SiamakAshrafi]

Trying to write code without VC is like being a bee keeper without a bee suit ... you can do it but you are going to be in a world of hurt when code starts attacking 🐝 ...

[@christophecornet2919]

I tend to rebase

[@mateusznepath3344]

git push --force

[@TomasHavlicek]

Team rebase

[@samirgawas]

Rebase

[@akashsinha5148]

Team cherry-pick

[@mrjackson9137]

cherry-pick commits😅

[@jaydeepbhayani]

Rebase