Version control tools allow developers and teams to save incremental changes to a project, collaborate on code, show which changes were made over time and by whom, and backtrack and undo those changes if necessary. In recent years, Git has become the open source standard and there are many Git hosted services.
Source control with Git is central to working with ossum for a smooth development workflow. In this blog, we’ll discuss a couple of best practices for using Git with ossum.
For more information about Git in ossum read: https://resources.ossum.cloud/blog/managing-source-code-in-ossum
Committing and Pushing
First of all, committing and pushing are separate things in Git. Git, in contrast to some other version control tools, copies the entire repository to your local machine, including the complete history of changes. Git natively stores the history of changes in an efficient manner so you don’t end up with gigabytes of unnecessary code on your computer.
When you write code or make changes to existing code, you use Git to commit those changes to your local repository.
Pushing code with Git pushes it back to the central repository (often on a server or a hosted service) so the entire team can see the commits.
With this in mind, it’s good practice to commit early and often. You can commit parts of new features as you write them and only push the changes up when the entire feature is done.
However, all of your commits ultimately end up in the main repository, so make sure your commit messages are always meaningful.
Having lots of intermediary commits can seem messy, and not everyone is comfortable with sharing their “in-between” commits with the team. Git squash is a command that allows you to make one commit out of multiple commits.
Branching is fast and cheap (in terms of resources needed) and it’s a natural part of using Git. It allows you to work on multiple features at once by using a branch for each feature.
Using Git, one popular workflow is to use feature branches for every feature or bug fix. Once implementation work has been completed, a merge request is created so that the change can be reviewed by other developers and verified by test or continuous integration (CI) tooling (we'll talk about this practice in more detail later).
The advantage of this practice is to keep changes small, self-contained, and easily tracked and tested or verified. In addition, the rest of the codebase remains unaffected by this work until the changes are committed and merged back in.
For example, say your project has a Master branch and you need to add feature X and feature Y.
You create two branches from master: one for Feature X and one for Feature Y. When Feature X is finished, you can merge it back to Master regardless of the status of the Feature Y branch.
That also means that when a bug is discovered on the master branch you can fix this bug and release master without having to wait for feature X or Y.
With ossum, keeping track of your branches is pretty easy because of the graph view. Be sure to clean up your branches when you’re done with them.
It is good practice to not push to your main branch. Instead, make all merges come through a merge request.
When a member of the team is done working on a branch and needs it to be merged back to the main branch, a merge request is created. This request must be evaluated and approved by other members of the team. This promotes shared code ownership, best practices, and code reviews.
A really cool feature in ossum is that you can connect your CI/CD system. You can make ossum automatically trigger a CI job to verify a merge request right when it gets created. Ossum then automatically provides feedback on the merge request regarding the CI verification outcome.
If a CI verification fails, you know more work is needed, which may indicate that other review or testing steps are needed. Even when the CI verification succeeds, another member of the team still needs to give an additional approval.
Keeping branches small and short lived will make it quicker to review and easier to merge them into the main branch.
Code reviews are a good practice. With code reviews, members of the team look at another member’s code before it gets merged into the main branch. Code reviews encourage better teamwork because merging code becomes more of a team effort. There are some guidelines for good and constructive code reviews, but that’s outside the scope of this article.
There is no built-in functionality in Git that supports code reviews. It’s possible, but you have to bring your own process. Ossum has a built-in process for code reviews. You can simply create a merge request and require a couple of team members to approve your code before it is merged back into the main branch.
Ossum compares the changes side by side or on top of each other. Team members are able to comment so the team can start a discussion if a piece of code requires it. The code is only merged into the main branch after the code is reviewed and a sufficient number of reviewers have accepted the code. The benefit to this is that not everyone can simply push any code back into the main branch, reducing the chance for bugs and technical debt.
Commit to Ossum
Git has many features and ossum helps in utilizing them to the fullest. Managing source code and releases is never easy, but ossum provides great tooling to make everything as clear as possible. Start today with a free trial on ossum.cloud
This post was originally posted on Ossum’s blog.