GIT as SCM For .NET Source Code

You need to step back and look at the big picture.

What kind of developments do you do?
How do you manage the development right now?
What tools do you use right now for what purpose?

Cause things I would think about first are:
- agile or classic development
- communications
- requirement management
- test management
- deployment management

In more leet terms: ticket system, collaboration tools (wiki, Teams, Slate, etc), CI/CD, automated unit and integration tests, built and test server, managed dev and test VM's, SCRUM and much more.

The fact that it is a free solution will make my Board Members happy!

Just because you don't need to pay for a license, doesn't make it free. And using this as USP will give you problems, cause managing a team requires time and budget. Not all tools are free, and when they are needed, you need really time to set them up correctly. Here sometimes budget spent for a good consultant setting up things and giving the introductory lessons can be cheaper mid to long term (time saved and bugs avoided).

With regards to your idea of how to setup the local repositories and such.  You are over complicating an already simple solution.

Git would be the sole source of truth where the development team will pull down a repository when they need to make changes.  They will either create a branch or fork (your preference) and make their changes to their local copy.  If you have any unit tests they will, ideally, create or modify the existing tests and then run them in order to ensure any code coverage requirements are met.  Once that is completed, the developer will then submit a pull request to merge their changes back into the branch they pulled their local copy from.  At least two approvals will be needed in order for a pull request to be merged (in your current situation, only one approval will be needed).  I would suggest that they never branch/fork from Master and only submit pull requests to merge their changes into Master when their changes have been successfully deployed and QA tested in a test environment.  The Master branch will represent the ultimate source of truth and will only be used to build deployable assemblies into your production environment.

We have small differences in our development cycle(s) depending upon the capability teams requirements.  All of our repositories that have at least a Master and a Development branch.  When I need to make a change to a repository, I will create a branch off of the Development branch.  I will then make my changes and create/modify any unit/acceptance tests.  I'll run my unit tests locally to gauge the code coverage and ensure that it will pass our quality gate.  I then check our quality gate for any code smells and correct.  I'll then rerun my unit tests to ensure that the corrections didn't adversely affect the code coverage and again check the quality gate for any additional code smells.  Rinse and repeat until the changes pass the muster of the quality gate.  I'll then run the acceptance tests locally to ensure that they will pass when ran in the development environment.  I'll then submit a pull request to have my changes merged into Development.  My code changes are reviewed internally by a senior developer on my team (I am one of the senior developers but you never review your own code changes).  Once approved, I then alert the capability team that the changes are ready for their review.  Some teams require one reviewer, others require two reviewers.  Once approved, the changes are merged and deployed by our CI/CD development pipeline.  I'll monitor the build and deployment.  If successful, I'll alert QA and have them run their tests.  Once everything checks out, I will submit a pull request from the Development branch into the Master branch.  Again a senior developer from my team reviews the PR (really just a formality).  Once approved, I alert the capability team, they review and approve.  Some teams will want you to merge your own PR, others will merge it themselves.  Once merged, I again monitor the build and deployment through the full CI/CD pipeline (development, integration, training and production).  After a successful deploy to all environments, I alert QA and have them run their tests.

-saige-

Hi - thanks for the replies. We were a development team of one here (.NET wise - other developers for legacy), and now we are a team of two. We are a very small team indeed. We have no testing team, we have no QA team. We are it. Everything here is, and always has been very manual. It has never been a problem due to the tiny nature of the team and the fact that we had very distinct responsibilities and rarely, if ever, did our areas overlap. When it came to testing it was again a very manual process. Nothing automated, just unit testing against requirements and then user testing (we are also a small-ish company, which is good given the size of the IT Team!). When it came to deployment it was a case of copy the required files from development to production. Horrible I know, but in 15 years we have not had a serious issue ever with a release, just as we have never had an issue with the software. But that is changing now with the retirement of one of the senior developers (30+ years experience) to be replaced with a graduate (2 months experience). This puts my nervousness into context.

It is clear that I have a lot to learn regarding GIT and SCM. I am trying to address the one glaring issue that is staring me in the face - the management of the Source Code now that we have two people potentially working on the same code. It is clear to me that this is now needed and soon. The new guy is not on live work yet, but he will be soon. I fully appreciate and accept that there are other items that need addressing such as Testing, Integration and Deployment, but I need to address the "urgent" one first.

I obviously got my terminology wrong at the outset! When I talked about "Local Repos" I was meaning local copies taken for the sakes of development, so I meant what you said - just phrased it wrong. What you say is precisely what I am after, a Repos on the server that is the "One Truth", and it is that that will get backed up. The local repos are as you say for development only and then merged back.

