Git forkflow

[Vanuan]

I've written some workflow instructions: https://github.com/gugod/redmine-gollum/wiki/Git-workflow

Do you have any thoughts on this?

[gugod]

On 2011/4/7, at 下午7:02, Vanuan wrote:

I've written some workflow instructions: https://github.com/gugod/redmine-gollum/wiki/Git-workflow
Do you have any thoughts on this?

Has this model be working to your team ?

I personally consider it very redundant to maintain an "unstable" branch that is meant to be always divert with
other branches. Topic branches are considered to be less stable the the master / development branches already.
As for those long-developing-feature problem, I don't think that can be dealt by any kind of git workflow.
We should simply avoid that from happening.

Besides, the timing and tasks to merge to master is uncertain -- if topic branches can be merged into master,
when should it be done, and why should those changes based on development be merge to somewhere else ?

I think the development branch is the only branch to be used to synchronize changes from different topic branches,

[Vanuan]

Has this model be working to your team ?

My team doesn't use git. It is experiment workflow.

I personally consider it very redundant to maintain an "unstable" branch that is meant to be always divert with
other branches. Topic branches are considered to be less stable the the master / development branches already.

Ok. I'll delete unstable branch.

Besides, the timing and tasks to merge to master is uncertain -- if topic branches can be merged into master, when should it be done, and why should those changes based on development be merge to somewhere else ?

Topic branches shouldn't be merged to master. They should be rebased on and merged to development. The criteria of merging a topic branch to development should be discussed separately. It may be "all the tests are passed", "peer reviewed", "tested manually", etc.

I think the development branch is the only branch to be used to synchronize changes from different topic branches,

I agree.

[Vanuan]

I've added a picture to illustrate a proposed workflow:
https://github.com/gugod/redmine-gollum/wiki/Git-workflow

And deleted unstable branch

[Vanuan]

Maybe it is a bad idea to rebase development on master...

Here is an updated version of the diagram:
http://dl.dropbox.com/u/4217195/github/git-workflow-2.jpg

[gugod]

In general, doing a pull --rebase is better only when you have a small number of un-pushed commits waiting to be pushed. Since rebase is essentially mass re-commit, you do not want to rebase a long sequences of commits.

Also the master branch is expected to have changes by incorporating other branches, instead of direct commits. As a consequence, master branch has no local changes to be rebased on top of development in most of cases. IIRC this makes git to perform a fast-forward.

There is a very good best practical with fast-forward: when merging into the master branch, it must be a fast-forward. This does force a linear history on master branch, and yet other branches can be as parallel as necessary.

Honestly I think we've been spending too much time talking about git instead of doing real work and I see no ending about it. If you consider this git workflow an important experiment to you, I suggest you define your expected outcome in the wiki page and let us do it your way for, say, a month or so. We will evaluate to see if the expectation is met in the future.

[Vanuan]

In general, doing a pull --rebase is better only when you have a small number of un-pushed commits waiting to be pushed. Since rebase is essentially mass re-commit, you do not want to rebase a long sequences of commits.

I agree. But I think making your private topic branch in sync with development is better through pull --rebase than through many merge commits. That makes the topic branch clean and easy to track. And if you do pull rebase regularly there are smaller number of commits to be rebased. And the topic branch can me merged without conflicts at any time.

Also the master branch is expected to have changes by incorporating other branches, instead of direct commits. As a consequence, master branch has no local changes to be rebased on top of development in most of cases. IIRC this makes git to perform a fast-forward.

Yes. That is what I'm trying to achieve: linear history in master.

There is a very good best practical with fast-forward: when merging into the master branch, it must be a fast-forward. This does force a linear history on master branch, and yet other branches can be as parallel as necessary.

We can't force a linear history on master branch without rebasing develompent on master. There will always be merges from topic branches. So, we can at least make a merges from development more visible. So we can see them on the network graph.

Honestly I think we've been spending too much time talking about git instead of doing real work and I see no ending about it. If you consider this git workflow an important experiment to you, I suggest you define your expected outcome in the wiki page and let us do it your way for, say, a month or so. We will evaluate to see if the expectation is met in the future.

The outcome will be a clear and visible history. So we will be able to say which features and fixes went to the release X.Y.Z just looking at the network graph, without reading a changelog.
Another advantage is eliminating merge conflicts.

[Vanuan]

Thanks for cloning my development!

So general rules narrowed to following:

• make private quick fixes in development to be public immediately, because they are "quick"
• keep long changesets in topic branches, to avoid "breaking" development.
• rebase topic branches on development regularly to avoid merge conflicts.
• make pull --rebase development and merge topic branch to development with --no-ff option to make it clear which commits belong to specific feature.
• merge development to master with --no-ff to make release history more vivid.

[Vanuan]

The only thing I'm worried about is how to mark whether a specific version is a development of stable in init.rb: http://stackoverflow.com/questions/5600916/how-to-make-different-version-labels-between-two-branches-in-a-git-repository