"A successful Git branching model" should be fixed a bit

[KES777]

The master branch should be updated only from develop and vice versa. Without that fix we see info about release and hotfix differently from view of master or develop

You can see the release/v0.02_16 branch from develop side

But you do not see it from master side:

[cdvv7788]

If you merge back to develop before a release, doesn't that break the whole purpose of release branches? The purpose of the release branch is to take a snapshot of develop and use that as a base for the upcoming release.
There may be issues with the way branches are handled, but i don't think that merging from develop is the solution if that's the case.

[KES777]

It is merged back into develop in any case. Look at Summary of actions for actual version:

Summary of actions:
- Release branch 'release/v0.03' has been merged into 'master'
- The release was tagged 'v0.03'
- Release tag 'v0.03' has been back-merged into 'develop'
- Release branch 'release/v0.03' has been locally deleted
- You are now on branch 'develop'

The change I suggest is to merge into master when finish release not the last commit of release branch but the commit of release merge

[cdvv7788]

It is merged back to develop, but develop may contain new commits by then, so once release is merged back to develop it is not suitable for merging with master anymore.

[mahlon-gumbs]

Am I misunderstanding your statement here? Since release is merged back to both develop an master, develop is either:

• exactly the same as master, in which case there is no need to merge develop into master
• ahead of master because it contains new commits, in which case you could still merge develop to master because develop is ahead

In the second case, you’d still not want to merge develop directly to master because the new commits do not necessarily represent what should be in production (master branch). When those new commits are ready, you’d start a new release branch in order to prep them for release. When done, you’d be back at the step where you are merging the release branch to both master and develop again (and tagging, etc).

On Sep 15, 2016, at 9:58 AM, Cristian Vargas notifications@github.com wrote:

It is merged back to develop, but develop may contain new commits by then, so once release is merged back to develop it is not suitable for merging with master anymore.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #287 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ACMxKOZ4CLQWi2ZGe4Fti2nVTxxVEBNbks5qqU8bgaJpZM4J92-K.

[KES777]

hm... Is there a way to see commits on release branch from master side of view like we see hotfix?

[petervanderdoes]

@KES777 What's confusing you in the latest log?

[petervanderdoes]

