Git branching model problems

Question

I'm implementing the successful git merging model by Vincent (http://nvie.com/posts/a-successful-git-branching-model/). So I've a main repository "main" on our gitorious server with 2 main branches: master and develop. Every developer of my team than should fork this into a personal repository and create locally a clone of this personal one. They should work on their personal and then create a pull/merge request.

Scenario: I need to develop a new cool feature.

1. I've origin pointing to my personal fork.
2. I add "main" as additional remote.
3. I exec "git fetch -p main" and that should fetch all the changes from main and sync my local.
4. I create a new branch from develop "git checkout -b feature/cool_feature develop".
5. Add, Commit ...
6. Question 1.
7. Question 2
8. I open a merge request
9. The integration manager than approved and merge into main/develop
10. Question 3

These are my questions:

1. During my work into the feature i should fetch the "main"? if yes i should merge into my feature branch or into my local develop branch?
2. After I finish my feature I should merge it with my local develop branch and push to origin (personal repository) or I leave it apart and push only the branch (creating a remote branch)?
3. If a branch was pushed into my personal repository i should delete it now?

Hope that is clear, Tnx in advance.

Answer 1

Step 3 only updates your remote references. It does not sync to your local branches. So in step 4, where you run git checkout -b feature/cool_feature develop, your actually creating the branch off of your out-of-date local branch, unless you're doing something else to bring it up to date.

Question 1

As usual, it depends. Merging from the main line can introduce "useless commits" (as Linus called them), and can clutter the history. Rebasing is often a better choice here, especially if the branch is really your private branch. If that branch has to be shared with others for them to build on, then you get into some interesting and dangerous territory with rebase, and merging becomes a better solution.

To be more specific, if during the cycle of your development new changes are introduced upstream, I'd rebase and incorporate them into my branch at my leisure. I may wait until my feature is fully implemented, if it doesn't take that long to implement, or I may do it right away especially if a change has been made near the area that I'm working.

Question 2

If you use rebase, then main is already incorporated. If you don't rebase, I tend to avoid the extra merge unless I think it's going to cause a problem, and there are tests that run and the final integrated results.

You would push it to the branch, not merge into develop.

Question 3

After the branch has been merged into the main repository, then you are free to delete the branch.

Other observations

Take heed to @michas advice. Depending on your situation, NVIE's model may not work well for you.

Also, you may not have thought of this, but how are you going to keep develop up-to-date locally? Which branch does it track: origin/develop or main/develop? I ask to bring to light a couple of issues. First, you'll need to keep your local develop branch up-to-date somehow. If it's tracking origin/develop then you'll need to do something like git merge --ff-only main/develop to git the new commits onto your branch. Alternatively, you can make your local develop branch track main instead: git branch --set-upstream develop main/develop. This means that your personal repo in gitorious will have an out-of-date develop branch, but it doesn't cause any harm.

FWIW, because of the fact that local branches are not updated with git fetch, and git pull may introduce useless commits, I've been using a script called git-ffwd to keep my branches up-to-date. It does the fetch, and the updates the local tracking branches as long as the branches don't diverge.

Finally, some of the issues surrounding remotes and keeping things up-to-date if you follow @michas advice and only work off of a central repository. That's what we implemented at my workplace, and it has worked out well.

Answer 2

First be a bit careful with that "successfull git branching model". - It might perfectly fit to your project or it might be totaly wrong. - It always depends on the situation.

Is there any reason, why you need a separate repository for each developer? - Each developer has to clone the main repository to work on the files, hence each developer already has a personal repository as a working copy.

Why not just have one single central repository and a branch for each feature? If you need to you can restrict who is able to push on which branch.