-4

As far as I understand in trunk-based development there are no long lived feature branches, one could even argue that there are no branches because at the end everything will be merged back to trunk very quickly and the only valid version is trunk, thus one can't use previous branches as a reference point.

Usually while working with feature branching one can follow a lengthy feature over time since one can know the first commit of the feature and the last, and use this info to know for example how long did it take to complete by substracting commit dates or view all the changes associated to the feature.

Does it make sense to do this in trunk-based development, and also if one wanted to do it, how could it be done?

1

Traceability is useful, but note that feature branches too cease to provide any traceability once they are merged: Git branches are just transient pointers rather than persistently recorded attributes of a commit. Therefore, we need some other traceability mechanism even in a feature-branch system.

(Non-Git version control systems might be a bit better in this regard but are practically irrelevant nowadays.)

One common solution is to put a ticket number into the commit message. The version control history can then be searched for that ticket to find all related commits. You can use version control system hooks to enforce or encourage the presence of a ticket number.

Features have a problem regardless of how they are managed in the version control system: long running features are difficult. This difficulty may concentrate in difficulty of merging or difficulty of tracking, but it is always there. This difficulty can be reduced by keeping features as small as possible. As an extra benefit small features are easier to estimate.

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.