Front end developer specialising in JavaScript and React. Experienced in all aspects of modern front end development. Passionate about making accessible, secure and performant software.
I agree that git rebase isn't always needed. I think it depends on every person's git workflow in general. Also, it's not like commit history needs to be perfectly clean to be usable. In fact, in most places where I've worked, commits are an utter mess, with branches ranging from a single huge commit with a message that doesn't describe what the work was, to multiple small commits all having the same commit message.
But everything still works fine. So I agree when you say that it doesn't hurt the work or readability very much. After all, you rarely need to read the commit history of the project. You probably also have a ticketing system to help.
However, for very little effort, I like to have a clean commit history in my code. So I use it as part of my workflow. Here are some areas and reasons for where / why I use it:
Fast forward merges
In the git top 20 list (gitstar-ranking.com/repositories), more open source projects use fast-forward merges than 3-way merges. So it may be necessary to use git rebase for this.
Linear commit history in feature branches
Even when using 3-way merges, I'd rather commit a branch with a linear commit history if I can. But sometimes there are conflicts with the main branch. So you merge the main branch into your branch to resolve them. But this makes the commit history and commit graph messier. Instead, I rebase to keep my branch's history linear.
Pull with rebase
Pulling without rebase can create 3-way merges in your local branch. I find these unnecessary, so I use git pull --rebase (actually I've set this as the default behaviour in the git config file).
Cleaning up bad commits in feature branches
Sometimes I use rebase for small refactors I do later. For example, if I'm working on a module, I'll have some commit message along the lines of "add module X" or "add function X". In the meantime, I might do some other related work and create more commits. Afterwards, as I'm checking over all of my work, I might do a tiny refactor on module X, such as writing a line of code in a simpler way, or maybe changing the name of a test.
I don't want useless commits for that:
"add function X"
(other commits in-between)
"rename test for function X"
"clean up code in function X"
So I rebase to have a single commit message of "add function X".
But, at other times, I don't commit until I've finished my work. In that case, I structure all of the commits properly the first time and don't use rebase.
Also, as part of my workflow, I commit early and often and also use TDD. That way, if I mess up, I can just reset to the previous TDD loop (from 2 minutes ago). I normally just use git commit --amend for these temporary commits, to save the effort of having to rebase them later. But sometimes, I end up with a couple of "temporary commits" for various reasons. In that case, I go back and use git rebase --interactive to organise them into something sensible.
But that's just my experience. What are your thoughts on this? Do you come across little issues like these? If you do, do you ignore them (because, let's be honest, I don't think they're significant), handle them in a different way, etc.?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree that git rebase isn't always needed. I think it depends on every person's git workflow in general. Also, it's not like commit history needs to be perfectly clean to be usable. In fact, in most places where I've worked, commits are an utter mess, with branches ranging from a single huge commit with a message that doesn't describe what the work was, to multiple small commits all having the same commit message.
But everything still works fine. So I agree when you say that it doesn't hurt the work or readability very much. After all, you rarely need to read the commit history of the project. You probably also have a ticketing system to help.
However, for very little effort, I like to have a clean commit history in my code. So I use it as part of my workflow. Here are some areas and reasons for where / why I use it:
Fast forward merges
In the git top 20 list (gitstar-ranking.com/repositories), more open source projects use fast-forward merges than 3-way merges. So it may be necessary to use git rebase for this.
Linear commit history in feature branches
Even when using 3-way merges, I'd rather commit a branch with a linear commit history if I can. But sometimes there are conflicts with the main branch. So you merge the main branch into your branch to resolve them. But this makes the commit history and commit graph messier. Instead, I rebase to keep my branch's history linear.
Pull with rebase
Pulling without rebase can create 3-way merges in your local branch. I find these unnecessary, so I use
git pull --rebase(actually I've set this as the default behaviour in the git config file).Cleaning up bad commits in feature branches
Sometimes I use rebase for small refactors I do later. For example, if I'm working on a module, I'll have some commit message along the lines of "add module X" or "add function X". In the meantime, I might do some other related work and create more commits. Afterwards, as I'm checking over all of my work, I might do a tiny refactor on module X, such as writing a line of code in a simpler way, or maybe changing the name of a test.
I don't want useless commits for that:
So I rebase to have a single commit message of "add function X".
But, at other times, I don't commit until I've finished my work. In that case, I structure all of the commits properly the first time and don't use rebase.
Also, as part of my workflow, I commit early and often and also use TDD. That way, if I mess up, I can just reset to the previous TDD loop (from 2 minutes ago). I normally just use
git commit --amendfor these temporary commits, to save the effort of having to rebase them later. But sometimes, I end up with a couple of "temporary commits" for various reasons. In that case, I go back and usegit rebase --interactiveto organise them into something sensible.But that's just my experience. What are your thoughts on this? Do you come across little issues like these? If you do, do you ignore them (because, let's be honest, I don't think they're significant), handle them in a different way, etc.?