some moths ago we switched our version control from Team Foundation Server to Git, and since then, our frustration is limitless.
Okay, we started in a wrong way and created one repository on a network drive for the use of all team members. Meanwhile we corrected the configuration to individual, local repositories following a (deprecated) tutorial of John Bowman.
For many years we were familiar with the situation of a central repository which mirrors our database objects 1:1 and we can have a look into the history of any object if necessary. Nothing else. Set and forget.
Now with Git we ran into all the branching and merging mambo & jambo that we do not need and do not want to have. We tried many things with pre- and post-commit hooks that contain pull, push and such stuff to automate the work with Git as far as possible.
But we could generate reproducable scenarios where the automatic pull & push stuff does not work because of some merge conflicts that only appear because of the decentral, individual repositories. We (especially our team leader) do not want to make any manual pull & push & merge mischief, we just want to check in our DB changes without thinking of any conflicts. We have one central database, and this database is the chief, not Git.
So now, we do not know what to do. Is there any possibility to setup the Git configuration in a way so that it acts as a VCS with a central repository, or would it be better to switch to another (which???) VCS?
I would be very happy about any tips and recommendations.
You most certainly can and should use git with a central repository. Our project uses Atlassian Bitbucket for that. Others use GitHub. Without the central repo, you are not really using git optimally. Git will not version database objects directly by, say, connecting with and referencing an Oracle database the way Oracle Designer would in the old days. You might take a look at RedGate for that. I reviewed RedGate for our project but found we could not use it in our environment because of certain conditions we have.
Git works fine for code objects (packages, procedures, functions, and triggers), but it is not very good with such things as tables, views, constraints, etc. What we do is maintain versionable files of create statements for objects that cannot use 'create or replace' syntax, which we keep up to date, and also have alter statement files to deploy changes to databases as these types of objects change over time.
We use git with Bitbucket extensively. Some of it is kind of kludgy, but we make do with it.
we are conscious of the fact that we should use Git with the central repository we that we host at Microsoft Azure DevOps. But we have no idea how we can connect to that repository directly from TOAD, because TOAD only allows file paths for Git repositories, no URLS...
Branching and merging isn't mumbo jumbo, it's pivotal to how modern source control system workflows work.
It sounds to me like you and your team aren't able to embrace the paradigm shift of Git, and are instead stuck using historic practices, whilst trying to emulate an alternate and vastly inferior source control system and workflow to Git, but using Git. Personally I think you are completely missing the point and power of Git.
Git allows concurrent development, many working on the same files if need be - that's a very powerful concept. You don't have to "check out" a file exclusively, like some other VCS and a developer can be doing prototyping (using a branch) which is extremely useful. You can checkout any version of the repo in time and view any file in that repo from that point in time, you can decide what version you work on and why. The developer has the choice what version his schema is built from, or his work is developing from. We use GitExtensions - which is the best free Get Client I've found.
Here's how we do things:
In my company, developers have their own schemas, but we have centralised Test and UAT systems.
All objects are in a separate file, and contain object evolution code in. E.g. If you add a column / index / constraint to the table, there is a block of code which checks if it exists, adds it if not. Same for if the structure changes - with corresponding update section. The full history of the object's evolution is in the file.
We have a Build Script which calls of the object scripts.
When a developer starts on new work, they create a branch off Master and do dev work in that, they run the Build from their point in time. Once their branch is tested, you fetch the latest version of Master and it gets merged in and pushed to origin (centralised repo). Devs sort out their merge conflicts.
Releases are branches off of Master.
Git connects to our local directory, when we push to origin it connect to hosted repo BitBucket.
If you take the time to use Git as intended, in time you'll never look back. Cherry picking, merging and managing versions is a breeze.
We switched to git to manage Toad's source code several years ago. It was completely foreign to me, so looked on LinkedIn Learning for some courses. There are a few courses in there by a guy named Kevin Skoglund. Here's a link to the first one. The courses were very good and extremely helpful. Set a few days aside. Work though his examples with him in the first couple of courses. You won't regret it.
at first - many thanks for your replies. Please let me make some remarks:
@Russ:
How do you connect from TOAD to your repository in Atlassian Bitbucket?
@Paul:
We know about all the benefits that branching, merging etc. offer for modern software development. But they do not fit to the way we develop our database objects which has grown over many years. We never use files, build scripts etc., we have no releases, we have a development and test database and we have a production database in our company. As soon as our changes have been tested, we transfer them to our productive system. There may be better ways to do all these things, but we can't turn all of our structures upside down because of a version control system.
@JohnDorlon:
Setting aside for a few days is a very good idea Our team had a git course some weeks ago, but that just scratched the surface of git. Yes, I will take the time to look into the courses, maybe it will fit into my calendar between christmas and new year's eve.
@jbowman:
In case you read this post... I think you are the VCS expert at Quest... Do you have any tips for us how to setup TOAD and git to work together the best way? Maybe there's an actual version of your tutorial?
Sad to hear that... I think he really had very good knowledges about VCS. But it makes me happy that YOU John are still there, you helped us so many times with tips and bugfixes. In any case I will try the course(s) that you posted.
Have a nice weekend, and I will have a beer for your health tonight
Sorry, Rainer, for the late response. I have been on leave for a while.
No, we do not connect TOAD to git either locally or remotely. We use SourceTree to interface with the BitBucket repo. Some of our devs use TOAD and some SQL Developer to edit database objects and save local copies that we then version with SourceTree in BitBucket. It is kind of kludgy. The industry is crying out for a tool that can do this, and I have been working on a C++ app that will eventually be able to do that.
That app will take me the better part of the next year to develop, but as I have over twenty years experience as an Oracle DBA and remember how Oracle Designer worked before it was discontinued, I think I can pull it off. The whole idea is to capture database objects including those that don't CM well and code an interface between Oracle and git. Then, release scripts could be generated automatically to update a database to a developed baseline with everything being nicely versioned in a git repo. Our industry needs something like this--not another TOAD but something that can aid TOAD developers and DBAs with properly versioning all objects in their databases and not just code.
No problem Russ, we deal with the problem of integrating Git and TOAD for several months now...
For our other non-Oracle-code we use a similar approach, we use TortoiseGit and SmartGit to interface with the Azure DevOps repo. For that, everything is fine.
We also see the problem that not all objects are in the VCS, but we have no capacities to deal with that problem. We would highly welcome a tool that could do that the right way.
For our other objects that we manage with TOAD and git we maybe have to think about our approach. We don't claim to handle all that in the best way, we know about our deficiencies in that point.
When time allows I will participate the cource John posted, and in our team we eill have some discussuions about our approach with git.
Thanks a lot for your explanations, and maybe your upcoming tool could also help us in our daily work.
Thanks, best regards and sorry for my faulty English...
Rainer
Our team had a git course some weeks ago, but that just scratched the surface of git. Yes, I will take the time to look into the courses, maybe it will fit into my calendar between christmas and new year's eve.
