- \n
- Using feature branches (also known as topic branches) for the initial development of code<\/li>\n
- Using Pull Requests to merge changes from feature branches into a mainline or shared code branch<\/li>\n<\/ul>\n
These two patterns are very common because Git encourages workflows that branch and merge often, even multiple times in a day. (To learn more about branching, read Branching in a Nutshell<\/a>.)<\/p>\n
In other words, Git is a powerful VCS and has very complex functionality at hand. In my experience, becoming familiar with patterns of branching, merging, and conflict resolution have helped make Git\u2019s complexity easier to understand and have helped me feel like I\u2019m working with<\/em> Git \u2013 rather than constantly fighting against<\/em> Git.<\/p>\n
A pleasant side effect is that this also makes working with Git more fun: I\u2019m able to work more frequently with common commands that work predictably and focus more on my work, rather than resolving an unexpected error.<\/p>\n
What does this workflow look like?<\/h2>\n
If you\u2019re not an experienced Git user, this probably sounds quite abstract. Here is a diagram of an example workflow which may help you visualize it. This workflow diagram shows a workflow with time flowing from left to right:<\/p>\n
![\"Branching](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/12\/branching-diagram.png\")
<\/p>\nIn this workflow, there is a main<\/em> branch. The main branch represents a mainline of code \u2013 it could be named master<\/em>; it could be named trunk<\/em>; the naming is up to your preferences. In this example, everything merged into the main<\/em> branch is expected to be code that has been reviewed and is considered to be ready to be deployable to a QA environment via automation.<\/p>\n
Let\u2019s say that our developers are working with the free Git client in VSCode and are using a tool like Redgate\u2019s SQL Source Control<\/a>, Redgate Change Control<\/a>, or SQL Change Automation<\/a> to script their database changes and manage the state of their development databases. (I\u2019m mentioning specific Redgate tools here because I\u2019m very familiar with how they work \u2013 if you\u2019re using other tools, they may follow similar flows as this. A lot depends on how the tool has been designed, how much of a Git client is implemented inside the tool, the types of files it uses, and the naming conventions of the files.)<\/p>\n
A developer, Amy, has used VSCode\u2019s Git client to create a branch named feature1 off main. Here\u2019s how feature1 progresses:<\/p>\n
- \n
- Amy works in a dedicated development database and uses their database development tool of choice (SQL Source Control, Redgate Change Control, SQL Change Automation) to generate database code and commit it to their local clone of the Git repository.<\/li>\n
- After the second commit to feature1, Amy merges from the main branch into feature1 to check if any other commits have been made to main since the feature1 branch was created. In this case, there have been no commits to merge in.<\/li>\n
- When Amy believes their feature is complete, they do a final code generation and commit with their database development tool, then push the feature1 branch to the upstream repository.<\/li>\n
- Amy then creates a Pull Request in the upstream Git repository to merge feature1 into main.<\/li>\n
- The Pull Request process may run a build against the code and automatically add the appropriate reviewers. It also supports discussion and interaction about the change.<\/li>\n
- The Pull Request is approved and completed, resulting in Amy\u2019s changes in feature1 being merged into main.<\/li>\n<\/ul>\n
Another developer, Beth, creates the branch feature2 from main using VSCode\u2019s Git client.<\/p>\n
Beth happens to do this a short time after Amy created the feature1 branch, but before<\/em> Amy used a Pull Request to merge her changes back into main.<\/p>\n
- \n
- By the time Beth decides that feature2 is ready to be shared, Amy already merged feature1 back into main via Pull Request.<\/li>\n
- Beth uses the Git client in VSCode to pull down main and see if anything has changed in it recently \u2013 and she finds that there have been changes.<\/li>\n
- Beth merges the main branch into feature2 and discovers that some of the files she changed when generating and committing code with her database tool was also changed in main.<\/li>\n
- This is presented as a conflict by the Git client in VSCode. The Git client asks Amy to resolve it for the feature 2 branch.<\/li>\n
- Amy has three choices for each file: she may decide to keep only her own changes which she made to feature2, take only the \u201cincoming\u201d changes (from main), or accept both and combine them. Amy may additionally make changes to the files involved in the conflict, such as fixing up commas or making other manual edits.<\/li>\n
- After deciding how to merge the changes (let\u2019s say they are compatible changes and she decides to combine them), Amy saves the modified files in VSCode. She then stages (\u201cadds\u201d) them and commits the changes into the feature2 branch. This commit concludes the merge process.<\/li>\n
- At this point, it\u2019s useful for Amy to validate that the merge has resulted in valid SQL and to update her development database with any changes she has accepted. She can do this by opening her database development tool and \u201capply\u201d updates to her development database.<\/li>\n
- When ready to merge changes into main, Amy pushes her commits upstream in the feature1 branch, and follows the same Pull Request workflow described above to merge changes into main.<\/li>\n<\/ul>\n
Q: Can the developers work in a shared database?<\/strong><\/p>\n
In this workflow, developers are working in isolated feature branches and sharing changes by merging. What if each developer doesn\u2019t have their own copy of the database to associate with their feature branch?<\/p>\n
First off, dedicated development databases solve many problems and promote better quality code. Troy Hunt outlines why this is the case in his post, The unnecessary evil of the shared development database from 2011<\/a>. Although this post is a classic, it\u2019s still highly relevant, and the only thing that has changed is that SQL Server Developer Edition is now completely free<\/em> (it was inexpensive at the time the article was written).<\/p>\n
That being said, if you must use a shared development database, you can try to work around the limitations. You may need to take special configuration steps, depending on the tool. For example, if you are using SQL Source Control, you may use a \u201ccustom<\/a>\u201d connection to access a shared database via Git. You may be able to use object locking in your database tool to mitigate the risks of overwriting each other\u2019s work, but you will still see changes in the shared development databases made by other people appear as suggested changes which you could import to version control, which can be very confusing<\/a>.<\/p>\n
Essentially, even if you are sharing a single branch, using a distributed version control system such as Git \u2013 where developers each maintain their own<\/em> local copy of the repo and do not all push and pull to the repo simultaneously \u2013 makes using a shared database environment for development awkward.<\/p>\n
Whether or not you are using shared or dedicated databases, it is worth your while to get into the practice of using individual feature branches and a Pull Request workflow because of the following benefits.<\/p>\n
Building good practices<\/h2>\n
There are five major things which I really like about this workflow:<\/p>\n
1. Team members may share changes safely and easily <\/strong>– Imagine that Amy and Beth do the same changes as above at the same times, but they are both working in the main branch. If either Amy or Beth attempts to push new commits to the main branch and it has been updated since they last pushed, they will get an error that the origin has changed and they cannot push.<\/p>\n
What if Amy or Beth is working on an experimental change that they\u2019d like to get feedback on from a team member, without having to integrate other changes? There isn\u2019t a good way to do that when they are sharing the branch.<\/p>\n
2. You may push changes upstream regularly without fear <\/strong>\u2013 It\u2019s convenient to work in a distributed VCS like Git because you can work in a disconnected fashion when you need to. If you\u2019re using a hosted Git repo like Azure DevOps Services or GitHub and your internet connection fails, no problem! You can still commit locally. However, I think it\u2019s also a good practice to back up your changes by regularly pushing them upstream to the repo. If you have a hardware failure locally or accidentally delete the wrong folder, no worries, you haven\u2019t lost work. Working in a private topic branch means you can push your branch up to the upstream repo anytime without worry about needing to handle a conflict.<\/p>\n
3. It makes merging purposeful and frequent <\/strong>\u2013 In the scenario where Amy and Beth are both working simultaneously on a shared branch, if one of them pushes a commit, the other will need to merge the changes the next time they pull. This may be done automatically by a Git client if there is no conflict, but if they are working on any of the same files, when pulling they will need to pause to go resolve the conflict. Because this occurs only sometimes on a pull, this feels like a distraction and a break in flow.<\/p>\n
To contrast, if Amy and Beth have the habit of working in their own feature branches, they can develop a habit of periodically comparing their branch with mainline branches at the origin, and deciding when they want to merge in changes from those branches. This tends to make merges happen at a point when the developer is ready to consider the merge\u2014not when they might be thinking about solving another problem.<\/p>\n
3. It allows frequent commits <\/strong>\u2013 Many times when people begin working in a shared branch in Git, it isn\u2019t just any<\/em> branch \u2013 it\u2019s a mainline branch. In other words, it\u2019s a branch that regularly (and perhaps automatically) deploys code to an environment. Doing your early development work in a shared mainline branch like this has some bad effects: it means you are either less likely to experiment, or you are less likely to commit your changes regularly. After all, what if you commit something that is an experiment which you don\u2019t want to get deployed? Well, you\u2019re going to have to undo those commits \u2013 that\u2019s not hard, but do you want a commit history full of doing things and then undoing them? Getting into the habit of working in feature branches gives you much more freedom: you can commit and undo commits knowing that at the time you get to a Pull Request, you\u2019ll have some options on squashing your commit history easily when you merge in. Or, if you prefer not to squash commit history, you can always create a temporary feature branch from your existing feature branch to play around with some changes before you decide what you want to do.<\/p>\n
5. It encourages early change review and communication <\/strong>\u2013 So far, I\u2019ve mainly talked about using Pull Requests as the way in which you merge changes from one branch into another. This is only a small bit of the value PRs give you. PRs often function as a major point of communication and review. Most hosted Git options even allow you to do things like automatically add reviewers and require a specific number of reviewers for a PR to be approved. When a PR is opened, you may also have it automatically run a build and test the code, potentially even deploying it to an environment for the reviewers to examine. In short, PR workflows promote communication and review early in code development. The workflow can be a strong foundation for ensuring you have quality code.<\/p>\n
Q: What if I forget to use a feature branch?<\/strong><\/p>\n
If you want everyone to use a PR workflow, you may choose to protect some branches. Many hosted Git providers allow ways to do this: you can configure protected branches in GitHub<\/a>, create a branch policy in Azure DevOps,<\/a> or set Branch Permissions in BitBucket<\/a>, for example. The protections or policies are generally enforced upstream at the origin. If you commit changes locally to a protected branch and attempt to push them, this will result in an error that you\u2019re not allowed to change the upstream branch directly. In this case, you can usually create another branch locally off your updated main branch and proceed from there. If you have some work in progress that you aren\u2019t ready to commit, you may want to stash it<\/a>.<\/p>\n
A detailed video example \u2013 \u201cSQL Source Control and VSCode: Handling Git Conflicts\u201d<\/h2>\n
In this video<\/a>, I\u2019m using a dedicated development database model with the following setup:<\/p>\n
- \n
- Azure DevOps Services<\/a> Organization and Project \u2013 this hosts the upstream Git Repo.\n
- \n
- The upstream repo is used to push and pull changes for Git clients doing the work. The upstream Git Repo is also where Pull Requests are created, reviewed, approved, and completed.<\/li>\n
- I have cloned two copies of the same Git repo to my local workstation so that I can simulate working as two people, each in their own local repo.<\/li>\n<\/ul>\n<\/li>\n
- SQL Source Control<\/a> \u2013 this compares the SQL Server database to the code in the Git Repo.\n
- \n
- It identifies when there are changes in the development database to commit to<\/em> the repo, automatically scripts changes to commit to the repo, and helps keep the development database in sync when new changes come from<\/em> the Git repo.<\/li>\n
- I\u2019ve already created a SQL Source Control project and committed it to the repo. Both of my local copies of the repo begin with having pulled down copies of the project.<\/li>\n<\/ul>\n<\/li>\n
- VSCode and Azure Data Studio \u2013 These free tools from Microsoft share the same free Git client. In this example I use these tools to manage my merge conflicts.\n
- \n
- I\u2019m using VSCode to represent one user and Azure Data Studio to represent the other, simply because I can set different color schemes in them and it makes it easier for me to track.<\/li>\n
- I have the free GitLens extension<\/a> installed in both VSCode and Azure Data Studio. This extension makes it easy to see details of commit history and has many more useful options. This is totally optional, simply nice to have in my experience.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
A list of chapters is below if you\u2019d like an overview, or if you\u2019d like to jump to specific sections.<\/p>\n
Chapters in the video:<\/p>\n
- \n
- 00:00<\/a> Overview of the demo setup<\/li>\n
- 02:07<\/a> Demo begins of a merge conflict when working in the same branch as your teammates<\/li>\n
- 03:17<\/a> Why conflicts occur as interrupts if we work in the same branch in Git<\/li>\n
- 04:35<\/a> Interpreting Git conflict messages in SQL Source Control<\/li>\n
- 05:58<\/a> Resolving a merge conflict within your current branch<\/li>\n
- 08:37<\/a> Why working in private feature branches is a common practice for Git users<\/li>\n
- 10:42<\/a> Traveling back in time with the GitLens extension<\/li>\n
- 12:07<\/a> Resetting SQL Source Control after resetting in Git<\/li>\n
- 14:30<\/a> Demo begins of working in a feature branch in SQL Source Control, and proactively merging from main when we’re ready<\/li>\n
- 15:17<\/a> Checking out a new branch in VSCode<\/li>\n
- 18:18<\/a> Merge changes from the upstream main branch into our feature branch. I have enabled VSCode to regularly fetch changes, so I haven’t manually ‘fetched’.<\/li>\n
- 20:38<\/a> Resolving the conflict in VSCode<\/li>\n
- 23:40<\/a> Staging and committing to complete the merge<\/li>\n
- 25:05<\/a> Applying changes we made in VSCode to our dev database in SQL Source Control<\/li>\n
- 26:06<\/a> Pushing our changes to the central Git repo and creating a Pull Request<\/li>\n
- 29:00<\/a> Approving and completing the Pull Request<\/li>\n<\/ul>\n
Branching and merging in Git is not as hard as it may seem at first glance!<\/h2>\n
If you are new to Git, this can seem daunting to learn.<\/p>\n
While Git can be quite complex, I have found that hands-on experience with Git and practicing in a test project got me a long<\/em> way, and it happened faster than I expected. The branching workflows described in this article have also made my work in Git flow easier, which has made it less frustrating and more fun.<\/p>\n
I hope this pattern proves useful to your team as well.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Feature branching and pull requests are two important concepts when using Git. In this article, Kendra Little explains these patterns and even provides a video to demonstrate.…<\/p>\n","protected":false},"author":321187,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143516,53],"tags":[124952],"coauthors":[61458],"class_list":["post-89209","post","type-post","status-publish","format-standard","hentry","category-database-devops","category-featured","tag-redgate-deploy"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/89209","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/321187"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=89209"}],"version-history":[{"count":3,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/89209\/revisions"}],"predecessor-version":[{"id":89239,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/89209\/revisions\/89239"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=89209"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=89209"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=89209"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=89209"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- 02:07<\/a> Demo begins of a merge conflict when working in the same branch as your teammates<\/li>\n
- 00:00<\/a> Overview of the demo setup<\/li>\n
- It identifies when there are changes in the development database to commit to<\/em> the repo, automatically scripts changes to commit to the repo, and helps keep the development database in sync when new changes come from<\/em> the Git repo.<\/li>\n
- Azure DevOps Services<\/a> Organization and Project \u2013 this hosts the upstream Git Repo.\n