Devs To Devs: How To Avoid Common Developers’ Mistakes On GitHub
The digital age is an age of opportunity. But along with opportunities come risks and problems. Developing modern #software is a complex task that requires attention to detail and a wide knowledge of many aspects of programming. But even experienced programmers can make mistakes that can lead to a host of problems, such as bugs, performance issues, or #security vulnerabilities. Let’s take a look at some of the most common mistakes developers make when working with #GitHub. Whether you’re a novice programmer taking your first steps or a seasoned expert looking to improve your skills, this article should help you avoid common pitfalls when working with the popular version control system. With this knowledge, we should create better solutions that are reliable, efficient, and secure.
In recent years, GitHub has become an essential tool for developers to collaborate and manage source code. However, using this tool can also lead to some common developer mistakes that can have a significant impact on the development process. One of the most frequent problems is simply the improper use of version control. And this can lead to loss of code and, most importantly, to the waste of our most precious resource: time.
An example of a mistake is not regularly making changes
Popular developers’ mistakes
None of us is infallible. However, the most common reason for developers’ mistakes is a lack of knowledge. Increasing awareness and proper education allow us to minimize risks and create better solutions. So let’s check out some common slip-ups that happen even to experienced programmers.
The risk may be associated with deleting branches, especially if they contain important code changes. Removal of a branch permanently erases all associated code, commits, and history, which in most cases cannot be restored. It’s important to carefully review the code changes and consider the potential risks before deleting any branches on GitHub. In addition, it’s a good practice to regularly back up code changes and ensure that important changes are properly merged into the main codebase.
Deleting the repository – on purpose or by mistake – could result in the permanent loss of this information if the repository was not properly backed up or archived. I don’t need to say that this can be quite dangerous to a project or organization. Additionally, if the repository contained any sensitive information, such as passwords or access keys, deleting it without properly securing or disposing of that information can put us or our organizations at risk of security breaches and data leaks. It is super important to carefully consider the potential consequences before deleting any old GitHub repositories.
On the one hand, this point seems like a minor problem. After all, we have an external repository; we can create another local copy at any time and continue working. Apparently, yes, but even in this situation, we will lose some time (depending on the size and complexity of the project) to start the environment again. However, this is only a minor inconvenience.
A much greater risk, on the other hand, is when, for example, we create some PoC from scratch, checking certain things before we share or show our work to others. It may then happen that our local copy is the only existing version.
It doesn’t matter if this happens due to hardware failure, accidental deletion, or any other reason. The result can be the loss of important code changes, documentation, or any other project-related data. Subsequently, this can result in lost time and effort to restore lost work, missed deadlines, and potential damage to the organization’s reputation. If the repository has not been backed up to another device or cloud storage service, it may not be possible to recover lost data. And it will only be our fault.
Recommended by LinkedIn
This topic has already been partially covered above. Hardware failures can result in the loss of our local data. But after all, even if we are doing everything right on our local side, a failure can affect the external server that hosts our repository. A total failure of GitHub is unlikely to threaten us, but what about the situation when we host our repository on our own? Usually, we have a separate department or people in charge of administration for this, and it is not the responsibility of a programmer. However, in a small startup, who knows? We may be responsible for many things, and our own hosting can always fail, so we need to have a backup prepared for such situations.
When working with GitHub, it is very important to ensure that access to repositories is properly managed and controlled. If credentials are compromised or authentication protocols are not properly implemented, unauthorized individuals can access sensitive information or modify code without proper permissions. This may have very serious consequences for companies, organizations, or individuals. To mitigate this risk, it is important to follow access control best practices
This is my “favorite” part. Unfortunately, it is still a very common problem. It usually concerns access to databases in various environments, but not only that. This may come as a surprise to many, but such a phenomenon is not only widespread but has actually been increasing in recent years! This is confirmed by reports such as ‘The State of Secrets Sprawl 2023′ by GitGuardian. For example, according to Cybernews, around 18K out of 30K investigated Android apps are leaking secrets! Not enough? One in ten GitHub users who made a push in 2022 accidentally exposed a secret.
This is doubly important in today’s IT world, full of cloud services like GCP or AWS. Such platforms charge based on the number of servers/requests etc. If we carelessly or ignorantly expose our cloud platform credentials we may end up consuming unplanned resources, and end up with a hefty bill for services we didn’t plan to perform. This is one of the most painful developer mistakes.
GitHub addresses this and provides a solution called “secret scanning.” It doesn’t solve the problem completely, but it makes it easier for us to control and track the accidental placement of secrets in our repositories. More about that tool you can find in GitHub Docs.
One of the key advantages of using GitHub is the ability to control access to repositories. Thanks to that, we can easily manage and restrict access to the code. At the repository level, we can set permissions to define who has read or written access to the code. This can be configured on a per-user or per-team basis, providing fine-grained control over who can do what in the codebase. In addition, we can also control access to specific branches within a repository, or limit who can merge changes or make modifications to certain areas of the code.
GitHub supports organization-level permissions, enabling centralized control over access to multiple repositories. This allows organizations to easily and effectively manage access at a higher level and ensure consistent permissions across all our repositories.
We can also control the access through the use of deploy keys, which allow for secure authentication and access to specific repositories or servers. This provides an additional layer of security, ensuring that only authorized individuals or systems can access sensitive code or data.
Want to learn more? Read our full story here Devs To Devs: How To Avoid Common Developers’ Mistakes On GitHub
