1

I would like to set up a version control system in which developers can push/commit they changes to one repository. Our testing department can pull those changes and test them. After those changes have been approved by the testing department, they would be committed to a second repository, ready for release.

I know we could use branches for this, but there are a lots of micro-changes and creating a branch for each of them seems like an overhead to me.

So in short, I need a system where each commit acts like a branch and can be individually merged to a master repository.

Note: Git's index does not count, since it exists only locally and can not be accessed by the testing department.

Bojan Hrnkas
  • 1,587
  • 16
  • 22

1 Answers1

2

With a distributed repo like Git, you don't need branches, you need multiple repos, one acting as a gatekeeper from the other.

Whenever you push to the gatekeeper repo, that repo triggers through a post-receive hook the tests.
If those tests pass, it pushed to the final repo which acts as the blessed referential for all developers to pull from.

This does not test "by commit", but for each set of commits pushed.

I mentioned that before when the final repo was actually an svn one.
I also mentioned it for tests or for private builds.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I also use the same style for the development in my organisation. all the changes are done on another repo called "development" which is actually driver from the master and once all the commits in ''development' are verified then its moved to master. – Adeel Jun 30 '16 at 06:24