Re: Git Deployment using existing multiple environments

On Sun, Sep 13, 2015 at 10:55 PM, Sukhwinder Singh <php_programmer_india@hotmail.com> wrote:

Generally speaking there are two ways of moving work from one repository to another. The first is the "pull" where you request data from a remote repository and then merge that data into your own. This is what you're doing when you perform a clone, a fetch, or a pull. It's what everyone does all the time when working with a local copy of a "trusted" remote repository. It can also be done between two "trusted" remotes, if your workflow is more distributed. (ie: more than one "official" source).

The second form of moving work is the "push" where you upload your work into another repository. This is most commonly used when the workflow is "centralized". By that I mean there is a single authoritative repository. Or when you are moving your own work on a local machine into a remotely accessible machine for others to pull from.

As Johannes said above, you really need to determine the work flow and team style you want before you can really understand the best way to setup repositories. For example, if you setup using a distributed chain of command, you can have one person be the "maintainer" of each given trusted repository. Then, maintainers can pull (or equivalent-ly, pull-request) between each other. This is generally how a project would work when using github. One person is the maintainer, then a developer "forks" the project, makes some changes, then requests that the maintainer pull these changes. The maintainer has final say and will perform the final merge in cases of conflict. In addition, maintainer is the one who says "this is ok to go into this repository".

You can also instead opt to use a single centralized repository. Thus, developers would work on code and get it ready to submit, and then simply perform a push. If the push requires a merge git will tell the user to update. There are many tools such as server side hooks in order to enforce various behaviors.

This flow generally doesn't use sole maintainers, as each developer has access to push directly. It may work well for smaller teams or for dedicated teams who don't change developers often.

A lot comes down to how your team is structured. Do you have one person who's job can be to maintain the repository? Do you have several developers who don't want to be the sole owner? Is your team willing to function much more distributed?

In the end, it's generally always a good idea to designate at least one repository as the "authority" so that everyone knows where to look for release tags and other such data.

Myself, I would say that I prefer to use the pull-request model so that code gets more review, as "push" based models tend not to do review. (Exception: Gerrit, but this uses "git push" on the command line to do something very much not like a push)

Regards, Jake