6

I'm new to Git and trying to move my website away from SVN to GIT for version control and also deployment.

I've got a number of developers who will work on their local machine and I've got 3 servers, 'development', 'staging' and 'production'.

I've been reading books and watching videos of how Git works so I think I'm pretty familiar with it now as in adding, committing etc, however I need advice on the workflow and deployment.

The first thing I need to know is where to initialize the GIT repository. Does it need to be on the 'production' server and then I clone it on 'staging' and 'development' and each developer also clones it to their local machine?

Secondly, should each server have it's own branch? I.e 'development' will have a 'development' branch, 'staging' will have a 'staging' branch and 'production' will have a 'production' branch?

Thanks

Derek Carlisle
  • 485
  • 10
  • 27

4 Answers4

8

I recently moved my team from SVN to Git too and we have the same setup of 3 servers, prod, stg and dev..

For the migration process, first sudo apt-get install git-svn and then..

$ git svn clone [subversion_repository_url] /path/to/git/repository
$ cd /path/to/git/repository
$ git remote add origin [gir_repo_url]
$ git push origin master

For Workflow,

This link titled "A successful Git branching model" was immensely useful. It entails how to go about using a 'Production - Staging - Dev' type of workflow for a team.

With regards to Deployment:

On each of the servers, what we do is, Each of the servers have the git repo someplace on the filesystem. To deploy, I archive the respective branch I need to deploy and unzip it into the /srv/www/ folder..

For example, on Prod, to deploy the master branch,

sudo git archive --format zip --output output.zip master -0

^The 'master' indicates the branch you want zipped up. This excludes the .git folder. And then to unzip inside the /srv/www/ folder, sudo unzip output.zip -d /srv/www/app/ This is the equivalent of an svn export command.

For the Staging server we usually checkout one of the Release branches or the Dev branches..

And for the Dev server, we checkout whichever feature-branch we need to perform testing on.

Community
  • 1
  • 1
keithxm23
  • 1,280
  • 1
  • 21
  • 41
  • I agree with everything except git-flow as a branching model - it is highly recommended without taking into account individual user or team workflows. It is often way too overcomplicated - would suggest starting with the Github branching model and making adjustments based on your workflow. – Nic Oct 31 '12 at 15:07
  • Do I have to migrate SVN in this way? I was hoping to simply remove SVN completely and start from fresh. Also, so you would have feature, release and a master branche? Does dev and staging have its own branch too? – Derek Carlisle Oct 31 '12 at 15:11
  • If you do it this way, you also migrate all your SVN-commits so that way you could also revert back to any point in your SVN history which is immensely useful methinks. – keithxm23 Oct 31 '12 at 15:28
  • @Nic [The workflow I suggested above](http://nvie.com/posts/a-successful-git-branching-model/) is THE most popular Git workflow on the internet and I'm sure there are thousands of dev-teams who could attest to it's effectiveness AND simplicity. – keithxm23 Oct 31 '12 at 15:32
  • Thanks keithxm23. So do your developers work on their local machine and then you have external development, staging and production servers ? – Derek Carlisle Oct 31 '12 at 15:38
  • Yes. We have 1 Git-repo that is hosted on Unfuddle which hosts all our branches (Master, Dev and feature-branches). All of our devs clone this repo and regularly push and pull to it to stay updated. When ready to deploy, we ssh to our server and pull/clone(only for the first time) the repo and then perform the zip-unzip steps I mentioned above. – keithxm23 Oct 31 '12 at 15:43
  • @keithxm23 sorry to nitpick, but the Github model is actually the most popular on the internet if we'd like to be pedantic about it :) All I'm saying is that git-flow isn't everything for everyone, and git is extremely flexible for everyone's environment. – Nic Oct 31 '12 at 15:44
  • @Nic Actually I apologize for being ignorant. I went through your presentation and did a little bit of looking up on the internet and I agree that you are right. The model you suggest is most appropriate for larger teams too. My team is a team of 6 devs and it works great for us. – keithxm23 Oct 31 '12 at 15:45
  • @keithxm23 thanks again. Can you please explain why your Git-repo is hosted on Unfuddle and not on your production server? Do I need another server to host my Git-repo? – Derek Carlisle Oct 31 '12 at 15:46
  • Unfuddle (like GitHub) and other Repo-hosting services offer additional goodies like issue-tracking, commit-graphs, release planning etc. – keithxm23 Oct 31 '12 at 16:00
  • OK but this isn't essential is it? I'm planning on FTP'ing my web files and creating my repo on my production server and cloning this to staging, development and mine and other developers local machines. Am I right in thinking I then need to import the web files to each cloned repository and add these them to git? Then I can simply start making branches? (Sorry for all the questions, I appreciate your help very much) – Derek Carlisle Oct 31 '12 at 16:04
  • I've never tried git with an Ftp-hosted repo before. I looked it up and found this related SO question: http://stackoverflow.com/questions/4664251/does-git-or-does-git-not-support-push-to-an-ftp-server – keithxm23 Oct 31 '12 at 16:13
  • Sorry, I simply meant FTP'ing the web files to the server before initializing GIT. Am I right in thinking the files must be there to start with so you can add them to Git? (N.B My production server is new and doesn't yet contain any files as my current, live site is hosted on a different server) – Derek Carlisle Oct 31 '12 at 16:17
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/18868/discussion-between-derek-carlisle-and-keithxm23) – Derek Carlisle Oct 31 '12 at 16:19
  • Your usual workflow would be something like.. Make changes to git repo locally. Push changes to git repo on server. (Which in your case is the ftp-server). And then to deploy.. On your server, Pull your repo from the ftp-server at some location (say ~/webapp/) And then perform the zip-unzip steps I mentioned above.. – keithxm23 Oct 31 '12 at 16:19
