I tell everyone to save/commit as much as possible , I don't want to hear I lost 2 weeks of work. After words I just squash the gesture into master named after whatever the short feature is "feature modal","new admin view" whatever...git history without squash or debase is a nightmare when everyone has commits like "typo 1" "typo2".
Git: Using Advanced Rebase Features for a Clean Repository
21–30 of 87 posts
Re: Git: Using Advanced Rebase Features for a Clean Repository
#22Editing git history makes sense in several cases: 1. Projects like the Linux kernel which use frequently use 'git bisect' to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers. 2. Open source projects, where some contributors have terrible git habits that the maintainers don't want to merge. Editing git history makes less sen…
Resolving conflicts through a merge or a rebase is a different style (all-in-one vs piece-meal), and I find both have their uses in different contexts. Sometimes, a big merge with tons of conflicts is too daunting, where a patch-by-patch conflict resolution is more palatable. Other times, you're doing busy work on tons of patches which would be far more efficient just doing once on a big merge.
But, again, this depends on the situation, the code, the history, the patches, etc. It's just a useful tool to keep in mind come merge time.
Re: Git: Using Advanced Rebase Features for a Clean Repository
#23I 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.
Re: Git: Using Advanced Rebase Features for a Clean Repository
#24I tell everyone to save/commit as much as possible , I don't want to hear I lost 2 weeks of work. After words I just squash the gesture into master named after whatever the short feature is "feature modal","new admin view" whatever...git history without squash or debase is a nightmare when everyone has commits like "typo 1" "typo2".
Try selling git commit --squash or --fixup. Your colleagues can use this without actually rebasing, and you can help them out with the final step by doing the rebase. Especially when you have:
git config --global rebase.autoSquash true
Re: Git: Using Advanced Rebase Features for a Clean Repository
#25I personally almost never rebase and/or squash, since I think that the information that gets lost (like: when was it started, what were mistakes along the lines) might be useful for future understanding of how the project work evolved over time, and what adjustments should/could be made to the development process. But I understand that a screen as shown in the article is not immensely usuful. But if it comes down on…
Say we work together. Why would you want to see my 5 solutions to a problem in `master`, of which 4 actually never really ran in production? I do commit often, things that I try and later throw away are in the history. Once rebased and squashed, only final solution is in `master` history.
Re: Git: Using Advanced Rebase Features for a Clean Repository
#26Editing git history makes sense in several cases: 1. Projects like the Linux kernel which use frequently use 'git bisect' to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers. 2. Open source projects, where some contributors have terrible git habits that the maintainers don't want to merge. Editing git history makes less sen…
is there a site that shows an animation for each git command?
Re: Git: Using Advanced Rebase Features for a Clean Repository
#27No 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) https://github.com/jonas/tig 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 inevitab…
Just one small thing, I have found a few times git rebase breaking git bisect. Git rebase can create large sequences of commits which no-one has ever checked out, and often don't build -- after a git rebase most people check their new head builds and passes tests, but I've never seen anyone bother check their new history works.
git rebase --exec runs your test suite on each commit during the rebase. It is super useful
Re: Git: Using Advanced Rebase Features for a Clean Repository
#28I 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…
Just 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
Re: Git: Using Advanced Rebase Features for a Clean Repository
#29I personally almost never rebase and/or squash, since I think that the information that gets lost (like: when was it started, what were mistakes along the lines) might be useful for future understanding of how the project work evolved over time, and what adjustments should/could be made to the development process. But I understand that a screen as shown in the article is not immensely usuful. But if it comes down on…
The thing is I commit very frequently, and a lot of the commits don't really make much sense by themselves. Often with stuff that's just plain wrong or confusing inbetween.
e.g. remove console.log
what do you need that in the git history for?
Re: Git: Using Advanced Rebase Features for a Clean Repository
#30I 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.
ok depends on the size of a feature I guess but usually I sit in a branch for 2-3 days before I finish the feature.
Also what's the point of preserving the history of a branch that is used for the development of a requested feature ? For each commit before the final, the feature is incomplete, possibly not working at all.