Правильный способ использования 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]

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

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

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

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

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

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

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

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