1

New to git and looking for some ideas on how best to configure my repository(s). We currently dont use anything. I need to support 6ish versions of the same codebase (demo,dev,test,integration,QA,PROD). What I'd really like to accomplish is having the developers commit their changes to dev then be able to promote that commit up the chain. I'm trying to use multiple branches in the same repo at the moment. Not sure if forks would be a better route. Do I have to start with the same codebase (set of code,config,etc)? I've set up gerrit and phabricator but I can't find a way to apply the changes to additional branches after the commit has been approved in dev?

Kevin
  • 127
  • 2
  • 11

1 Answers1

1

Branches are good when you are making changes to the code base:

  • demo
  • dev
  • test
  • integration

That first main repo can be managed by gerrit, and you can push to a specific branch.

But branches are not the only solution for steps in the development lifecycle where only read-only operations take place:

  • QA
  • PROD

Those two steps, with a distributed version control system, can be managed in independent git repositories:

  • one for QA (user acceptance test, system wide tests, ...)
  • one on your production server.

Those repos aren't exactly "forks", but simple clones of your main codebase repo (the one that all developers are cloning to work in the branches demo, dev, test or integration).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Where can I set up the process? example: code gets checked into dev, reviewed in gerrit, approved , committed. This part I understand. Now when that commit gets committed into dev i'd like it to automatically get sent to the next level up the chain(test in your list) as a candidate commit ready for review (with a different set of reviewers). – Kevin Nov 06 '13 at 15:14
  • @Kevin that would be a post-commit hook, as in http://stackoverflow.com/a/7925891/6309, assuming test is another repo. – VonC Nov 06 '13 at 15:16
  • @Kevin you can be helped by a job scheduler too, as in this setup: http://twasink.net/2011/09/16/making-parallel-branches-meet-regularly-with-git-and-jenkins/ – VonC Nov 06 '13 at 15:18