7 ms·
The way I phrase and teach what I consider to be the important rule of git is: > Don't rewrite history on shared branches with proper communication. I don't t
by ohwellhere 3y ago
The way I phrase and teach what I consider to be the important rule of git is:
> Don't rewrite history on shared branches with proper communication.
I don't teach "never", I don't teach that `main` is special, I don't teach that force pushing is forbidden, because I don't believe in those things.
I highly prefer a rebase-heavy workflow. In addition to not "cluttering" the history, it's an invaluable tool to keep commits focused on "the right level" of atomic changes.
- jakelazaroff 3y agoI assume that “with” is meant to be “without”?
- joshribakoff 3y agoYou can simply pass flags to “git log” to hide merge commits, without needing to rewrite history to “destroy” that information. While they are often noisy, sometimes they can be useful. I usually prefer to hide information rather than destroy it.
- unlikelytomato 3y agoI read this justification in nearly every thread that pops up git rebase. I feel like a full because I cannot think of a real world example when this information crosses from signal to noise. Generally, branches that are not ready to merge tend to have enormous amounts of noise commits. Is there a blog post or some concrete examples I could work through that illustrate these benefits? I feel like workflows dramatically different from mine are likely the source of my struggle.
- fulafel 3y agoIt's a log of what happened in dev and supports reconstructing history to understand why something worked or didn't in retrospect. "It work when we tried it" "oh this dependency was updated in this merge commit that could have changed the behaviour"
- unlikelytomato 3y agoI am not sure how this is unique to a merge commit. The commit with the dependency change still exists in the main branch. The commit should never have gotten into main branch of it failed tests. If I take a positive action to rebase, I am accepting my fate from master anyway. If I merge into my working branch instead of rebase, that historical context issue only useful for that moment in time of reconstructing history and is not useful anymore. Once a branch goes into master, I want commits to main to have a 1:1 ratio of committed code for a task to positive action taken by a human.
- fulafel 3y agoIt's not unique to a merge commit of course, but a point in favour of preserving history.
- thebigspacefuck 3y agoIt’s annoying when someone force pushes to a branch that you just reviewed, but you can no longer see the history so you have to scan through the whole PR you already reviewed looking for the change. Please just commit the fix, let me see it, then squash it.
- sam_bristow 3y agoUnfortunately I haven't seen a git forge that will let you do "autosquash on merge" so I could just push up fixup commits as part of an merge request.
- PhilippGille 3y agoGitHub: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests https://docs.github.com/en/repositories/configuring-branches...
- seba_dos1 3y agoThat always squashes the whole PR into a single commit, making it not very useful in practice. Git's autosquashing is much more powerful than that.
- seba_dos1 3y agoYou can just diff the previous head with the new one. In GitLab, it's simply a matter of clicking "Compare with previous version". Locally, it's `git diff branch@{1}..branch`. It's only becoming tricky if the MR has been rebased onto a different base in the process, but it's not very hard to deal with that too if needed (just annoying).
- seba_dos1 3y agoActually, it's not that annoying at all - TIL about `git range-diff`.