0

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.

John Szakmeister
  • 44,691
  • 9
  • 89
  • 79
th3n3rd
  • 375
  • 1
  • 3
  • 20
  • How many versions of your software do you have to support simultaneously? (like a production one, a official testing one, and a future one,...) How many people are supposed to work on that repository? Are they all from the same company, or from different contractors or something like that? Is that "integration manager" an idea of you or some kind of management requirement? – michas Jun 01 '13 at 08:36
  • @michas atm we are just a team of 8 developers of the same company (in future maybe something will be outsurced) and as i explaned to jszakmeister since gitorious doen't give us branch permissions i can't have just one central repo. – th3n3rd Jun 01 '13 at 09:43
  • much related: http://stackoverflow.com/questions/2850369/why-does-git-use-fast-forward-merging-by-default/2850413#2850413 – cregox Dec 02 '13 at 16:11

2 Answers2

1

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.

michas
  • 25,361
  • 15
  • 76
  • 121
  • Good advice @michas. I'm actually not a fan of the NVIE solution because it doesn't work well with supporting multiple versions. And using the central repository is often much easier--and just as sane--approach. – John Szakmeister Jun 01 '13 at 09:09
  • @michas the integrator manager is just the reposnsible to integrate changes into main as in the integrator model workflow (http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow) – th3n3rd Jun 01 '13 at 09:19
  • @michas i googled around for branch permissions, but i didn found anything, especially regarding gitorious. Can you please explain me how push to branches can be restricted? – th3n3rd Jun 01 '13 at 09:55
  • You are free on your workflow. If you want the integrator manager pattern use it, but it doesn't seem to fit well in your situation. – michas Jun 01 '13 at 10:06
  • gitorious seems not to support branch permissions. - Why not setting up something like gitolite or gerrit instead? - Many different possibities for many different situations. - You have to find the most suitable one depending on your situation. – michas Jun 01 '13 at 10:08
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.

John Szakmeister
  • 44,691
  • 9
  • 89
  • 79
  • Well the additional layer of "personal fork" is due to a missing feature, that is gitorious doesn't give us branch permission, just repository, and beside that gitorious just give "request merge" only if you have a fork of the main repository. So the personal repository created is there to give a pubblic repository where to put the developer work to integrate. So the integration manager can pull from that and review, eventually merge it into the main develop branch. As you said, the problem is mantain in sync the personal repository in sync or just use it only to push branches. What you think? – th3n3rd Jun 01 '13 at 09:29
  • I think it's a fine way to work. It's certainly doable, and I work that way on many projects where I don't have commit access. It's just a bit of extra work staying in sync and maintaining my private repo. The only real downside is it's harder for new users to keep track of the actual flow. But that improves with experience. – John Szakmeister Jun 01 '13 at 09:55
  • if, as you said, set my local 'develop' branch to track 'main/develop' then my local will be updated, but the 'origin/develop' will not. But i want to have a build server monitor 'origin/develop' of developers. If i want that I think my local 'develop' should track 'origin/develop', then fetch 'main/develop' and merge/rebase, then open the branch and after my work i should merge my 'feature/cool_feature' on my local 'develop' and push it to 'origin/develop', is that clean? in these way i should have all in sync? – th3n3rd Jun 01 '13 at 10:19