Jeff King <peff@xxxxxxxx> writes:
> In a workflow that merges feature branches to master, you can generally
> recognize them by looking for merges along the first-parent chain of
> commits:
>
> git log --first-parent --merges master
>
> (Depending on your workflow, some feature branches may be fast-forwards
> with no merge commit, so this is just a sampling. Some workflows use
> "git merge --no-ff" to merge in feature branches, so this would see all
> of them).
> And then for each merge, you can get the set of commits that were merged
> in (it is the commits in the second parent that are not in the first).
> The bottom-most one is the "start" of the branch (or close to it; of
> course the author started writing code before they made a commit), and
> the "end" is the merge itself.
A few things to keep in mind are
* A feature branch may be merged to the master multiple times,
when the feature branch is properly managed.
E.g. It may have been once thought to be complete with 3 commits,
get merged to 'master', then a bug is discovered and gain its
fourth commits to fix the bug and merged to 'master' again,
resulting in a topology like this:
A---B---C-----------D (feature)
/ \ \
---o---o---o---1---o---o---2---o (master)
"git log --first-parent --merges master" will first find commit
'2' that merged the feature for the second time, bringing in
commit 'D', and then it will find commit '1' that merged the
feature previously, bringing in commit 'A', 'B' and 'C'.
* A feature branch that depends on other feature may have merges on
their own. You may start a feature X that depends on another
features Y and Z that are not yet in 'master', in addition to
depending on things in 'master' that have been added since Y and
Z forked from it. In such a case, your feature X may look like
this:
.-------------------1----------2--------x---x (feature X)
/ / /
y---y---y (feature Y) / /
/ / /
---o---o---o---o---o---o---o---0 (master) /
\ /
z---z (feature Z) /
\ /
.----------------------.
where '1' and '2' are merges of feature Y and then Z into the tip
of 'master' when you start working on feature X.
And then feature Y and feature Z may graduate to 'master' before
your feature X is ready to do so, resulting in something like:
.-------------------1----------2--------x---x (feature X)
/ / /
y---y---y (feature Y) ---- / ------- / --.
/ / / \
---o---o---o---o---o---o---o---o---o---o---o---o---Y---Z (master)
\ / /
z---z (feature Z) ---------- / ----------.
\ /
.----------------------.
where 'Y' and 'Z' are merges of features Y and Z to 'master'.
After that, feature X may become ready to be merged, resulting in:
.-------------------1----------2--------x---x (feature X)
/ / / \
y---y---y (feature Y) ---- / ------- / --. \
/ / / \ \
---o---o---o---o---o---o---o---o---o---o---o---o---Y---Z---o---X (master)
\ / /
z---z (feature Z) ---------- / ----------.
\ /
.----------------------.
When "git log --first-parent --merges master" finds X, it would
notice that it pulled in commits '1', '2' and two 'x'. The "tool"
to inspect the history needs to be careful deciding if '1' and '2'
are the part of feature X. There are variants that make it tricky
(e.g. 'Y' may not have yet been merged to 'master' when 'X' is
merged, in which case you may end up pulling both 'x' and 'y' into
'master' with a single merge), which should be avoided if feature
branches are managed carefully, but not everybody is careful when
managing their history.
Coming back to the introduction of the original message:
>> I assume that feature branches are not frequently enough merged into
>> master. Because of that we discover bugs later than we could with a more
>> continuous code integration. I don't want to discuss here whether feature
>> branches are good or bad.
For our own history and workflow, the duration between the inception
of a topic branch and the time it gets merged to 'master' is not all
that interesting. More interesting numbers are:
* The duration between the time a topic hits 'next' and the time it
gets merged to 'master'. This is the time the developers and
testers are using the new feature in their own work to make sure
it does not have any ill effect.
* The percetage of topics that is merged to 'master' with some
follow-up changes since it hits 'next'. This is an approximate
for the number of bugs that are caught by developers and testers
before a new feature goes to the general public.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html