4 ms·
I think a lot of people don't bother with rebasing because they either don't know how to do it, or they are scared of the idea of a version control system not e
by EnderMB 9y ago
I think a lot of people don't bother with rebasing because they either don't know how to do it, or they are scared of the idea of a version control system not explicitly saying what they've done to accomplish the latest version of their code.
Once you get even a small understanding of it, there are plenty of places you can use it. For example, in the past month I've used it to:
1. Rewrite the history on a coding test I was given for an interview. The recruiter was oddly specific about how long to spend on it, and when it had to be in by, even though they said no one would look at it for another week. I worked on it throughout the extra week, and modified the history to make it look like I had done it in the allotted time-slot.
2. Rewrite history in feature branches where it doesn't accurately reflect what I had to do to get the code working. I work in an agency environment and (whether I like it or not) requirements change, sometimes mid-way through delivering something. If I've written something that won't ever see the light of day, or if I've done something that won't help the next person to read that code I'll rebase where needed.
3. Saving time for pull requests. I tend to commit early and often, and when I'm in "the zone" on a fairly chunky bit of work that can mean quite a few commits! When it comes to peer review, some people like to do it by commit, rather than the finished output, so to help these guys out I squash commits where possible, since we use our pull requests to illustrate the problem we're solving anyway. I think an untarnished history is important, but sometimes a PR audit trail is more useful than what you'd get from pure commits.
- nothrabannosir 9y agoJust a note on your nr1: I don't think rebase back-dates the CommitDate, does it? There are two dates on any commit: AuthorDate and CommitDate. Try git log --format=fuller. E.g.: Author: ... AuthorDate: Wed Aug 2 11:02:03 2017 +0100 Commit: ... CommitDate: Wed Aug 9 12:08:52 2017 +0100 This is a commit I originally created last week, but rebased onto my current branch just now. To change the CommitDate, you have to go filter-branch, afaik. But maybe I'm ignorant of a germane rebase feature?
- dmacedo 9y agoYou're correct, it doesn't change the author date. In order to do no.1; perform your rebase, and then change the dates with filter-branch. I have a couple of helper functions for both for resetting to commit or author dates [1], use at your own risk! :) [1] https://gist.github.com/dm/aad8e34a5ee6b542a0bc788375b548ed https://gist.github.com/dm/aad8e34a5ee6b542a0bc788375b548ed
- EnderMB 9y agoYep, it took me a while to figure out why my commit dates didn't match the dates within GitHub. Luckily, it's fairly straightforward to figure out once you know what the issue is!
- jogjayr 9y agoAnother note on #1 (which I've also done in the past). Don't your pre-rebase commits remain in the reflog?
- Vinnl 9y ago> 3. Saving time for pull requests. I tend to commit early and often, and when I'm in "the zone" on a fairly chunky bit of work that can mean quite a few commits! When it comes to peer review, some people like to do it by commit, rather than the finished output, so to help these guys out I squash commits where possible, since we use our pull requests to illustrate the problem we're solving anyway. I think an untarnished history is important, but sometimes a PR audit trail is more useful than what you'd get from pure commits. I think this is the most important one. Your commits are documentation for people reading your code, so whatever helps them is good.