Потягніть за іншу гілку 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

— Морфілдур
джерело

git pull --allза замовчуванням не буде тягнути master в live, він витягне master і злить його з master, і (якщо він існує на сервері) потягне live, щоб об'єднатися в live. Ви пробували?

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

Чи викликана ваша проблема файлом, який не знаходився під контролем версій перед відгалуженням в прямому ефірі та доданим git після модифікації, щоб згодом освоїти? Ось що траплялося зі мною раніше, зазвичай цього достатньо, щоб тимчасово перейменувати цей файл, або якщо він не потрібен у прямому ефірі , використовуйте git checkout -fдля ігнорування проблеми - але робіть резервну копію!

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

1

пов'язані з : stackoverflow.com/questions/3216360 / ...

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

21

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

— Тобіас Кіенцлер
джерело

6

git pull --allотримає всі віддалені, але він все ще намагатиметься об'єднати гілку (або гілку за замовчуванням) у поточну гілку.

— mipadi

@mipadi так, але тільки поточна гілка в себе, без спроби перевірити майстра і викликати конфлікт, ні?

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

Він злиється, будь-яка гілка налаштована для автоматичного об'єднання в поточну гілку (якщо така гілка налаштована).

— mipadi

1

@Superole Це задокументовано як "отримати всі віддалені", що включає не лише декілька сховищ, а й гілки. Хоча на задньому git fetch --all

— плані

2

@TobiasKienzler Це лише вказівка git отримувати з усіх налаштованих видалень. Найпоширеніший випадок - мати лише одне віддалене ім'я з походженням. Якщо у вас трапляється більше одного віддаленого пристрою з тією ж гілкою, що і ваша поточна, і вони не перебувають у швидких відносинах вперед, а потім, використовуючи цю --allопцію, ви отримаєте злиття восьминога різних версій гілки в поточну ! Тож моя порада - не триматися подалі, --allякщо це не те, що ви хочете, тому що в більшості інших випадків це не дасть вам нічого.

— Superole

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 і не бажають дізнаватися переваги чогось нового. Можна буде лише створити нову гілку в прямому каталозі. Об’єднання віддаленого майстра з живою гілкою - це те, чого я хочу уникати, оскільки я не можу перешкодити нікому відштовхувати код налагодження, неповні функції, синтаксичні помилки та що-небудь інше до майстра (я все-таки молодший розробник). Дякую за вашу пропозицію.

— Morfildur

2

@dbeme: Ви можете використовувати тарболи та патчі. ;) Якщо вони не хочуть вивчити git (і це зовсім не важко для того, щоб розгалужуватися та зливатися), у вас виникнуть проблеми.

— Джош К

0

Рекомендую створити тестовий git repo, щоб усі могли здійснити. Усі репости, включаючи ваш веб-сайт у прямому ефірі, будуть клонами тестового репо. Таким чином, кожен може перейти до тестування, не торкаючись прямого веб-сайту. Коли комусь потрібно оновити веб-сайт, який ви можете оновити, ви можете витягнути веб-сайт наживо з репо-тестування git. Цей робочий процес досить схожий на SVN. Для додаткової гнучкості я рекомендую використовувати гілку "live", яку ви описуєте.

Підводячи підсумок, git repo кожного є клоном тестувального репо. Живий майданчик - це лише клон тестового репо. Крім того, тестування може бути клоном живого продуку, так що "git push" завжди рухається до виробництва.

Інші варіанти, включаючи додавання до цієї домовленості гілки "в реальному часі" або включення репо "стадії" між тестуванням і виробництвом. Для додаткової безпеки я рекомендую обмежувати доступ до репортажу в реальному часі і змушувати людей використовувати захищений сценарій, який робить потяг до живого виробництва.

— крайник
джерело