Потяните за другую ветку Git без переключения

55

мы недавно переключились с SVN на Git и в то же время перевели наши действующие системы в систему управления версиями (вместо локальной проверки и копирования файлов в живую).

В проекте мне поручено, чтобы мы все имели доступ к одному и тому же репозиторию, и чтобы внести изменения в жизнь, мы просто git pullтам. Это вызывает проблемы, потому что наши веб-дизайнеры вносят изменения в VCS, которые еще не должны быть активными, но должны быть в среде веб-тестирования.

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

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

Моя идея такова:

Создайте новую ветку в live ( git branch live).
Каждый раз, когда что-то должно жить
- Напряжения изменение мастеров (например: git checkout master; git pull; git checkout live)
- git merge master

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

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

git

— Morfildur
источник

git pull --allпо умолчанию не будет извлекать мастер в прямом эфире, он извлечет мастер и объединит его с мастером, и (если он существует на сервере) потянет в прямом эфире, чтобы объединить в оперативный. Вы пробовали это?

— Тобиас Кинцлер

Ваша проблема вызвана файлом, который не контролировался версией до ветвления с live и добавлением git после модификации на master позже? Это то, что случилось со мной раньше, обычно достаточно временно переименовать этот файл, или, если он не нужен в прямом эфире , используйте git checkout -fдля игнорирования проблемы - но сделайте резервную копию!

— Тобиас Кинцлер

1

связанные: stackoverflow.com/questions/3216360/…

— Сиро Сантилли 新疆改造中心法轮功六四事件

21

Вы можете использовать его git stashперед проверкой master и pull, и после проверки live снова используйте git stash pop(или если ваш git старше, git stash applyи git stash clearпри условии , что вы больше ничего не спрятали)

— Тобиас Кинцлер
источник

6

git pull --allизвлечет все удаленные устройства, но все равно попытается объединить ветку (или ветку по умолчанию) с текущей веткой.

— Мипади

@mipadi да, но только текущая ветвь в себя без попытки извлечения мастера и возникновения конфликта, нет?

— Тобиас Кинцлер

Он объединит любую ветку, настроенную для автоматического слияния с текущей веткой (если такая ветка настроена).

— Мипади

1

@Superole Это задокументировано как «получить все удаленные устройства», которое включает в себя не только несколько репозиториев, но также и ветви. Хотя в ретроспективе, git fetch --allвозможно, был бы лучший ответ

— Тобиас Кинцлер

2

@TobiasKienzler Он только инструктирует git получать данные со всех настроенных пультов. Наиболее распространенным случаем является наличие только одного удаленного имени источника. Если у вас есть более одного пульта с той же ветвью, что и у вашего текущего, и они не находятся в быстрой перемотке друг с другом, ТО, используя эту --allопцию, вы объедините осьминога разных версий ветки в текущую. ! Поэтому я советую держаться подальше, --allесли только это не то, чего вы хотите, потому что в большинстве других случаев это вам ничего не даст.

— Супероль

74

Я смог вытащить изменения из origin/masterво masterвремя работы в другой ветви с помощью этой команды:

git fetch origin master:master

— Джефф Б
источник

6

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

— Маркус Шепард

2

Вы можете найти документацию по этому вопросу здесь: git-scm.com/docs/git-fetch#_examples

— c1moore

fetch! =pull

— Д. Ковач

5

Решите проблему в первую очередь. Они не должны подталкивать к филиалу, к которому они не имеют никакого бизнеса.

То, что вы спрашиваете, было бы что-то вроде

git checkout live
git pull origin master

Это попытается объединить удаленный мастер и вашу живую ветку.

— Джош К
источник

Проблема в том, что в настоящее время у нас есть только одна ветвь, и изменить ее будет невозможно, поскольку все слишком привыкли к SVN и не хотят изучать преимущества чего-то нового. Будет возможно только создать новую ветку в директории live. Я хочу избежать слияния удаленного мастера с веткой live, поскольку я не могу помешать кому-либо передавать отладочный код, неполные функции, синтаксические ошибки и все остальное на мастер (в конце концов, я всего лишь младший разработчик). Спасибо за ваше предложение, хотя.

— Морфилдур

2

@dbeme: Вы можете использовать тарболы и патчи. ;) Если они не хотят изучать git (и совсем не сложно разветвляться и объединяться), у вас будут проблемы.

— Джош К

0

Я рекомендую вам создать тестовое репозиторий git, чтобы каждый мог его принять. Все репо, включая ваш живой сайт, будут клонами тестового репо. Таким образом, любой может перейти к тестированию, не касаясь живого веб-сайта. Когда кому-то нужно обновить действующий сайт, вы можете извлечь его из репозитория git testing. Этот рабочий процесс довольно похож на SVN. Для дополнительной гибкости я рекомендую использовать ветку "live", которую вы описываете.

Подводя итог, можно сказать, что все git-репо являются клоном тестового репо. Сайт живого производства также является клоном тестового репо. В качестве альтернативы, тестирование может быть клоном живой продукции, так что «толчок мерзавца» всегда движется к производству.

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

— edgester
источник