Git is a tool with a lot of flexibility. You will feel more confident in your ability to manage things once you have mastered Git Commands. At the same time, if you are unsure about specific usages or mismanaging them, you may end up losing changes, making yourself & the team frustrated. Here are eleven things we should cease doing or avoid doing.
1. Do not Commit Directly to the Master, Release, Dev Branches
Yes, directly committing to the master branch and other key branches (such as release, dev) is not recommended. A master branch in Git is required to contain the most stable version of your source code and other project artifacts. Most likely, you’ll start with the master branch or a release branch to create your final product. Directly committing and pushing to these branches increases the chance of corrupting changes, introducing bugs, and requiring hours of additional effort.
In many circumstances, you won’t be able to commit directly to master. The branch protection restrictions would have been set by the administrator of your source code repository. If you have the ability to do so, please do not do so unless you are certain of what you are doing.
As a result, it’s preferable to build a feature/fix branch before using Change => Stage => Commit It is preferable to push to it rather than master/main/release.
💡 Even if you’re alone in the repo, role acting is a good way to rehearse.
2. Do Not Commit the Application Secrets (.env/.env*files)
You may have a few details that you want to keep confidential while working on a project (including side hustles). API Keys, Secret Keys, Database Secrets, Auth Secrets, and many other things could be involved. Making these publicly available could put your app in danger of being hacked. At the same time, if someone misuses it, it may burn a hole in your pocket.
Any unintentional pushes to the remote repository should not be used to commit your project secrets.
💡 Create a .gitignore file at the root of the project folder, and include file patterns to exclude from staging (such as .env*).
3. Do Not Treat Git as File Storage. Stay Away From Storing Large Files
Do you want to keep movies on your computer? Is there a lengthy demo video? It’s not the place to do it on Git. These use-cases are better served by other media services. Large files and binaries should not be stored in Git repositories. It’s called a source code repository, after all!
You can technically store anything in a Git repository as long as it does not annoy or cost someone. Money isn’t always the most important factor. It’s also about the passage of time. Someone cloning a repository because we have a few terabytes of video in it would be a huge waste of time.
💡 To limit and keep it under control, you can use GitHub, BitBucket, and other similar services to set the kind and size.
4. Do Not Work ON Multiple Issues in the Single Branch
It’s common to work on numerous features/fixes/issues at the same time. However, do not tackle several issues in a single branch (even if you are quite certain!). When you (or your lead) decide to remove one or more issues from the planned remedies, it might be a nightmare. Now you must choose and remove the undesirable fixes and code modifications. Who wants to put in any further effort? So, let’s stay away from that.
- problem => 1 branch => 1 PR and repeat is a better approach to follow.
5. Do Not Force Push
Here’s a scenario:
- Your friend and you both work in the same branch.
- She committed her edits and pushed them to the remote.
- You’re finished with your changes as well, but you’ve forced a push to the remote branch.
- All of your friend’s changes have vanished in the blink of an eye!
Don’t use force until it’s really necessary. It’s possible that your coworkers will go nuts as a result of this.
💡 Always pull before the push.
6. Do Not Modify or Delete the Commit History
When you commit a modification to a branch, git records and saves the commit history. Assume you’re wondering why commit messages are significant since they become part of the history of the project. You can figure out why certain changes were made to a file and who made them.
We will lose the ability to troubleshoot and discover the error points if we modify or delete the history. As a result, please refrain from doing so.
7. Do Not Ignore .gitignore
The .gitignore file is a special file where you can provide file name patterns to exclude certain files from staging. As a result, there is no risk of the ignored files being accidentally committed and pushed. It’s a lifesaver. You might not want to push the node modules folder to your remote repository if you’re a web developer.
Please retain a .gitignore file at the root of the project folder with file name patterns.
8. Do Not Reset a Branch Without Commit Changes
Do you find yourself resetting frequently? If you reset a branch without stashing or committing your modifications, you risk losing them. When you’re having problems with your Git files, resetting them may not be the only option.
💡 Ask yourself, do you require a branch to be reset?
9. Do Not Make Bulky Commits
Do not save a large number of commits for a push at the end of the day. A high number of modest logical commits is preferable to a few large ones. As we all know, git records each commit we make in the history with a commit id and a message provided by the user. As a result, breaking your commits into little logical parts is a good idea.
💡 Commit often, push logically. It reduces your chance of facing deadly merge conflicts.
10. Do Not Amend a Commit in the Remote Casual
Directly amending a commit in the remote is not a good practice. If you’re not sure why or what you’re doing, don’t do it.
💡 If a StackOverflow solution is amending commits in the remote, look for another solution!
For more info:Â https://www.qaaas.co.uk/testing-services/
Also Read:Â https://www.guru99.com/software-testing.html