2:04 says con of squash commit is losing history on branches? Is this true, or it assumes feature branches are deleted? Because after a sqaush merge, github->insights-> network still shows the commits that went into the squash commit. They are not lost. Some feedback: It's not clear when speaking of commits, are you talking about the contents, or the commit SHA. Contents can stay the same but new SHA are created. 1. 2:24 when describing squash merge, an extra commit was added 2. 3:39 when describing rebase merge, no extra commit was added. This may cause people to think the commit SHA wil stay the same. To be consistent with 1, i expected 1 new commit to be added per moved commit (so 2 in this case) OR to clarify whether you're describing exact SHA or the contents (code/file changes)
I'm currently facing a bit of trouble using squash when I merge from develop to master. Whenever I do that, and merge the master back onto develop, with the next pull request the old commits re-appear that were already squashed. I guess that's the case because develop still contains the full history which is squashed again and again. So my question would be, should squashing only be used for feature branches and rebasing for develop -> master merges? Or how else would I get a clean history on master without duplicated commits in pull requests?
Thanks for the interesting question! If you always squash when closing features into develop, you will end up with develop being clean with only one commit for each PR and this is fine. In this case, I'd probably go with a regular merge commit when doing develop -> master and maybe use tags (on master) to better keep track of versions. How does this sound to you? :)
Back in the day I would always do a rebase... We had a large code base with many devs doing various things... Being very newb I wanted my changes pulled forward and tested. I always made a commit message and thought my commit log didn't go with -- woops! Maybe I did know that it went but forget now... Either way....
If you have stacked PRs a squash merge can cause pseudo conflicts that actually are no real conflicts but still need resolution (not possible through web UI). At least in Bitbucket that is.
Great help, thanks. I think it would have been easier to follow if your intonation for 'commit' was heavier on the second syllable, as is the norm. I found it a bit confusing sometimes because when you say 'comment' and 'commit' it sounds the same. Usually the intonation goes like COMMent and comMIT
Hey, welcome to the channel :) If commits are pushed and you're on a feature branch, the video shows how you can squash the commits when merging into the main branch. If you mean you want to join more commits into one without doing a merge, you can use interactive rebase (git rebase -i)
The demo of the rebase was helpful thanks
That's great to hear, thank you Joe!
Also welcome to my channel :D
I've read so many threads saying basically this but seeing the live demo removed the fear that I was misunderstanding something. Love this, thank you!
the demo part helped in understanding the strategy very clear..
thanks for the video, mate.🤩🤩
Best explanation yet.
Thank you! Did you like the "live" demo? 😂
nice, clean, simple explanation. Thanks 🙌
The explanation is superb!
2:04 says con of squash commit is losing history on branches?
Is this true, or it assumes feature branches are deleted?
Because after a sqaush merge, github->insights-> network still shows the commits that went into the squash commit. They are not lost.
Some feedback:
It's not clear when speaking of commits, are you talking about the contents, or the commit SHA. Contents can stay the same but new SHA are created.
1. 2:24 when describing squash merge, an extra commit was added
2. 3:39 when describing rebase merge, no extra commit was added. This may cause people to think the commit SHA wil stay the same. To be consistent with 1, i expected 1 new commit to be added per moved commit (so 2 in this case) OR to clarify whether you're describing exact SHA or the contents (code/file changes)
Tnx. Really simple and streight forward.
What is YOUR merge strategy? Let's talk about it on Discord: discord.gg/bqwyEa6We6
Nice overview! Thanks.
Very good, thank you for the video, it helped a lot, especially for the examples
thank you for the video! it was interesting to know about the squash
Thank you for the comment and welcome to my channel! :D
Good choice with squash 😉
I'm currently facing a bit of trouble using squash when I merge from develop to master. Whenever I do that, and merge the master back onto develop, with the next pull request the old commits re-appear that were already squashed. I guess that's the case because develop still contains the full history which is squashed again and again. So my question would be, should squashing only be used for feature branches and rebasing for develop -> master merges? Or how else would I get a clean history on master without duplicated commits in pull requests?
Thanks for the interesting question!
If you always squash when closing features into develop, you will end up with develop being clean with only one commit for each PR and this is fine.
In this case, I'd probably go with a regular merge commit when doing develop -> master and maybe use tags (on master) to better keep track of versions.
How does this sound to you? :)
@@DevLeonardo Hi Leonardo, sounds great, thank you. I'll try that
Back in the day I would always do a rebase... We had a large code base with many devs doing various things... Being very newb I wanted my changes pulled forward and tested. I always made a commit message and thought my commit log didn't go with -- woops!
Maybe I did know that it went but forget now... Either way....
If you have stacked PRs a squash merge can cause pseudo conflicts that actually are no real conflicts but still need resolution (not possible through web UI). At least in Bitbucket that is.
I like squash when I have to do a ton of tiny commits when I am debugging or working through trial and error cycles.
That's true! Also you don't need to worry if you need an extra commit if you forgot a file, or a typo :D
Thankyou!
Soo helpful thank you so much
Great help, thanks. I think it would have been easier to follow if your intonation for 'commit' was heavier on the second syllable, as is the norm. I found it a bit confusing sometimes because when you say 'comment' and 'commit' it sounds the same. Usually the intonation goes like COMMent and comMIT
And you haven't seen yet the tanstack router series where in the first 4 videos I say "route" and "root" the exact same way :D
Thanks for the hint!
Nice explanation
why it is called squash and merge and not squash and rebase?
"... all your sins will be forgotten." 🤣
...kind of 😆
nice, now i got a better understanding of those commits. And love the Demo Time! No code.
Thank you! I had a lot of fun doing the live demo, it's great to hear you liked it :D
how to squash commit 'pushed' and 'locally' ?
Hey, welcome to the channel :)
If commits are pushed and you're on a feature branch, the video shows how you can squash the commits when merging into the main branch.
If you mean you want to join more commits into one without doing a merge, you can use interactive rebase (git rebase -i)
In my opinion always use squash. If you use continous integration your branches will hopefully not live for a long time anyway.
I ❤ed DeMo time