I am managing a Github repository where I have around 20 developers working, pulling/pushing changes, modifying classes and files, etc. he developers in the project are using two IDEs: IntelliJ IDEA and VS Code, where we are using as main programming languages Java and Vue.js.
I'm working with Github for a while already, but previously I've worked with TFS (Team Foundation Server), and here I had the option of locking a file or class for being edited while I was working on it, not allowing other users to edit my file until I finish with my changes and unlock the file for other developers. In our Github repos we already implemented some branching strategies for pulls/pushes following an approach based on this link
Now, using Github, as it is distributed, I know that you save a local copy of the repo and its history, which is a big difference comparing it with TFS, which is centralized.
Being honest, this thing about locking a file while it is being edited, and unlocking it when the developer completes the changes was quite useful, and I don't know if there are way to mimic this behaviour when using Github. By this way, I could prevent developers removing code from other people during merging processes when pulling / pushing changes.
Is it possible to lock/unlock files while being edited in Github. Is there a tool or an option that could help me to prevent those scenarios? If not, are around there some best practices that maybe I'm missing to prevent these overwriting issues I might have with Github, and that I didn't have with TFS? I guess that as the developer has a local copy of the repo, is quite difficult, or even impossible, to lock/unlock files as in TFS, but maybe there is something around there that can help developers to not kill others' codes.
This feature exists in Git-LFS. See https://github.com/git-lfs/git-lfs/wiki/File-Locking
You set files or type of files as lockable and they are in readonly until you lock it to be able to edit them.
GitLfs is a paid option in GitHub but I don't know if GitHub provide the feature of git-lfs.
Normally this 'lock' feature should be kept for non-mergeable binary files.
Locking files also has downside which could be worst than having to deal with file conflicts like someone locking a file during a long time or holidays, ... that imply communication and synchronization. It introduce also some slow down on development where most of the times there is no problem of merging.
For source code files, I think you should not set file as lockable and accept that there will be conflicts and you will have to solve them. That's the kind of problem that normally are solved or prevented as much as possible with some communication and synchronization.