In this blog, I'm going to share about common mistakes beginners make while contributing to Open Source. These mistakes may be silly and common but they affect your Github profile to a large extent. Mistakes that I'm going to mention in the blog are also done by me and they taught me a great lesson on the way. It's good that you will be learning a lesson without actually making a mistake. Sound's like a fair deal! Let's dive straight into them and correct them if you have been doing it wrong.

1. Configuring username and email

The above contribution graph shows my contribution in the year 2022. It shows a total of 123 contributions. But what if I told you I made much more contributions than this? Let's know how your important contributions just disappear from the contribution graph.

This type of mistake is mostly done by newbies who have just started with git and GitHub or by someone who has just switched to a new machine.

Every commit on your git has a username i.e. author, email and date-time associated with it. Each commit has its commit metadata which stores the email, author and time of commit. Therefore, you have to config your username and email by running the below command

git config --global user.name "My Name"

Similarly to config your email you must run :

git config --global user.email "myemail@example.com"

To check if your email and user are already configured you can run :

git config --list

So if haven't configured your username and email yet just go and configure otherwise the email by default will be taken as username@hostname which won't reflect contributions in your GitHub graph. I made this mistake when I brought my new MacBook Pro and forgot to config my email and username due to which many of my contributions never reflected on my GitHub profile.

2. Working on a branch

It's always a good practice to create a new branch of the main branch at a particular instance. Working on a branch comes with tons of benefits. You can create a new branch and switch to working on it with the command:

git checkout -b feature-branch

Working on a branch allows you to isolate your changes from the main codebase, which helps you avoid conflicts with other contributors. This isolation is particularly useful when you're experimenting with new features or making major changes to the codebase. By working on a separate branch, you can make changes to the code without affecting the main codebase or the work of other contributors.

It also makes it easier to collaborate with other contributors. Each person can work on their own branch and then merge their changes into the main codebase, which reduces the risk of conflicts and makes it easier to work together on a project.

If something doesn't work the way you want in the branch you can discard the branch right away and create a new branch from the main codebase which is in working condition.

3. Things not be open-sourced

This was the title of an email I received just after working on my personal project and making a commit on the remote repo in GitHub. After reading the title you know what has gone wrong, I have pushed the code containing my personal API key on GitHub making the key open-source (that's too much of open source). Now even if you make changes in the file the key is still visible in the commit history of the repository.

To avoid this you can store sensitive information such as API key in your .env folder, ignoring the .env folder by using gitignore. You can find more about this method here

And if you already pushed some sensitive data on GitHub then you can use the git filter-branch command to edit your commit history. More about this method here

Meanwhile, Python developers don't forget to add your env folder in .gitignore or you might end up pushing the whole Python environment on GitHub.

4. Making a git repo in the root directory

This is the silliest mistake beginners make when learning git. Git is meant to track your project, not your whole operating system. Beginners sometimes while learning git, out of excitement forget to change the directory and run git init directly in the root of the machine. This mistake can also be done in the parent folder of the project directory. Therefore always make sure to run git commands in the specific folder where you plan to build your project with the help of git

You can remove the empty git repository which you made in the root directory by running the command :

rm .git

for window's user :

del .git

5. Setup the development version

For some of the open-source projects, it's not always the traditional method of git clone and directly start contributing to the repositories. Some of the open-source projects have their development version which needs to be set up in the machine, to start contributing to the project.

Developers, here go with the traditional method of git clone and later on face problems regarding the version of the project. Setting up the development version of a Git repository allows you to contribute to the project by making changes, submitting pull requests, and collaborating with other developers. The development version usually contains the most recent updates, bug fixes, and new features that may not be available in the stable release or official distribution. By setting up the development version, you can work with the latest codebase and contribute to its improvement.

It's important to note that the setup process may vary depending on the project and its specific requirements. It typically involves cloning the repository, installing any necessary dependencies, and configuring the development environment according to the project's guidelines. It's recommended to refer to the project's documentation or contributing guidelines for detailed instructions on setting up the development version and making contributions.

Conclusion

These are some small mistakes often repeated by developers or beginners who are just getting started with git and Github. Even if you didn't come across such situations mentioned above, you must still read the mistakes cause I'm sure that you will fall into some of these pitfalls someday.

I plan to continue this series of common beginner mistakes and will come up with part 2 very soon. Please make sure to leave a comment and let me know if you made any of these mistakes in your journey. Ideas for part 2 are much appreciated in the comments!

You can follow me on Twitter, Goodbye!