A few months ago, I wrote a DEV post about resolving merge commits. The resounding feedback I received from readers was: "JUST AVOID THEM." While...
For further actions, you may consider blocking this person and/or reporting abuse
"Pay attention and communicate" that's so true !
If you hear during stand-up "I'm renaming that file", or "I'm refactoring that part", just synchronize yourselves instead of continuing in your own development bubble !
I'm glad that you and others agree with me on this!
Based on git-branchless wiki, development is already underway for stock Git to get in-memory merges (speculative merging). Seems in the future we can have less "bad times" with merge conflicts.
That's exciting to look forward to!
One thing shall be clearly noted to understand most of rebase problems:
A rebase is hidden merge.
The first direct consequence is that a rebase result shall be tested (with assigned tests) and verified (at least visually).
The second one is that conflicts found in rebase are principally the same found in merge. But, as far as people usually think easier in a sequential history, rebase result is simpler to read later on. More so, git automatically shows single-parent commits as diffs but doesn't do this for merge commits - they require separate cumbersome actions to find their changes out.
And, well, rebasing of published changes is, at least, a tricky action. Some sources afford this constantly (Linux kernel development trees). There is a section "Recover from upstream rebase" in Git manuals. Anyway, this is the true aerobatics:)
Well said! Thank you. I learned a lot from your comment
I think it's good to modularize code (AKA put code for a feature into a single file).
For example, when I working in JavaScript if I'm creating a an accordion I might name the file accordion.js and then I'll use a task runner and
importstatements.I absoultely hate merge conflitcts. As you said, they aren't completely avoidable but I'm pretty much doing what you outlined and it works for me.
My workflow is like:
Start writing code on a new branch
When done, commit my changes (always striving for small commits)
Pull and rebase changes from main (git pull origin main --rebase)
Push
If there are any changes while the the PR is under review, I just rebase again and push force. This makes my branch history clean and is fine because usually there's a single person per feature branch.
Also, and this might be controversial, I strive to have a single commit per PR. So I often do
git commit --amendfollowed bygit push -fwhen doing small fixes. I guess I picked this up from when I worked at Google and we don't use branches there and there's always exactly 1 commit per PR (called a changelist) and now I can't work any other way :)ah, very nice! I love to hear about developer's workflows. Although the last part is a little controversial, this sounds like it works well for you. I hope your comment is helpful for other people.
I think sometimes people have to experiment and figure out what workflow is best for them as individuals and as teammates.
Very true words It's really important to make small commits and always make a communication with the team. The less the communication gap 🗨 the less it takes to merge branches 🧑💻.
We developers need to understand, that yes we may have been lone wolves but communication always helps and team work does makes things less complicated and easy to approach ✌.
You worded this well! Communication and teamworks always makes coding a little easier!
This goes under formatting rules, but where possible I like to sort lines alphabetically (things like union types, options, language translation keys, even CSS rules and function/variable declaration)
I find this helps avoid some unnecessary conflicts, but has an added benefit of making code a little easier to grok/scan when searching for needles.
That's a great tip! I do this as well!
How do you reconcile small, frequent commits with the fact that what you're working on is neither complete nor has been tested, and you don't have a clue how many files it's going to affect before you're done?
I think that's where working with a product manager and team to make smaller stories comes in. Like if breaking the tickets into small little bits..where you don't have to complete the whole feature for it to parts of it to get merged in..
OR creating a feature branch that branches off of the main branch. Then making small commits into the feature branch and frequently rebasing off the main branch. That way your feature branch is up to date with the main branch.
Happy to hear other people's thoughts on this.
Small file size is also a good way to avoid conflicts. There's a smaller chance that other people will be editing the same file that you're working on.
Yes, i agree with this!
That's really helpful! Thank you 💕😊
I'm glad! You're welcome and thank you for reading!
Thank you for sharing this experience!
Thank you for reading!
This was super helpful and fun to read, Rizèl. Thank you!
Awesome I'm glad it was enjoyable!
YEP, sounds like we are aligned on this.
I wonder how could we do when "refactoring" in this prevent merge conflicts style