Does creating a Git branch copy ALL of the source code?

user_8560955 0
Viewed 1046

So e.g. you are working @ Google in the YouTube team and you want to modify how the search bar looks like, or just want to change the font size, or work on a major project like the recommender system etc., does making a Git branch copy over ALL of the backend code for YouTube on your machine? So if there are 100 engineers working from their laptops in the YouTube team, are there 100 copies of YouTube code on their tiny laptops in circulation? Because as I understand Git, when you branch off, you create a copy of the source code, which you merge back into the production branch, which merges into the master branch.

Please correct me if I am wrong as I have only worked on MUCH smaller projects which use Git (~100 files, ~15k lines of code).

Your support will be much appreciated.

Thanks.

github python git
1 Answers

Creating a branch in Git copies nothing.

OK, this is a bit of an overstatement. It copies one hash ID. That is, suppose you have an existing repository with N branches. When you create a new branch, Git writes one new file holding a short (currently 40-byte long, eventually to be 64-byte long) hash ID. So if your previous disk usage was 50 megabytes, your new disk usage is ... 50 megabytes.

On the other hand, cloning a repository copies everything. If the repository over on Server S is 50 megabytes, and you clone it to Laptop L, the repository on Laptop L is also 50 megabytes.1 There are ways to reduce the size of the clone (by omitting some commits), but they should be used with care. In any case, these days 50 megabytes is pretty small anyway. :-)

There's a plan in the works for Git to perform a sort of mostly-delayed cloning, where an initial clone copies some of the commits and replaces all the rest with a sort of IOU. This is not ready for production yet, though.

The way to understand all of this is that Git does not care about files, nor about branches. Git cares about commits. Commits contain files, so you get files when you get commits, and commits are identified by incomprehensible hash IDs, so we have branch names with which to find the hash IDs. But it's the commits that matter. Creating a new branch name just stores one existing commit hash ID into the new branch name. The cost of this is tiny.

1This isn't quite guaranteed, due to the way objects stored in Git repositories get "packed". Git will run git gc, the Garbage Collector, now and then to collect and throw out rubbish and shrink the repository size, and depending on how much rubbish there is in any given repository, you might see different sizes.

There have been various bugs in which Git didn't run git gc --auto often enough (in particular, up through 2.17 git commit neglected to start an auto-gc afterward) or in which the auto-gc would never finish cleaning up (due to left-over failure log from an earlier gc, fixed in 2.12.2 and 2.13.0). In these cases a clone might wind up much smaller than the original repository.

user_12564520
Related