0

I've been researching Git quite a bit, and I get the basic concepts, except how it fits into the workflow of a small team.

As I understand it, I would want:

  1. one shared semi-public repo for myself and my team to work from (pulling changes into our local copies) and test features in.

  2. one repo where we push anything that's tested and ready to go live.

  3. a live repo where the working directory is the root folder of the actual website

Am I understanding this or complicating it more than it needs to be? Just trying to wrap my mind around it, and very few of the tutorials go into detail on this topic.

CharlesB
  • 86,532
  • 28
  • 194
  • 218
evanhuntley
  • 73
  • 10

3 Answers3

0

My dev team has only one remote repo where all changes are pushed.

Features in development are branched to avoid breaking the master copy, so there may be multiple active branches at the same time. Each developer has a "local" repo that's actually running on the dev server (we tend to do our development using VIM via SSH). Each of the "local" repos is set up as a unique virtual host that's tagged with the user's name. As a result, there may be three or four different versions of the site running on the dev server. This allows developers to test code changes instantly.

When preparing for a release, all finished branches are merged and the resulting code is pulled via git to a pre-deployment server which closely matches the production environment. After approval, the specific commit is tagged with a version number and either pulled using git or rsynched onto the production server where it goes through a few more tests to make sure the deployment went smoothly.

Mark Wetter
  • 68
  • 1
  • 6
0

There is many git workflow that you can apply but if you need a starting point I would recommend nvie blog post which explain a good centralized way to manage your changes in your application through branches.

You can read more about it on http://progit.org/book/ch3-4.html.

Also, it seems like somebody already asked about this: Git branch strategy for small dev team

Community
  • 1
  • 1
Vincent B.
  • 4,038
  • 1
  • 23
  • 18
0

Instead of using several repositories for development/release/... I would use branches in one repository.

More ideas about a possible model for that (and how it is used in a team) can be found in this blog post: http://nvie.com/posts/a-successful-git-branching-model/

(And don't be scared, the graph on the top looks complicated, but if you just read the article becomes very clear :) )

On an unrelated note: Git is very powerful and good for a lot of things but can also be quite complex to use (both exactly what you would expect for a version control system written by kernel hackers ;D).

For a decentralized VCS, Bazaar might be a good alternative. It shares the essential ideas with git. But I have heard repeatedly from a number of different people, that it tends to be a lot easier to handle for teams that don't have a computer science background and maybe use version control for the first time.

(Just in case that matches your criteria. I don't know your team and the range of people's background and experience is quite broad in web development. Don't want to start a VCS flamewar here either.)

zpea
  • 1,072
  • 6
  • 23