21–30 of 201 posts
I follow your flow, and I don't bother squashing my commits. So the repo history has lots of dumb little commits. We use a branch model for features, though, so I can just filter for those merge commits if I want to see granularity at the feature level.
In the 20+ years that I've been using computers, and ≈15 or so that I've been writing software, I've never experienced a drive failure.
I follow your flow, and I don't bother squashing my commits. So the repo history has lots of dumb little commits. We use a branch model for features, though, so I can just filter for those merge commits if I want to see granularity at the feature level.
Easier for you. Harder for who reads you history.
Shameless plug, but here are other efficiency tips I wrote about, for working in a high demanding environment: https://dimtion.fr/blog/average-engineer-tips/
(based on years of experience with errors, failures, data loss, etc...)
edit: But I also now like to be messy in a dev branch, so it matters less in the grand scheme.
I do the same, but before pushing, I squash the commits to remove the small intermediate commits. That may be what your coworkers are doing as well.
2. Make changes
3. Commit changes at whatever point and write a good commit message about the feature.
4. Commit more.
5. Create feature/branch_rebase
6. Squash all the commits.
7. Push to fork
8. Make pull request
9. Make fixes and push those commits per fix.
10. Squash when merging back to that first commit.
I like having a separate rebase branch because then I have all my work in one branch and the history of what I did. Then I squash it and get rid of the that history, then maybe rebase main back into it if there we changes since I started the feature.
Earlier quoted context omitted.
...what is the golden rule of rebasing edit: googled, "Never rebase while on a public branch" i.e. a shared branch
It usually works out fine when you do a `git pull --rebase`, but not everyone does this or has it setup so pulling might have some nasty effects. Generally helps to consider a feature branch as a private branch. Don't push to other people's features without asking, don't fuck up other people's work.
Such an annoying mess it leaves otherwise. And CI is building 'merge branch master', on the master branch, great.