Much has been said about version control systems and their importance in the efficient management of code changes, as well as in the delivery of products of higher quality and better cooperation among developers. But even with all this information, understanding the critical terms such as merge requests and pull requests in different version control systems can be tricky, especially for beginners.
Let us briefly guide you through the difference between merge and pull requests and a step-by-step procedure of how to version-control SQL Server databases using dbForge Source Control, an SSMS add-in for SQL Server database change management in all popular version-control systems and servers.
Contents
- Understanding version control systems
- Pull request vs. merge request
- Version-controlling SQL Server databases with dbForge Source Control
Understanding version control systems
A version-control system (VCS) keeps track of every change made to files or code and records them as the history of changes so developers can always be aware of who, when, and for what reason made modifications to files. In addition, a VCS ensures access to the latest project version. If any issues occur, developers can roll back to the earlier version, compare the current version with the previous one, and fix the issues. If developers make different changes to the same piece of code or file, they may encounter a conflict. In these cases, the version-control system offers a way to resolve it by merging the local or remote changes to the repository.
Version-control systems can improve productivity and accelerate product release. They empower multiple developers to work on the same product simultaneously by developing different features and functionalities. Moreover, the changes can be merged after a thorough code review and change analysis that facilitates the maintenance of error-free and accurate code.
To sum up, with a VCS, you can benefit from the following:
- History of changes helps identify the author and reason for a code change. For example, this information can be useful for troubleshooting and debugging.
- Collaboration enables seamless cooperation and smooth integration of changes. In addition, developers can remotely access and manage the code from different locations, improving flexibility and efficiency.
- Maintenance of code integrity prevents accidental overwrites, unintended modifications, or data loss.
- Rollback to earlier versions if any issues occur.
- Testing allows for verifying the development results in a staging environment independently before merging them into the main codebase. This capability ensures stable and tested code will reach production.
- Iterative code commits help control changes and make code maintenance easier.
- Integration of version-control systems into Continuous Integration and Deployment allows for automated testing, building, and code deployment.
- Branching such as feature branching, release branching, and hotfix branching enable developers to work on different parts of the project simultaneously and manage the flow of changes effectively.
- Code reviews allow for reviewing each other’s changes before they are merged. This process maintains code quality, knowledge sharing, and adherence to coding standards.
So, how does version control work? In our article, we will use one of the most popular version control systems – Git. That’s why the explanation will refer to this source control. Developers start by cloning the main repository to their local machine. They create a branch for their specific task, make and test changes locally, and then commit them to their local repository. Before pushing the changes to the remote repository, developers pull the latest changes from the remote repository’s main branch to have the latest version of the code. Then, they open a pull/merge request for code review and discuss and fix any issues. The system will then verify the code automatically. If the code works properly and possible conflicts are resolved, the request gets approval, and the changes can be merged into the main branch.
Now that we’ve briefly covered what a version control system is and how it works, it is time to differentiate its main terms, which often cause confusion, pull and merge requests. Basically, they have a similar purpose: by submitting a pull or merge request, you ask the receiver of the request to review the code changes before merging them into the main repository. Let’s look at each request in detail.
Pull request vs. merge request
If we compare pull and merge requests, we see that, in many aspects, they are similar. The difference lies in the platform developers use: a pull request is a GitHub feature, while a merge request is specific to GitLab. Apart from this difference, they both serve as mechanisms to merge the branch of the developer to the main branch of the repository.
So when you initiate a pull or merge request, you notify your colleagues that the changes have been pushed to the branch of a Git repository and request them to do a code review before merging. The reviewers can leave their feedback in the comments section of the request. Subsequently, you can discuss their comments and fix your code. Once done, the system automatically checks the code for interoperability, which may involve executing unit tests or automated checks to detect errors. If the code works properly and the proposed changes are fixed and accepted, the pull/merge request gets approval and can be merged into the main branch of the repository.
Still, there might be some peculiarities regarding the flow of creating the pull or merge request. We recommend you refer to the official documentation: GitHub for pull requests and GitLab for merge requests.
Version-controlling SQL Server databases with dbForge Source Control
In your daily administrative work, you may often need to version-control databases. In this case, you can use dbForge Source Control to see version control in action.
dbForge Source Control integrates into SQL Server Management Studio (SSMS) as an add-in, providing database version control capabilities directly within the SSMS environment. The tool helps set up version control of the database from scratch, view and resolve conflicts, roll back changes to previous versions that ensure data integrity, track the history of changes, as well as work with multiple branches. dbForge Source Control supports the most popular version-control systems allowing you to choose the one that best suits your organization’s preferences and infrastructure. They include Azure DevOps Server, Apache Subversion, Git (including GitHub, GitLab, and BitBucket), Mercurial, Perforce, SourceGear Vault, and TFVC. Moreover, the tool facilitates automated deployment of database changes from version control to production environments, reducing the risk of manual errors and enhancing deployment speed.
Let’s exemplify how to link a SQL Server database to GitHub using dbForge Source Control. Before linking the database to source control, you need to create a Git repository locally or clone it from the remote repository.
To proceed, open the SQL Server Management Studio and establish a server connection. In Object Explorer, expand the Databases node, right-click the database you want to link to a version-control system, and select Source Control > Link Database to Source Control.
In the Link Database to Source Control dialog that opens, choose a source control repository.
In the Source Control Repository Properties dialog, choose Git as a source control system. In the Repository folder field, click the browse icon to select the repository folder created locally on your machine. The same name will be automatically used for the repository name. If you want to set a distinct name, you can do this in the Repository name field. Click Test to check that the database has successfully been connected to source control. Click OK to save the settings.
On the Link page, select Dedicated as a database development model and click Link.
Linking a database to source control for the first time may require adding the database objects to source control in an ‘initial commit’. If you linked a database that is already in source control, update your database to the latest version.
Conclusion
In the article, we have examined the similarities and differences between merge requests and pull requests. To sum up, pull and merge requests encourage collaboration among teams by “asking” peers to review their code and providing feedback through commits or comments. They collect the changes from the developers’ branches, make fixes, check the code, and then when it is approved, their code changes can be merged into the main code.
In addition, we have explained how to version-control SQL Server databases using dbForge Source Control.
If you want to see dbForge Souce Control in action, download a trial version for free and enjoy the advanced features and functionalities of the tool for free, available to you for 30 days.
