If you found this article helpful, you will most likely find my tweets useful too. So make sure you follow me on Twitter for more information about web development and content creation. This article was originally published on my Blog.
Hello friends 👋. I hope you all are doing great and had a productive week learning something new. Today, we will discuss Git and a few usages, practices that you should avoid making your development experience a better one.
What is Git, and How does it work?
Git is an open-source version control system(VCS) that helps all project contributors to keep their project artifacts(folder, files, source code, and many more) in sync. It provides a workflow that is easy to understand, learn, and use in practice. If you are a beginner to Git or have any difficulties with its usages, here is an in-depth, hands-on video tutorial for you. Please have a look.
Suppose you like the content, please feel free to subscribe to the channel. Thanks a lot 🙏. Let us now see ten usages & practices that you should avoid.
10 Git Usages You Should Know to Avoid
Git is a highly flexible tool. When you know to handle Git Commands, you feel superior about managing things. 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 ten usages we should stop or avoid.
The master is special
Yes, it would not be the best to commit to the master branch and other main branches(like the release, dev) directly. In Git, a master branch must contain the most stable version of your source code and other project artifacts. It is most likely that you will build your end product from the master or a release branch. Committing and pushing to these branches directly have a higher risk of corrupting changes, introducing bugs, hours of extra work.
In many cases, you will not have access to commit to master directly. Your source code repository administrator would have set the branch protection rules. If you have access to do some, please don't do it or be sure of what you are doing.
"With great power comes great responsibility"— the Peter Parker principle.
So better to create a feature/fix branch and then Change => Stage => Commit => Push to it than pushing directly to master/main/release.
💡 It's better to practice it even when you are alone in the repo—do a role play.
Keep application secrets a secret
When working on a project(including side hustles), you may have a few details that you want to keep private. It could be the API Keys, Secret Keys, Database secrets, Auth secrets, and many more. Making these publicly available may increase security risks to your application. At the same time, it may make a big hole in your pocket when someone misuses.
Do not commit your project secrets with any accidental pushes to the remote repository.
💡 Create a .gitignore file at the root of the project folder and mention file patterns(like .env*) to ignore from staging.
Git is not your file storage
Do you want to store movies? An extensive demo video? Git is not the place for it. Other media services work better for these use-cases. It is better not to store large files and binaries in Git repositories. You know, they call it source code repository!
Technically, you can store anything in a Git repository as long as it doesn't bother and cost someone. The cost is not always the money. It is about time too. It would be a massive waste of time for someone to clone a repository because we have stored a few gigabytes of video in it.
💡 You can configure the type and size with GitHub, BitBucket, etc., to limit and keep it in control.
Together we strong, but not always
It is usual to handle multiple features/fixes/issues in parallel. But do not handle multiple issues in a single branch(even when you are super confident about it!). It may cause a nightmare when you(or your lead) decide to drop one or more issues from the planned fixes. Now you have to pick the unwanted fixes, code changes and remove them. Who wants to do any extra work? So, let's avoid it.
💡 A better pattern to follow is, 1 issue => 1 branch => 1 PR and repeat.
Do not force
Here is a situation,
- You and your friend are working in the same branch.
- She made a commit and pushed her changes to the remote.
- You are also done with your changes now but you have made a force push to the remote branch.
- In the blink of an eye, all the changes done by your friend are just gone!
Don't perform a force push unless you need it. Your co-workers may go insane because of this.
💡 Always pull before the push.
History is important
When you commit a change to a branch, git writes the commit history and preserves it. Suppose you wonder why commit messages are important because those messages become a part of history. You can understand why someone has done specific changes to a file and who has done them.
Modifying or deleting history will take away the opportunity for us to debug and find the error points. So, please stay away from doing it.
Don't ignore to ignore
The .gitignore is a particular file where you can mention file name patterns to ignore specific files from the staging. Thus there is no chance of any accidental commit and push of the ignored files. It is a savior. If you are a web developer, you may not want to push the node_modules folder to your remote repository.
Please create a .gitignore file with file name patterns and keep it at the root of the project folder.
Resetting is probably the last solution
Do you reset often? You may lose your changes if you reset a branch without stashing or committing your changes. When you are in trouble with your files in Git, reset may not be the only solution.
💡 Ask yourself, do you need to reset a branch?
Don't make it bulky
Do not park many commits for an end-of-the-day push. Many small logical commits are much better than a larger ones. As we know, for each commit we make, git writes it to the history with a commit id and user-provided message. Hence it is a good practice to break your commits into small logical chunks.
💡 Commit often, push logically. It reduces your chance of facing deadly merge conflicts.
The past is past
It is not a good practice to amend a commit in the remote directly. Don't do it if you are not sure why and what you are doing.
💡 If a StackOverflow solution is amending commits in the remote, look for another solution!!!
That's all for now, friends. I have shared this content originally as a Twitter thread recently. You may be interested in reading and following the discussions there as well.
I hope you enjoyed this article or found it helpful. Let's connect. Please find me on Twitter(@tapasadhikary), sharing thoughts, tips, and code practices. Please give a follow.
You may also like,
Top comments (1)
Force push isn't so bad if you have a rebase policy, --force-with-lease is helpfully here.
Reset is safe if you don't add --hard
Do change history before you merge it in. Tell a story that shows you understand the changes made, make code review a breeze.