Should I commit ...
In this article, we are going to talk about the most common files that raise doubts when you want to commit them to a git repository.
No! Some people could argue to include this file, however including this file could hurt other people who use VisualCode, for example, an absolute path where the repo is installed. It's very common to see
.vscode being ignored using the .gitignore.
Here is an example of how to ignore
.vscode/* !.vscode/settings.json !.vscode/tasks.json !.vscode/launch.json !.vscode/extensions.json *.code-workspace # Local History for Visual Studio Code .history/
Yes! You need to commit this file. Whiout this file other people working in the git repository will not be able to execute npm install.
Yes! This file needs to be committed to your git repository. This file was introduced by npm 5 and its goal is to avoid two different installs from the package.json. Check here for more information of npm 5.
Yes! This file is similar to package-lock.json and you should commit it to the repo. You should not commit both files! Since you can have two different tree lock file. It seems that yarn will move to package-lock.json. You can also import a package-lock.json to yarn.lock.
Yes! The (dot)gitignore is a file that allows you to ignore certain patterns of filenames to be included in the git repository. You can also opt not to commit. the most common case is to ignore .DS_Store or pyc files.
No! It's not a good recommendation to include the node_modules directory and its a common practice to include it in the .gitignore file. Why? You will include code from a third party in your repo and it will affect your git history. Also since the introduction of package-lock.json you will have information about your dependency tree. There are more problems that you could have when you commit the node_modules, for example, conflicts with library code.
Yes! The composer.lock file tracks information about dependencies and it allows another developer to reproduce the installation.
Yes! This file contains the checksum of the content of a specific module. This file will help other team members to verify that they are using the expected dependency.
Yes! The Podfile contains information to track dependencies, also the cocoapods documentation has the following text the Podfile and Podfile.lock should always be kept under version control..
Meabe! Its common to commit the Gemfile.lock to a project. The exception to the rule is when the project is Gem itself. For production environments, the lock file will guarantee the libraries being run.