Правильный способ использования Git/GitHub - система PHP с серверами Dev/Testing/Production

Я прошу прощения, если это очевидно или просто, я просмотрел большое количество учебников по git/github и прочитал другие статьи, но я хочу убедиться, что я прав.

Я хочу включить VC (по понятным причинам) в свою команду разработчиков и процесс.

Текущий процесс разработки (с использованием Dreamweaver):
* Получить билет (или рабочий заказ)
* Загрузить файл на сервере разработки
* Внесите изменения в файл
* Загрузить файл обратно на сервер разработки
* Изменения проверены/подтверждены
* Отправить на производственный сервер

Я пытаюсь понять, как сделать наш новый процесс разработки с помощью Git.

Я перехожу к PHPStorm (который является реальной PHP IDE с прямой интеграцией с Git).

Будет ли это что-то вроде

Получить билет (или рабочий заказ)
Оформить заказ/Обновить/Скачать файл (ы)
Изменить файлы
Загрузить файл (который я предполагаю также текущий рабочий каталог...?)
В конце дня сделайте фиксацию
Построить script отправить данные на сервер тестирования (ночная сборка)

Или было бы лучше сделать что-то вроде

Получить билет (или рабочий заказ)
Оформить заказ/Обновить/Скачать файл (ы)
Изменить файлы
Загрузить файл /commit
Построить script отправить данные на сервер тестирования (ночная сборка)

Или есть другой способ? Имея немного проблемы с пониманием того, что будет оптимальным потоком?

Любая помощь будет принята с благодарностью.

Edit

Я пытаюсь посмотреть, лучше ли иметь локальную версию сервера (каждый разработчик), и если да, то как это работает, если у вас есть 7 или около того ветвей?

Если нет, как вы имеете дело с 7 или около того веток с ними в Интернете? Вы загружаете файлы FTP или используете Git Крючки, чтобы автоматически обновлять их?

Обновление 27.07.2012

После долгой работы с Git я довольно долго слежу за этой ветвящейся моделью: Успешная Git ветвящаяся модель

Ответ на вышесказанное был да - обязательно должен быть локальная версия сервера.

Ответ 1

Предполагая, что у вас есть живой сервер и сервер разработки, я бы сделал что-то в этом направлении.

До начала цикла разработки у меня было бы, по крайней мере, две ветки:

Мастер - сервер разработки работает на этой ветке
Стабильный - сервер работает на этой ветке.

Итак, если разработчик получит билет или рабочий заказ, он выполнит следующие действия:

git pull origin master
git feature featureBranch (названный как идентификатор билета или как хорошее описание для рабочего порядка)
git функция checkBranch
Внесите изменения, которые сделают желаемое изменение. Зафиксируйте так часто, как это необходимо. Сделайте это, потому что вы создадите ценную историю. Например, вы можете попробовать подход к проблеме, и если это не сработает, откажитесь от нее. Если через день вы увидите свет и хотите повторно применить решение, это в вашей истории!
Когда функция полностью разработана и протестирована локально, мастер проверки.
git функция mergeBranch
git push origin master
Проверьте измененные изменения на сервере разработки. Это момент для запуска каждого теста, который вы можете придумать.
Если все работает, объедините функцию или исправьте ее в устойчивую ветку. Теперь это изменение для ваших клиентов.

Получение кода на сервере

Обновление серверов не должно быть проблемой. В основном я бы установил их как пользователей так же, как вы, разработчики. В моей компании мы настроили серверы как пользователи только для чтения. В основном это означает, что серверы никогда не могут ничего толкнуть, но всегда могут тянуть. Однако настройка этого элемента не является тривиальной, поэтому вы можете просто создать простой веб-интерфейс, который просто позволяет использовать git pull. Если вы можете запретить разработчикам делать какие-либо действия в реальных реализациях, вы в безопасности:)

[EDIT]

В ответ на последние вопросы, заданные в комментариях к этой реакции:

Я не знаю, правильно ли я правильно понял ваш вопрос, но в основном (немного упрощен), вот как бы я это сделал, были ли я в вас обувью.

Тест-машина (или веб-роутер, которая действует как тестовая реализация) имеет исходный код, основанный на репозитории git с проверкой ведущей ветки. При создании этого репозитория вы даже можете удалить все другие ссылки на все другие ветки, чтобы вы не сомневались, что не можете проверить неправильную ветку в этом репозитории. Таким образом, в основном тестовая машина имеет репозиторий git с выделенной только ведущей ветвью.

Для живых серверов я бы сделал то же самое, но на этот раз с проверкой стабильной ветки. Разработчик должен иметь клонированный локальный репозиторий, в котором существуют все ветки. И локальная реализация программного обеспечения, которое вы создаете. Это программное обеспечение получает свой источник из локального репозитория git. Другими словами: из текущей проверенной ветки в этом репозитории.

Фактическое кодирование

Когда требуется новая функция, можно создать локальную ветвь свойств на основе текущего мастера. Когда ветка проверяется, изменения могут быть сделаны и проверены локально разработчиком (поскольку программное обеспечение теперь запущено на источнике ветки признака).

Если все, кажется, в порядке, изменения объединяются из ветки функций в мастер и помещаются на ваш "git machine". "ваш github", так сказать. Тестирование теперь может привести к изменениям, поэтому каждый необходимый тест может быть выполнен с помощью QA. Если они решат, что все в порядке, разработчик может объединить изменения от главного к стабильному и снова нажать.

Все, что осталось сейчас, вытягивает форму ваших живых машин.