основные проблемы понимания Git - PullRequest
5 голосов
/ 27 сентября 2011

Ситуация

Я никогда прежде не использовал git или любой другой контроль версий.Теперь у меня есть веб-проект, который должен иметь стабильную и разрабатываемую версию, и оба они работают на одном сервере в разных каталогах.

  • Стабильный: /var/www/afod/afod
  • Разработка: /var/www/afod_dev/afod

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

То, что я делал до сих пор

Я создал репозиторий git в /var/www/afod/afod и клонировал его в каталог dev с помощью:

cd /var/www/afod_dev/afod
git clone /var/www/afod/afod

Теперь у меня есть 2 репозитория, которые я хочу синхронизировать с помощью git pull на стороне стабильной версии.

Проблема (и)

У меня уже есть 2 ветви,сеть и разработчикНо, как кажется, git pull синхронизирует стабильную версию из обеих веток.Но я хочу только синхронизировать изменения в стабильной версии, которые я уже слил с веб-веткой в ​​dev-версии.

полная путаница

Я надеюсь, что смогу как-то указатьмоя проблема.Кажется, у меня есть базовая проблема понимания того, как работает git, но, похоже, это правильное программное обеспечение для того, что я хочу делать.Я в основном хочу иметь ветку, которая автоматически синхронизируется со стабильной версией, и другие ветви, которые я объединяю в нее.Но разработка должна быть в другом каталоге, чем стабильная версия.

Относительно первого ответа от Billy Moon

Ну, стабильный и dev размещены в другом домене на другом сервере apache vserver,Не имеет никакого смысла работать над веткой разработки, которая находится в каталоге, который люди видят при просмотре сайта.

Итак, моя идея состояла в том, чтобы клонировать репозиторий и затем синхронизировать их.

Я что-то здесь не так понял?Как вы справляетесь с такими конфигурациями?

Ответы [ 2 ]

4 голосов
/ 27 сентября 2011

Филиалы

Я думаю, что вы на правильном пути, но немного путаете с идеей ветви. Вы можете визуализировать ветку как две ветви на дереве. Оба имеют одинаковую магистраль, источник , но советы разные. Различия между одной и той же кодовой базой могут быть незначительными или значительными . Когда вы запускаете команду git checkout <branch_name>, вы говорите git, что хотите, чтобы разные кончики дерева были активными, копировались в рабочий каталог .

В вашем случае одна ветвь имеет код разработки, а другая - ваш стабильный код. Чтобы получить код из ветви dev в ветку web, вы используете git merge <branch_to_pull_in>. Это объединяет подсказки этих двух ветвей, поэтому их содержимое одинаково. Для получения дополнительной информации о ветках в целом, Здесь - это общая не git-страница.

Возможное решение

Ниже приведено решение, которое может работать на вас. Существуют и другие возможные рабочие процессы, но это один из самых простых.

Клонируйте ваш репозиторий разработки в /var/www/afod/afod. Если из /var/www/afod/afod запустить git checkout web и из своей папки разработчика, убедитесь, что вы находитесь в dev ветви. git branch должна иметь такую ​​строку * dev.

Теперь у вас есть две разные ветви одного и того же хранилища, извлеченные в разные подпапки. Делайте свою работу в Dev, как у вас есть. Как только вы почувствуете, что он стабилен, из папки dev запустите git checkout web. Чем git merge dev. Это объединит эти изменения с вашей веткой web. Теперь из /var/www/afod/afod запустить git pull. Это потянет ваши изменения в производственный сервер. И dev, и web будут перетянуты, но только тот, который извлечен , будет в вашем рабочем каталоге.

Если вы хотите снова работать в ветке dev, запустите git checkout dev из папки dev.

0 голосов
/ 27 сентября 2011

Я думаю, что стабильность и развитие должны быть ветвями, а не отдельными репозиториями.

Вот отличное руководство по основному git и тому, как может работать простой рабочий процесс: http://www.ralfebert.de/tutorials/git/

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...