If your goal here is to have linear history, then just use a merge commit when merging the PR to main and always use `git log --first-parent`. That will only show commits directly on main, and gives you a clean, linear history.
If you want to dig down into the subcommits from a merge, then you still can. This is useful if you are going back and bisecting to find a bug, as those individual commits may hold value.
You can also cherry pick or rollback the single merge commit, as it holds everything under it as a single unit.
This avoids changing history, and importantly, allows stacked PRs to exist cleanly.
The cases where bisect fails you are, basically, ones where it lands on a merge that does too much - you now have to manually disentangle the side that did too much to find out exactly what interaction caused the regression. But this is on the rarer side because it's rare for an interaction to be what caused the regression, it's more common that it's a change - which will be in a non-merge commit.
The squash merge workflow means every single commit is a merge that does too much. Bisect can't find anything useful for you by bisection anymore, so you have to get lucky about how much the merge did, unenriched by any of the history that you deleted.
We do. If we are building out a feature, none of its code is merged into main until it is complete (if this is a big feature, we milestone into mergeable and releasable units).
The feature is represented by a Story in Jira and a feature branch for that story. Subtasks in jira are created and multiple developers can pick up the different subtasks. There is a personal branch per subtasks, and PRs are put up against the feature branch. Those subtasks are code reviewed, tested, and merged into the feature branch.
In the end, it is the feature branch that is merged (as a single merge commit and complete unit) into main, and may well have had contributions from multiple people.
Somewhat Linux-like. You could probably improve it purely from a git perspective by letting subtask dependencies be many-to-many (the commit graph is a dependency graph), but what you have is probably best for your whole Jira workflow.
I get your POV, but I’ve always considered that long-lived branches in the canonical repo (the one in the forge) other than the main one should be directly related to deployable artifacts. Anything else should be short-lived.
There can be experiment on the side that warrants your approach, but the amounts of merge going back and forth would make this hard to investigate (especially when blaming) I would prefer to have one single commit with a message that describe every contribution.
Unlike merge strategies, where squash-to-merge is almost always motivated by someone not knowing how to use the tools well, branching strategies can be very diverse and project-dependent for very good reasons. Some projects have to maintain multiple versions of the thing they produce simultaneously, others don't. Some projects effectively maintain a patchset on top of some external upstream project, some are the upstream that's being forked by others - and some are somewhere in-between. Sometimes you break half the world to slowly fix it afterwards in a long running refactor, often you don't. Often there's a single canonical repo where all work happens, sometimes there's not. There's no genuine one-size-fits-it-all, but fortunately, git is very flexible there.
Blame, bisect etc. work well with histories with lots of back-and-forth merging, as can be easily seen in Linux, so blaming is definitely not a reason not to do it this way if your project calls for it otherwise. Perhaps one issue with such workflow is that some popular review tools aren't exactly great at letting you review merge conflict resolutions.
* git merge ALWAYS does a merge and git pull ALWAYS does a fast forward.
* git log --first-parent is the default. Have a git log --deep if you want to go down into branches.
If you use a workflow that always merges a PR with a merge commit, then git log --first-parent gives you a very nice linear history. I feel like if this was the default, so many arguments about squashing or rebasing workflows wouldn't be necessary to get our "linear history", everyone would just be doing merges and be happy with it. You get a clean top level history and you can dig down into the individual commits in a merge if you are bisecting for a bug.
I set merge.ff = false and alias ff to merge --ff-only. I don't use pull but I do have pull.ff = only set, just in case someday I do.
The graph log and the first-parent log serve different purposes and possibly shouldn't be the same command conceptually; this varies by user preference but the first-parent log is more of a "good default", generally. Merges do say "Merge" at the start, after all.
This is what I advise people to do in consulting engagements, too, it's not one of my personal quirks.
They could switch their domain to another email provider and start getting emails, which is great. The problem though, is they also used their Google Account to log in to all the 3rd party services (payroll). I have no idea how you would get back into those services. Some _might_ let you switch off the Google Sign-in SSO, but I imagine that is a headache.
I always thought the "planets"[1][2][3] were a neat idea. I wish there were more of them for dedicated topics. Then I can just subscribe to specific planets which pulls curated feeds from various blogs on that topic.
I just want the simple feature of PRs updating when the target branch changes. For example, say I have two tickets: T-100 and T-101. Both are targeting main, but T-101 builds on top of T-100. I put up a PR for the T-100 branch against main, and put up a PR for the T-101 branch against main.
The T-101 PR can't really be reviewed yet, since you are looking at changes from both T-100 and T-101 (because T-101 was based on T-100).
Ideally, after T-100 is reviewed and merged, the T-101 PR would automatically update to show only the T-101 changes. But it doesn't. You have to manually rebase or merge main and push changes to the branch to get it to update. It would be great if GitHub handled this automatically.
If you want to dig down into the subcommits from a merge, then you still can. This is useful if you are going back and bisecting to find a bug, as those individual commits may hold value.
You can also cherry pick or rollback the single merge commit, as it holds everything under it as a single unit.
This avoids changing history, and importantly, allows stacked PRs to exist cleanly.
reply