top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

performance impact of branch in GIT

+1 vote
272 views

I have heard conflicting statements about the impact of branching in git. Let's say we have 100 feature branches that are all stored in a remote repo, would that affect performance (CPU/network) in a noticeable way ? How about 1000? 100,000 branches? In other words how does git scale with regards to number of branches?

posted Aug 15, 2013 by Garima Jain

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

Remember that git branches are not copies of the files, they are simply pointers to commits. So thinking about the two extremes that this allows, you could have 100,000 pointers (branches) all referring to the same commit. Or you could have 100k branches each referring to a different commit. Thus a repository of 100k commits.
Branch lookup and commit checkout times are bound by filesystem and disk performance. Checkouts might slow down in a repository with a lot of files/commits. But the branch objects themselves are very lightweight.

answer Aug 16, 2013 by Satish Mishra
Similar Questions
+2 votes

I would like to know what are the best practices when creating a new branch. For example. If I get a request to do update website title from XYZ to ABC; then should I create a branch named; "Update Title"? Or I should prefix this as suggested here (http://stackoverflow.com/questions/273695/git-branch-naming-best-practices). Are there any official prefixes?

Also I am concerned about the following; Let us say I create the branch named "Update Title". Finish the change. Merge back with Master. I then get another request to change title from ABC to DEF. Can I create another branch "Update Title". Will not this be confusing?

+5 votes

basically, I've got clones of some expensive-to-build projects (node.js), and I have changes that I want to rebase/cherry-pick onto dev and stable branches.

I know I can push to a remote, then pull into my other, and keep the two on different branches so the builds don't get out of date. But, I think I'd like it if they all just shared the same objects, branches, etc...

Could I symlink together my .git{branches,config,hoks,logs,objects,packed-refs,refs} directories? Is this just going to kill me later?

+2 votes

How do I switch to a hash on a branch without creating moving to a new branch? Say I'm currently at the HEAD of master, and its hash is aaa. I want to stay on master, only switch to a previous hash... (say eee...)

I know I can use the HEAD~ or whatever, but I'd like to find out how to do it based only on a hash...

+1 vote

At some point I added a large file into a git repository. It now exists on multiple branches, possibly with some changes to it. I'd like to remove it from git, but leave its current form (say the one on the master branch) on the file system.

I tried (on a dummy git archive)

git filter-branch --index-filter 'git rm --cached --ignore-unmatch bigfile' master branch1 branch2

That, however, does not leave a copy of bigfile on the file system.It isn't clear to me why not, though the description of the --tree-filteroption to filter-branch (I'm using the --index-filter option, but is is "similar") states:" (new files are auto-added, disappeared files are auto-removed ... )".
Is there a direct way to do what I want, with git? I've found similar requests;none of the responses point out that the above command actually deletes the file from the file system.

0 votes

$ git push origin :ABRANCHNAME
remote: Firing Pre - receive hook
remote:
remote:
remote: Firing Post receive hook
remote:
remote: Branch is ABRANCHNAME -- not creating Trigger file since this is not _int branch
remote: error: Trying to write ref refs/tags/ABRANCHNAME!SN-BL-20130605_100513_04363 with nonexistent object 0000000000000000000000000000000000000000
remote: fatal: refs/tags/ABRANCHNAME!SN-BL-20130605_100513_04363: cannot update the ref
To ssh://git@ourgitserver/repositoryname.git
- [deleted] ABRANCHNAME

I would not expect this behavior. Is git attempting to modify the tags associated to the HEAD commit on the branch in addition to the branch? If so, I would like to consider this a bug report...

...