Yes. They do. A lot of people will use vacuous terms like “clean history” when arguing for one over the other. In my opinion, most repositories have larger problems than rebase versus merge. Like commit messages.
Also, remember, even if your team/repository prefers merges over rebases for getting changes into the main branch, that doesn’t mean you shouldn’t be using rebase locally for various things.
You nailed it with the critique of commit messages. We use gitmoji to convey at-a-glance topic for commits and otherwise adhere to Tim Pope’s school of getting to the point
I must have read that blog post in the past because that’s exactly the style I use. Much of it is standard though.
One MAJOR pet peeve of mine (and I admit it is just an opinion either way) is when people use lower case letters for the first line of the commit message. They typically argue that it is a sentence fragment so shouldn’t be capitalized. My counter is that the start of sentences, even fragmented ones, should be capitalized. Also, and more relevant, is that I view the first line of the commit more like the title of something than a sentence. So I use the Wikipedia style of capitalizing.
Quasi parallel reply to your other post, this would kind of echo the want for a capital letter at the start of the commit message. Icon indicates overall topic nature of commits.
Lets say I am adding a database migration and my commit is the migration file and the schema. My commit message might be:
🗃️ Add notes to Users table
So anyone looking at the eventual pr will see the icon and know that this bunch of work will affect db without all that tedious “reading the code” part of the review, or for team members who didn’t participate in reviews.
I was initially hesitant to adopt it but I have very reasonable, younger team mates for whom emojis are part of the standard vocabulary. I gradually came to appreciate and value the ability to convey more context in my commits this way. I’m still guilty of the occasionally overusing:
♻️ Fix the thing
type messages when I’m lazy; doesn’t fix that bad habit, but I’m generally much happier reading mine or someone else’s PR commit summary with this extra bit of context added.
I see things like adding dependencies but I would add the dependency along with the code that’s using it so I have that context. Is the Gitmoji way to break your commits up so that it matches a single category?
Yes, that is another benefit, once you start getting muscle memory with the library. You start to parcel things by context a bit more. It’s upped my habit of discrete commit-by-hunks, which also serves as a nice self-review of the work.
I don’t see that as a benefit tbh - if I have a dependency, I want to see why it’s there as part of the commit. I’m imagining running blame on Cargo.toml and seeing “Add feature x” vs “Add dependency”. I guess the idea is it’s “➕ Add dep y for feature x” but I’d still rather be able to see the related code in the same commit instead of having to find the useful commit in the log.
I suppose you could squash them together later, but then why bother splitting it out in the first place?
I see that some use a subset of Gitmoji and that does make sense to me - after all, you wouldn’t use all of them in every project anyway, e.g. 🏷️ types is only relevant for a few languages.
How would rebasing my own branch work? Do I rebase the main into my branch, or make a copy of the main branch and then rebase? I have trouble grasping how that would work.
Say I work on authentication under feature/auth Monday and get some done. Tuesday an urgent feature request for some logging work comes in and I complete it on feature/logging and merge clean to main. To make sure all my code from Monday will work, I will then switch to feature/auth and then git pull --rebase origin main. Now my auth commits start after the merge commit from the logging pr.
You’re still rebasing your branch onto main (or whatever you originally branched it off of), but you aren’t then doing a fast forward merge of main to your branch.
The terminology gets weird. When people say “merge versus rebase” they really mean it in the context of brining changes into main. You (or the remote repository) cannot do this without a merge. People usually mean “merge commit versus rebase with fast forward merge”
100% they do. Rebase is an everyday thing, merge is for PRs (for me anyway). Or merges are for regular branches if you roll that way. The only wrong answer is the one that causes you to lose commits and have to use reflog, cos…well, then you done messed up now son… (but even then hope lives on!)
Yes. My rule of thumb is that generally rebasing is the better approach, in part because if your commit history is relatively clean then it is easier to merge in changes one commit at a time than all at once. However, sometimes so much has changed that replaying your commits puts you in the position of having to solve so many problems that it is more trouble than it is worth, in which case you should feel no qualms about aborting the rebase (git rebase --abort) and using a merge instead.
I have the bad habit of leaving checkpoints everywhere because of merge squash that I am trying to fix. I think that forcing myself to rebase would help get rid of that habit. And the good thing is that I am the sole FW dev at work, so I can do whatever I want with the repos.
Never use rebase for any branch that has left your machine (been pushed) and which another entity may have a local copy of (especially if that entity may have committed edits to it).
Thanks for the explanation. It makes sense. To my untrained eyes, it feels like both merge and rebase have their use. I will try to keep that in mind.
Yes. They do. A lot of people will use vacuous terms like “clean history” when arguing for one over the other. In my opinion, most repositories have larger problems than rebase versus merge. Like commit messages.
Also, remember, even if your team/repository prefers merges over rebases for getting changes into the main branch, that doesn’t mean you shouldn’t be using rebase locally for various things.
You nailed it with the critique of commit messages. We use gitmoji to convey at-a-glance topic for commits and otherwise adhere to Tim Pope’s school of getting to the point
I must have read that blog post in the past because that’s exactly the style I use. Much of it is standard though.
One MAJOR pet peeve of mine (and I admit it is just an opinion either way) is when people use lower case letters for the first line of the commit message. They typically argue that it is a sentence fragment so shouldn’t be capitalized. My counter is that the start of sentences, even fragmented ones, should be capitalized. Also, and more relevant, is that I view the first line of the commit more like the title of something than a sentence. So I use the Wikipedia style of capitalizing.
Gitmoji?
https://gitmoji.dev/
Quasi parallel reply to your other post, this would kind of echo the want for a capital letter at the start of the commit message. Icon indicates overall topic nature of commits.
Lets say I am adding a database migration and my commit is the migration file and the schema. My commit message might be:
So anyone looking at the eventual pr will see the icon and know that this bunch of work will affect db without all that tedious “reading the code” part of the review, or for team members who didn’t participate in reviews.
I was initially hesitant to adopt it but I have very reasonable, younger team mates for whom emojis are part of the standard vocabulary. I gradually came to appreciate and value the ability to convey more context in my commits this way. I’m still guilty of the occasionally overusing:
type messages when I’m lazy; doesn’t fix that bad habit, but I’m generally much happier reading mine or someone else’s PR commit summary with this extra bit of context added.
I looked at it and there’s a lot of them!
I see things like adding dependencies but I would add the dependency along with the code that’s using it so I have that context. Is the Gitmoji way to break your commits up so that it matches a single category?
Yes, that is another benefit, once you start getting muscle memory with the library. You start to parcel things by context a bit more. It’s upped my habit of discrete commit-by-hunks, which also serves as a nice self-review of the work.
I don’t see that as a benefit tbh - if I have a dependency, I want to see why it’s there as part of the commit. I’m imagining running blame on Cargo.toml and seeing “Add feature x” vs “Add dependency”. I guess the idea is it’s “➕ Add dep y for feature x” but I’d still rather be able to see the related code in the same commit instead of having to find the useful commit in the log.
I suppose you could squash them together later, but then why bother splitting it out in the first place?
I see that some use a subset of Gitmoji and that does make sense to me - after all, you wouldn’t use all of them in every project anyway, e.g. 🏷️ types is only relevant for a few languages.
How would rebasing my own branch work? Do I rebase the main into my branch, or make a copy of the main branch and then rebase? I have trouble grasping how that would work.
Here’s an example
Say I work on authentication under
feature/authMonday and get some done. Tuesday an urgent feature request for some logging work comes in and I complete it onfeature/loggingand merge clean to main. To make sure all my code from Monday will work, I will then switch tofeature/authand thengit pull --rebase origin main. Now my auth commits start after the merge commit from the logging pr.Thanks for the example. Rebase use is clearer now.
You’re still rebasing your branch onto main (or whatever you originally branched it off of), but you aren’t then doing a fast forward merge of main to your branch.
The terminology gets weird. When people say “merge versus rebase” they really mean it in the context of brining changes into main. You (or the remote repository) cannot do this without a merge. People usually mean “merge commit versus rebase with fast forward merge”
Yeah I was confused because you are right, merge is usually refered as the git merge and then git commit.
It makes sense. Thanks for the clarification
100% they do. Rebase is an everyday thing, merge is for PRs (for me anyway). Or merges are for regular branches if you roll that way. The only wrong answer is the one that causes you to lose commits and have to use
reflog, cos…well, then you done messed up now son… (but even then hope lives on!)Yes. My rule of thumb is that generally rebasing is the better approach, in part because if your commit history is relatively clean then it is easier to merge in changes one commit at a time than all at once. However, sometimes so much has changed that replaying your commits puts you in the position of having to solve so many problems that it is more trouble than it is worth, in which case you should feel no qualms about aborting the rebase (
git rebase --abort) and using a merge instead.I have the bad habit of leaving checkpoints everywhere because of merge squash that I am trying to fix. I think that forcing myself to rebase would help get rid of that habit. And the good thing is that I am the sole FW dev at work, so I can do whatever I want with the repos.
Never use rebase for any branch that has left your machine (been pushed) and which another entity may have a local copy of (especially if that entity may have committed edits to it).