Your code repository is your most valuable asset, it represents the timeline and story behind what you’re building. It serves as your backup in case something goes wrong, which is why it’s essential to keep it as clean and organized as possible. Here are some best practices you can follow to achieve that for both private and public repos:
## The main contains the latest code always
I’m a fan of using GitHub Flow for code management. Unlike the traditional Git Flow, where you have multiple main branches (one branch per environment), GitHub Flow has only one main branch. Other branches are used exclusively for feature development. The main branch always contains the latest code merged from feature branches. However, this doesn’t necessarily mean the code is already in production; it simply reflects the most up-to-date work from the developers.
By following this approach, you ensure a single source of truth for the latest code and a single branch to deploy from. Even fixes and feature rollbacks are merged into the main branch after proper validation and approval, before moving to deployment.
## No one, literally no one, should push directly to the main branch
Since we are trying to keep the main branch as our source of truth, we don’t want any code added to it without proper validation. Therefore, we will implement policies to prevent direct commits to the main branch.
The only way to update the main branch is through a merge request. It’s always better to link this merge request to a CI pipeline to ensure that the code being pushed is actually built successfully. Additionally, we require at least one approval for the merge request—someone who thoroughly reviews the code rather than just clicking the "approve" button.
## Maintain your ignore file.
Keep your `.gitignore` file up to date and remove any unnecessary files from your repository. These files include editor configuration and preference files, such as those found in the `.idea` folder for Rider IDE.
Additionally, remove any libraries or binary files from your repository. Even if these files are not available on the internet, use an artifact store or secret vault to manage them. Including binary files in your repository can significantly increase its size, making pushing and pulling code a slow process. Moreover, it could pose a security risk if someone replaces the binary with a malicious version.
## Prevent pushing secretes to the code
Passwords, API keys, and any credentials for any environment should never be pushed to the main branch. There are SAST tools, such as SonarQube, that can be integrated into CI pipelines to help scan your code for sensitive information.
**Note:** In case your secrets are accidentally pushed and committed to the main branch, don’t panic. You don’t need to delete the entire repository. Instead, make sure to update or rotate those secrets at their source. I trust you’ve got this covered!
## Use Squash commit on merge
To prevent insecure commits from being added to the main branch, [squash all commits](https://gist.github.com/lpranam/4ae996b0a4bc37448dc80356efbca7fa) into a single final commit during the merge.
This ensures that each merge results in a single commit, making the code history easier and faster to review.
Additionally, this approach prevents any security fixes or vulnerabilities from being visible in the commit history, reducing the risk of someone rolling back to an insecure commit.
## Use secret vault for your configurations and Environment variables
Keeping your configuration files and environment variable values out of your repository is a good practice. By doing so, you ensure that no one can accidentally alter your configurations. Instead, inform developers where they can access the latest configurations—this could be from a secret vault or any other configuration management system.
## Conclusion
In this article, we explored how to keep our repository clean, highlighting the importance of maintaining secure code and preventing security breaches in our codebase.
Special Thanks to [Mohamed Othman](https://www.linkedin.com/in/mohammad-othman-55351b20b/) for his help in editing this blog. ## Introduction If you are generally working in the technology sector and specifically in the software industry, you will be under stress by the number of new things that are coming up every day. New stuff can be a new integration technology, a new framework, a language version upgrade, or even a new library that helps you to do specific tasks in your code. In this article we will refer to those as: "new Tech". And if you are like me, you will feel messed up if you don't know or know how to use the new trend! So here, I will list some tips and tricks, along with best practices for keeping your projects up-to-date. **Note**: the tips in this article for when and how to implement the new technology in your daily working projects are not concerned about keeping your knowledge up to date, knowing things and doing them are two different t...
Introduction In this article we will discuss adding multiple DB contexts to our DotNet projects, we will use EF core as our ORM to make a "Code First Database" approach. In this article example, we will use DotNet 7 connecting to SQL Server through EF Core 7, all of this will be in a web API project to see how to define those DB contexts as services in program.cs file. You can download the example source code from here . Why would we need multiple DB Contexts in our Solution? There are two situations where you need multiple DB Context in your project or Solution: We have a single database but need multiple schemas in our database, and each scheme will have a group of entities. We have Multiple databases and our project needs to connect them to do its operations. We will take the first situation as our code example. Creating Our models Let's assume we have a si...
Comments
Post a Comment