I've always said rebase is underrated, i always rebase in local branches and then merge into main (squash there are more than a few committs), it makes the MR way easier to review and reason about, also rebasing helps me to sort my mind so i don't forget anything and am content with the MR at the end
@@tillcarlos I'm actually not lol. Although that would make sense with this TH-cam account. I'm a PHP dev with my own business who contracts for other companies mostly. Small teams. Love Symfony and Laravel etc etc. :) the French is a personal project :)
Nice ideas, and approaches discussed within this video, any ideas how can I promote this in my dev team to start using it? Cause right now, the average size of pull request is about 40-70 files changed and 1500-2500 lines changed (additions/deletions). Much appreciate your response.
Hey Tima - My thoughts on big MRs: - Some MRs need to be big. Things like big translation changes, or adding a lot of assets. Those cannot be made smaller. Fine like this. - It also depends on the framework. 10 lines in Python or Javascript or Go are more impactful than 10 lines in Java. - Earlier in the project: larger MRs. Example: generate code to set up projects etc. - If you have huge MRs all the time, and you are working with more than 2 developers on ONE area - you will likely have a lot of conflicts and merge hell. - If these larger MRs take longer than a couple of days, AND you are working on the same thing, you might have people fixing the same things. Some ideas to improve - If MRs are big, and tickets are big -> Make tickets smaller - If tickets are small and MRs are big -> Developers refactor on their own. That might be a good things, but could also lead to conflict. Not sure if these help. Other idea: we could have a call and brainstorm some ideas. Just send me an email and I reply with my booking link (free of charge).
I replied from another account, not sure it came through. I'll wait for the google caches. Punchline: - if you have many changes with multiple developers on the same code parts, they might interfere if you don't have enough tests (do you?) - If MRs are too big but tickets are still small: then the devs refactor outside the ticket scope (potential problem) - If MRs are big and tickets are also big: make tickets smaller. In any case, have you had 1on1s with each dev to figure out why there are so many changes? And how they feel about it? If I can help, we can jump on a call and brainstorm solutions. Email me and I'll respond with a booking link (free of charge)
Yeah - that can be a good thing. If the developers refactor a lot, that could be a sign that they care. Or a sign that the codebase is not good enough.
Don't rebase. By doing that, you're creating a situation in which only the last few commits (perhaps even just one) are guaranteed to work the way you intended. The rest of them could contain the project in a state that doesn't work or doesn't make sense, because you're replaying the changes in context in which they weren't originally created. I know that a rebased history looks neat, but in my opinion it's not worth the risk of having to investigate something on an older commit and not being able to without extra effort.
Hey Rafal Yes, rebasing messes with the commit history. If other branches depend on it these might fail. When rebasing you need to decide which change to take, through the whole rewritten history. In our case we use a modified trunk-based development. Feature branches are short, and we discourage branching off of feature branches. Once we merge, main is usually correct. I would like to understand your comment a bit better. Do you never rebase? What's your project structure like?
@@tillcarlos Personally I don't rebase, but there's no hard requirement about this at my company. We squash commits on merge which I'm also not a fan of 😁 but it's industry standard I guess - anyway, because of this it doesn't mater much how the commits are structured before the merge. With short-lived branches rebasing shouldn't cause big inconsistencies, but I would still prefer to stick with the commit history that reflects how changes were made throughout the branch's life.
Yes. If you rewrite the history, you cannot push normally, else it'll be rejected. If you force push: make sure you pull first. Also, ideally, other devs don't depend on the branch which you force-push. There's an 'update-refs' command - that could help here as well. But I digress.
Yes. I responded with another channel - hope this came through. You need to force push else you cannot overwrite the refs on the remote. Just make sure you pull before so you don't overwrite other people's changes. And hopefully nobody branched off the branch you force-push. Else they need to use "update-refs" or cherry-pick.
@@tillcarlosif i branch off and somebody force pushes, i just switch to the branch do git pull, then switch back and do git rebase branch-i-branched-off also i always use git pull --rebase (there is a git config option to make it default) so when people add commits my commits always go on top instead of doing a local merge rebase is just way cleaner for feature branches than merge imo
I've always said rebase is underrated, i always rebase in local branches and then merge into main (squash there are more than a few committs), it makes the MR way easier to review and reason about, also rebasing helps me to sort my mind so i don't forget anything and am content with the MR at the end
Totally! We even put it into our checklist now. "I have rebased and squashed my commit messages so that they make sense"
I love this idea. I've never created a merge request first. This is a great. Thanks
Thanks for the encouragement!
Thanks, Mate! Are you building a language learning app?
@@tillcarlos I'm actually not lol. Although that would make sense with this TH-cam account. I'm a PHP dev with my own business who contracts for other companies mostly. Small teams. Love Symfony and Laravel etc etc. :) the French is a personal project :)
Nice ideas, and approaches discussed within this video, any ideas how can I promote this in my dev team to start using it? Cause right now, the average size of pull request is about 40-70 files changed and 1500-2500 lines changed (additions/deletions). Much appreciate your response.
Hey Tima -
My thoughts on big MRs:
- Some MRs need to be big. Things like big translation changes, or adding a lot of assets. Those cannot be made smaller. Fine like this.
- It also depends on the framework. 10 lines in Python or Javascript or Go are more impactful than 10 lines in Java.
- Earlier in the project: larger MRs. Example: generate code to set up projects etc.
- If you have huge MRs all the time, and you are working with more than 2 developers on ONE area - you will likely have a lot of conflicts and merge hell.
- If these larger MRs take longer than a couple of days, AND you are working on the same thing, you might have people fixing the same things.
Some ideas to improve
- If MRs are big, and tickets are big -> Make tickets smaller
- If tickets are small and MRs are big -> Developers refactor on their own. That might be a good things, but could also lead to conflict.
Not sure if these help. Other idea: we could have a call and brainstorm some ideas. Just send me an email and I reply with my booking link (free of charge).
I replied from another account, not sure it came through. I'll wait for the google caches.
Punchline:
- if you have many changes with multiple developers on the same code parts, they might interfere if you don't have enough tests (do you?)
- If MRs are too big but tickets are still small: then the devs refactor outside the ticket scope (potential problem)
- If MRs are big and tickets are also big: make tickets smaller.
In any case, have you had 1on1s with each dev to figure out why there are so many changes? And how they feel about it?
If I can help, we can jump on a call and brainstorm solutions. Email me and I'll respond with a booking link (free of charge)
@@tillcarlos thank you, in my case it might be related to the ticket size and code refactors outside the ticket's scope.
Yeah - that can be a good thing. If the developers refactor a lot, that could be a sign that they care.
Or a sign that the codebase is not good enough.
Great tips!
Thanks, Tales!
Thanks, Tales!
Don't rebase. By doing that, you're creating a situation in which only the last few commits (perhaps even just one) are guaranteed to work the way you intended. The rest of them could contain the project in a state that doesn't work or doesn't make sense, because you're replaying the changes in context in which they weren't originally created.
I know that a rebased history looks neat, but in my opinion it's not worth the risk of having to investigate something on an older commit and not being able to without extra effort.
Hey Rafal
Yes, rebasing messes with the commit history. If other branches depend on it these might fail. When rebasing you need to decide which change to take, through the whole rewritten history.
In our case we use a modified trunk-based development. Feature branches are short, and we discourage branching off of feature branches. Once we merge, main is usually correct.
I would like to understand your comment a bit better. Do you never rebase? What's your project structure like?
@@tillcarlos Personally I don't rebase, but there's no hard requirement about this at my company. We squash commits on merge which I'm also not a fan of 😁 but it's industry standard I guess - anyway, because of this it doesn't mater much how the commits are structured before the merge.
With short-lived branches rebasing shouldn't cause big inconsistencies, but I would still prefer to stick with the commit history that reflects how changes were made throughout the branch's life.
after rebase, I suppose, force push?
Yes. If you rewrite the history, you cannot push normally, else it'll be rejected.
If you force push: make sure you pull first. Also, ideally, other devs don't depend on the branch which you force-push.
There's an 'update-refs' command - that could help here as well. But I digress.
Yes. I responded with another channel - hope this came through.
You need to force push else you cannot overwrite the refs on the remote. Just make sure you pull before so you don't overwrite other people's changes.
And hopefully nobody branched off the branch you force-push. Else they need to use "update-refs" or cherry-pick.
@@tillcarlosif i branch off and somebody force pushes, i just switch to the branch do git pull, then switch back and do git rebase branch-i-branched-off
also i always use git pull --rebase (there is a git config option to make it default) so when people add commits my commits always go on top instead of doing a local merge
rebase is just way cleaner for feature branches than merge imo
From Bangladesh🎉
Much love from Vietnam
Thanks, Mate!