Comment by raju | Hacker News Reader

Comment by raju | Hacker News Reader

Parent Full thread

Do you use feature branches, or does everyone work off `master` ? (From your comment it seems like you do)

If you use feature branches, then it might help to

- rebase interactively to clean up/edit/remove commits that are not relevant before merging

- merge into master with the `--no-ff` flag - this forces Git to create _one_ merge commit, even if it is a fast-forward merge

FWIW the two above can be used individually or together. The way I work (and many others I work with) is

- create a feature branch off master

- hack, commit, hack, commit

- rebase interactively to clean up history

- issue PR on Github

- Merge using Github (which under the covers does a `--no-ff` merge so you get ONE merge commit)

Bisecting with this workflow is a bit more coarse grained than if you did a workflow allowing fast-forward merges b/c usually the closest I get is to know that it was a PARTICULAR merge introduced a bug or a regression. That merge commit might have any number of commits that constitute it.

Hope that helps.

[Edit: Formatting]

[Update 1] - If you use the CLI to merge, perhaps alias merge to merge --no-ff so you don't forget?

Re --no-ff, you can flip the behavior so that you need --ff when you really want to fast forward by adding this config:

    [merge]
      ff = no

We use feature branches, using atlassian stash rather than github.

I'm confused though -- 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?

Thanks so much for all the suggestions!

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.

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.

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.

> 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.

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).

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

I haven't mastered rebasing yet (nor interactively) but I've started feature branching off master, committing (and more if needed), then checking out master and `git merge --squash feature/<branch>` to squash the commits. Seems alright, so far.

Reply on news.ycombinator.com