RE: Git Deployment using existing multiple environments

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

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

Date: Sat, 12 Sep 2015 12:55:46 +0200
From: johannes.schindelin@gmx.de
To: php_programmer_india@hotmail.com
CC: git@vger.kernel.org
Subject: Re: Git Deployment using existing multiple environments

Hi,

On 2015-09-12 08:31, Sukhwinder Singh wrote:

quoted

We already have 3-4 environments setup on our Windows servers without Git
and each environment already has code which is different from each
other.

There are three environments
Live
UAT
Test (has the latest code)


And then developers have their local copies.

We write and test the code locally and manually move each point from
one environment to other using merging software and test at each
environment.
Now we want to use git because manually moving the code is a lengthy
process. Also as the developers have local copies, it is very
difficult to manage code.

Code is written locally by the team and then after testing locally it
is first merged with "Test" environment code, then "UAT" and then,
finally with "Live".
So we have two concerns:

There is different code already existing on these environments.
Testing the code on each environment using the web server.

What is the best way to go about it? As I am new to git more details
will be helpful, like commands to use.

It seems you are not only looking for commands to use, but for a proper workflow in which Git supports your work best.

The key is to define the roles in your flow first, and then identify the optimal commands.

In your case, I figure that there are three "merge lords" or "merge ladies", one for "Test", one for "UAT", one for "Live". And each of them needs to be notified when changes are ready to be merged, then merge the changes.

If I was walking in your shoes, I would set up four repositories that each are owned by one of the "merge lords/ladies", or the developers, respectively. The code would move from one to the next repository, triggered by a notification, then being pulled into the environment, then tested, and if everything is okay, pushed into the next repository.

(Actually, you could do without the repository corresponding to the "Live" version, but it would be a nice record.)

However, this is just one possible suggestion. I would highly recommend buying and reading the book "Git for Teams", as it has extensive coverage of different work flows, their strengths and their weaknesses.

Ciao,
Johannes