I am sharing my personal experience through this article.
When working with Git, it's important to properly configure your user name and email to accurately reflect who made a particular change in the version control history. You can change this by setting Git configurations globally (using git config --global) or at the repository level (using git config without --global). While global configurations can be convenient, they can also lead to serious issues when working on a project with multiple developers or using a shared machine.
Use of git config command
Git config is a command in Git that allows you to configure various settings for a Git repository or globally on your machine. With the git config command, you can set options such as the user name and email, default text editor, default merge tool, and other settings.
There are 3 levels of git config; local, global and system
local: [Highly Recommended] Local configs are only available for the current project and stored in .git/config in the project's directory.
Create a project specific config, you have to execute this under the project's directory.
git config user.name "Parimal"
git config user.email "parimal@codeofrelevancy.com"
global: Global configs are available for all projects for the current user and stored in ~/.gitconfig.
Create a global config
git config --global user.name "Parimal"
git config --global user.email "parimal@codeofrelevancy.com"
system: System configs are available for all the users/projects and stored in /etc/gitconfig.
Create a system config
git config --system user.name "Parimal"
git config --system user.email "parimal@codeofrelevancy.com"
The Hidden Risks of Global Git Configurations and Loss of Business
Setting Git configurations globally can cause problems if you push to another client's repository using the wrong name by mistake. The global configuration settings are stored in your computer's global Git configuration file, which is usually located in the ~/.gitconfig file.
When you make changes to the global configuration file, these changes are applied to all Git repositories on your machine. If you push to a repository using the wrong name, the name will be recorded in the repository's history, and it can cause confusion and lead to errors in the future.
To avoid this issue, it is recommended to set the user name and email at the repository level using git config, without the --global option, so that the correct information is associated only with that particular repository.
When multiple developers use the same machine and the Git configuration is set globally, it can cause issues when they switch between their own repositories. This is because the user name and email that are set globally will be applied to all repositories on the machine, regardless of which user is making changes. This can result in commits being attributed to the wrong person.
That is a potential risk of using global Git configurations. Pushing commits with incorrect author information can lead to confusion and a loss of trust, loss of clients, especially in a private company or client-based setting.
In such scenarios, it's essential to maintain the integrity and accuracy of the version control history to ensure that everyone involved has a clear understanding of who made what changes. By using repository-level Git configurations, you can avoid pushing incorrect information and ensure that each repository has the correct information associated with it. This helps to maintain trust and transparency in the project and reduces the risk of losing clients or creating confusion among team members.
It may also be a good idea to have a clear Git policy in place for your team or company to help prevent these types of mistakes from happening.
πConclusion
It is recommended to always set your Git configurations at the repository level, rather than globally. This ensures that your personal information is associated only with your own repository and the version control history accurately reflects who made what changes. Avoiding global Git configurations helps preserve the integrity of the version control system and avoids confusion and mistakes in the history of your project.
πSupport
Please consider following and supporting us by subscribing to our channel. Your support is greatly appreciated and will help us continue creating content for you to enjoy. Thank you in advance for your support!
Top comments (7)
This article is wrong on several points. You say that global config is per-user (which it is), then proceed to say it causes problems if there are multiple users on the system. The only time that could be problematic is if everyone uses the same account, which is already a mistake if that's the case. Global configs are completely safe and usually the recommended method.
I never use local config, but if anything wouldn't that one cause problems with multiple users? I would assume that local overrides global. That would be problematic if multiple users shared the same directory on one system.
I have never heard of system config before and I wouldn't recommend using it. That could definitely cause problems on a multi-user system. System-wide account configs are a bad idea.
Realistically though, are there any useful scenarios where you will share git directories with people? It would cause all kinds of problems if people tried to work on it at the same time. I often use remote multi-user systems, but everyone has their own home folder where they make their own clones of the repos. Even if realistically only one will use it at a time, you don't want to mess with other people's work.
If you happen to have the need for multiple accounts, such as a work account and personal account you can use the
includeIfstatement.This allows you to have a specific git config that overrides your main config for all repos inside that directory. It's a one-time setup and you only need to remember to clone it into the right directory.
And as a final note, you probably won't push by accident either. Ssh keys are also stored per-user. And if you don't have an ssh key you have a password, which only you should know.
Thank you sir for bringing this to my attention. I appreciate your valuable feedback and insights on Git configs..
Yes, you are correct that the global Git config is per-user and is typically the recommended method. But the only situation where it may cause issues is when multiple users share the same account, which is not a recommended. I apologize for any confusion my article may have caused.
I would like to share my personal experience regarding this issue. 5 years ago, as a beginner in a private company, I had a similar experience. I was assigned to continue a project that was previously worked on by another developer, and both projects were on the same machine, under the same user account. I forgot to change the Git configs for the new project and ended up pushing changes with the wrong author information. Sad to say, this resulted in losing a client for the company..
I double checks the Git configs before pushing changes to avoid such incidents. That experience taught me the importance of using local Git configs instead of global ones. After that, I always use local configs, even on my personal laptop, as I work with multiple Git accounts. When using the
git commitcommand, the system prompts us to set the user name and email for the current project if they have not been set globally. That's what I want.Thanks again for your valuable comments and I hope my response clarifies any confusion..
Ok I see, that makes sense. That company already made the mistake of giving you his account, so it's not really your mistake.
Global level configs are user-specific.
It's the system config (
--system) that should be handled more carefully, as it applies to all users and all folders on a operating system.It's important to set global configs like the pull/prune strategy, default branch, merge tool, core editor, or helpful aliases.
There's no hidden risk. Always use
git logbefore pushing anything to a remote repo to ensure everything is set recorded correctly.Thank you sir. I appreciate your valuable feedback..
Nice Post. Thank you for noting this risks.
Thanks for reading..