Earlier quoted context omitted.
Squash merges cut down the noise considerably.
Squash merges are rebases.
Just when I thought I was starting to understand git...
Git rebase, what can go wrong
31–40 of 404 posts
Re: Git rebase, what can go wrong
#32I like how Atlassian puts it: > The golden rule of rebasing > Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commit…
Squash merges cut down the noise considerably.
[deleted]
Re: Git rebase, what can go wrong
#33Just don't rebase something that you've shared with others. It's just rude.
Re: Git rebase, what can go wrong
#34Re: Git rebase, what can go wrong
#35I might be lucky but in my whole developer life I have only used like 3 commands git stash, git pull --rebase and git merge. I'm not even sure I used git rebase once.
what do you think git pull --rebase does..
I think the most cited drawback of rebase - public branch refs becoming obsolete - is not applicable when you only use it to pull from a canonical remote.
Re: Git rebase, what can go wrong
#36I like how Atlassian puts it: > The golden rule of rebasing > Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commit…
The way I phrase and teach what I consider to be the important rule of git is: > Don't rewrite history on shared branches with proper communication. I don't teach "never", I don't teach that `main` is special, I don't teach that force pushing is forbidden, because I don't believe in those things. I highly prefer a rebase-heavy workflow. In addition to not "cluttering" the history, it's an invaluable tool to keep comm…
I assume that “with” is meant to be “without”?
Re: Git rebase, what can go wrong
#37Earlier quoted context omitted.
Squash merges cut down the noise considerably.
I actually hate squash merge because of all the noise it adds. Sure, the commit graph looks nicer, but it come with a terrible loss of information when doing git blame. I'm a big proponent of rebase and squash if it helps to make a commit more coherent, but we use squash merges by default in the current project I'm working on, and I die a little bit each time I try to understand what changes were related to a line wh…
I do squash merges but keep the feature branches. So after determining that I made a change as part of a big pull request, I can then look at the commit/blame history for the pull request source branch if necessary.
Re: Git rebase, what can go wrong
#38I love rebase (I'm a tip-of-master-only person, no merges ever, squash all your commits with `rebase -i` before pushing and write one good commit message for the group). But there's one really, really irritating thing about them: You should not be able to use `--amend` during a rebase. For me editing all my changes onto the commit I'm working on with `git commit -a --amend` (or as I've aliased it, `gcaa`) is automati…
I’m curious how this workflow differs from `git merge --squash`.
Re: Git rebase, what can go wrong
#39This is nice to read because I’ve been recommended rebase by so many people who clearly have no idea what it does and what to do if it goes wrong.
Re: Git rebase, what can go wrong
#40I’ve never understood the tradeoff of rebasing, squashing or otherwise “keeping a clean history”. It always seemed like tons of sometimes highly error prone work (sometimes you can wipe out a colleague’s work with it! Wtf!), for almost no gain (why does it matter that the git history is “clean”?).
Another thing is if you keep commits in a clean "state", it is easier to revert a commit, when you squash or keep them messy it can make it harder to revert.
Also sometimes you decide you want to backport some change to other releases, and if commits are in a good state, it is much easier to do this.