80

We are a team of 60+ developers working on the same product and are moving from SVN to Git and GitHub. We have a process in SVN where in individual files are locked and whenever a developer wants to commit code, he needs to get it unlocked by the owner of the file. Three of us are the owners of the total 150+ files. The unlocking is preceded by a code review.

In Github, we are planning to use the Fork-Clone model - each project a group of dev is working on will do a fork, each developer will do a clone of the fork, write the code & commit to origin, the lead of the feature will do a pull request to upstream.

Though this seems fine, the problem is when a big project gets delivered, it brings in lots of changes for review and hence, increases the load for the file owners. Also, this might happen in the later cycles of development and hence the project might be jeopardized.

One method we thought might work is to have hooks when the git push is done to the origin (fork). There can be one final review git pull to upstream.

However, we could not find any github extensions or push hooks for the same. Is there a quick way (read, existing extension) to do this with Github or should we use the same hooks that we would use with git?

jww
  • 97,681
  • 90
  • 411
  • 885
Karthick S
  • 3,204
  • 6
  • 36
  • 52
  • 10
    I don't feel like file locking is something Git is missing (it's mostly annoying in SVN). In most cases, I'm pretty sure pull request and branching are the way to go for you. You could even separate different part of you project in different repo using submodules, and then you have a much cleaner separation (file protection) between team. So the file owner, would just become the main submodules owner, and he revise every pull request made by his team on his main branch. Then every user have it's own fork. – Simon Boudrias Dec 01 '12 at 19:03
  • http://programmers.stackexchange.com/questions/184435/workflow-using-binary-document-formats-in-git-without-locks-moving-from-subver – Steen Jul 03 '15 at 10:32
  • 5
    @SimonBoudrias Your ideas are perfectly non-working if git is used for any document type for which no merge-tool is existing (which is nearly always the case). With TortiseSVN/WebSVN we _can_ avoid MS Exchange, but with git we can't. On my opinion, it is a very unfortunate fallback of the git. – peterh Mar 16 '16 at 09:34
  • [Locking binary files using git version control system](https://stackoverflow.com/q/119444/995714) – phuclv Aug 22 '17 at 03:22
  • 2
    This is not a tech problem; it's a process problem. Why do you need 60 developers to work on 150 files? Seems like the problems starts there. What programming language are you using? Your 150 files should probably be 1500 files that you can then divide into modules. Then split your development "team" (at 60 people, it's not a team, it's a small village) into smaller units of 7-ish people that can actually function as a team and give them ownership of a module. That way you and your 2 colleague gatekeepers won't be the bottleneck anymore and everyone will be happier. And you won't need locks. – Frans Feb 01 '21 at 16:58
  • The rational for this question can be found on this link: [SSIS solution on GIT?](https://stackoverflow.com/questions/28744948/ssis-solution-on-git/28745433#comment124916512_28745433). Sometimes in a mono repo we may need some files to be locked. Locks force explicit communication. – Rajesh Swarnkar Jan 18 '22 at 09:21

8 Answers8

100

No chance, if file is not mergeable and you need to lock it, use a centralized solution instead of GIT, i.e. SVN or ClearCase.

user5694595
  • 1,025
  • 1
  • 7
  • 3
  • 8
    This is the correct answer. Not the one accepted at this time of writing. Upvoted. It doesn't even have to be binary files for locking to be necessary. Take the comment on the iOS storyboards on the other question for instance. – Harindaka Mar 01 '16 at 07:39
  • iOS storyboards? "Other" question? May you please link? – usr-local-ΕΨΗΕΛΩΝ Mar 30 '16 at 09:32
  • I believe @Harindaka means "other answer," not "other question." The comment being referred to is: http://stackoverflow.com/questions/13662255/is-there-a-way-to-lock-individual-files-or-directories-on-fork-when-using-github#comment41679865_14864163 – Billy Jo Apr 05 '16 at 20:31
  • Correct. It should be "Take the comment on the iOS storyboards on the other answer...." – Harindaka Apr 07 '16 at 05:39
  • 2
    A use case we have is a heavily normalized XML file. For instance we have a string table. If anyone modifies a string in the file, the table has to be changed and assuming it is alphabetical, every string reference after it will have to increment by one. All in all a minor change to the diff in the file, but a merge nightmare. Hence we lock. Nonetheless, storage of the differences is done as UTF-8 file differences, which are relatively small compared to storing the whole file. SVN works perfectly for this use case, and a non-locking system will have major problems. – Bill - K5WL Dec 19 '17 at 22:53
  • @Bill That’s surely a poor file format for other reasons...why would you tie a reference to a position in an alphabetized list, rather than giving things more durable IDs? – Marnen Laibow-Koser Jun 15 '18 at 03:36
  • @Marnen, good point. What we did is give them a durable integer ID, but included the ability for the user to provide readable names. The name table is simply normalized following what was considered best practices 20 years ago when it was decided. Perhaps the name table shouldn't have been sorted, but that would have had other consequences. Maybe sort on load or something. – Bill - K5WL Sep 11 '18 at 22:14
  • 1
    Sounds like something that could/should be generated automatically and not committed to the repository. Or we all these changes done manually? – Dan M. Feb 06 '19 at 17:29
46

If you are using git LFS (which is supported by some git hosting providers, like GitHub) you could use File Locking.

Mark a file type as lockable by editing the .gitattributes file:

*.docx lockable
# Make MS Word files lockable

And lock it with:

$ git lfs lock example.docx

You can unlock your files with git lfs unlock example.docx and those of somebody else by adding --force.

Nijin22
  • 850
  • 13
  • 20
6

this is possible. git-lfs 2.0 introduces the ability to lock files: see these links: https://github.com/git-lfs/git-lfs/wiki/File-Locking. Support for this feature is available starting from TFS 2017.2: https://learn.microsoft.com/en-us/vsts/release-notes/.

erradi mourad
  • 259
  • 4
  • 7
4

Not exactly locking, but Github has introduced a concept called "Code Owners". Allows you to restrict part of your codebase to only allow commits after review by the code owners

Michael
  • 22,196
  • 33
  • 132
  • 187
3

Git does not provide any locking functionality, since it is decentralized. However, if you host your code on GitLab Enterprise Edition Premium, you can use the web interface to lock individual files or folders, achieving exactly what you want to do.

If you do not want to host your project on someone else's server (their website), you can also download GitLab and host it on your own webserver.

Rory O'Kane
  • 29,210
  • 11
  • 96
  • 131
Leonardo Torok
  • 55
  • 1
  • 5
    it's not something related to Gitlab ,this is also possible with git lfs. git-lfs 2.0 introduces the ability to lock files: https://github.com/git-lfs/git-lfs/wiki/File-Locking. Support for this feature is available in TFS 2017.2: https://learn.microsoft.com/en-us/vsts/release-notes/. – erradi mourad Apr 23 '19 at 12:40
3

You can use LFS and you could lock individual files, or instead jus add the files to .gitattributes file,

https://github.com/git-lfs/git-lfs/wiki/File-Locking

Camilo Pineda
  • 41
  • 3
0

For reference:

Git is a distributed version control tool, so centralising files to lock them is against its devlopment philosphy, so its not possible.

However, there are ways by which we can achieve the same result.

one is using git-lfs that is used for large file system. But this require you to migrate the git repo, installing git-lfs alters git repo, and uninstalling require you to migrate again to git repo. As stated in its document. This is already explained more clearly in other answers.

Other solution is to use git in some way to achiveve the same result. like using git pull's upload-pack to trigger command on server that will invoke some command(manually written) on server that will handle file locking in some way. and put (pre|post)-recieve hooks to disallow changes if pushed by someone other then who locked it initially. you can also alter git-upload-pack command to trigger warning if some files are locked, at the time ot pull requests, or repo update, if you want, but i don't recomment that, as that will make git update/upgrade difficult. check out this git repo of mine here i achieve the same using git-pull's upload-pack.

For background, in our project we have import/export functionality that generate XMLs on exporting and when there are multiple XML pushes from multiple persons it become extremly difficult to do manual merging XMLs as its structure changes on every export. so even if two XMLs are technically same, but from file's and git's prespective they are always very different files, so we coordinate using chat groups to stop working on one XML when someone is already working. here using git-pull's upload-pack now we coordinate in team just for alerting, and sometime don't and handle locks by this script of mine, so even if someone didn't recieve the alert can still be working without worry.

dinesh saini
  • 431
  • 5
  • 8
-28

This use case is one of the reasons Git is so much better than SVN --> rebase! If you follow good git workflow you rebase from upstream before submitting your Pull Requests. You don't need to worry about file locking and stomping on another person's commits and merge conflicts etc... a rebase sets your work aside, applies the remote commits and then applies your work on top.

I think this just takes a rethinking in your process and relying on the strengths of git versus force fitting a Subversion workflow on top of git. Your "fork-clone" model might need another look as well. Most often every developer has their own fork, you can share repos via remotes between teams if you want. But contributors sharing the same origin sets up some bad habits.

Gitflow is a very popular git workflow, and Github themselves has some nice tips and shares their workflow.

Kyle Campos
  • 1,034
  • 8
  • 9
  • 96
    This works as long as you have mergable files. You are stuck if you have binary files (like Word documents). – schoetbi Oct 23 '13 at 06:22
  • 11
    Git ins't much better than svn and vice versa. Git fits well for a developer who uses non binary files. In our company case for binaries we opted for svn because it handles big binary files (20mb+ with 100+ versions) better than git ( in the scenario we tested) ps: i love git, – thclpr Apr 30 '14 at 16:19
  • 1
    Going off of what schoetbi said above, but expanding this to non-binary situation: if you are developing for iOS and using Storyboards, then merging/rebasing isn't feasible. So essentially you can't have 2 developers working on the same Storyboard. – Fraggle Oct 23 '14 at 10:40
  • 51
    Down voted because instead of providing a solution, you're convincing people they don't need what they want to do, because Git has something else. If you rebase your changes on top of other people's changes, does it mean there won't be any conflicts (i.e. editing of the same lines) and you surely are not going to overwrite other people's work. I really do not think so – xorcus Jan 27 '15 at 09:35
  • 1
    But how can I lock a binary file in GIT? – pan40 Jul 23 '15 at 08:11
  • 3
    @pan40 you can't. Full stop – usr-local-ΕΨΗΕΛΩΝ Mar 30 '16 at 09:27
  • 5
    I disagree with this answer because rebase is **not** the panacea to handling conflicts, even worse! The purpose of SVN lock, unless one tricks with the working copy or abuses the force steal lock, is to warn people that somebody is doing large modifications to a file. In a Git rebase, if one applies multiple commits to the same file modified by others, he will have to solve conflicts for each and every commit to replay. Merge will be cheaper in that case because you solve conflicts once, but that is not the purpose of locking. Surely, a good project management and coordination helps – usr-local-ΕΨΗΕΛΩΝ Mar 30 '16 at 09:30
  • I'm afraid this does not answer the question. – JulianG Dec 13 '16 at 14:33
  • 1
    Saying "it's a good thing that you can't do that" does not answer the question. There are many reasons people might want to lock files to restrict modifications, e.g., deprecated classes, open source code that shouldn't be changed, etc. – Vroo Apr 05 '17 at 19:48
  • @usr-local-ΕΨΗΕΛΩΝ [you can in LFS 2.0.0](https://stackoverflow.com/q/119444/995714) – phuclv Aug 22 '17 at 03:13
  • even for text files it's not always mergeable. My project uses IAR Visual State for designing state machines and even changing a single transition may introduce tens-thousands-of-changes and most of the time it's not mergeable so we have to fetch the latest state machine and redo our needed things on top of it – phuclv Aug 22 '17 at 03:21
  • Don't rebase already published commits! This is not a good workflow because it muddles up historys of other developers contributing to the same upstream repository. – Sebi2020 Nov 18 '18 at 04:05
  • 2
    Git is terrible at the things that traditional source control took for granted, like preventing conflicts on unmergeable files. This is why things like LFS and gitlab are adding back in these essential features. This answer isn't a solution. – Rumbleweed Nov 03 '20 at 13:46