Git push synchronization between team members

Question

What is the "correct" way to ensure that other people don't push to git remote repo while someone else is doing a time-consuming merge/rebase operation and would like the repo to remain stable while doing so? Is there a elegant way to lock the repo in a read-only mode until a person finishes with lengthy operation or is running the test suite to ensure everything plays well?

Currently, we're using a....creative (read: slightly unorthodox?) approach to this problem - we have a special file on a local, separate SVN repository that each team member has to manually checkout (i.e. perform a 'lock') before doing pushes to remote git repo. Now, this approach (such as it is) works but is prone to errors and mind slips (someone, usually a new team member, pushes in the middle of someone else's merge/rebase).

There has to be a more elegant way to do this.

Now, I am not a git expert in any way (I am just a regular user) but writing a custom command to do the lock shouldn't be too onerous. But that doesn't solve the problem of preventing the other user from pushing to remote repo, i.e. how to make git repo conscious that somewhere out there, there is a flag that - if raised - should prevent user from pushing to repo.

Is there a more standard way to solve this, an existing pattern that people use? Is there even a way to put the entire repo in read-only mode?

I am open for any and all suggestions but would certainly like to avoid introducing new inter-repositories and/or dedicated person(s) that would be the only ones with premissions to push to the remote - we want all developers to have that capability but just to prevent stepping on each other's toes.

Answer 1

There is a standard way for doing this. Use git normally and this never happens.

Git is distributed version control system. When you fetch from a repository (A) into yours, you get a copy of the branches in that repository in yours, named A/branch_name. You probably have seen this when doing git merge origin/master for example. Changing the branch on the remote repository doesn't affect your local copy of it until your next fetch, which happens whenever you decide.

So, what does this mean? Let's think of the following actions:

1. A has branch branch.
2. You fetch from A in your repository and merge into your local branch.
3. You start your lengthy process on your local repository.
4. Meanwhile, somebody else pushes to branch on A.
5. You still do your lengthy process on your local repository without ever knowing about step 4.
6. You try to push back your merge.

So at this point, you know that everything works on your local repository. However, when you try to push, you can't. Some observations:

• At step 4, whoever pushed to A did the same lengthy tests in parallel with you, but finished earlier. So he made sure that everything with branch on A is ok.
• If the other person had locked A as read-only, you wouldn't know until step 6, since you were reading from the repository anyway. So making the repo read-only wouldn't change anything.

Now what this means for you is that you have to repeat the above steps. So you have to fetch again, merge again and run your lengthy tests again. But this is ok and is usually what is done, however not as bad as you might think.

There are two possibilities:

1. The other person was working on something you had been working on yourself (unlikely).
2. The other person was working on something totally unrelated (likely).

In the second case, there is no problem. The merge would go smooth and you don't need to repeat the lengthy tests since the tests for each subsystem are separate (they are, right?!). Perhaps you would run the tests on the complete integration.

In the second case, there would be merge conflicts, which means more work for merge conflicts and running tests again. But that merge conflict would sooner or later manifest itself, whether you had locked the repository or not. However, if you had locked the repository, then it would be your coworker that would have to deal with the conflict. In the end, either you or him have to do it.