RE: Git Deployment using existing multiple environments

Thank you very much for the detailed reply. There is going to be just one person who'll manage all the moving of the code. On approval he'll move code from one environment to other on our own servers (right now it is being done by manual merging). Development team is not that big right now. They'll be committing all new code to the git repository we have setup up at github using all over test environment code. And the person handling the code at our server will move code from one environment to other by USING Git and not by manual merge.

Now lets say we set up a repository at github which has the latest code (all test code)., Now at each of our own servers we already have existing code, that is Test, UAT and Live. For example, first he'll pull code from github to our Test Server and then move branches to UAT and then to Live. Can it work? If it can work then can I please get some some example commands or the procedure to set it up? Time is a bit of problem right now or I would have read book suggested by Johannes. I have searched on the internet but couldn't find any similar case.

Regards,
Sukhwinder Singh

----------------------------------------

From: jacob.keller@gmail.com
Date: Mon, 14 Sep 2015 01:32:39 -0700
Subject: Re: Git Deployment using existing multiple environments
To: php_programmer_india@hotmail.com
CC: johannes.schindelin@gmx.de; git@vger.kernel.org

On Sun, Sep 13, 2015 at 10:55 PM, Sukhwinder Singh
[off-list ref] wrote:

quoted

Thank you for the reply. Let's say I do setup three different repositories then how can we move work from one repository to the other. For example, from Test Environment to UAT. If there are any links that you can provide me that I can check, it'll be great.

Regards,
Sukhwinder Singh

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