6

I was holding an introductory presentation on GIT when someone from the audience asked me how to lock a remote branch, preventing a push from someone else.

I understand why a person that has been using TFS wonders about it, but are there reasons why you would need to lock a remote repository in GIT? If so, which ones?

MaPi
  • 1,601
  • 3
  • 31
  • 64
  • Related: http://stackoverflow.com/questions/2471340/is-there-a-way-to-lock-a-branch-in-git – jub0bs Sep 02 '14 at 18:44
  • There is a bit of a debate in the comments below as to what you mean by "locking a remote branch". Could you clarify? Do you mean "preventing any further push" to that remote branch? – jub0bs Sep 02 '14 at 21:01
  • Also, if their intent is unclear, perhaps you should have the audience member post their question here themselves! – Joe Atzberger Sep 02 '14 at 23:31

3 Answers3

4

Locking a branch in TFS makes it read only (see "Making a TFS Branch Read-Only")

Git itself isn't able to make a branch read-only: if you have access to a git repo, you clone it all (with all its branch), and you can commit in any branch.

You can control what is pushed through:

That means you can put in place a policy (hook or gitolite) which will prevent the modified branch to be pushed to the upstream repo.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

For the most part, git has a different way of handling this situation (mainly: tag the branch, delete the branch) but, to answer the question you asked -- why would you want to? -- the answer is: to prevent the branch from changing.

Here's one example of when that's useful: A lot of SCM organizations create a branch when a product is getting near shipping, so that the branch can be under strict change control, but development can continue on master (/main/trunk/etc. in other environments).

So you might have, for example a branch dedicated to v2.1 which has been sent to QA before being shipped, and the only changes that will be allowed on the v2.1 branch will be those changes deemed by management important enough to include in v2.1. In the mean time, the rest of the team is working on master, or branch v2.2, or v2.5, or Experimental-feature-branch, etc.

Then v2.1 ships.

Again, in git, one typically just tags the thing that shipped (an important concept in SCM/SQA is to always be able to re-create the delivered build from the exact same sources that were used to create the one the customer has) but, since there's a branch with that name, wouldn't it be handy to "freeze" that branch at its end-of-life so that no one can change it further?

This is mostly a leftover from svn and similar other-environments. A git-centered shop would probably say "just tag it and delete the branch!", but old habits die hard, and people like to continue using the familiar, so they end up doing things like freezing the branch.

That's certainly how I arrived at this question looking for a way to freeze my git branch! :)

Olie
  • 24,597
  • 18
  • 99
  • 131
-1

The git approach to "locking" a unique code state is to create and push tags. The most common motivation for this is to track actual released versions of the code, like:

git tag v0.1.37
git push --tags

Now that tag is available to be checked out, like its own branch. It is important to have a strong naming convention for tags, since you want it to be absolutely clear what the arbitrary state represents. For example, if it is a beta release that should be indicated by the naming convention. Since git is a distributed system, it is technically possible for a committer to overwrite published tags (with --force), but this behavior is not common (certainly far less common than rebasing a branch).

Alternatively or additionally, you can use gitosis, gitloite and other advanced tools to provide more granular security.

Joe Atzberger
  • 3,079
  • 1
  • 18
  • 16
  • I think this answer is completely off the mark. There are ways to prevent one from pushing to a remote branch (using a server-side hook like `update` is one of them), but tags have *nothing* to do with that. – jub0bs Sep 02 '14 at 19:18
  • User asked "are there reasons why you would need to lock a remote repository in GIT? If so, which ones?" This is sufficiently broad to include all reasons for locking code states, thereby inducing my description of tags. – Joe Atzberger Sep 02 '14 at 19:20
  • The OP is asking about locking a remote branch, not tagging. Tagging is not locking. – jub0bs Sep 02 '14 at 19:20
  • Tagging preserves a code state which is not just one of the reasons you would lock a branch in earlier VCSs, but the **single most common reason**. For anything else, I linked gitosis and gitolite for handling repo access control. – Joe Atzberger Sep 02 '14 at 19:25
  • 1
    Tags allow you to pin a particular commit as having some historical importance (such as a release, e.g. `v1.2`); they do not allow you to prevent further push to a branch, which is what the question (as I understand it) is about. If there is any doubt about that, the OP should chime in. – jub0bs Sep 02 '14 at 19:48
  • Again the question here is WHY, not how. The audience member has barely been introduced to git. So they are asking about locking branches not because they know that git can or should do it. It isn't the goal itself. They are thinking from the perspective of their godawful primitive centralized VCS where "locking a branch" or "locking a repo" actually mattered for a basic operation like cutting a release. Or that's my read anyway. – Joe Atzberger Sep 02 '14 at 23:44