DEV Community

Discussion on: There Is No "Right" Way: Git Rebase vs Merge

Collapse
 
jessekphillips profile image
Jesse Phillips

The real question is what do you want to get out of your history?

To me history is the why. I like to use the example of undo trees, seen in emacs and vim, these could be view as in memory commits. They have branching and timestamps, but limited in scope to a single file.

The reality is, this isn't the history people keep. They work and craft out a spot they believe is complete. Or they adhere to someone commit twice a day rule. Either way the history is not real.

There are specific tools which make use of history. bisect which searches for a commit. blame which describes a file based on its makeup of commits. revert which is the 'undo' of git, cherry-pick the copy/paste of git. I want to build out a history which maximize the usefulness of these tools.

Git also provides the tools to help with that, staging area, commit --fixup, rebase -i, and more. Fixup is great for code reviews while allowing for quick cleanup before merging.

Yes it doesn't matter, unless your goals line up with mine.