Team-based Git Workflow

Question

I've recently setup a Gitolite Ubuntu server, along with repositories and users (within groups). Everything is going swimmingly for things actually working.

In my Git research, I've found a specific Git Model that works in the way we want it to. We were in dire need for a way to apply hotfixes to our current source without screwing the current development version. This model from "nvie" attends to all of our needs.

The problem is that it doesn't really explain remote hosting using this model. And we can't figure out a few things.

Currently we're thinking that every time we add a new feature-* branch which is finished, we'll push it to a remote branch under the same name. But this means that one of us will then at a later date have to have to manually pull them and ensure there are no conflicts.

How can we use the "nvie" model but in a team based workflow?

Edit to be more clear:

None of the team understand how, say, two people can be developing their own features. The first person finishes their feature and merges into develop. What does the second person do? Stash their changes and pull down develop into their branch, then apply their stash or what?

We're unsure how we can be pushing into develop at the same time etc, without overwriting each others newer changes.

Answer 1

This is a huge topic of contention. Branch-per-feature is made possible by modern tooling like Git. Before, it was frowned upon as the level of granularity was not possible - or it was too difficult to do.

I would explore adding a branch that you can reset based upon potentially not getting QA approval - UAC after integrating. This has worked well for me and others. Here is a very detailed account of it and a good discussion after. I hope it helps:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Answer 2

Quote from topic

The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).

Feature branches typically exist in developer repos only, not in origin.

must make all crystal clean. Later code show the same style

Finished features may be merged into the develop branch definitely add them to the upcoming release:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

Note pushed branch, develop, not feature-branch. You just make as much merge|push, as it needed

Answer 3

This quick tutorial on atlassian website will be a great start.

https://www.atlassian.com/git/workflows