Imagine you think of some new feature for your product. You write hundreds of lines of code overnight to get it to work. Suddenly, everything stops working.
You go through your code and can't find what went wrong. You even delete all the previous days' code, and nothing still seems to work.
This problem would be amplified tenfold if you were working in a team. You have to sort out who coded which part.
This is why you need version control. A simple command and you're back to a previous version—no looking through code or anything.
Working in teams is simplified. Different people can work on various features using different branches.
Only once a change is ready can you add it to your main code by merging it. Even if something goes wrong, now you can revert to the previous version of the code.
As a beginner, it is always a struggle to understand how to manage your Git history, branches, issues, etc. Many pick up bad habits such as force pushing and using only main branch.
It might seem easy at the start, but these mistakes will create friction.
Read the points below if you have grown out of the beginner phase and want to become a better developer.
Commits are the heart and soul of a Git project. If you manage your commits, you manage your project. It's as simple as that.
So when working on a code base, there are really only two broad categories of commits — Features and Fixes. You should have this distinction very clear in your mind when you choose to alter a project.
You can generally break a particular task into functional chunks of fixes and features. You must Isolate each chunk of the task, then work on implementing the specific chunk. Follow the simple arrow guideline!
Task → Chunks of Isolated Fixes and Features → Implement a single chunk → Commit it → Repeat to Completion.
You will run into trouble if you make multiple changes for one commit. Everything becomes cluttered, and you won't have a previous Commit to fall back to.
Anyone who sees your code will get confused if you work on your login and sign-up functionality in the same commit.
Follow these steps meticulously. This ensures that your Commit history remains consistent and clean. It will save you a lot of time if things go wrong; you always have a functional Checkpoint to go back to!
I like to think of Branches as Commit queuers! They define a line of commits. A particular task may require more than one commit to complete, and be ready to do so if required.
As branches sit on top of commits, they are secondary to commits. Committing clean is of the essence.
Name your branches well. Use them like how you would use a filesystem.
feature/backend/<adding_analytics> instead of — feature/<adding_analaytics>
Don't be afraid to Branch more often. This is a common problem I see among beginner developers.
They're ignorant or lazy to switch branches. They push commits directly to the main branch. If any mistake happens, the whole staging goes down.
When you use a different branch, you must create a pull request before merging to master. This way, someone can go through the branch and check if everything is working fine.
Github can also run lint checks on your pull requests and check for issues. This way you will be prompted to fix any lint issues.
I see this mistake from a lot of younger developers and some seniors too! Their Git is, simply put, not managed. Writing all the commands is so taxing.
If Git commands are a pain, you are never gonna be consistent, No matter how hard you try.
Make your Git actions simple. Ever since I started using these short-cuts in my
Just these four will save your life. You can do the same for all your common commands.
Also, set up your Git lens on your favorite source code editor to the fullest degree possible. Github with Vscode is a life saver. You will allow yourself to view all the files you have changed at a glance and be able to commit right from that Window! All you have to do is press the plus icon and write a message.
This is best for people who prefer to look at their git in a visual manner and don’t like writing commands. Staging individual files is also much easier and you don’t have to use the command git add <file name>.
Making it easy for yourself helps you be more productive.
It's always good to use dedicated software that helps you manage your codebase. These act as accessories to your Github and make everything easier.
When you use
When you use
You get all your Github project information on your