I want to add chromedriver file in my repo using git LFS. The steps I followed are:

1. Install git LFS using this command:

   sudo apt get install git-lfs

2. Initialize our repository with git-lfs using following command:

   git lfs install

3. Track the files we want to add using this command:

   git lfs track chromedriver

4. git add chromedriver

   It is giving this error: The following paths are ignored by one of your .gitignore files: savedrivers hint: Use -f if you really want to add them. hint: Turn this message off by running hint: "git config advice.addIgnoredFile false" How to fix it?

Secondly, what is the purpose of command git add .gitattributes?

Other questions:

1. After the file is pushed in our repo, in which folder can we see the file and how can we access it inside our code?
2. Will the size of our repo be affected after adding file with GitLFS? As the purpose of Git LFS is to store file in our repo without affecting its size.
3. When the branch containing git lfs code gets merged to master branch, does everyone have to pull it locally?
4. In Github LFS, instead of pushing the files in our repository, we push them in a different server, and then can only reference from inside the repository. How can we access it in our code?

CodePudding user response：

It appears that your chromedriver file is in the savedrivers folder, which is marked as ignored in one of your .gitignore files. Either use the -f to force adding it, or remove savedrivers from .gitignore.

For the .gitattributes file, see this question and others on SO.

Other answers:

1. Using git lfs is transparent for the end user. From your point of view, it is just like any file. Internally, git uses some smart mechanism, but generally users need not concern themselves with how exactly it is done, they can just treat it as any file.

Also, git is generally smart enough to detect binary files, so if you add a bunch of files e.g. with git add *, in most cases it will automatically detect binary files (there are of course exceptions but in my experience this is very rare).

2. The size of the overall repo will increase in the sense that if you clone it, you will get a large .git folder locally. You should find these files in the .git/lfs/objects folder. On servers such as GitHub, Bitbucket, GitLab, the objects are stored using special LFS-storage.

3. There is no difference between binary files and text files from the end users' point of view. Binary / LFS files that are introduced in a commit get pulled like any other file. If someone commits a DLL, it will show up in the others' working folder when they check out a branch containing it.

4. GitHub's internal workings and storage of files should be transparent. Users should push binary LFS-tracked files like any other file. When someone pulls a branch with references to binary files, those binary files will show up there in their working folder. The thing to pay special attention to is that EVERYONE from the team has properly configured GIT LFS on their system / repo, or else they might end up pulling only the references and not the actual binary files, or pushing binary files to the "proper repo" instead of the LFS area.