Right now, I use KDiff3 to merge our QA branch and personal branches to fix conflict resolution, but a feature within SQL Source Control would make things a lot simpler. I think I spent an hour fixing that yesterday, and I still have to go back and deal with it on one of my team mate’s machines. The developers don’t always remember to bring down the latest version and when they check something in, it causes a conflict. What about conflict resolution?Ĭonflict resolution would be another great feature because sometimes it’s difficult. Team keep forgetting to pull down changes that exist on the repository so this would be a real bonus. The pull button is the more important one, to make sure you’re on the right version. A number on the buttons would work as well, to show how many items have been checked in locally and are ready to go up or come down. Near the ‘Push’ and ‘Pull’ buttons, it would be nice to know if there are files to pull or push, in case other stuff has been checked in from other users. Right now I can see which database I’m on, but not which branch How many changes are ready to push or pull? Top of the list would be to see which branch I’m on. So it has made my life easier, but do you know something? There are still some improvements I’d like to see. A glance at what it looks like in SSMS demonstrates how simple it is: As well as saving time, it makes it easier for less technical staff who are new to using repositories. They can commit changes, get the latest changes, and do everything they need to do without complications. I use SQL Source Control every single day and I’ve now got my entire team checking in their changes using Git. It also made things a lot clearer to team members who were new to using version control by taking the complexity out of the process. No more closing this, opening that, moving this, quitting that, going back to the application you were happily working with before. I was thrilled because this one apparently small move eliminated an entire step in another application. That was when Redgate announced SQL Source Control users could now push to and pull from remote Git repositories.Īnd not just from within SQL Source Control – from within SQL Server Management Studio (SSMS).
The tweetĪt the beginning of October 2015, everything changed.
#REDGATE SQL PROMPT AZURE FREE#
A free Git client, it provides a visual GUI to do the push and the pull between the server, Git, and the local repository. I tried a workaround using command prompts, but it was so painful and cumbersome I turned to Atlassian SourceTree instead. That’s where I had a difficulty because there was a gap between SQL Source Control and the Stash repository on the server. Like many other people, I moved from Subversion to Git because its branching features are so much better, and adopted Atlassian Stash (now called Bitbucket Server) as the repository. The missing linkĪs much as I love SQL Source Control, a niggle I’ve had has been its limited support for Git. Using SQL Source Control, you can do it quickly and easily. You might think, for example, oh yeah, I was working on indexing and I should probably get those indexes into production. It’s especially useful if you’re working on multiple projects and one project is sitting there for three weeks and you come back and look at the changes. SQL Source Control makes it a really easy process and defines all of your changes. You have to actually bring in the changes and then see what your changes are. At one point in one company, we used the Visual Studio version, and that’s painful as well because you don’t get the immediate gratification of knowing what’s changed. Before it came along, we scripted out database objects, which is a pain. I fell in love with SQL Source Control the first time I used it in another company. When I heard that Redgate had improved the Git support in SQL Source Control, I have to confess I got excited about it.
0 kommentar(er)
