TL/DR: We don't need everything Git does, and transitioning to Git is going to add more steps to our job. How can we ease the pain?

I'm involved with a small team that has been using SFTP to put code and configuration files onto a side-project server.

• A newer member of the team said, "Hey! Why don't we use Git to track the contents of the CUSTOM_CODE folder on this server, and keep a copy of that repository with a reliable cloud provider? We'd have good backup, change logs, and we'd have a better idea of who changed what, why, when."
• The response was basically, "Okay, sounds good. Set it up and teach us how when you're ready."

The other day, he announced that he's all ready to go with a 3rd-party cloud repository that we should treat as the "source of truth," that he has set up with continuous integration so that if we change something in our 3rd-party repository, it will overwrite the contents of the CUSTOM_CODE folder on our server.

Therefore, rather than SFTPing into the server and uploading files to it, we'll want to use standard Git procedures to throw our code into the 3rd-party repository (and then, apparently, just wait for the CI system to pass our changes over to the server).

Now, the files in CUSTOM_CODE aren't really part "software running on" the server in the way that, say, the code responsible for keeping dev.to online is "running on" a web server.

• They're mostly-unrelated-to-each-other scripts, scheduled through a task scheduler, to clean up data, move it around, etc.
• Typically, a file in CUSTOM_CODE:
  • is its own self-contained world of business logic,
  • is only edited once every 3 months - 10 years,
  • when it is edited, takes about 5 minutes - 2 hours to edit,
  • often takes more like 1 minute, because someone without server access made a 1-line edit to a copy of the script they'd kept all along on their hard drive and now just wants a "gatekeeper" to update the server with the latest version of the file containing the script.

In other words, a lot of the "distributed development" and "merging" problems that Git is so great at solving aren't problems we currently face, or expect to face in the near future.

(There's a different team where I work that develops traditional web apps ... I'm sure their workflow is quite different. I feel like I've seen them share responsibilities editing a tightly-coupled set of files for months on end, rather than "for 5 minutes - 2 hours.")

I asked my colleague who set up the 3rd-party remote and the CI, "Okay, so instead of just logging into the server and dropping a file into its filesystem, we'll do the following?"

1. Make sure we have a fresh copy of the "official" codebase on our computer in a repository that's a "local" for the 3rd-party "remote"
2. Edit the file on our local computer (either according to our own preferences or as specified by someone asking us to "gatekeep" their script updates)
3. Use various "Git" commands to get our "new & improved" copy of the file's contents over to the 3rd-party "remote" along with our commit notes, doing "merges" to fix any issues that came up from our own failure to plan in "step 1" (or, extremely unlikely given the low frequency of file updates, a colleague working simultaneously to us)
4. Wait for the CI to put the file on the server
5. Be patient and resist the temptation to just SFTP into the server and drop the file there

He basically confirmed "yes," and added, "The CI will overwrite anything the 3rd-party remote doesn't know about that you SFTPed onto the server, if that helps w/ #5."

That said, he said he's relatively new to Git himself, so he didn't have a lot of opinions about best practices.

• For example, I said, "Do you think we might want to share git fetch --all + git reset --hard origin/master with the team as a "before beginning to edit code" best practice?
• He answered, "Why not just merge if there's a problem?"
• I replied, "I dunno. Because I've never merged before and it sounded harder, given the way we typically work with files. It kind of feels like the way I occasionally use my computer to edit my blog files on GitHub. I don't really care what's on my computer; I just care what's on GitHub. But I have no idea what merging is like. It just sounded like work."

It seems neither of us have enough experience with Git to have any strong opinions -- just things we have / haven't yet tried.

So ... Dev community ...

Any "war stories" & "best practices" from collaboratively editing filestores like ours through Git?

It feels like there is a lot of potential for frustration compared to the old "SFTP, drag, drop, exit" system.

Tips to help old dogs learn new tricks, so that the whole team will enjoy the transition and feel productive, would be much appreciated!