As projects grow more complex and team sizes increase, source code management becomes an important part of how well a team can collaborate and operate efficiently. Thinking about how your team wants to manage source control with Git upfront allows you to set up your tools, processes, and best practices to scale for long-term success. This article discusses the key areas you should consider when creating a code management strategy for your team.
Contents
Branching
One of the first decisions to make when setting up your code repository is what type of branching will you use. Your branching strategy informs how your team manages their individual code changes, what process is used for merging, and how code is deployed. You should consider your team’s current needs as well as how you might grow in the future to choose a branching strategy that will scale. For a deeper dive into branching, check out Proven Branching Strategies for Your Development Team.
Sync Your Repository
Once you’ve identified your branching strategy, developers can start contributing to the project. Many projects today have teams of developers contributing to them. To avoid merge conflicts or other errors when you commit your code changes, it’s important to do regular pull or fetch requests to ensure you are working from the most up-to-date version of the code. To learn more about how to avoid merge conflicts, see Troubleshooting Merge Conflicts: Common Scenarios and How to Resolve Them.
Commit and Push Often
Commit code changes often in Git to save changes to your local repo and improve source control with Git. Committing changes frequently creates a clear timeline of the code changes you are making. Keeping track of more granular code changes makes it easier if you need to roll back to a previous version of the code. If it becomes necessary to roll back the codebase due to issues, you will be able to pinpoint exactly where they occurred and revert back only to that point, keeping prior changes and avoiding redoing work. Because code commits are local operations, you can save your incomplete work in progress without impacting your teammates.
You should also push committed code changes frequently. Git push saves your commits to the remote repository, creating a backup of your work and sharing your changes with your team who can then pull them down into their local repositories. Because pushing changes shares them with your team, you should only push completed code changes. For more information about the difference between code commit and push, check out the Difference Between “git commit” and “git push”? on GeeksforGeeks.
Document Changes
This may seem obvious, but well-written commit messages are an important part of source code management. Commit messages clearly document the history of changes, enabling you and your teammates to see a history of each small change. This documentation is useful during pull request reviews and in the event an issue is uncovered in your changes and needs to be rolled back. Git Best Practices – How to Write Meaningful Commits, Effective Pull Requests, and Code Reviews offers tips for how to effectively document your code changes, such as using imperative commands to keep your commit messages brief but helpful.
Configure Branch Security
Protecting your source code is important and can be done in two ways: limiting branch access and limiting merge requests. In larger projects or in companies where multiple projects are in a shared repository, not all developers need access to all source code files. In these cases, restricting dev access to read-only in the sub-branches that don’t pertain to their projects can prevent accidental changes by individuals not familiar with that area.
Similarly, not all developers should be able to merge changes back into shared branches. For larger teams, access to the main branch is often restricted, so developers create merge requests to signal changes are ready for integration into the master branch. This is typically when a formal code review will happen, and once all of the comments are addressed, your code changes will be merged into the master branch.
As with code commits, a best practice for merge requests is to keep them small and include brief but informative descriptions with your submission. A merge request will often be scoped to the changes related to a single feature or bug fix.
Source Control with Git in Assembla
Merge Requests and Protected Branches
In Assembla, you can protect branches in order to prevent code commits or to create mandatory review workflows. If a review workflow is set up, when a developer with read-only permission creates a merge request Assembla will automatically create a review branch and assign a merge request. You can specify if the review request is assigned to the entire team or to a subset of team members. To learn more, see Protect your Branches in Git.
Code Reviews
Once the merge request is submitted your team can leverage Assembla to communicate during the code review process. On the Merge Requests tab reviewers can upvote or downvote the merge request, enabling you to easily keep track of who has signed off on the code. Reviewers can leave inline comments to specify needed changes and you can keep track of which comments you have addressed by marking them as resolved. For more information, see Git: Merge Requests & Inline Comments.
Tickets
You can associate Tickets with your merge request to keep track of which bugs and tasks are related to your code changes. If a Ticket affects multiple areas you will be able to see all of the associated merge requests from the Ticket. If any issues are found with the Ticket’s feature you can quickly track down which source code files may be impacted.
Start a Free Trial of Assembla
Assembla is the only cloud-based source code management platform that supports source control with Git, Perforce, and Subversion. Assembla gives you the power and flexibility to use the version control of your choice, while enhancing security and taking away the overhead of managing your own infrastructure.
Git source code is automatically scanned as part of every commit and Assembla’s source code tools add an additional layer of security with features such as two-factor authentication, user activity audit reports, and static code analysis.
If you’re ready to improve your source control with Git, start a free 14 day trial of Assembla. Our team would love to talk with you about how Assembla can help your team get set up for success.