I am just trying to get a handle on what needs to go on the server to give me the ability to set up that "One Truth" so that I can go back to our infrastructure management company (we have outsourced that now) and ask them for what is needed - but I don't know that yet. I have spoken to someone who I have been told is knowledgeable in matters GIT, and he has said that what I need on the server is GITea for Windows which I then need to configure with a remote repos. I have had a read of a few articles, and it does seem like this would be a solution, but I want to make sure I am going the right way.

I have answered some of the questions posed by Ste5an - we have manual processes for everything, always have - testing, build, deployment, documentation, everything. Being a tiny team has meant that there have been no issues.

To answer some of the others (ignoring the legacy applications, which will all move to .NET as they are updated). We develop Desktop Winforms Applications and Windows Services. No web, no mobile. We do have applications that run on Scanners and Tablets, but they are all Windows based. Obviously we develop DLL's also that are used by the applications and by their nature DLL's are referenced by multiple applications. So, our development environment is very simple.

When it comes to unit testing and user testing that will stay the same as it is for now. I know that really we need Test Scripts accompanying our developments so that we can have repeatable tests and confirmation of no-break changes, but we are not there. I know that Integration and Deployment management needs to be better, but that too is going to stay the way it is for now. Final approval for release will, now, always lie with myself.

For now the intended use of GIT is purely for version management of the source code and will be a 100% IT internal thing for now. I know that many other things can be managed in GIT, but I am not worrying about that for now - I want protection for the code as the first step.

If the end result is me being told that this is an incorrect use of GIT and that I should be doing all the other stuff as well, then so be it - at least I know. I don't have the time or resource to do all of these things as well as being the Team Leader and the primary developer!!

I know I am probably approaching this all wrong, but my entire environment has completely changed in the space of a few days and it makes me nervous - I am even taking my own manual backups of the development areas twice a day which is crazy!

Steve

Do you need distributed SCM? Then you should use GIT, otherwise give SVN a chance.

It's much simpler too understand and use, also free when you use a *nix server and Tortoise SVN in the file explorer. For VS integrated use, there is VisualSVN for some bucks. All you need to know about SVN is in the free red bean book.
I prefer it for small projects and few team members.

So the first thing to recognize is that git comes in primarily two flavors, cloud and inhouse (or enterprise).  Cloud is nice because you don't have to worry about infrastructure but security becomes your primary concern, you can setup an organization and have it marked as private but then your security centers around dev access because they can have offsite access to your repositories.  Enterprise is nice because you don't have to be as conscientious about security but you do have to worry about infrastructure.  Cost is obviously a determining factor where Cloud is the least expensive of the two and enterprise, clearly is more bang than you probably require at the moment.

Once you have established your organization in GitHub and have retained access to it for at least yourself.  You can interact with GitHub through either CLI (command line interface) or a variety of UI interfaces (GitHub Desktop, SourceTree, etc) many are free, some will require licenses.  GitHub is also directly integrated with Visual Studio as of 2019 v16.4 (you can use an extension for previous versions 2010 and above).

Once you do that it's simple enough to create a repository in Git, go to your organizations dashboard page on GitHub.com and select the New button next to Repositories (there are other locations to do this as well, from the Overview page, from the Repositories page, etc.).  Give it a name, mark it as private and choose any options (add a README [this is akin to a developer documentation page, primarily used to let developers know what they need to do in order to build, deploy, pretty much anything that they may need to know], Add a .gitignore [defines what files/folders are ignored with code commits; e.g. bin, node_modules, user specific files, etc, etc]).  When considering the creating of a repository, normally this represents one project or one solution.  It's like a folder so if you have lets for the sake of argument have a singular folder on your system/server which contains all of the projects/solutions that your company is developing, that folder would represent the organization.  Each individual project/solution under that folder represents it's own repository, if that makes sense.

HTH,

-saige-

Hi Saige,

I think your comments highlight a mismatch between what I ideally "need" to do and what will I "have" to do to satisfy the powers that be!

Everything we do is on-site. All the software (with the sole exception of the Finance Product) is developed in-house, and is bespoke. Always has been for the entire life of the company. The powers that be are very averse to anything being outside the company servers. All our database are internal, the only thing that is outside is the email, and even that was internal until a couple of years ago!

That is why I was after an on-site repos on our server as I have had these battles before and was just saving my self the headaches, but it seems I have them from another quarter now!

If I go to the powers that be and inform them that I want to start storing all our source code off-site under the control of someone else I dread to think what would happen to me!

I really am starting to think that it is time to retire myself!

Steve

Totally understandable.  Just to give you some comfort, the company that I work for is also very security conscious and we used to have GitHub Enterprise but when dealing with almost 500 developers in the company it becomes very, very costly.  So about a year and a half ago, we migrated all of our repositories into GitHub on the cloud and have not looked back since.  We are also in the process of reallocating our CI\CD pipeline from in-house to Azure DevOps (ADO).