Hi all,

I found that there's a bit of confusion when you document the merging of a topic branch inside master, there is no description on what type of merging is used (fast-forward or --no-ff).

By looking to the visual image it seems that's a --no-ff (hope it is) merge but it's never clearly mentioned in the description.

Thank you guys

For my own project I wrote a script witch can automate the creation of a pu branch.

First it merges all mature feature/topic branches which are already in next into pu.
When this task is done, an empty ### Match 'next' commit helps to identify is state.
Then all branches which are not in master and not in next are merged into pu

Branches which are labeled with wip/ will not be automatically merged into pu.

The script is licensed under GPLv3 and if you like it can be integrated into your project.

Link to script to rebuild next based on topics currently in next
Link to script to rebuild pu based on topics currently in pu

I remember you mentioning this in your tute, but you didn't explain why.

Ok, I have the four branches and I have created a topic and all went well. Then I went thru pu and then next processes. Did the same to other nine topics and eventually had 10 of them.

Now we want to cut a release after CI passes on next. If I got it right you said master and next never merge nor does pu and next nor pu and master. It means I have to merge those topic branches one by one into master, so why not just merge next into master seeing that is the state of the project we want to release?

This is similar in concept to GitFlow’s release branch, but far more flexible and powerful, since master has no dependencies on next whatsoever, nor is next ever merged wholesale into master (unlike the corresponding GitFlow branches develop and release).

The keyphrase here is:

nor is next ever merged wholesale into master

What's wrong with that since they all have a common ancestor?
Will something bad happen when we reset next and pu to master?
Is there a caveat in git checkout master && git merge --no-ff next && git checkout next && git reset --hard master approach, when the state of next branch is what we want to release?

Add some simple scripts that can do things like described here:

#5

In some cases, a branch may be merged into an integration branch as part of another topic. Generally, one should explicitly merge in dependent branches first, but in some cases this does not happen.

If so, sometimes it is useful to document the merge of that branch in the first-parent log. However, git will refuse to merge the branch because it will report "Already up to date".

We should document the use of empty commits on the topic branch, that will allow git to merge the topic into an integration branch, despite it already being there via another topic.

Git 2.18 has an option for interactive rebase called --rebase-merges, which will eventually replace the clunky --preserve-merges. This capability can be used to rebase a topic with merges interactively, and can therefore be very useful for topic-based development with gitworkflow.

See https://git-scm.com/docs/git-rebase#_rebasing_merges

Add information to the docs about how this option can be used e.g.:

• Redoing merges of other topics (for example, if that other topic was itself rebased)
• Splitting topic branches up into separate topics
• Adding additional merge commits to the topic without rebuilding it with reset, merge, and cherry-pick

Ref: http://trunkbaseddevelopment.com/short-lived-feature-branches/

And GitHubFlow - https://guides.github.com/introduction/flow/ :)

Git 2.19 has a cool feature called range-diff which can be used to diff two commit ranges e.g. two versions of a branch. This is really useful for git-workflow.

See https://www.git-scm.com/docs/git-range-diff.

Hi! Big fan of this workflow, thanks for all the write up around it. It has been working great for us with our CI/CD.

One question about merging topics into other topics when they depend on each other.
Your recommendation is to:

create your topic and merge the other topic into it. This explicitly records the dependency relationship between the topics, and puts the commit resolutions (if any) on the right branch.

But

if topic B depends on another topic A that has not yet graduated to master, topic A may be merged into topic B. This complicates interactive branch rebases so this should be avoided when possible, however if necessary, git should handle this situation without too much problem.

Interactive rebasing to clean up commit history etc is an obvious pain point here, that would be nice to avoid.

But my main concern is this use case:
If Topic B depends on Topic A and both are in development, I merge Topic A into Topic B and do some work. But Topic A is still being developed and I need to pull in the newest features again into Topic B, a second merge commit in this case would complicate rebasing and history even more. What would be your thoughts in this case?

Instead of merging topic dependencies, wouldn't it be better to keep them rebased during development? And maybe only merge the dependency when it graduates by first getting rid of the depending commits:
git rebase --onto master topic-a topic-b
and then merge topic a into topic b to record the dependency?

While this is a solution, it's not the cleanest one imho, as it relies on best effort from everyone to rebase and merge correctly when necessary.

I'd love to hear any ideas for a better approach :)

A post about stacked diffs:

• https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/

This is a very interesting approach that works quite well, and with a slight tweak (stacked branches vs stacked diffs), is not mutually exlusive with gitworkflow.

Stacked branches essentially takes all the pain out of managing topic branch dependencies -- in gitworkflow these are handled via recording topic dependencies i.e. topic B depends on topic A, by merging A into B, and then continuing to work on B. In stacked branches, B is simply "stacked" on top of A, and the tooling manages the stack i.e. if A changes, B is automatically rebased.

Stacked diffs / branches is more about developing code and doing code reviews and managing a developer's stack of work, while gitworkflow is more about CI and deploying code, so I believe these tools and techniques are complementary.

I've been playing around with https://graphite.dev/ and its really very nice. See this introductory video: https://www.youtube.com/watch?v=cE59cfwWL7M.

https://github.com/tummychow/git-absorb could be a useful tool if it works well. Experiment with it, describe it, and link it.

I'm looking at implementing this, and comparing man gitworkflows with what is here.
I noticed that gitworkflows says:

https://git-scm.com/docs/gitworkflows#_maintenance_branch_management_after_a_feature_release

Recipe: Update maint to new release

    git checkout maint

    git merge --ff-only master

But https://github.com/rocketraman/gitworkflow/blob/c3cb27618e5fcd41dc96508c403b35de50a296cc/docs/task-oriented-primer.adoc#create-a-release create a release suggests instead:

$ git checkout maint
(maint) $ git reset --hard v2.7.0
(maint) $ git push --set-upstream origin +maint

Why the difference?

What's the best way of doing this and having the fix in the topic branch?

The https://github.com/mhagger/git-when-merged tool is useful for gitworkflow.

Describe it here, and link to it.