1

I'm transitioning our code base from svn to git.

Our current deployment process is to run an in house script that checks out the most recent svn revision into a newly created directory to create a working copy on the server. It then runs any sql commands that need to occur and changes a symlink from the curent working copy to the newly checked out working copy.

This is a simple way of handling updates and allows us to easily roll back the code base to the old one by changing the symlink if there is an issue.

Is it possible to fetch just a single specified branch from a git server into a newly created directory or do I need to clone the entire contents of the repository?

Or is there is a better method of handling the code base with git?

Aglystas
  • 379
  • 6
  • 19
  • git-export may do what you want - see http://stackoverflow.com/questions/160608/how-to-do-a-git-export-like-svn-export – Rory Hunter Sep 07 '12 at 14:25

3 Answers3

2

Each commit in the git is identified by "sha1" id. This id represents exact snapshot of files. So, instead of creating multiple working copies and symlinking them, you could just do git checkout of a particular commit. To rollback you just do checkout of the last known good commit id. Since checkout works very fast (in comparison to the SVN) and doesn't rely on a network repo (so it never fails), I recommend you to forget the symlinking nightmare.

To make more human friendly IDs you could utilize tags (essentially a human readable alias of a commit id).

kan
  • 28,279
  • 7
  • 71
  • 101
  • Other than preventing users access to the .git directory are there any security risks associated with running a websites code base directly from a git repository? – Aglystas Sep 07 '12 at 15:50
  • @Aglystas You should not share the root folder. Just change the layout. In the repo root create a folder `WebContent` and share it only, in this case you will not care about the `.git` folder. – kan Sep 07 '12 at 18:01
  • @Aglystas Hence this is also good advantage over the svn, because svn has `.svn` in each folder, so you should care about access control of the shared working copy. – kan Sep 07 '12 at 18:50
0

Git is a distributed repository. You need to clone the entire repository when doing a git clone, you cannot just just clone a branch nor a sha id. However, git is compressed quite well and you should not have problems with your strategy because of git.

We do this at my work and have been using this methodology for over 5 years now - it does not slow us down, we have a Continuous Delivery system that allows us to deploy to production many times in a day, and our deploys are about 3 minutes long - depending on database migrations.

Sorry that the answer is - you must clone the entire repository.

Michael
  • 10,124
  • 1
  • 34
  • 49
0

We have the following scheme:

  1. We use gitolite for access control to our networked repository, and have our build server use a special SSH key that only has read access to the repository.
  2. We have a full clone on our build machine, and periodically do a fetch from our build scripts.
  3. We use tag names to mark things that are to be built. We use 2012-09-01[a-z] as the pattern for these names, as they sort nicely. E.g. 2012-09-01 is followed by 2012-09-01a if you need more than one build per day...could also use a full timestamp.
  4. When the automated shell script sees the tags to change (last tag is the latest), is does a checkout/rebuild.

Symlinks are not needed, as checkout in git is super fast. You can also use

git -xfd clean

to make sure your source tree is sparkling clean in case your script leaves cruft around.

Your development team then need only make a tag and push it to get an updated build:

git tag 2012-09-01
git push

and of course tags can use nested names, so you can do things like:

git tag test/2012-09-01
git tag release/2012-09-01
...

to categorize the thing you are doing: testing fixes, working up to a release, etc.

Tony K.
  • 5,535
  • 23
  • 27