Hi, On 2015-09-12 08:31, Sukhwinder Singh wrote:
> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
