My company uses gitflow for several different projects (several different git repos) with teams of varying sizes, anywhere from 3 - 20 developers (so, yes, relatively small). Gitflow works well for us and, for the most part, I fail to see any significant differences between gitflow and the others mentioned here. I'm familiar with the "successful Git branching model" article but I prefer Atlassian Gitflow Workflow. In my opinion, it's simpler. Regarding the complaints about gitflow, either we've subconsciously tailored gitflow to meet our needs or two articles linked above are wrong about gitflow (or I am wrong about gitflow). Two key claims made in those articles are 100% inaccurate (there are probably more, I only skimmed): 1. "Another big difference from git-flow is that we push to named branches on the server constantly." -- yeah, we do that too with gitflow and, in fact, Atlassian's page says "Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration". 2. "The other gap that I’ve found with GitFlow is that it doesn’t provide support for old release versions." -- Huh? I don't think so (e.g. git checkout v1.2.3 where v1.2.3 is a tag for release 1.2.3 and you are currently on release 10.11.12) and then patch your code and release v1.2.3.1. Other complaints about gitflow are more about "problems" with dev-process or company-culture: 1. "Long-running branches" is a relative term. I agree "long-running branches" are a very bad thing but branches that last a week or two are fairly common on our smaller teams but I suspect larger teams might reasonably consider these to be "long-running branches". 2. We do code reviews (not just merge requests) so would rather not tolerate the overhead and interruption involved in some strange policy that "all team members commit to trunk at least once every 24 hours". 3. The projects I'm working will never scale to 25000 developers on a monorepo so a flow technique that scales to that level is not a selling point for me. Bottom line is that all of these flow techniques work and all of them can be customized to fit your needs. What's more important is that you choose *some* flow technique, then decide on the "official" documentation, and then point all current and future devs to that documentation.

I have this desk (with a custom-built desktop that could be molded perfectly to your belly): 2-Leg Height-Adjustable Desk Frame | Shop UPLIFT Desk[^] And two of these arms (for two 27" monitors): Single Monitor Arm | UPLIFT Desk[^] Uplift also has dual monitor arms (that apparently support two 27") but the two separate arms allow more flexibility. The monitors don't move/wiggle at all when I type. If you pound the keys, maybe the monitors wiggle a bit but it isn't noticeable. If you regularly pound your head on the desk, the monitors will wiggle quite a bit, however, your face will be on the desktop so monitor movement still won't be noticeable! Note in all of these "normal use" scenarios, the monitors don't actually move, they just wiggle. Rest assured, these arms are well made and include adjustable friction at every joint of the arm so you might be able to eliminate the head-bang-on-desk wiggle. The desk itself has been flawless. I've maybe had to reset it once after a long power outage but this doesn't happen with every power outage (where "reset" finds the desktop's fully lowered, zero, position). It's also fast -- fully raises or lowers in ~15 seconds.