How to use git to organize my development, approval and production environment?

Question

How to use git to organize my development, approval and production environment?

Navigation

#1 by (2 votes)

7

We are adopting the use of a homologation server here in our company, but we still do not know how to organize the development flow from this paradigm, since currently each developer when it wants to consolidate the implemented modifications performs push or merge directly to origin / master , using or not a branch for this.

This relationship occurs only between the developer machine and the production server, which in turn has its hooks / post-receive script in each repository for automated deploy to the < strong> / var / www .

Our new environment will work as shown below, where each square is a remote and each circle represents a fixed branch :

I have not yet defined whether the project will run from the branch test and origin (production) branch master , or if this distinction is made only from remote , both projects being executed from the master , because I do not know the ideal solution in these cases. What do you suggest? How do you usually use it with your teams?

versionamento git testes

asked by anonymous 26.11.2014 / 17:43

1 answer

How do I know if a feature is in the browser cache? Maximize solution: construction of sublists meeting limit

score 2 · Answer 1

Here at work we have the master as the "always implantable" version according to github flow , for each feature we create a "correccao_xxx" branch, after tested, a pull request is opened, analyzed, approved and integrated to the master. Very simple. (of course, we use GitHub to facilitate this process).

Another possibility (which I think is very interesting) is to create a branch that includes changes to the current iteration (sprint, for example, a level below the master.), I believe this can be considered your branch of "development ", with new smaller branches representing the features. After the sprint, it integrates in the master (production branch) and closes the version (tag).

But it all depends on your need, a good way of thinking is to ask yourself "does this make sense when I'm going to need this remote? and this branch?"