14

Having the full Git revision history has a lot of benefits as part of the development process.

But our product is the source code, we are using scripted languages that don't need compilation or processing, and then the Git history becomes a burden on deployment- in our example we deploy a clean virtual environment following every change, having several deployments on a single machine.

There are some ways to reduce the amount of history, for example shallow clones whose efficiency depends on how deep the revision is in the branch, doing a fetch instead of clone but then you still get history from the revision and back, or getting the full repo once then pull when needed but this is wasteful in terms of disk space and tends to be less reliable.

Is there a way to get a single revision from Git without it's history ?

030
  • 13,235
  • 16
  • 74
  • 173
Rsf
  • 340
  • 1
  • 9

3 Answers3

16

Shallow clone

You can indeed get a shallow clone out of Git using:

git clone --depth=1 <url>

This will still clone the repo and create a .git folder with the objects, only smaller in size (difference depending on your total file size vs. history size).

Git archive

You can also use git-archive to extract an archive of the repo:

Creates an archive of the specified format containing the tree structure for the named tree, and writes it out to the standard output. If is specified it is prepended to the filenames in the archive.

In the examples it shows for instance:

git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz

Create a compressed tarball for release.

Hosted Git, archive API

If you are hosting your repo on GitHub, then you can use their archive API:

https://api.github.com/repos/<username>/<repository>/zipball/<commit_hash>

Bitbucket.org has a same functionality for this:

https://bitbucket.org/<username>/<repository>/get/<branch_name|commit_hash|tag>.zip

7ochem
  • 974
  • 10
  • 22
11

Don't deploy your git repo. Develop a real deployment methodology. Even if it's as simple as tarring up an archive (= building an artifact with just the necessary files in it to be deployed) of deployed scripts.

Even if you shallow-clone the tip of your source repository, you likely don't need unit tests, documentation, linting profiles, and other supporting ephemera in your deployed environment.

Note: for repositories of scripted languages that don't really have a "build" step, a trivial way to release an artifact would be to package them in an archive, such as tar or rpm. Then, to "deploy", you untar the archive or install the rpm. this removes the need for git tooling in your deploy chain (not all prod servers will have those dev tools).

Pierre.Vriens
  • 7,205
  • 14
  • 37
  • 84
RubyTuesdayDONO
  • 211
  • 1
  • 3
  • it's okay to question (or even challenge!) an answer -- that's what makes Stack Exchange great :)

    for repositories of scripted languages that don't really have a "build" step, a trivial way to release an artifact would be to package them in an archive, such as tar or rpm. then, to "deploy", you untar the archive or install the rpm. this removes the need for git tooling in your deploy chain (not all prod servers will have those dev tools)

     – RubyTuesdayDONO Mar 07 '17 at 19:30
  • 1
    @Pierre.Vriens yes, you're missing what's is suggested as tarring an archive, I.e building an artifact with just the necessary files in it to be deployed. That said I agree that's not a quality answer and this point should be extended. We are in private beta and answers should née explicit – Tensibai Mar 07 '17 at 19:32
  • Then I don't see what this brings more than the accepted answer, if it's to point toward fit archive... it's just redundant, you should edit to extend on this way iMHo – Tensibai Mar 07 '17 at 19:34
  • 1
    Please check my edit of your answer (just integrated your interesting comment). Feel free to improve/rework of course, or just rollback if you don't like my edit at all. BTW: your comment (= note I added) made me think like "really, that simple? Again a sample of how we Get Things Done in zOS ... with z for zero downtime ...". I think it's time to start to question way more questions/answers via similar comments ... Don't challenge me too much ... – Pierre.Vriens Mar 07 '17 at 19:38
  • i don't purport that this is a complete or model answer, but i didn't see anyone else addressing the elephant in the room: if you use git to "deploy" your project, you're "gonna have a bad time" ;) – RubyTuesdayDONO Mar 07 '17 at 19:40
  • just saw your edit to put my comment in the answer, yes, thank you for that :) – RubyTuesdayDONO Mar 07 '17 at 19:41
  • @RubyTuesdayDONO using git to deploy is perfectly fitting the goal in some situation, static angular js front ends are a good example of app absolutely ok to deploy with a git pull in my experience – Tensibai Mar 07 '17 at 20:10
  • you don't mind if users see unit tests & other meta/planning docs? and you don't mind resolving merge failures when deploying? and you always want everything in the repo included in the delivered product, accepting unforeseen interactions w/ experimental features? yes, for simplistic/hobbyist cases, it's adequate to deploy your source repo -- but we shouldn't promote it as best practice. by the time you're trying to optimize away little things like storage overhead of the git object database (which is pretty good at deduplication), you might want to look at more explicit release methodologies. – RubyTuesdayDONO Mar 07 '17 at 20:22
  • Actually there is a reason to why we son't use achieved artifacts. Our product is part of a bigger build system, where each build might use a different revision of the product. That means we need to keep (or generate on the fly) an archive for each Git revision. Git archive solves most of that, with the exception of having unnecessary files. – Rsf Mar 08 '17 at 08:03
  • @RubyTuesdayDONO I've been unclear sorry, we have 2 apps like this, we deploy branches per environment, chef run every 30 mins on the machines and a simple merge into a branch allow a deploy within 30 mins. Preventing access to unit tests/non relevant files is done by the webserver configuration. I agree this is a simplistic case, and adding a level of overhead with a build/package/store wouldn't bring really much for those simple cases. That doesn't mean promoting it for everything, but I think it shouldn't be frowned upon on all cases neither. – Tensibai Mar 10 '17 at 10:13
6

Question is there a way to get a single revision from Git without it's history ?

To get a repository, no there's no way, mainly because there's no 'revision'. Git store commits, which are changes from previous state.
If you want your repository at a specific point in time you have to pull the commit at this time and all it's ancestors or you'll get only the changes made in the commit.

To avoid confusion: Shallow cloning is getting the needed history and then truncating it to free space, the tree is still made from history.

For the solutions, @7ochem answer does cover them.

Tensibai
  • 11,366
  • 2
  • 35
  • 62