2

You've got 3 questions here: how to deploy, how to structure branches, and how to structure/host repositories.

How do I structure branches?

You could start simple. You've already got an SVN repository, so if you've got a trunk and branches, you could set those up the same way in git. If that doesn't work for you, change it only when you find the need.

If you want something more advanced, look at git flow. Another good workflow is the one that github uses. It's designed to be simpler than git flow.

How do I host the repository?

One easy way would be to do just as you're doing with SVN. Have a central repository on a central server. Everybody pushes and pulls to and from that central server. Another option would be to give some sort of lead developer the "official" repository, where that lead would pull other changes from the contributing developers as they meet the lead's approval. There are a number of ways you could do this. You'd just have to decide what works best for you.

How do I deploy?

Again, this doesn't need to change from your SVN workflow either. You're probably doing an svn update from each box. I'd just do a git pull to each box and keep everything else much the same.

Dan
  • 3,665
  • 1
  • 31
  • 39
  • I want to completely move away from SVN. The site is being moved to a new server which will have a completely different structure to the current site. To initialise Git can I do this on my local machine and then clone this on the 3 servers or does it have to be initialized on the server so that I can SSH to clone it? – Derek Carlisle Oct 31 '12 at 15:05
  • 1
    @DerekCarlisle use something like gitolite to manage permissions and be your "central" host for repos. Get your servers communicating with it and have all of your pushes and pulls going through that. Check out my presentation from last week: http://nicbertino.com/?p=141 – Nic Oct 31 '12 at 15:10
  • I would say it's easiest to SSH to your central repo server, and initialize the repository there, then clone it to everywhere else. But after that original clone, you can do everything else with push/pull. So clone to local, import the code, commit, then push that back to central. – Dan Oct 31 '12 at 15:11
  • Thanks Nic, I'll have a look at your presentation now. – Derek Carlisle Oct 31 '12 at 15:12
  • I agree with Nic here. Something like gitolite is helpful for managing multiple users off that central server. Of course you could also think about using a service, like bitbucket.org, or github (most offer private hosting). – Dan Oct 31 '12 at 15:12
  • @Nic [That was a lovely presentation!](http://nicbertino.com/wp-content/uploads/2012/10/Modern-Version-Control.pdf) Well constructed! :) Is there a link to the audio/video of the deck being presented? – keithxm23 Oct 31 '12 at 15:38
  • @keithxm23 thank you! Unfortunately, it wasn't recorded. I'll make an update with more context and edits soon. – Nic Oct 31 '12 at 15:57
1

A lot of it does depend on what ends up being right for you.

The branching model linked in another answer here is a very good starting point.

Generally, you'll have a master branch which represents the released code.

Staging depends on what you want to stage - our team has a separate branch called staging which is used by the continuous integration server's staging build. Different features can be merged into this branch to test them on staging.

Deployment will depend on whether you use CI or deploy directly from a branch in the repo.

Community
  • 1
  • 1
bcmcfc
  • 25,966
  • 29
  • 109
  • 181
  • I simply want each developer to be able to work locally, have a branch for each 'feature' that they can push to the 'development' server which is hosted externally, the 'development' server can then be checked and pushed to 'staging' for testing and then if all is good this can be pushed to 'production' which will be the live site. – Derek Carlisle Oct 31 '12 at 15:07
0

I've developed my own strategy. It was originally based off of nvie's:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

It allows ad hoc mix and match of completed features. The cornerstone of this strategy is to start each feature from the same place in history per iteration.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141