0

I am looking to set up git with file trackble and File locked when one user checks out. I want other users should not be able to checkout when on user is using a particular branch for work for a particular file in the branch for work and the rest of the users should be alerted that the file is locked and needs the other user to unlock prior check out . IS this scenario possible ?

Becky Mannie
  • 1
  • 3
    This is exactly the kind of workflow Git was designed to avoid. You can't lock files in Git, and you never have to, that's one of the main selling points of a distributed version control system. It's not clear why you think locking a file is necessary, but it's certainly not if you're correctly using Git. – user229044 Feb 22 '19 at 02:43
  • You should try to avoid and have a very good reason to do that (like binary file or not mergeable files) but 'git lfs' could help you achieve something approaching: https://github.com/git-lfs/git-lfs/wiki/File-Locking – Philippe Feb 22 '19 at 09:10

1 Answers1

0

No locking is possible.... Not 'at the git level'. Why would you want to lock, anyway? To avoid conflicts? Conflicts are part of a developer's life.

Let me elaborate a little bit: you have to realize that when you are working with git you work on your own repo. That would be a repo that comes with everything but the kitchen sink so, when checking out a branch (even a remote branch), it's a local operation that no other developer knows about. If you reeeeally need this kind of support you should consider using a centralized VCS so that you can have that kind of control.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • Conflicts costs us double work more then developing and its absolute mess , we have processed to avoid , however dev team wants a better system to lock branches while one is developing – Becky Mannie Mar 11 '19 at 00:03
  • @BeckyMannie I'm wondering why you would spend so much time dealing with conflicts... I mean, as I said before, conflict are part of a developer's life.... but you shouldn't be spending so much time working on conflicts. There are some special cases that can be relatively easily dealt with: - Developers are reformatting code _just because_? This is a major deal breaker. - Developers are working without realizing that _other_ developers are also working on the same piece of code? Sometimes a little bit of coordination (off VCS) can help with that.... There's another big one on my next message – eftshift0 Mar 13 '19 at 17:45
  • Are there major refactors going on at the same time that other developers are working on the same piece of code? Major refactors (refucktors, as they are called) are a tricky subject. Should you avoid them? Sure not.... if you need to do a major refactor, do it. But it will create major headaches for people working on the same piece of code. You _should_ make sure that whenever there's a major refactor going on, there should be as little noise as possible from other branches on the same piece of code. Here coordination is key. – eftshift0 Mar 13 '19 at 17:47