Рабочий процесс производственного / промежуточного сервера Git


108

В настоящее время на моем веб-сайте (производственном сервере) уже есть много кода. А теперь я хочу начать использовать Git для своих проектов и настроить промежуточный сервер для моей команды. Кто-нибудь может дать мне совет?

Вот картина в моей голове:

        Production        - Production server which already have codes
            ↑             
         Staging          - New staging server, will install Trac too
         ↗↙ ↖↘          
  Developer1  Developer2  - Local development 

У меня вопрос, с чего мне начать?

Вот несколько шагов в моей голове:

  1. сделать git initрабочий сервер (это безопасно?)
  2. clone репо с производства на промежуточный сервер
  3. разработчики cloneрепо от постановки на локальную машину
  4. push файлы на промежуточный сервер после завершения изменения
  5. когда постановка готова, pushвсе до постановки

Имеет ли смысл этот рабочий процесс или есть какой-то лучший способ сделать это?

Что, если я хочу изменить только один файл?

Имеет ли происхождение / мастер какое-либо отношение к этому в этом процессе ?? Кто происхождение? я собираюсь иметь несколько происхождений ??

Кроме того, когда разработчик должен использовать branchв этом случае?

Ответы:


59

Лучше использовать основную ветку только для Production и ветку разработки для Staging. Каждый разработчик должен создать локальную ветку, чтобы добавить новые функции, а затем объединиться с веткой разработки. Если вы новичок в git, попробуйте использовать - http://github.com/nvie/gitflow. Также есть хорошая картинка, описывающая модель ветвления git - http://nvie.com/posts/a-successful-git- ветвящаяся модель /


Это лучший ответ. Я был не очень хорошо знаком с концепцией ветвления Git.
kayue

@bUg. У вас есть ссылка на какой-либо ресурс, объясняющий более подробно ветку разработки -> отправку в промежуточную систему и главную ветку -> отправку на рабочий сервер ? В превосходной статье «Успешная модель ветвления Git» эта часть не упоминается, даже если в ней упоминаются очень хорошие концепции ветвления и управления версиями.
Эдгар Аллоро

19

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

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


1. выполните git init на рабочем сервере (это безопасно?)

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

2. клонировать репо с рабочего на промежуточный сервер

Вероятно, у вас должно быть «центральное» репо, отдельное как от производственного, так и от промежуточного сервера. Его можно клонировать и отправлять по мере необходимости.

3. разработчики клонируют репозиторий из промежуточной среды на свой локальный компьютер.

4. После внесения изменений отправьте файлы на промежуточный сервер.

5. Когда постановка готова, отправьте все в постановку

Замените «staging» на «central», и я думаю, что у вас все в порядке, но большая проблема заключается в том, как вы будете работать с ветвями и слиянием, как указывает bUg.


10
1: Чтобы сделать репозиторий Git безопасным в производственной среде, обязательно добавьте файл .htaccess с надписью «Запретить все» внутри.
kayue

2
2: «Центральное» репо Феликсиза относится к чистому репо. Используйте команду --bare для создания чистого репо.
kayue

1
@keyue 1: Еще лучше, добавьте RedirectMatch 404 /\.gitв свою продукцию .htaccess, чтобы защитить ваши .gitignore , .gitattributes и папку .git .
Лео
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.