PS: This post is for someone who has little knowledge of Git and GitHub.

Yellow People✌!!

I remember, when I was a junior dev and I didn’t know how to use Git, what approach to use, what kind of mindset I need to adopt. All these are really confusing when you start a fresh. The jargons, steps you should follow and so many more, everything confusing even after someone explains it. Don’t worry, you are not alone. We were all there at times.

What important lessons did I learn as a developer using Git? I really got confused between Git and GitHub. It sounds so similar when it’s not. It’s something like Java and JavaScript. Well, that’s another topic, for another blog😜.

This blog post will be an easier one, I promise. It’ll only focus on how to use Git and GitHub, so that you get no/less merge conflict. I’ll discuss some of my simple steps and how to check-in your code without any errors.

Let’s look at some important Git rituals before check-in in any new commit.

Before the new changes:

1. Always, I say “Always” have the latest version of the branch you’ll add new code to. Always pull the branch before doing any change. (Must follow)
2. If the branch you are using is common, then try (if possible) to know if anyone else is working on the same branch. If yes, you need to co-ordinate with that person.

After the new changes:

1. Keep a copy of your new changes until your code is checked-in successfully.
2. Do a pull on the branch again. Just to make sure you have the latest version.
3. Compare your new changes (without ignoring the spaces) with the latest change in the branch. Just to check if you didn’t add, modify, or remove anything that was not needed.

1. Remove anything that was not required for the feature/bug you’re working on (even spaces). Spaces can also creates merge conflict. I’ll discuss later how spaces can create a big problem.
2. Always review your commits before you send them, you will be amazed by how many bugs you will catch of yourself.
3. Commit the changes with some good commit messages like using the ticket number/issue numbers or specify WHY you did it. Using a ticket number in commit will always be helpful for future tracking.

What to do after your commit is done?

Now, starts the main step of moving your changes to the actual branch i.e., creating a pull request. This is where the merge conflict arises. Make sure to verify your branch names before merging a PR because sometimes GitHub page get refreshed and it changes the target branch to the “main” (happen a lot).

Some point to keep in mind before merging:

1. Check the “Able to Merge” checklist before creating the PR.
2. Re-verify the source and target branch.
3. Check the number of files you changed.
4. Compare the changes of all the files. Even slightest of change can cause merge conflict.

Keeping these points in mind and making a habit out of them will help you in long run. You better waste 10 minutes of your time than hours of multiple colleagues. These really worked for me, and they might do good for you as well.

What’s the issue with whitespaces in merge conflict?

Whitespace has ended up being a horrible pain for me while using Git. It seems to heighten your chances of getting conflicts. Why? The merge conflict is given as textual markers in the file by Git. Whitespace parsing is challenging due to the various coding and scripting languages. So, whitespaces end up causing merge conflict.

Though, it is possible to remove whitespaces manually using some Git commands. But that also gets cumbersome sometime.

That’s all folks…!! These were the simple steps to no/less merge conflict. You can always have your own steps for dealing with merge conflicts. This is not something carved in stone that you must follow. But it’ll do you good when you follow these steps and get saved from the horror of resolving merge conflicts.

Please do add your comments and let me know your life saving tips for using Git and GitHub.