@Haitaish
2 minutes into the video and animations help understand rebase 1000x better than any static explanation on any website ever could. Thank you.
@AlbertLeng
One of the best channels to learn about sw technologies. No fluff talks, no distracting music, no ads, pure substance with straight to the point explanations and amazing animation!
@Dmittry
We squash our personal PRs and merge our team branch to main. To update my branches I prefer rebase . But rebase is not so good if several people work on the same branch.
@spfeu
There's a reason merging squash commits is so popular, and that's because it's the easiest and most compatible with how most people use git. Most people want their branch to be their own workspace, and while in some kind of fantasy world each commit would be filled with very useful information, in reality it's mostly swear words and short notes. Having squash commits and PRs can force developers to write a longer, better description of their entire feature when merging instead, and get rid of all the mostly scattered and hard to understand commits from the feature branch. The only people I've ever met that prefer rebasing are people who live and breathe git and feel like every commit is sacred, but this is an incredibly tedious way to work -- if your features are so large that you feel that the history of a hundred commits is necessary, just make smaller features, or better yet, actually comment your code like you're supposed to.
N/A
Tried various strategies and so far I prefer to always work with merge commits and almost no rebase (unless the branch was never published). Merge from main branch to feature branch. Merge from feature branches to master when ready, no squash, no fast forward, always creating a merge commit. I don't find the history messy as it's exactly as development happened. Remember that you can always see history with --first-parent if you want to see only a commit (similar with how squash result can be viewed).
@jamoncitovideos
One major advantage of using rebase instead of merge that is not mentioned in the video: when two developers work on different feature branches in parallel, when merging git will mix up the commits of each branch, so it's easy to break someone else's code. As an example, dev1 makes commit A at 9am and commit B at 11am, while dev2 makes a commit in a different branch at 10am. When merging both features, git tries to combine the 3 commits in this order: A, C, B. This mix up makes it easy to break code and merge conflicts become a mess. With rebase&fast-forward, the commits will be seen as A, B, C (or C, A, B if dev2 made the PR first). Just because the changes from both branches were committed in parallel, it does not mean that the logic in the code evolution follows the same logic, as the features were independently developed. Hope that was clear enough - I feel like I didn't explain myself that well :') To the creators: Great video! Could I suggest making an explanatory video on how to work with forks as a follow-up? I've been recently taught this together with rebase+squash by a senior dev & it has made my workflow so much better!!!
@Furki4_4
I've never used rebase and squash techniques but i like the way they combine the commits in the feature branches to the main branch. Thank you ❤
@MrZiyak99
I used to rebase the main branch into my feature branch. the issue with that which not many talk about is that if you're too many commits behind you'll be forced to fix merge conflicts on a commit by commit basis. i usually prefer merging now and then user interactive rebase to pick commits in my feature branch before pushing to main
@Clem.E
With Git rebase, I find myself rebasing more often on the main branch in order to prevent the branch from diverging to much. It has the benefit of avoiding too many conflicts on the final rebase.
@alexeibrinza2719
I prefer the hybrid approach. First create a new feature branch from main branch. Add a few commits on feature branch. If the commits all belong to the same task or represent the same feature, fixup/squash them. If each commit represents distinct functionality or it makes sense to revert a part of the feature, not the whole feature, then don't use fixup/squash. After the work is done - rebase the branch with the main. Using this technique, you can combine both squash/rebase as needed.
@kevalan1042
The squash approach makes sense to me, you can see the whole change at once and the full detail in the branch if needed
@Staunch_Dev
Updating my main branch, I prefer working with GIT MERGE. It feels a lot more straightforward for me more importantly is the fact that I can track my commit history when I make use of the MERGE option.
@hello_world_zz
Alex, you truly are the epitome of excellence. With my 15 YOU as a SWE, I can confidently say that collaborating with someone of your calibre has undoubtedly been the utmost highlight in my professional journey.
@tushar8133
Believe me, you always make us clear long due complex topics in a single shot. I have been trying to figure out this topic for the past few years, but never understood. Thanks a lot! We ❤ your channel.
@maxspielberg6612
This was more helpful than i can explain. I am collaborating on github for the first time and didnt know what any of the differences were and just had a terrible day merging changes when i should have rebased. Everything makes perfect sense now.
@aaraz101
This guy graphics is always the best to understand and remember , thanks man !!
@esra_erimez
These animations really facilitate the meaning of these concept in a clear and concise manner. Thank you.
@jorden123
Rebase whenever you want to get your feature branch in sync with main, when done implementing - squash, tag and merge into main.
@supermamoru
This helped me understand the difference between git rebase/merge/squash just by looking at the diagram! TYSM <3
@mhopado