To Vendor or Not to Vendor: Should the `vendor/` Folder Be Ignored in `.gitignore`?

Handling Go Vendor Folder in .gitignore

Issue

Whether or not to add the vendor/ folder, generated by the go dep command, to .gitignore has been a topic of debate. Currently, the folder is ignored, resulting in dep ensure being invoked during every deployment.

Discussion

The decision of whether to ignore vendor/ depends on specific project requirements and development needs.

Reasons to Ignore vendor/:

• github/gitignore's Go.gitignore template does not include vendor/.
• Versioning the vendor's content locks in dependencies, potentially undesirable in the face of library updates.
• Vendoring tools may evolve over time (e.g., from dep to vgo to modules), potentially invalidating tracked dependencies.

Reasons to Not Ignore vendor/:

• Modifying dependencies in version control can be useful for tracking changes and resolving conflicts.
• gitignore.io/api/go recommends ignoring vendor/.
• If team members have different local environments, the vendor folder can ensure consistency in dependency versions.

Recommended Approaches

If not in specific scenarios:

• Consider ignoring vendor/ as per github/gitignore's template.

If there are specific needs:

• Use virtualization or containers to standardize development environments, minimizing the need for local dependency management.
• Employ a hybrid approach by keeping vendor/ outside version control but providing scripts for local generation.
• Consider using a private repository to manage vendored dependencies, ensuring consistent usage across developers.
• Explore the use of Go Modules, which offer precise dependency versioning and potentially eliminate the need for vendoring.

The above is the detailed content of To Vendor or Not to Vendor: Should the `vendor/` Folder Be Ignored in `.gitignore`?. For more information, please follow other related articles on the PHP Chinese website!