1

Let's assume that I am working on a small project that uses feature branches to organize tasks. For example, feature/login would be for working on the login functionality and feature/create-new-post would be for adding functionality to allow users to create new posts. When a feature branch comes to a relatively stable stopping place, it gets merged into development which is an up-to-date-ish version of the codebase.

Now let's say I find a typo in a comment in some file. This file is quite generic and doesn't really fit into one particular feature branch. If I am working away in feature/login when I discover this, what branch should I commit this fix to? I feel that it would be wrong to commit to feature/login because the typo is completely unrelated to login functionality. It also feels wrong just to commit directly to my development branch because that isn't usually the process.

Note - this is (pretty much) a hypothetical, I'm wondering what the cleanest solution in general would be.

  • 5
    I suspect there's no right answer to this. My gut feeling is that I'd commit it straight to development. But someone else may well offer a compelling argument for a different approach, so I reserve the right to totally change my mind. – David Arno Jun 28 at 8:54
  • 3
    I'd say straight to development or along a feature branch, as long as it's a very minor change. Especially if you adhere to the boy scout rule you'll accept that minor changes are allowed if they improve the codebase. – Kayaman Jun 28 at 9:13
3

I've seen a number of different approaches:

Submit with feature

Although it doesn't belong in the feature code per se, it is simply added to the feature branch as long as the risk is low.

Submit on separate branch

For larger or more riskier changes, it may be prudent to have a separate branch.

Submit on child branch

Admittedly quite rare, but a change might be triaged and the change made on a child branch with a view to merging this into a later feature branch.


For trivial changes, it can be tempting simply to merge this into development but it is worth at least discussing this with peers first to set the ground rules. I've seen many a trivial change break builds and the fall out is usually more painful than simply putting it into a branch.

  • Good answer, thanks for discussing multiple different avenues to take – Llew Vallis Jun 28 at 9:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.