Common Git mistakes

Do we really need to introduce Git!? It has become the essential version control tool for us developers. When I started as a developer, I used CVS... Arf, not all good memories unfortunately, the switch to Git was a very pleasant change 🙂

Even after several years of using Git, it is easy to make mistakes that can waste time or even lose code. Fortunately, most of these problems can be avoided by following a few good practices.

Working directly on main

One of the most common mistakes is developing directly on the main branch. In case of a bug or an unfinished feature, you risk making the project unstable.

Prefer creating a dedicated branch for each feature or bug fix. This also makes code reviews and rollbacks easier.

Accidentally committing sensitive information

This is one of the most serious mistakes: committing sensitive information such as API keys, passwords, or private files. Once this data has been pushed to a remote repository, especially a public one, it is important to act as quickly as possible.

If sensitive information has already been committed and pushed, you can use git filter-repo or BFG Repo-Cleaner to remove this data from Git history (otherwise, it may still be accessible). You should also immediately revoke and replace any exposed credentials, passwords, or API keys, even if the repository has been made private again.

The best solution is still to avoid this situation in the first place. To do this, add files containing sensitive information to .gitignore so that Git does not track them! And that's it, you avoid the incident 🙂
Note that .gitignore does not remove a file that is already tracked by Git. In that case, you first need to remove it from the index using git rm --cached.

You can also use environment variables or configuration management tools to store sensitive data instead of including it directly in your code.

Committing large or unnecessary files

This has already happened to me: committing large files such as log files, executables, or build artifacts, even though they do not belong in a Git repository.

If a large file has already been committed, you can remove it from the Git index without deleting it from your disk:

git rm --cached <file>

Then commit the change and push it to the remote repository. If the file is already present in multiple commits in the history, it may be necessary to rewrite the repository history to remove it completely.

To avoid this kind of problem, add file types such as .log or .exe to .gitignore to prevent Git from tracking them. Use Git LFS (Large File Storage) to manage large files that really need to be versioned.

Forgetting to make commits regularly

Waiting several days before making a commit makes it harder to track changes. A commit containing hundreds of modifications is much more difficult to review and fix.

Try to create small, consistent, and frequent commits. Each commit should correspond to a specific change.

Also, don't forget to push your changes to the Git server. One of the risks is losing the code you have written and potentially losing several days of work. And that's really frustrating...

Writing unclear commit messages

Messages like "Update", "Fix" or "Test" do not provide any useful information.

Prefer descriptive messages such as:

Fix login validation when password is empty

A few months or years later, you will be happy to immediately understand why a change was made.

Using git push --force without caution

A forced push can delete other developers' work if the branch is shared. I once had a colleague who did this... Not very nice...

When it is really necessary, prefer:

git push --force-with-lease

This command checks that nobody has modified the branch in the meantime.

Forgetting to review changes before a commit

Before each commit, take a few seconds to check what will actually be recorded.

The following commands are very useful:

git status
git diff

They help prevent adding sensitive files, forgotten test code, or unintended modifications.

Thinking Git is a backup solution

Git is a version control tool, but it does not replace a real backup strategy. If your repository is only stored on your computer and it fails, you risk losing your entire history.

Regularly push your changes to a remote platform such as GitHub, GitLab, or Bitbucket (which I no longer use since they reduced repository size limits with the free plan...) to keep a copy of your project.

Conclusion

Git is essential for developers. Moreover, with the arrival of generative AI, if we run into a problem, they can now generate the commands we need to unblock ourselves. No more spending hours struggling with a Git issue 🙂