4 ms·
No this is totally fine. I'd say the slightly more rare thing about this workflow is the fact that you squash multiple commits for a feature together. At least
by xxbondsxx 13y ago
No this is totally fine. I'd say the slightly more rare thing about this workflow is the fact that you squash multiple commits for a feature together. At least at larger companies it's nice to maintain a series of commits that lead to a feature (rather than getting a giant commit that plops the feature down with no sense of how it slowly developed).
I added support for merge --no-ff since a fair number of people like that workflow:
http://pcottle.github.io/learnGitBranching/?NODEMO&command=git%20commit;%20git%20checkout%20-b%20foo%20C1;%20git%20commit;%20git%20merge%20master;%20go%20master;%20git%20merge%20foo%20--no-ff http://pcottle.github.io/learnGitBranching/?NODEMO&command=g...
but maybe --squash should be next
- prezjordan 13y agoIn that case, I just pop into the reflog and undo the squash.
- xxbondsxx 13y agoTrue, although ideally reflog is just a backup in case you make a mistake (and not an integrated part of your workflow). What I've found surprising is just how different workflows can be from project to project (or company to company). Some developers are die-hard about preserving history at the expense of the graph, whereas others are straight-line purists (and don't even accept merge commits on the remote). I actually have some limited support for "git checkout -" to go back, but I should get around to making a legit reflog...
- wging 13y agoI work in a team of about 10 at a large company and it's convention to squash. The alternative is turning a potentially very messy history into something we'd care to look at two months from now. This doesn't seem worthwhile, especially since you now have a situation where some commits on master are intermediate, unshippable states. What am I missing?