4 ms·
I see a bunch of vague and non answers to this question. Here is mine: Git rebase + squash Actually sitting down and understanding what it's about, trying it o
by jstummbillig 7y ago
I see a bunch of vague and non answers to this question. Here is mine: Git rebase + squash
Actually sitting down and understanding what it's about, trying it out and implementing it should be possible within 1 hour without ever having touched it before, and has at least a huge potential to make you way better at Git.
- jobigoud 7y agoI only have a vague idea about what this does so I may be missing the point. I only ever saw this as a way to hide the multiple commits that go in the creation of a given piece of code, in order to present a neat commit as if everything was figured out first try. First, I don't like to have too many commits that aren't pushed to the remote repo, if my machine fails, I would loose work, so usually I only have one or two commits unpushed. Secondly, I like to think of the history as containing these previous tries, and sometimes I will realize that the end result has a subtle bug that was introduced somewhere along the line while piling on the feature. I work mostly on repositories with very few team members (1 to 5). What am I missing? Why would I destroy history? Is it reversible? Is it just to hide messy progression?