Historically there has been a number of complaints on the way git allows people to change history. There are continued discussions on using rebase, merge, and/or squash. I want to bring focus to the point of all these choices, communicating. I'm not looking at providing new suggestions, someone has already written about why you should do one thing or another.
Who might you want to be communicating with?
- Future self
- Other Developers
- QA member
- Project Management
What is it you might want to communicate?
- That a feature is complete (to the best of your ability at this time)
- This code change is needed to fix bug X
- I have this important documentation update
- I was doing some work and my editor decided to change these files and I don't know why.
- I don't like the formatting of this document, here is my recommendation
- I completed X, Y, or Z and think it is important to get these upstream for everyone to benefit.
- Can we please upgrade our visual studio project files to the latest version of .net?
Now as a developer, wouldn't it be great if this is actually how you developed your work? Nice clear goals, good discipline in only doing one thing, ignoring that bug you found because it isn't the task at hand? Well, no it wouldn't be good you'll forget about that bug, or you will be so busy documenting that it needs fixed you forgot where you were in your task, it's just much better to get those changes into the code base and move on. And this is why Git's history rewrite is so valuable.
Top comments (2)
I don't like the idea of history rewrites; that word tells you more about the implementation than the conceptual changes you're making.
I like to think about history changes like this: I check out a commit, make some changes, then I redo all the changes I had done previously. Now I reset the old branch to this new head.
This also reflects one implementation detail: your old hostory isn't lost, there's just no more references to it, so you don't see it. The commits are still there, until they get garbage-collected at some point. In other words, the git "history" is immutable and cannot be changed; you can only create a modified copy.
I argue that it is representative of those ideas. Consider how history is written and what happens when it is rewritten. First there is the event, then what was written about the event. To rewrite history, the old writing isn't gone, but may no longer be referenced. ReRead that thinking about coding.
I'm also not advocating rewrites, so much as advocating to use it as a means to an end, communicating.
he-the-great.livejournal.com/61227...