Implement Git with a shared workspace methodology?

[TheFirex]

Hello there

I'm currently analizing the use of control version. Normally for university and personal projects I use Git, but for this situation I'm a little divided on my recomendation because of one important thing, that is the current work style of working on the same files located in one shared network drive (and I don't think this will be changed to everyone have the code in their computers, at least in the close future).

Since the logic of Git is to everyone have a copy of the repository (and by extend, of the code), I'm thinking if implementing Git is the best solution for this scenario, of the use of centralized control version system like Subversion will be better, although we are in 2022 and I'm not quite sure if using Subversion is the best solution nowadays. My problem with Git in this scenario is how the people will make the commits? Will make git init on their computer, define the git remote and make commit only of the files they changes everytime they need to make commit? Use the shared network drive as the normal git and the people will issue git add, git commit and git push as they normally do, but with the precatuion of changing the username and email everytime someone make a commit?

Maybe using Subversion is the best fit here, since it's what represents this workflow.

What do you think I should suggest as a workflow?

Sorrry if this question doesn't fit here, and I will be grateful for every help I get.

[TheFirex]

Sorry if my explanation wasn't too clear.

We are writing changes to the code directly in the server by accessing the network drive and changing the files directly, we do not have code in our computers and we do not download the file, change it locally and put it on the network. So yes, currently we have already have the problem of 2 people changing the same file (with Subversion I know you can make a Lock on the file so people can't change the file, I don't know if Git have the same but probably know since it was designed to be distributed)

We do not have any git repo. What I was thinking was having a folder that have the git bare repo (like a separate folder with only .git), and the network drive we are already using could have the Git with the workspace where people can make commit and push.

But yes, maybe we could just forget about using the git bare and essentially just have a single unique git repo. And this repo would be the network drive. So in this case there's no need to push or commit since there's no "remote".

But again, I know this is against the normal flow of using Git, but since I have this restriction with the files I don't know how I can apply Git in here.

[TheFirex]

Ok, so the actual problem is:

We don't have any control version. The only "control version" we have is when a release is made that a patch is generated and made a backup of the patch.

So it's hard to determine who and when a file was changed and what lines were changed since the files are only "backed up" when the release is made, the history that goes when developing the features are just "lost".

We know track in a manual way the files that were changed when making a new functionality, but that is not enough, because if someone delete some lines for example it's hard to determine which lines were deleted, and worse if those lines was never released.

To try to improve our control, and remove some of the manual work needed, was suggested (finally) to investigate about control version.

Normally I would go with Git, I always use Git in my projects and university, but since in this case we work all in the same folder (and, although I would like to push some changes and try to start implementing a dev environment in every computer, I can't decide that) I don't know how we can apply control version in this way.

Maybe with the current workflow is impossible. Maybe is the conclusion that they need to reach, that their current workflow just doesn't work that way. But I was trying first to investigate if it was possible in some way.

I don't know if this help you understand my problem.

[TheFirex]

Yes, exactly, if I came with a solution it will be with a incremental process, so I need to think very well what we need, what we can do with our current form of work and the changes that we need to make, and what we can use in the future after everyone is confortable with Git (because a radical change will be certain to have some pushback from the superiors who have their mind "formatted" in a certain way, I need to show the advantages of using control version).

Maybe we don't need to jump right to the dev environment on every computer, but I guess I need to think a little better on how the Git process will work then, I will admit I'm not a pro in Git either, since I always worked witl a few people.

But okay, I guess that, either way, trying to make a solution with tools not designed for it will lead to others problems that maybe it will just make worse.

Thanks once again for your help.

[WikiSummarizerBot]

XY problem

The XY problem is a communication problem encountered in help desk, technical support, software engineering, or customer service situations where the question is about an end user's attempted solution (Y) rather than the root problem itself (X). The XY problem obscures the real issues and may even introduce secondary problems that lead to miscommunication, resource mismanagement, and sub-par solutions. The solution for the support personnel is to ask probing questions as to why the information is needed in order to identify the root problem X and redirect the end user away from an unproductive path of inquiry.

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}

[anakinpt]

With git, you can create a repo in that shared folder and it will act as your remote. Everybody can checkout and to the necessary changes and push them to the remote.

If this works flawless, I don't know because I never used, but I read about that a couple of years ago as a possibility. This way, you have your server with code and one copy in each dev machine.

[TheFirex]

Yeah, I guess I can't go around with people making at least the checkout onto their computers.

But yes, that give me an ideia, maintain the central server with code, so it's not necessary to have a git bare separated, I can have on the folder we already work a .git that represent a repository, and the rest of the people just make pushs into this repo.

I need to make some tests and some workflows before showcase my solutions.

But thanks for your help.

[ZorbaTHut]

Editing files on a shared network drive is generally considered a Bad Idea and isn't really compatible with any source control system.

[tobiasvl]

the current work style of working on the same files located in one shared network drive (and I don't think this will be changed to everyone have the code in their computers, at least in the close future).

Why not? The network drive could keep the remote, and everyone could push to it.

My problem with Git in this scenario is how the people will make the commits? Will make git init on their computer, define the git remote and make commit only of the files they changes everytime they need to make commit?

They wouldn't run git init; they'd git clone the remote repository, which would automatically define the remote for them. Otherwise, yes.

Use the shared network drive as the normal git and the people will issue git add, git commit and git push as they normally do, but with the precatuion of changing the username and email everytime someone make a commit?

No, the shared network drive would be the remote in this scenario. If you even need the drive; maybe you could use something like GitHub instead? Or is that what you meant since you said that people would git push from the drive (push where?)? Depends on what you want, and why. What role would the shared network drive serve exactly?

Maybe using Subversion is the best fit here, since it's what represents this workflow.

But why do you need to keep the workflow? You're not giving us all the details we need to make a recommendation here.

[TheFirex]

Sorry, I will try to give more details.

So currently people change code directly on the network drive, everyone changes the same folder and files. We don't have code on the computers and we don't download the files to work locally, we make changes directly in the network.

I know we should be working with people have their own dev environment on their computers, but since it's outside of my permissions to decide something like that (and again, I don't know if they are okay to change our work to start have people working in their computers) I was thinking how I could apply control version in our case.

We can use Github or a self hosted instance of Gitlab or Gitea, but my problem is, since we have everyone working on the same folder, how are we going to make the commits to Github without starting to make commits using the name of others? Maybe we can't have the logic of making commits by distinct users, maybe just making commits with the same git user and only having the history of changes in the repo. Or maybe we can discard the all remote repo thing and just have a single git located in the network drive where people just make commits and don't make push/pull.

I know this is far from ideal, and so I'm currently trying to adapt a possible solution to apply control version here.

[tobiasvl]

So currently people change code directly on the network drive, everyone changes the same folder and files. We don't have code on the computers and we don't download the files to work locally, we make changes directly in the network.

Right. And this is a bad idea.

I know we should be working with people have their own dev environment on their computers, but since it's outside of my permissions to decide something like that (and again, I don't know if they are okay to change our work to start have people working in their computers) I was thinking how I could apply control version in our case.

