Re: Identifying user who ran “git reset” command

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 21, 2015, 04:58 UTC
Message-ID: <CAPc5daULfa8oASxvWQ7RuV9T4SXoCw_Pi0EfGkk1GGafa1r9Xg@mail.gmail.com>
In-Reply-To: <1424493989740-7625788.post@n2.nabble.com>

On Fri, Feb 20, 2015 at 8:46 PM, Technext <varuag.chhabra@gmail.com> wrote:

> The biggest problem that I see here is that
> every developer has the rights to commit, which I feel is not right.

Hmm, if you have some way to classify developers into two (or more?) categories, what would you do instead? Allow some to commit, and what can others do? Show their change to more senior people and ask them to commit?

That is more or less in a traditional centralized SCM set-up, I think.

With Git, you can do something similar with "rights to push", if you prefer such a workflow. It would go like this:

 (1) Everybody can commit to their own repository and grow their own
      history. What you want to protect is the shared view of the project
      history, and restricting what people can do in their own playpen is
      unnecessary.

 (2) Senior people can push into the project's central repository, just
      like in the set-up you currently have.

 (3) Junior people can ask senior people to pull from them. Senior
      people will pull their changes, review, and if the changes are
      good, merge them and push the result to the project's central
      repository. Alternatively, junior people can do this asking by
      sending patches to senior people, who will review and then
      apply to their tree and push the result out to the common history.