Honest question - does git have to be as complicated as it is for most usages? The number of times I got stuck fixing (mine and other people's) git issues is way more than seems necessary. I have not used a merge at a workplace for so long that I forget how it works, because rebases make so much more sense. Git provides a thousand features and I find myself using only three. And yet mercurial (which I remember having a more streamlined UX) went the way of the dodo.
Git could definitely have a simpler interface, but massively simplifying the mental burden would ultimately involve reducing its power as a tool. A significant part of the appeal is that the power users and the novices can both agree on the same tool and make it work for their needs. There's a huge "aftermarket" of frontends and scripts to simplify the experience in the way you want. Some of them, like jujutsu [0] are basically entirely new VCSs built on top of git (and influenced by mercurial).
I didn't mind mercurial, but I think it's telling that even the tech behemoths championing it like Google and Facebook forked off into their own tools (fig/sapling). The latter even supports git directly. That battle is long over.
> The number of times I got stuck fixing (mine and other people's) git issues is way more than seems necessary.
I almost never have any issues with git, I wonder if you're working differently than I do?
> I have not used a merge at a workplace for so long that I forget how it works, because rebases make so much more sense.
Oh, that's the reason.
I've been using git almost as long as github.com has been a thing and I'm convinced that if you find yourself rebasing, _especially_ if rebasing is a normal part of your workflow, you're using git wrong.
Here's how I work:
1. All development is on a features branch
2. Feature branches are tight and focused
3. Frequent merges from `main` to stay up-to-date
4. Squash your branch into a single commit before merging
This gets you everything you want from source control (linear history of well-structured atomic changes) without any of the gymnastic skills necessary to be a competent rebaser.
Oh, and I never get stuck fixing weird issues, because it's impossible for me to generate weird issues. The worst thing I encounter is a merge conflict, and merge conflicts are the easiest possible conflicts to resolve.
Disagree pretty strongly about rebasing. If you are an experienced and full-time programmer then you should know how to rebase and merge, and understand when the time and place is for each one, and I personally always rebase my local topic branches. I understand this is a bit subjective and may depend on local context, but essentially my view is this:
When you merge, conflicts are resolved for a large number of independent commits all at once and crammed into a potentially large blackbox commit that is not directly related to either the work on main or your topic branch. When a developer makes a mistake in that merge (which happens often), it's hard to reason about their mental state and whether they fully grokked the state both both branches. Even worse is when there is a logical conflict, but the lines aren't near each other, so git just happily merges.
By contrast, when you rebase, you are essentially going through the exercise of updating your commits for the current state of the world, and each conflict is resolved locally to where it was authored, including completely removing things that no longer make sense. The result is fully bisectable, and this property can be preserved along with the ability to see original author and merge times with existing timestamps and merging to main with the -no-ff flag. Obviously this requires some expertise with git, but it's not very difficult once you get the hang of it, and in fact leads to more disciplined thinking about how your changes will roll out.
WRT to squashing, I think the value depends on the scale of the team and codebase you're working for. The larger it is, the more squashed you want things for posterity. However for small teams, as long as you keep CI building, finer grained history can be useful. This also depends on the size of your feature branches and deploy cadence, so YMMV.
It’s irrational, but I always stand on the sidelines of these conversations being a little bit cross that people slag off rebasing.
At some point someone pointed out that rebasing changed the history and if you change the history of a public branch everyone was going to have a bad time. That got turned into “rebasing is bad” and now people keep rolling it out the same old trope. It’s a tool, and a good one for managing your work. If you don’t know how to use it then you’re doing yourself a disservice.
In terms of squashing, my rule is that I squint at the PR and if the commits are going to have value in a years time then I’ll merge commit otherwise I’ll squash. In 10 years of running my codebase I’ve never blamed and thought to myself “I wish there were more fine grained commits here” so it’s obviously working fine for me.
As you say, do what works for your team but make sure you understand the tools and what they provide for you.
I think squashing or not squashing really depends on the quality of individual commits in the topic branch.
Myself, I almost always "edit the history" of my topic branch before merging. Often enough some interactive rebasing and occasional commit-splitting is employed. I do it to turn my topic branch into a series of clean logical commits, so that each one can easily be reviewed on its own. I would not want to loose such history, so I avoid squashing unless it's mandated.
When people don't have time\energy\skills\inclination for this kind of clean-up and their topic branch commits are a mess of random things reflecting their actual development process -- including errors, fixing these errors, random experimentation, etc., there is not much value in keeping such history, and squashing often produces and cleaner and easier to review commit.
However, for me the end result of a development cycle is not just a good state of the code (functional, tested, documented), but a good history of that code too: reviewable and bisect-able. Git provides tools to maintain such manageable history, but does not do it for you.
I have never understood the "squash a branch to one commit before merging" attitude. I prefer small commits, both during code review and later, during looking into repo history (which is needed once in a while) or bisecting.
Also, technically, "squashing to one commit before merging" is rebasing, so apparently rebasing is a normal part of your workflow, too.
That said, our discussion only confirms that Git is pretty versatile and flexible. (Of course, the UI is terrible, but Magit helps a lot in that department.)
> I have never understood the "squash a branch to one commit before merging" attitude. I prefer small commits, both during code review and later, during looking into repo history (which is needed once in a while) or bisecting.
I 100% agree. You don't have to make massive feature branches for your changes. If your feature branch is huge, it's a sign that you probably should be breaking your work up into smaller chunks.
> Also, technically, "squashing to one commit before merging" is rebasing, so apparently rebasing is a normal part of your workflow, too.
Yeah, I know ¯\_(ツ)_/¯
This gets brought up every time I have this discussion, and it's correct, but also a little misleading. Squash-merges are never going to be any more challenging to make than regular old merges. Rebase conflicts are where people run into real trouble.
Rebase conflicts are just the dual to merge conflicts. Instead of applying the end result of my work, I apply my work step by step. I don't see the final big picture, but move towards it.
This is of course a nightmare if the branch is long-running, because then it becomes easy to forget what I was thinking and doing when making the first few commits. But this is where organizing and crafting good commits (good commit messages are just the beginning), and frequent rebases on top of the source branch help.
Frequent rebasing also makes it possible to start working on a feature that depends on somebody else's in-progress work. It works best if the other person also frequently commits, publishes and rebases their work to keep the trouble with rebasing to a minimum.
Git serves many kinds of dealing with concurrent activities in other branches well. Maybe too well :-)
That's true, but merge conflicts are the easiest possible conflicts to resolve. Main branch and my branch both changed this line, no matter what, you must resolve that conflict.
Rebase conflicts might be just as easy or they might be an order of magnitude more complex and confusing. They'll never be easier than a merge conflict.
Merge conflicts are often much harder to resolve than rebase conflicts. I often find myself going through individual commits in order to understand how to resolve such conflict anyway, which rebase does for me automatically (especially with diff3), providing enough context right away. In many cases, it's much simpler to follow the changes step-by-step.
Sometimes I even ended up resolving merge conflicts by rebasing and then rewinding back and committing the resulting state as a merge. It was easier that way.
Sure, there are cases where rebasing naively gets super annoying as each commit conflicts on cherry picking, but you can end up with pretty nightmarish merges just as well if you're not careful.
I'm not sure I understand. Why would rebasing ever be more complicated? They're the same thing at the end of the day, no? Main branch and my branch both changed this line no matter what, you must resolve that conflict.
Image you have a feature branch where you changed a block of code two times and are rebasing that branch onto main, where that block of code was also changed. During the rebase, you'll need to resolve that conflict twice. If you had merged main into your branch you would only have to resolve it once.
No matter how complex your branch gets or how much it diverges from main, you'll only ever need to resolve a conflict once. For rebasing you may need to resolve conflicts multiple times for changes you may have made hours/days/weeks ago.
If you're strict about rebasing and keeping your working branch clean and remembering what you were doing in that commit from three weeks ago the rebase process might not be that bad, but it can never be easier than a merge.
Rebase conflicts are like short-selling stocks; there's no upper limit on how bad it can get.
It seems there are 2 types of rebases involved here.
I never rebase a feature branch on top of the changes in the main branch. The branching point of a branch always stays the same.
But I use rebase for editing commits in my feature branch all the time, i.e. I rebase interactively one feature-branch commit on top of another feature-branch commit.
Because the evolution of the topic branch is largely irrelevant to future analysis. If you write tests firsts, then you have a commit in the repo where tests can never pass; fun for bisecting. If you write the code first, then you have a commit with a bunch of dead code in it because the tests appear in the next commit.
I would say that my average topic branch looks like: "edit the protos and rebuild them", "add feature", "add tests", "add CLI", "fix lint". There is no value in checking that into the main history in that order; the first commit doesn't compile because the API servers don't implement the API server interface anymore. The second commit is a bunch of dead code. The third commit is somewhat useful except the code doesn't follow the style guide and static checks fail. The fourth commit at least un-deadifies the code; something calls it now. The last commit is something that can be checked in. I really see no value in preserving that history; the set of commits makes more sense as one commit.
You could redo this to "edit the protos, and rebuild them, and add stubs that return Unimplemented", "add feature and tests to replace the stubs that return Unimplemented", "add CLI binding", which could stand alone if you felt like it. It is more work for the author, though, because you had to write code that you are literally going to delete in the next commit. Why bother? Personally, when I'm reviewing code, the more context I have, the better. If there is a design doc for the feature and someone sends me just the protos that they describe in the design doc and the design doc is actually good, fine. I got the context and this just speeds things along. If there isn't, how do I know this API is even right? If I see how it's implemented across the client and the server, then it's easy to make suggestions for improvement. If it's just the API, it sounds right, but I don't know if you can actually implement that feature until I see it done, right? More importantly, how do I know this set of 3 patches isn't going to be followed by "oops, forgot this in the protos", "oops, forgot this in the server", "oops, forgot this in the tests", and "oops, forgot this in the CLI"? Now we've turned one commit into 8. Why? Because "small PRs are good"? Prove it. I had to do 8 code reviews instead of 1. You had to write code that you're literally deleting the commit after you added it. Why bother? I'm unconvinced that the history of "do it", "oops fix it" is more useful when doing archaeology than "do it right the first time".
This is a problem with how you work. You're not making atomic commits, you're spreading a logical change over multiple commits. Non-atomic commits are just bad.
Here's an example of a correct way to use small commits: add a new function+unit tests into a library in one commit, then switch existing code to use it in one or more follow-up commits.
1. New function & unit tests
2. Switch existing code to use new function
3. Whoops, new function broke some existing code
4. I guess I need to fix tests too
5. Spelin mistakes
There's at least three ways to clean this up:
First, you could maybe do an interactive rebase, move commits 3-5 up and squash into commit 1. Maybe easy, or maybe you hose yourself and break everything.
Second, just squash it into a single commit. No possible way to screw this up, works every time.
Third, do a `merge --no-commit`, commit your changes and your tests, commit the changes to the existing library to use your new method. Easy and straightforward and keeps the two change separate if that's something you're into.
You call git rebase "worst" purely because you don't currently see the value in granular commit history. If and when you do, git rebase is just the tool for the job.
`git merge --no-commit` only works for trivial things, real world is a lot messier than that. But perhaps you haven't needed to deal with the complex changes. For an idea of what complex changes look like, skim some linux kernel VFS or MM refactoring patch sets.
> You had to write code that you're literally deleting the commit after you added it. Why bother? I'm unconvinced that the history of "do it", "oops fix it" is more useful when doing archaeology than "do it right the first time".
My suspicion is that people are using rebasing to clean up their prior commits as they go instead of just getting everything working and then breaking the work up into commits, if needed. And this is also how they work themselves into horrible knots trying to figure out what they did to hose their branch.
I have to disagree with #4. If your branch's commit history is unnecessarily fragmented because it evolved as you worked, then yes, squash those commits - but "one commit per feature" as a rule doesn't work for many kinds of features which by their nature can be made only so "tight and focused". Sometimes it's an undue burden to have to view a feature's patch as a single diff, even if the feature is functionally as atomic as it can get.
First, my feature branch commit history is always fragmented and unusable. I commit extremely liberally, every few minutes if I'm actively making changes. Why not? If I always squash before I merge, nobody seems my junk, and being able to back up a few steps after coding down the wrong path is super useful.
Second, if I do create a feature that should be multiple commits for clarity, I find it a lot easier to do all my work in a scratch feature branch, get everything working correctly, tests passing, etc., then do a `git merge --no-commit` onto my final feature branch for the PR. At that point I can break my work up into a few different commits, as necessary.
Maybe consider you're just a messy person, and don't extrapolate from that to "if rebasing is a normal part of your workflow, you're using git wrong".
For me, rebasing is the means by which I keep my development branch neat and tidy. Each commit changes one thing. It's easy to see what's "prep work" and what's the ultimate change of functionality. Git bisect can find the commit that caused a bug. And so on.
I view squash merges largely used as a crutch to hide bad habits. I find the resulting history from lots of squash merges is not useful in figuring out why a change was made; by that time the specific change is part of a big ball of mud with a very vague high-level goal.
> Maybe consider you're just a messy person, and don't extrapolate from that to "if rebasing is a normal part of your workflow, you're using git wrong".
Possibly? But I also find it hard to believe that there's this many developers out there typing out perfect code on the first try with no mistakes or false starts.
> I find the resulting history from lots of squash merges is not useful in figuring out why a change was made; by that time the specific change is part of a big ball of mud with a very vague high-level goal.
That's the developer's fault though. If someone is lazy enough to squash-merge a big ball of mud onto the main branch, they would also be lazy enough to generate a commit history filled with barely working and unclear commits, or incompetent enough to completely hose themselves with a rebase.
At the end of the day, I'm generating the same set of small, atomic commits as you. The difference is that I don't spend any time worrying about what the commit history looks like while I'm coding. It's only at the last second before sharing a PR that I consider it. 95% of the time I've got a tight one-commit PR containing a little code, a few docs, a few tests. Sometimes I break my changes into separate PRs, very rarely I'll add multiple commits to a single PR, but those aren't my default workflows.
"Messy" and "tidy" is not something I'd expect to see in the conversation about private branches.
Version control in the private branch is a tool which helps me maintain state and go back and forward in time. It looks exactly like I thought about the code or work I needed to do at some point in time. It is not messy or tidy, it's just what it is. I don't have to please anyone's sensibilities when I'm in the private branch.
The merge into main is squashed and atomic, of course.
> But I also find it hard to believe that there's this many developers out there typing out perfect code on the first try with no mistakes or false starts.
Cleaning up one's own mess is what git rebase -i is for.
I pretty much only work in the context of teams. My own git skills matter quiet little - there are many other people of various skill levels who are working on the same codebase. Junior developers get very easily confused by git.
Git is a data structure manipulation tool. LibreOffice also doesn't have to be so complicated as it is for most usages, it's just that everyone uses a different 5% of its functionality and considers it essential.
There is a very simple workflow that uses a small subset of git commands -- I try to never stray from that. When I do, there is stackoverflow, ohshitgit.com, and I also know an expert who can help me untangle things if I am really unsure.
Also I've always found that cp working-tree broken-tree, then git clone <new-tree> then <manually fix up files I was working on> almost always beats trying to detailed the 10 suggested SO solutions.
I've always found that a good Git user interface goes a long way to understand what is really going on. The commit graph and the conflict resolution UIs are most important. The right choice is very personal - I've found understanding the contents of a repo purely on the terminal to be torture, even though I issue most commands from there.
That's just version control, nothing special about Git there. I guess a lot of kids running around these days never had this stuff happen, in worse forms, with CVS et al.
> I have not used a merge at a workplace for so long that I forget how it works, because rebases make so much more sense.
It boggles my mind that people think 1) rebase makes more sense than branching and merging, and 2) that someone would use rebase so much that they forget how to branch and merge.
I had a detailed discussion with a former colleague about this the other day. They're in the merge camp, and I'm in the "any code that actually makes it into the wild should have a linear history" (rebase) camp.
Merge commits have multiple parents which makes visual inspection confusing, and it makes it much harder to use git bisect which is a tool that can save many hours of painstaking manual work.
I clearly think that the rebase version is the correct approach, but I can see there are upsides and downsides for both. Sometimes for long lived branches I get merge commits in my feature / bugfix branches, but those are going to end up squash merged onto our release branch, so in the end the main thing I care about is the linearity of history in master/develop.
Combination of linear history and appropriate use of annotated tags for releases makes it way easier to see what actually happened (i.e. the intentionality). A merge based approach shows you what people were actually doing though.
> Combination of linear history and appropriate use of annotated tags for releases makes it way easier to see what actually happened (i.e. the intentionality).
I still haven't heard a good reason why linear history using git as an archaeological tool is the appropriate method to "infer intent". It seems like you would only have to infer intent this way if you have poor development practices, like not adding appropriate comments and not tying important changes to tickets that provide more background/context.
If you have a nasty nasty difficult to find bug that emerged some time ago, and your history is littered with merge commits, git bisect is going to go badly. If your history is linear, and your data model is compatible with itself across history for the bits you're interested in, and you can write a sane test case - auto or manual, then your troubleshooting is going to be O(n^x) simpler than the case where you've got merge commits, and save you many hours. Not something I have to do often (once a year or less really) but valuabable enough that it's important to me nonetheless.
Rewriting history when things land in develop/master I think is a good thing. To use an analogy from the humanities, history is written by the winner.
At work we're collaborating with the merge camp at the moment and it's very difficult to work out what they're doing from reading their history - some of it is their bad practices elsewhere, but the merge commits are confusing.
I'd also be fine with no rebasing but any merges must be fast forward, so if you can't do that fix your problems prior to integration.
Also I've used a few different approaches for a few different projects, and the rebase/squash merge approach is the one that in my experience makes things clearer and easier to understand. I'd be reluctant to return to other approaches (aside from enforcing fast forward merges in public branches).
I believe that squash merges are a good compromise as so long as you don't mess with the reflog and keep the automated parts of the commit messages, then there is no lying about history.
Gotta say, in 20+ years of branching and merging using CVS, SVN and then Mercurial, I've never had an issue tracking down nasty bugs. Maybe git bisect on a linear history would hypothetically be a few minutes faster in some cases, but doesn't make it worth all of the extra work and the dangers of overwriting other people's work.
I think the Fossil devs also make a good case that the problem is really a limitation in the tools like git bisect.
Intentionality is the perfect argument against merging feature branches: I intentionally don’t want my half-broken commits to be in the production branch. I want the complete product to be there.
Apparently what you do makes sense for you, but I hope you realize that using interactive rebase you can turn your half-broken commits into nice and clean commits!
I try to do this as I go, but there is always a "history review and fix if necessary" stage after I've got the code I wanted and before merging.
Apart from having granular, reviewable, bisectable history, there were many a time when by having this extra look at the code I found bugs or design flaws.
Whether such effort is worth it for you, and whether you have time\energy\discipline\skills for it is a different question.
> I intentionally don’t want my half-broken commits to be in the production branch.
That makes no sense. What does it matter that interim versions from a merge might not work, what matters are the milestones like merges and tags. Basically you're imposing a silly aesthetic restriction on what's supposed to be a functional tool.
The whole argument feels a bit People's Liberation Front of Judea to me. On the other hand I do have strong views on the matter, and I am pretty certain that my views are pretty close to the correct ones.
If your feature branches have independently working commits, go ahead and branch. Most people’s feature branches are developer diaries instead of potentially releasable products. Merging them would make everyone’s lives worse, so of course they get squashed.
Rebases are a bit weird since they mostly help during bisecting but still require production-ready commits in feature branches.
Who is "everyone", in "it would make everyone's lives worse"? Worse in what way, exactly? What quantifiable metric are you using to judge "worse"?
I agree that some feature branches can be developer diaries, but I'm not sure why throwing away the diary is a good thing, and why the repo should only contain "releasable products". Sounds like an aesthetic preference rather than something concrete.
> still require production-ready commits in feature branches.
I make a point of requiring that anyway. You gotta learn to build incrementally, repeatedly landing squashed mega-commits into main is just a recipe for future pain. To level up as a software developer, learn to create incremental work. git rebase -i is your friend.
I’ve had my share of rebase -i and I’ve gotten fed up with it, though GitHub plays no small part in that. Years ago when I worked with gerrit it made more sense. I just stopped caring because of the tool.
I still use Mercurial for personal projects! I do think it's superior to Git in many ways, and simpler than Git in many ways, but now i've got used to Git, i increasingly find myself getting stuck in Mercurial. For example, recently i included changes i didn't want in a commit, and found i had no good way out of the situation, whereas in Git i would just reset the branch to HEAD^ and try again.
Git was conceived to manage the Linux source tree, which is a problem in a class of its own. Fully decentralized source management requires an extremely flexible system, which conversely precludes any kind of implicit workflow. While this goes against previous SCM (svn, etc.) it also leaves a serious void for regular organizations that just need to keep doing centralized, trunk-based development. Github provides that missing layer in a friendly, accessible manner.
Ironically, by normalizing its usage, Github takes away a lot of the justification for git itself. You could achieve the same model with mercurial, bazaar, etc. which also have the advantage of a sane CLI.
I mean, this article is talking about how git works behind the scenes to make cherry pick work better and be less likely to fail to apple the patch. Yes there is complexity, but this is actually one of (rare) cases where git hides complexity successfully.
That's version control. You have every choice from straight forward to mind-blowingly time-manipulatingly complex. If you fear the unknown, then just do the out of the box stuff via a GUI like Sourcetree. If you're willing to sweat, then use Sourcetree but sometimes `git rebase HEAD~3` and rewrite history.
And there's no shame in adding a `Fix: Change var to int` to be written into the annals of history forever. Don't worry about it.
Funny enough. I only use merge because rebase makes no sense to me.
As an aside, I think git complexity can arise for two reasons. One is legitimate, if you have hundreds or thousands of devs committing to the same repo regularly you need to have some order to the chaos otherwise it just will grind to a halt.
The other is bullshit. Where some dev / management people believe that the git process needs to be complex for small teams due to the need to justify their place by "promoting safety". In small team environments, simple branching off of main and then committing prs directly to main is more than enough in my opinion.
But git gives you the tools to go as crazy as you want, so some people do.
Rebase is simple. It's "take these commits, and apply them one by one on top of another branch".
So let's say your main development line is the "main" branch. You start working on "bugfix", so you branch-off from "main". You do this on November 1.
So you make commits: "Fix bug". Then "Remove debug code", then "Rename X to Y". Now it's 10 days later.
Say a coworker is doing some other work at the same time, and just merged this into "main". You want to make sure that after that, everything still works properly. Maybe somebody changed something that makes the code you wrote no longer work, because somebody happened to fix a typo in a function's name or something, and you wrote your code against the old name which just ceased to exist.
So you do "git rebase main". What you're telling Git is "take the commits I made during the last 10 days, and apply them on top of the current main". It's like if you created a new branch then just applied the commits one by one by hand.
You can do this as often as you want, so if you've got some experimental refactor that takes you a month you can keep on rebasing daily to make sure that if there's any conflicts you have to deal with, you deal with it a little at a time, instead of having to figure out how to square a month of your work with a month of the rest of the project's work once you're done.
With this once you merge this into master, you get a "fast-forward" merge, which looks as if you were working on top of master all along. Instead of a single merge commit you see all 10 commits you made for the branch.
You can also do an "interactive rebase", where instead of having the process automated you can make decisions about each commit individually. This allows you to rename, merge, or discard commits. Like you've got 10 embarrassing looking commits where you just poke stuff at random in hopes of that it'll finally work? You can make them disappear entirely, or merge them all into one commit.
Not who you're responding to, but I also understand merge more readily than rebase. Your explanation doesn't really help.
Applying a commit "on another branch" isn't really well defined in my mind. In my understanding, a commit consists of one or more parent commits, and the complete state of a tree, including the entire contents of all the files in it.
Maybe there are other ways to be confused, but all of the uncertainty has been shoved into that simple phrase "apply a commit on another branch". What does that actually mean?
Have you ever used git cherry-pick? Git rebase is if you were loop over each commit (bottom to top) and run `git cherry-pick` on each commit separately.
If you haven't used git cherry-pick, then it is basically a shortcut for `git show $REF | git apply -`, where the short cut is the simplest form of using git, you have a patch (via git show) and you want to apply it to your local checkout.
Rebasing isn't that hard, but you also spent 8 paragraphs explaining it. Explaining merging just takes one paragraph: Copy all the changes from the main branch into my branch, if someone changed the same line that I changed, then create a merge conflict and manually figure out which change is right.
> In small team environments, simple branching off of main and then committing prs directly to main is more than enough in my opinion.
Interestingly enough, trunk based development is what all the big teams have arrived at also. It’s the only thing that works.
If trunk based development doesn’t work for you, it’s because you’re missing feature flags or can’t use them for a specific project. And it always leads to pain.
Yeah I'm a huge fan of trunk based development. It's my preferred operating method for git.
I know a lot of people like git flow for its ability to create seperate envs that can be controlled and tested, however it always felt extremely unnecessary to me when building saas products. Changes should not be long lived in this space.
I can understand how git flow would be great when the product is an artifact like a docker image, binary, vm image etc... but for managed applications / saas stuff, it's not the best.
I think yours is the sensible path. Rebase can make sense for some specific cases, such as a local branch being organized to present a clearer motivation for an implementation. Rebase of a shared or externally-visible branch should never be done, and rebase as a default behavior is just a recipe for merge conflicts.
My preferred default would be to only ever merge, with an explicit merge commit at all points. (i.e. Never rebase, never use a fast-forward merge.) The main branch is then a sequence of merge commits, visible with "git log --first-parent". This is the same cleaned-up history that rebase proponents espouse, but doesn't lie about the true history the way a rebase-by-default workflow does
When I am working mostly alone I never rebase or merge. I have code in various directories on my laptop or ephemeral ranches, or more likely stashes if I have more than one thing in flight. When working with others, I will pull a branch while I work on something especially once I am ready for reviews or comments. If main progresses substantially while I work on it, I will rebase and then close and reopen any pending PRs. Especially the first time I start working on a repo, when I want a low key low pressure approach. Once they take some of my work and seem ok with me in general, I will switch to more frequent branchless PRs.
"I've only ever used a hammer so other tools should not exist."
Supporting remote-use CVS for a distributed multi-team development group was pure hell, and regularly had me going to lunch while waiting for simple command to finish. I'm glad git's features exist.
Instead of hijacking this post to start a flame war, why not promote mercurial without hijacking a post by drawing a parallel to mercurial's implementation of the same thing described in the article, highlighting commonalities and distinctions in the approaches?
I probably should not have mentioned mercurial. I do not really know it anymore, but it is somewhat more UX focused than git. I think my original argument stands, especially considering the comments - too many ways to use Git, while most people need only basics.