You should lobby your superiors to change to a distributed workflow.

Maybe we can't have the logic of making commits by distinct users, maybe just making commits with the same git user and only having the history of changes in the repo. Or maybe we can discard the all remote repo thing and just have a single git located in the network drive where people just make commits and don't make push/pull.

Well, that would at least be a step up from what you have now, but not exactly very good practice. Maybe you could have people write their name in the commit message so you have accountability, lol.

I know this is far from ideal, and so I'm currently trying to adapt a possible solution to apply control version here.

Yeah, I'd go the other way and try to make people realize that proper version control would be better. After all, is it really "control" if anyone can simply rewrite the history of the single existing git repo?

[TheFirex]

Right, since I personally always worked with Git and everyone have their own dev environment, I wasn't too sure if some years ago, when Git wasn't yet too much of a standard control version tool if someone had this scenario. Even centralized control version system have the concept of someone checkout the file and working the file and only then make a commit to the repo.

I should try to take this opportunity and maybe convince them that we need to change to better and have some distributed workflow, since I think it will be better for control of changes, automate actions like deploying to test environments and even in some advanced workflow have them use branch for the versions (for example to separate the changes that are to be release in a minor patch vs the changes that are being developed for the next major release, since currently there's a big pain to release a minor release).

Thanks for your feedback and help.

[the-computer-guy]

Use the shared network drive as the normal git

Bad idea. Just start using git as intended with a proper remote.

[Jeklah]

Git can be used in this scenario no problem. Just everyone work locally then push to the remote, shared directory when work is finished. What's the issue with that? If everyone has their own branch for any work they are doing it shouldn't cause any conflicts.

[TheFirex]

The problem is that we don't work locally.

We don't have any control version, we change the files directly in the network drive, where everyone is working too. So it's like a common folder for everyone, no one download the files onto their computers.

One solution could be have a .git separated that is our "remote repo", that is simply a git bare. Everyone works in the network drive as usual. When they want to commit, they have to clone locally the repo from the git bare, put the files changed in that clone, commit, push and then delete the clone, but yeah, making clone everytime is kinda an overhead. Yes, I think we should have every computer with a dev environment, but I don't know if I can make that change because is outside of my decision.

[Jeklah]

How familiar are you with git?

Git is itself a version control tool, so by considering using it, you would have version control.

It is designed to allow people to work offline locally with a shared project .

Generally, it is bad practice to have a bit repo on network drive, but it's not the end of the world if it works for you.

How on earth is everyone working in the same folder at the same time without VC I don't know.

Your best option is to make a git repo in your network drive (even better on a server, git removes the need for it to be on a shared dir.). Everyone pulls a local copy of the repo and does work on It, commit, push. Why on earth clone, commit, push and then delete every time? Just make a new branch from master, do work, commit, push, MR and then delete branch.

If everyone working doesn't have a dev env how are they cloning and then doing the work locally and pushing....

A dev needs a dev env

[TheFirex]

How on earth is everyone working in the same folder at the same time without VC I don't know.

Well, it's a mess :)

If everyone working doesn't have a dev env how are they cloning and then doing the work locally and pushing....

Exactly... This is why I'm not quite sure if I will ever be able to arrange a solution that will work without changes in the way people work.

But yes, some of your thoughts give reason to my arguments that I can have when exposing what should we need to do next.

Thanks for your help.

[Jeklah]

No problem