As far as your drawn suggestions in the first post, like people have indicated your develop branch could be ahead of your release branch, so merging the develop branch into the master branch is not advisable.
Merging the hotfix tag into develop doesn;t sound crazy, maybe worth developing as it could mean you are missing tags "on" your develop branch. This is mostly important for git describe (nvie/gitflow#49)

[petervanderdoes]

Just checked, and the code actually backmerges the tag to develop for a hotfix finish

The image used in the documentation is from the original version. It needs updating I just don;t know how to :/

[maldag]

I don't get the purpose of the release branch if it's completely merged into develop again. Release should focus on:

• No new features from develop to roll out
• Test Release branch on test server
• Modify stuff needed for unique version (Edit version string to x.y)
  If master receives the release from develop first it'll incorporates new features originally not planned for that release.

[petervanderdoes]

@charles4711
You are correct when it comes to the first two points.
As to point three, the release branch is merged in master, master is then merged into develop.

[KES777]

Yes. As first arrow on my picture. With last two I was wrong.

[maldag]

I've startet drawing a new diagram in inkscape. I'll let you know, when it's done

[maldag]

Here's the corrected version. Please let me know, what you think.

git-flow.pdf

[KES777]

1. Is it possible to not hide arrow from 'tag 1.0' to 'develop?
2. For last commit in 'release brunch' add hint: "Change version of your product here". Because product is ready after all tests passed and all bugs fixed

[natros]

@charles4711 can't you use the original to make the changes preserving the graphics style?
http://github.com/downloads/nvie/gitflow/Git-branching-model-src.key.zip

[maldag]

@natros Thanks for providing the source code. Which program did you use to create it? I was working on an open source format svg. I think, the style is a bit different, but the content matters more to me.
EDIT:
I double checked that and it seems to me, that your file was made with keynote, which is a mac application. IMHO we should use an open source alternative which works well on different platforms like inkscape. If someone knows a better graphical style, that would be fine to me.

[natros]

@charles4711 I did not create the diagram. It's on the bottom of the page for download http://nvie.com/posts/a-successful-git-branching-model/

[mahlon-gumbs]

I think the style of the new diagram is close enough to the original to render any differences moot. While I'm a fan of Keynote, I agree that a cross-platform graphics tool (or at least a platform-independent format) is better here since it would allow more contributors to make changes.

Excellent work @charles4711 . I do agree with @KES777 that you should try and not hide the arrow showing the merge of Tag 1.0 from master to develop.

Also, if you haven't already, could you check in the image source so others can chip in?

[maldag]

I checked the source in and created a pull request for it in this repo. I changed my nickname from charles4711 to maldag, so don't be irritated :)

[maldag]

I changed the image according to your reviews and updated my pull request.

[KES777]

It is strange to see when two branches are merged into another in one commit.
Look at last purple circles

PS. Yes, it same as origin but it is not correct

[maldag]

You're correct with this, but as you noticed, it's the same in the original drawing. You could see the circles as individual commits or as a set of commits of the same kind. (aka "merge tag to develop" or "merge featrues to develop" or "create release branch from develop". It's probably a matter of perspective.
We should try to update some docs and use either one perspetive throughoutly.

[vukanac]

Any consideration to update "Feature for future release" branch with updated develop branch after v1.0?

[hackel]

I stumbled upon this trying to figure out what where a "bugfix branch" fit into the new flow, and how they differ from hotfix branches. I can't seem to find any documentation on it anywhere, but I gather they are like hotfixes for a release branch? In any case, it would be nice to see them incorporated into this new graphic.

[petervanderdoes]

@hackel Bugfix branches are nothing more than feature branches. People wanted to see a difference between if a branch was a feature or bugfix. So I added the bugfix branch.

[hackel]

Aha, thank you @petervanderdoes! So simple!

[3kynox]

Hello folks.

I would like to add something about the bugfix branch which seem to have more commands than the others, any particular reasons for that ?

Thanks

[jrial]

@3kynox How do you mean, more commands?

Hotfix, 5 commands:

(zenoss_palantir)[10:15] nighty@saltmine zenoss_palantir$ git flow hotfix help
usage: git flow hotfix [list]
   or: git flow hotfix start
   or: git flow hotfix finish
   or: git flow hotfix publish
   or: git flow hotfix delete

    Manage your hotfix branches.

    For more specific help type the command followed by --help

Release, 6 commands:

(zenoss_palantir)[10:15] nighty@saltmine zenoss_palantir$ git flow release help
usage: git flow release [list]
   or: git flow release start
   or: git flow release finish
   or: git flow release publish
   or: git flow release track
   or: git flow release delete

    Manage your release branches.

    For more specific help type the command followed by --help

Bugfix, 10 commands:

(zenoss_palantir)[10:15] nighty@saltmine zenoss_palantir$ git flow bugfix help
usage: git flow bugfix [list]
   or: git flow bugfix start
   or: git flow bugfix finish
   or: git flow bugfix publish
   or: git flow bugfix track
   or: git flow bugfix diff
   or: git flow bugfix rebase
   or: git flow bugfix checkout
   or: git flow bugfix pull
   or: git flow bugfix delete

    Manage your bugfix branches.

    For more specific help type the command followed by --help

Feature, 10 commands:

(zenoss_palantir)[10:16] nighty@saltmine zenoss_palantir$ git flow feature help
usage: git flow feature [list]
   or: git flow feature start
   or: git flow feature finish
   or: git flow feature publish
   or: git flow feature track
   or: git flow feature diff
   or: git flow feature rebase
   or: git flow feature checkout
   or: git flow feature pull
   or: git flow feature delete

    Manage your feature branches.

    For more specific help type the command followed by --help

[3kynox]

Hey,

You just pasted it, 10 commands for bugfix, like feature. hotfix branching got 6. If bugfix goal is the same as hotfix one but for the develop branch, if I understood correctly, why does we have more options to treat that new branch ?

I'm just trying to understand correctly the new bugfix branch and maybe to help update the git flow branching picture for peoples be aware of that changes.

[jrial]

@3kynox Oh, sorry, misread you there. Thought you were talking about hotfix. My bad.

You're right, there are a couple of commands that look like they could be common commands, which appear to be missing from hotfix/release. Or at least from the help documentation; haven't checked the code. My guess is they were simply forgotten rather than purposefully ommitted, but I'm sure @petervanderdoes can shed some light on this.