We interviewed hundreds of software developers, and perfomed code scanning on thousands of GitHub repositories using our own product to produce this list.
These best practices are still applicable even if you use something other than GitHub for version control or source control, because they’re all about ensuring source code security and writing good code.
Regardless if you use Gitflow or any other git branching model, it is always a good idea to turn on git branch protection to prevent direct commits and ensure your main branch code is deployable at all times. All commits should be managed via pull requests.
Sometimes you commit code using the wrong email address, and as a result GitHub shows that your commit has an unrecognized author. Having commits with unrecognized authors makes it more difficult to track who wrote which part of the code.
Ensure your Git client is configured with the correct email address and linked to your GitHub user. Check your pull requests during code reviews for unrecognized commits.
When you’re dealing with dozens, hundreds, or more repositories and engineers, it’s nearly impossible to know who owns which parts of the codebase and need to review your changes.
Even in smaller teams you’d still have code owners – for example, front-end code changes should be reviewed by the Front-End Engineer.
Use Code Owners feature to define which teams and people are automatically selected as reviewers for the repository.
Secrets, or secret keys or secret credentials, include things like account passwords, API keys, private tokens, and SSH keys. You should not check them into your source code.
There are also tools for scanning secrets in repos and prevent them from getting into repos.
Pushing dependencies into your remote origin will increase repository size. Remove any projects dependencies included in your repositories and let your package manager download them in each build. if you are afraid of “dependencies availability” you should consider using a binary repository manager solution like Jfrog or Nexus Repository. Or check out GitHub’s Git-Sizer.
We strongly recommend against committing your local config files to version control. Usually, those are private configuration files you don’t want to push to remote because they are holding secrets, personal preferences, history or general information that should stay only in your local environment.
A .gitignore file is a must in each repository to ignore predefined files and directories. It will help you to prevent secret keys, dependencies and many other possible discrepancies in your code. You can choose a relevant template from Gitignore.io to get started quickly.
Over time, for various reasons, we find ourselves with unmaintained repositories. Sometimes developers create repos for an ad hoc use case, a POC, or some other reason. Sometimes they inherit repos with old and irrelevant code.
In any case, these repos were left intact. No one is doing any development work in those repos anymore, so you want to clean them up and avoid the risk of other people using them. The best practice is to archive them, i.e. make them “read-only” to everyone.
Your manifest file contains information about all packages and dependencies in your project and their versions. The best practice is to specify a version or version range for every package and dependency listed in the manifest. Otherwise, you can’t be sure which version will get installed during the next build, and consequently your code may break.
Even when everyone on your team are using the same packages, reusing code and tests across different projects can still be difficult if the packages are of different versions.
If you have a package that is used in multiple projects, try at a minimum to use the same major version of the package.
All that’s left for you to do is check off each of the aforementioned best practices, on each of your repositories, one by one…
Or, save your sanity and connect with Datree’s GitHub app to scan your repositories and generate your free status report to assess if your repositories align with the listed best practices.
Make every pull requests compliant with security policies and coding standards.
Datree is free for Github accounts with less than 5 developers.
I was really happy to give this interview to Jeff Meyerson on Software Engineering Daily, talking about DevOps, GitOps, software quality and how Datree can
During this year’s AWS Summit TLV, I attended the GraphDB presentation on the innovation track. What made this session stand out was that the track…
The Serverless Framework is one of the oldest (and still going strong!) deployment frameworks around for serverless applications. It’s my framework of choice and enjoys a great deal of support from the community in terms of contributions as well as plugins. In fact, its ecosystem of plugins is one of its greatest strengths compared with