3

I am very new to version control and I would like some help if possible.

I was wondering, which is the best way of controlling 3 development environments: Development > Testing > Production

  • Development(Localhost environment) - all the work developed is being done here before any upload
    • Every1 working on the specific project should have a clone of this folder (each collaborator with its user, if possible) and every push by user will be sent here, to development folder.
  • Testing - Should be a clone folder that contains data pushed by Development and which is automatically synced with the subdomain testing using ftp, or whatever protocol.
  • Production is the live site, where the stable updates are released.
    • Should it be a clone of Testing, or testing upon push should upload the data here?

How about conflict problems when a user pushes a file/s different from what other user pushed 1 minute ago? Of course there can be the task separation and each to do certain things but what if not, what if X commits submit.php and Y also commits submit.php 1 minute before?

What version control software will be most suited?

Stewbob
  • 16,759
  • 9
  • 63
  • 107
Alex
  • 7,538
  • 23
  • 84
  • 152

2 Answers2

3

If you translate that in term of a DVCS (Distributed Version Control System), like Git, each of your "folders" can be an actual clone of your code repository.

That means that you:

  • would push from your local development to 'development' repo
  • would push from 'development' to 'testing' (or better yet, have a task on 'testing' in charge of pulling 'development' and trigger some tests if any new commit is detected
  • would push from 'testing' (if tests are ok) to production

Plus you wouldn't accept non fast-forward update to remote repo, which means any conflict would be first solved locally, before being pushed.

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

Git is awesome if you have a large team, but IMHO Subversion (SVN) is easier to learn and still provides a good set of core features that will handle your requirements. A common approach to handling the needs you mention above is to create a subversion repository with three folders called 'trunk', 'branches' and 'tags'.

  • Development: Happens in the 'trunk' subdirectory.
  • Pre-release testing: Happens in an intelligently named subdirectory of 'branches' e.g. 'RC1-test'
  • Stable-release maintenance: Happens in a version-tagged subdirectory of 'tags', e.g. '2.0'

Basically, all these subdirectories are forks off of your trunk which you can create via the SVN export command.

Josh Kuhn
  • 176
  • 5