Branching models for use with version control tools (git and git-flow)

This post is a high-level overview of the subject, with a little discussion.

A version control (or source code control) tool helps you manage versions or branches of software (or whatever: code, text, images, ….)  For example, git is a version control tool.

But on a project (whether with one developer or a team), you also need ‘business processes’ for using the version control tool.  These business processes help you and the rest of the team cooperate effectively.  Such a ‘business process’ comprises:

  • a branching model
  • a set of standard procedures for using the version control tool (how members behave)
  • a product roadmap or feature list that drives development

A branching model describes the branch artifacts that the project will use, and guidelines for creating and merging branches.  Examples:

Comparison of the examples

The git-flow branching model only has two long-lived branches:

  • ‘master’
  • ‘develop’.

The Qt branching model as three long-lived branches:

  • ‘dev’ (alpha)
  • ‘stable’ (beta)
  • ‘release’ (corresponds to git-flow master)

The traditional terms are alpha, beta, and release:

  •  Alpha: so buggy that usually only developers will want to work with it.
  • Beta: nearing release, feature frozen, and usable by early-adopters, but probably still having some bugs, and not supported to customers.
  • Release: published, and supported to customers.

The branching models both have other temporary branches, for releases and bug fixes (although they are not shown in the Qt diagram.)

The Qt branching model is a little fuzzy about how bug fixes are put back in development: it says they are ‘periodically’ moved back to development, i.e. from most frozen to least frozen.  The git-flow branching model shows that a bug fix always goes to both long-lived branches (master and develop.)

Both branching models also have mostly unstated (implicit) rules for the merging.  Rules about quality, size, frequency, etc.

Qt discusses that their project only supports the latest release.  You can infer the same from the git-flow diagram, since there are no long-lived, other branches from ‘master’.  In other words, to support an ancient release version that had diverged sufficiently from the current release so that a fix could not be made without conflict, you might need to create other branches from ‘master.’  (This might be a so-called ‘support’ branch, which is alluded to, but not fully described, in the git-flow documentation.)

The Qt branching model doesn’t seem to have a tool, instead you must know and remember the processes.  The git-flow branching model has a tool:

git-flow the tool

git-flow is yet another tool.  It extends git.  It enforces it’s branching model.  It is ‘high-level’, on top of git.

Another, ‘only a long-lived master’ branching model

Some of the criticism of git-flow seems to say that only one long-lived branch (master) is really needed.

Anecdotally, large projects (such as Qt) seem to use many long-lived branches.

While it may be true that only one long-lived branch is necessary, it may also be true that a tool such as git-flow, which hides some of the details of the git commands needed to enact the business processes, may be helpful.  In other words, I don’t care how many long-lived branches a tool or business process uses, as long as there is not a ‘model clash’ with my mental model.   I want to think less about version control, and more about the application.


Replacing Honda CRX/Civic/Acura rear trailing arm bushings: lessons learned

There are plenty of posts on car forums, including here.  This post gives additional tips.

First: its a lot of work; its not as easy as some suggest.  It took me many hours.  If you remove the rear trailing arm (RTA), you must dissassemble drum brakes, disconnect the brake lines and the parking brakes lines.  And you might need a hydraulic press.  My point is, allow plenty of time.

Second: it might not be necessary.  As bad as my bushings looked (noticeable cracks in the rubber pillars), after I removed them, I found they were were NOT totally ripped, top and bottom.  A lot more twisty than the replacements.  I am no expert in suspension geometry, but it seems to me that the other bushings in this suspension design keep the wheel mostly in alignment.  The symptom that I was trying to fix was: alligatoring of my tires on the inside, which might result from the wheels being toed out when driving (even though properly aligned statically.)  This bushing MIGHT be what is keeping the wheel from pulling backward under friction from the road, which should be a very small force.  If so, the stock bushing doesn’t seem to be designed for that, since the rubber pillars are mostly in compression from the weight of the car, and the rubber pillars would be in shear from any front and back force.  Maybe the different design of solid, urethane bushings would help in this regard.  The rest of the suspension keeps the wheel traveling more or less in a plane, up and down.  Only the rubber bushings, in shear and twist, keep the wheel from moving forward and back and twisting out of toe alignment.  This bushing is probably the main bushing for that.  Even so, the forces are not great.  If the bushings are not totally ripped, it might be easier to just buy tires more often.

Yes, you can knock them in and out with a big hammer.  But I found that the original bushing is tapered toward the inside (so that they knock out easy toward the outside) but the replacements were not tapered.  I found that the RTA hole is like a funnel towards the inside, so that the bushings are easier to press in towards the inside (as others advise.)  But I found that the replacements were hard to get started with just a hammer: I ended up filing a slight taper on the inner quarter inch (which is not a mating surface).  And I still needed a press to get them started, although I finished using a hammer.

Also, the original had the same pillars top and bottom, while the replacement had one fatter pillar, which I put down.  (The weight of the car compresses it.)

Also, you don’t need to mark the original alignment of the bushing: there are little circles stamped on the RTA front and back of the bushing: align the flat lug of the bushings with those.  Again, the long lug goes towards the inside and the fat pillar down.  So there are three things to get right when you start the bushing.

Note my 89-91 stock service manual doesn’t cover this repair (why, since they discuss replacing all the other bushings?)

Yes, you push the bushing in to the same place as the original: 7/16 inch showing on the inside, the outside just flush with the outside, rounded plane of the RTA.   When I failed to get it right, once I put it back on the car I found it took a lot of force with a broomstick to adjust the compensator arm.  So I am going to drop the front of the RTA and try moving the bushing with a hammer (same as if I were replacing the bushing without removing the RTA from the car.)  I want the bushing to be under neutral toe-in forces, so the compensator arm is not pre-tensioning the bushing.

To remove the parking brake line on drum brakes:  first unscrew the rearmost bolt clipping the line to the RTA.  Then take the brake shoes off and free the lug end of the brake cable.  Then take a 12 mm box end wrench and thread it over the end of the cable, compressing a spider that holds the cable into the backing plate.  The circle of the wrench squeezes the cylindrical spider.   Then pull the compressed spider and cable out of the hole in the backing plate and out of the wrench.

Finally, the bushing I took out seems to have been installed asymmetrically (twisted).   Probably didn’t matter, but maybe that little twisting force put a tiny camber in the wheel and helped to rip the top pillar.