Git рабочий процесс (Dev> Staging> Live) основные технические вопросы

Я новичок в Git (и VC, если на то пошло), и я немного борюсь за понимание концепции рабочего процесса Dev > Staging > Live с помощью ветвей.

Я пытаюсь применить часть рабочего процесса this, в котором используются ветки dev и ветки релиза вместо фиксированный этап.

Прежде чем пытаться использовать Git, у меня был "тот же" рабочий процесс с использованием SVN. Но вместо создания ветвей для каждого этапа мы использовали для этого разделенные репозитории. Теперь, когда я пытаюсь применить ветки, все становится немного размытым.

Я могу понять идею рабочего процесса, но не могу получить ее с технической точки зрения.

Шаги, которые я выполняю для его создания:

Создать папки

user:/var/www/$ mkdir dev.example.local
user:/var/www/$ mkdir staging.example.local
user:/var/www/$ mkdir example.local

Репозитории инициализации

user:/var/www/example.local$ git init
user:/var/www/example.local$ git remote add origin [email protected]:user/example.com.git
user:/var/www/example.local$ echo "README" > README
user:/var/www/example.local$ git commit -am "First"
user:/var/www/example.local$ git push origin master

user:/var/www/example.local$ cd ../dev.example.com
user:/var/www/dev.example.local$ git clone [email protected]:user/example.com.git .
user:/var/www/dev.example.local$ git checkout -b dev
user:/var/www/dev.example.local$ git push origin dev

user:/var/www/dev.example.local$ cd staging.example.com
user:/var/www/staging.example.local$ git clone [email protected]:user/example.com.git .

Некоторые работы с веткой dev

user:/var/www/dev.example.local$ echo "New" > newfile
user:/var/www/dev.example.local$ git add .
user:/var/www/dev.example.local$ git commit -am "Some new file"
user:/var/www/dev.example.local$ git push origin dev

Когда все будет готово к новой версии

user:/var/www/staging.example.local$ git fetch
user:/var/www/staging.example.local$ git checkout -b release-0.1 dev
user:/var/www/staging.example.local$ git push origin release-0.1

user:/var/www/staging.example.local$ cd ../example.com
user:/var/www/example.local$ git fetch
user:/var/www/example.local$ git merge --no-ff origin/release-0.1
user:/var/www/example.local$ git tag -a "0.1"
user:/var/www/example.local$ git push origin master

user:/var/www/example.local$ cd ../dev.example.com
user:/var/www/example.local$ git merge --no-ff master
user:/var/www/example.local$ git push origin dev

Я уверен, что не буду следовать правильным шагам. Итак, что означает "правильный путь" к:

  • создать dev, организовать, жить папки и запустить репозиторий Git в каждом из них?
  • проверка/слияние новых выпусков?
  • сливаться с релизом, чтобы жить?
  • создать всю среду?

и

  • , где я должен запускать эти команды Git? на моем местном репо? для каждого из этапов?

Релевантная информация:

  • Я использую BitBucket
  • Это для разработки сайта (Drupal).
  • Моя главная ветка - это живая сцена
  • В настоящее время работают около 3 разработчиков, и каждый из них в другой стране

Ответ 1

Вам не нужно создавать разные репозитории. То, что вы должны изучить, и вы, вероятно, любите о git, - это то, как легко работать с ветвями. Итак, шаг 1:

  • Забудьте обо всем, что вы знаете, из своего SVN-фона.

Теперь, когда мы все настроены, вот идея. Скажем, у вас есть только master на вашем битбакете:

  • Clone the repository:

    $ git clone [email protected]:user/example.com.git
    $ cd example.com
    
  • Создайте ветки:

    $ git branch dev
    $ git branch staging
    
  • Пусть другие знают об этих ветвях:

    $ git push origin dev
    $ git push origin staging
    
  • Начните работать!

    $ git checkout dev
    $ touch new_file
    $ git add new_file
    $ git commit
    $ git merge master         # and resolve conflicts
    $ git checkout master
    $ git merge dev
    $ git push origin
    

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

Короче говоря, у вас нет разных репозиториев, но есть ветки в одном репозитории. Между этими ветвями вы можете объединить столько, сколько хотите, с любым рабочим процессом, который вам нравится. У вас могут быть дополнительные ветки, которые не подталкиваются к происхождению, поэтому они скрыты от других. Вы также должны, конечно, git fetch/git merge ветки, которые вы хотите работать каждый раз, чтобы убедиться, что вы получили последние изменения от других соавторов.