having the right GIT (or whatever) for when i clone repos from devops
-
Hi, i'm getting set up to begin using dev ops for source control over lots of dev types of objects including ssis, db objects etc etc.
My understanding is that if i want to use that familiar gui experience where after you clone a repo and want to just click (instead of issuing git commands in the various command window alternatives) to check out from the hierarchy that shows below your solution in vs, check in, roll back, "merge" (not the way .net guys do but more like in a different branch like prod) etc etc, git has to be sitting behind the scenes for vs 2022's gui to use to accomplish that.
i get a bit confused when folks talk about git repositories because i also thought a dev ops repo can (but doesnty have to be) be a git flavor repository. My recollection of git is that its biggest selling point is "distributed" coverage. Honestly, its a bit much.
anyway while we see git this and git that in vs's various dropdowns we dont think git is installed on the pc im building. we looked in program directories on c: etc. i just finished adding a couple of addins to vs including ssis and ssas.
Can the community dumb this down for me and tell me if i need to install "git" based on where im going? and where/how i should get it from? when i go to manage extensions i see tons of things showing related to git. and its one of those never ending lists that when you get to the bottom, it grows further. I dont want to be an expert, i just want to be ready for managing source control with versions and at least 2 branches, dev and prod. we may consider ci/cd , tapping into tasks etc later but right now we just want to see versioning in action.
-
A lot to unpack there, but to summarize git is included with VS, but there is no server associated with it. So all the git stuff would be local which defeats the purpose of git, or source control in general.
I would strongly recommend you get a git server set up (there are free ones), so get that that up as a first step. Then load up visual studio and do a very simple project and connect it to git and do some test pushes, pulls, branches, etc.
If you DON'T have a git server of some type, all the code version control is local. The whole point of a modern CVS (content versioning system) is to have it centralized. You push the code to the server and the client machines pull from there so you are all working off the same base (main branch) but on your own specific bits (branches or forks). The big selling point is that it is "centralized", not "distributed". You CAN make it distributed and have multiple git servers, but for starting up a git project, start small - set up a proof of concept with plans to expand it. Get a VM set up to host a git server and push a few things to it so you can make your own documentation on how you want to use it for your team.
The above advice is assuming you want to use git, which I recommend, but there are other options out there.
As for a GUI, there are GUI's outside of VS, and those are what I use. Nothing against the VS one, but I find sometimes when you bundle too many things into a tool, it makes it get bogged down and can cause performance issues if you lose access to the server. I like my tools to be specific to the task at hand, so I like the command line as well as git gui's like SourceTree. Plus, then I can toss non-Visual Studio stuff into my git server like scripts I have written or documentation related to the project that I generally don't include in my VS solutions.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
Install - https://git-scm.com/
This provides the Git system on your machine. Not to nitpick Brian, but each machine is really a server and you interact with it using a GUI or the CLI. VS works and has integration to connect to Git, but MS and others can't install Git as it's a separate program.
It's always nice to have backups, so installing git on a machine to use as a server, or using GitHub, Azure DevOps, etc. as a server, is a good idea. You can use any other machine on your network, but its' easy to use a service.
When I work with clients, git is just a place in the file system we store things. We have a couple of extra "save" commands (add, commit, push, pull) to replicate our file system to another place. That's most of it.
Here's an article I wrote to try and make this easier: https://www.sqlservercentral.com/articles/getting-your-dba-teams-scripts-into-git
-
I learned Git by working with it. There is a lot going on & I can sympathise if you're feeling overwhelmed.
Jump in and try the following
- Create a 'Database' repo on the server
- Clone that repo to your local machine
- Add a database solution to the repo (locally)
- Check in your changes (locally)
- Push the changes to the remote repo
- Ask a colleague to clone the repo … they should see the DB project you just checked in (and can also change it locally)
Those are the basics. You'll need to get to grips with branches and pull requests next, so that you can collaborate on changes with multiple users.
-
Here is an illustration of the basic commands, from here you can learn what each means. You probably will only need to use a few.
----------------------------------------------------
-
Just to add to what MMartin1 said, branches are good to learn early on so you can try to avoid merge conflicts or code overwriting. Multiple people working on the same branch (main) can cause a conflict or lost code. Branching helps ensure that the correct code hits the main branch.
Plus, in the event of a disaster recovery situation, knowing that "main" is identical to "prod" means you can check out the main branch and push it to prod and have no in-test or in-development code hitting production.
Git feels like a LOT when you first start out, but find a GUI you like (or command line if you prefer) and try things out. Create test projects and push, pull, branch, commit, merge and you will have the basics. Rebase is something that took me a while to actually need to use, but it is also a very useful one to know.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply