Git: Using Advanced Rebase Features for a Clean Repository
1–10 of 87 posts
Re: Git: Using Advanced Rebase Features for a Clean Repository
#2nice work Tarik!
Re: Git: Using Advanced Rebase Features for a Clean Repository
#3I have been using that in every branch: I commit regularly and end up with 10+ commits. Then I rebase + squash them and at the same time write a summary commit. Eventually I merge.
This has multiple good effects. First, you get a clean, featured-based history.
Secondly, although your commit message is the one you wrote when you rebased, you can keep the old commit messages and you get a better summary of what happened during the development process of that branch.
Re: Git: Using Advanced Rebase Features for a Clean Repository
#4Is this a fixed-width comic font? :-/
Re: Git: Using Advanced Rebase Features for a Clean Repository
#5Is this a fixed-width comic font? :-/
Looks like Inconsolata or Consolas font to me. Not comic font at all.
Re: Git: Using Advanced Rebase Features for a Clean Repository
#6I have been using that in every branch: I commit regularly and end up with 10+ commits. Then I rebase + squash them and at the same time write a summary commit. Eventually I merge. This has multiple good effects. First, you get a clean, featured-based history. Secondly, although your commit message is the one you wrote when you rebased, you can keep the old commit messages and you get a better summary of what happene…
Why have a history then at all?
The idea is not to squash history but make it reasonable chunks. Remove chaff so to speak while keeping the general history.
A single feature is very rarely a reasonable chunk. (For example, see Linux kernel patch series per feature.)
Otherwise you may lose the "why" unless code is extremely well commented and that never happens.
Re: Git: Using Advanced Rebase Features for a Clean Repository
#7Is this a fixed-width comic font? :-/
Looks like Fantasque Sans Mono. It takes a bit of getting used to, but I've found it amazing once you do get used to it. YMMV.
Re: Git: Using Advanced Rebase Features for a Clean Repository
#8I have been using that in every branch: I commit regularly and end up with 10+ commits. Then I rebase + squash them and at the same time write a summary commit. Eventually I merge. This has multiple good effects. First, you get a clean, featured-based history. Secondly, although your commit message is the one you wrote when you rebased, you can keep the old commit messages and you get a better summary of what happene…
Why have a history then at all? The idea is not to squash history but make it reasonable chunks. Remove chaff so to speak while keeping the general history. A single feature is very rarely a reasonable chunk. (For example, see Linux kernel patch series per feature.) Otherwise you may lose the "why" unless code is extremely well commented and that never happens.
Not the OP but with my own personal usage, sometimes I'll end up with multiple related commits where I've had to go back and fix a test or correct an issue I missed with an earlier commit. Therefore I commit and squash that into the earlier commit with related changes.
I don't buy that every change should be a separate commit - if changes are related and the commit message covers the changes it makes sense to squash.
Not sure if OP is talking about squashing all commits into one. I have seen people do this and I'm always a bit confused why, similar to your point.
Re: Git: Using Advanced Rebase Features for a Clean Repository
#9No one's perfect with this stuff.
If you don't believe me, clone git itself ($ git clone https://github.com/git/git) and open up the repo in tig(1)
To be honest, I only in the past 2 years even bothered to view ($ git log --graph). Regardless of --graph getting wide now and then, I always visualize my git history as a straight line.
Also, sometimes having a non-linear history is inevitable. Especially in large open source projects where you're pulling in patches to a branch, and patches on top of that. You're not always going to be merging a branch with a single author straight onto master.
Despite posts like this (http://www.bitsnbites.eu/a-tidy-linear-git-history/) encouraging good git hygiene, I've had multiple open source projects merge in code via GitHub and never had negative consequence for it :P
Maybe there are corner cases where git bisect wouldn't work? Though I never used git bisect even once. Most I do is scroll through tig and view diffs. Also used to play with a cool git plugin in vim (https://github.com/tpope/vim-fugitive).
Also, GitHub has (since that linear git history post) introduced Rebase + Merge https://github.com/blog/2243-rebase-and-merge-pull-requests. I think that'll get you what you want.
I do keep branches ("pull requests" if you're using GH lingo) up to date with ($ git pull --rebase). That does mean a force push ($ git push --force), but it's ok if it's your personal branch. I also use interactive mode ($ git rebase -i ) to edit/blend multiple commits.
Also, when I do merge, if I go through CLI, I'll preserve the history of the branch by not doing fast forwards ($ git merge --no-ff).
Re: Git: Using Advanced Rebase Features for a Clean Repository
#10keeping a clean commit log or even strong commit rules is something which I only see as barrier for improving existing code... just thinking of code improvements by PRs which got rejected by bigger projects because the commit history was not "clean enough". History is not always good or pretty in real life... it should be the same on git commits.