git - Best practice: Workflow: When to merge in a inhomogeneous team -


i'm technical manager of team of student-programmers applying scrum , using git.

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

while i'm working half of week students program whenever suites best schedule/personal needs (also on weekends or late in evening).

now have different requirements (as see it) don't go together:

on 1 hand 1 has technical responsibility review code before gets development branch , able inspect code in regards existence of unit tests, adherence coding style , maintainability in general.

on other hand want team merge no merge conflicts arise (or @ least stay little possible.

  • is common problem - others have found proven solution?
  • do have special problem here? have idea how solve it?
  • do go wrong direction thinking - premises somehow false?

that can take advantage of distributed nature of git:

you can have them merge in dev branch of dedicated "qa" repo, in turn push final centralized repo if commit approved.

ideally, qa repo gerrit one, meant facilitate review process.

but general idea, dvcs, is: don't have merge workflow (merging branch branch), have publication workflow (pushing repo upstream repo).


Comments

Popular posts from this blog

java.util.scanner - How to read and add only numbers to array from a text file -

rewrite - Trouble with Wordpress multiple custom querystrings -