2

I'm the technical manager of a team of student-programmers applying SCRUM and using Git.

We use the following branching model: http://nvie.com/posts/a-successful-git-branching-model/

While I'm only working half of the week the students program whenever it suites best to their schedule/personal needs (also on weekends or sometimes late in the evening).

Now we have different requirements that (as I see it) don't go too well together:

On one hand as the one who has the technical responsibility I would like to review the code before it gets into the development branch and be able to inspect the code in regards to existence of unit tests, adherence to coding style and maintainability in general.

On the other hand I want my team to merge very often so that no merge conflicts arise (or at least stay as little as possible.

  • Is this a common problem - for which others have already found a proven solution?
  • Do I have a very special problem here? Do you have an idea how to solve it?
  • Do I go into a wrong direction by thinking so - are my premises somehow false?
  • Why do you want to prevent code from being checked in to the development branch if it doesn't conform to some rule? Why not simply create an issue / ticket if you encounter such a case? – Daniel Hilgarth Oct 07 '13 at 11:08

1 Answers1

2

That is where you can take advantage of the distributed nature of Git:

You can have them merge in the dev branch of a dedicated "QA" repo, which in turn will push to the final centralized repo if the commit is approved.

Ideally, that QA repo is a gerrit one, which is meant to facilitate that review process.

But the general idea, with DVCS, is: you don't have just merge workflow (merging from a branch to a branch), you also have a publication workflow (pushing from a repo to an upstream repo).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250