Can I commit directly to a remote Git repository?

Question

I'm setting up Git on a network drive. Due to the sensitivity of the contents, the code cannot be pushed to a cloud-hosted Git solution like GitHub, etc. Personally, I'll be committing to a local (cloned) repository and then pushing to the network drive, but others in the office may make changes directly to the network drive. Can these changes be committed directly to the remote? What happens if the changes aren't committed at all? How are they handled? Alternatively, would it be better to make the network repository "local," and then just refrain from adding a remote at all?

Answer 1

Git is meant to be a distributed VCS. While it's generally used with a central source of truth (think Github, Gitlab etc.), there's nothing stopping from using it fully distributed, with many people having their own clones and everyone pushing and pulling to/from each other. In this case, every person represents a remote for your local.

If you make a change on network drive and never commit it, then it cannot be pulled to other clones. You have to use rsync or something, but that beats a lot of git's purpose.

Also, any uncommitted changes are always unsafe. ie they can get deleted, reverted very easily, and you'll not be able to recover them.

Moreover, since changes aren't getting committed, you lose out on change history, diffs and a lot of features that make version control great. In other words, if you're not committing, you're not really using version control at all.

Suggestion: Use network drive as a remote (like Github). Everyone clones that to their own local, commit changes and push to this remote network drive. Additionally, back up this network drive to protect against data loss.

If people absolutely have to write directly to network drive, at least make sure they're committing changes. The suggestion for backups still stands.