It does confuse anyone who has pulled before the squash, but if you're working on feature branches, then there shouldn't be anyone else who's working on the branch. If the feature is too large for one person, let's say you have 5 people working on a feature branch; then each one of those 5 people should be branched off the feature branch, for the same reason.

> I thought that if you rebased & squashed something after you pushed it, then it would confuse the git clients of anybody who had pulled before the squash?

When a single developer if working on a feature in their own feature branch, and using that branch also as a backup (e.g. pushing "going to lunch" commits), there should be no need for anyone else to pull this branch when the work is unfinished and ongoing.

Well, they can pull it to e.g. take a look at the code, but as long as they contribute to the branch themselves (and why would you base your work on someone else's "going to lunch" commit?).

If a group of people works on the same feature, then they should set up a "master-feature" branch, in addition to their personal branches.

One of the pure joys of working with Git is being able to commit early and commit often. I'll often commit a 100 times in a day, and not always with cogent commit messages. The freedom to make a mistake or false start and know you can rewind to an earlier point is very liberating.

But before I share that work with anyone, it needs to be squashed and then broken out into a logical progression of cleaned up commits with good descriptions that are bisect friendly.

By all means use the power of Git to give you great freedom while coding locally -- but don't push the resulting cruft to shared repos.

I use the index as a sort of quasi-commit, which lets me effectively step back one revision if needed. I find this to be a lighter-weight option than many commits that may be meaningless, while providing probably 90% of what those commits would give me throughout the day. As a result I typically make 4-5 actual commits but may have had many transient points at which I could have - and sometimes did - revert a set of changes.

To avoid this the team could agree on what branches rebase is OK, maybe adopting a naming scheme that will make clear what branches might pull the rug from under you (e.g.: branches namespaced with the developer's username (i.e.: drewg123/fix-for-bug)).

I personally prefer to rebase on a new branch, naming the new branches with a suffix in the form "-vN". Would something go wrong with the rebase, it will be way simpler to reset the new branch to the head of the old than to recover from the reflog. Nowdays I rely heavily autosquash, interactive add, interactive rebase and Magit (which makes the later two a breeze).

Usually, a feature branch is a branch from which only a single person works from. So other git clients aren't part of the equation, there is only you. As such, rewriting history/git push --force is allowed there.

We also use Stash and just enforce that PR descriptions should be the "clean" version of your combined commit messages. This way you:

a) Never change pushed history

b) Have the Pull Request act as a single source of what changed in each feature branch. Since Stash also includes comments from code review, we find it offers more context than straight commit history

c) Don't have to worry about team commit-early-commit-often vs. team commit-only-when-it-works-perfectly. The changes will all be centrally documented in the PR, no matter the individual styles