Как обновить ветку git из репозитория

Как правильно обновить ветку?

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

Отслеживать
задан 8 фев 2021 в 10:07
1,833 1 1 золотой знак 19 19 серебряных знаков 39 39 бронзовых знаков

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Команда git pull используется для извлечения и загрузки содержимого из удаленного репозитория и немедленного обновления локального репозитория этим содержимым. Команда git pull на самом деле представляет собой комбинацию двух других команд: git fetch и git merge. На первом этапе git pull выполняется команда git fetch, ограниченная локальной веткой, на которую указывает HEAD. Сразу после загрузки содержимого команда git pull выполняет слияние. Для слитого содержимого создается новый коммит, а указатель HEAD обновляется и начинает указывать на этот новый коммит.

Отслеживать
ответ дан 8 фев 2021 в 10:12
Sergey Samusik Sergey Samusik
26 5 5 бронзовых знаков

В принципе, @SergeySamusik правильно написал, но не до конца. Предложенным способом Вы обновите локальный master , а дальше объединяете изменения мастера со своими с помощью merge . Если же Вам нужно сделать локальную ветку точной копией мастера, отбросив все, что в ней было сделано, то, как по мне, проще пересоздать ветку от нового состояния мастера.

8 фев 2021 в 12:26
@ЮрийКозлов, а pull , разве, не делает merge ?
8 фев 2021 в 12:48

@nup pull делает мерж, но между локальной и удаленной копией одной ветки (например origin/master и master ). А у ТС, как понимаю, есть мастер-ветка ( master ), и есть своя ветка (например, branch-1 ) , и ему нужно перенести изменения из удаленного мастера не в его локальную копию ( origin/master -> master ), а в свою ветку ( origin/master -> branch-1 ).

Git: обновление ветки до актуального состояния

Если в ветке master появились новые коммиты и вы хотите обновить свою ветку до её состояния, то проще всего это сделать так:

Находясь в своей ветке выполняем команду git rebase master (либо загружаем с сервера git pull —rebase origin/master )
Если есть конфликты, то правим их и выполняем git add конфликтующие_файлы , затем git rebase —continue

При этом коммиты вашей ветки окажутся наверху истории изменений.

Получение изменений из удаленного репозитория

Для доступа к удаленным репозиториям можно использовать распространенные команды Git.

Options for getting changes

These commands are very useful when interacting with a remote repository. clone and fetch download remote code from a repository’s remote URL to your local computer, merge is used to merge different people’s work together with yours, and pull is a combination of fetch and merge .

Cloning a repository

To grab a complete copy of another user’s repository, use git clone like this:

$ git clone https://github.com/USERNAME/REPOSITORY.git # Clones a repository to your computer

You can choose from several different URLs when cloning a repository. While logged in to GitHub, these URLs are available on the main page of the repository when you click

When you run git clone , the following actions occur:

A new folder called repo is made
It is initialized as a Git repository
A remote named origin is created, pointing to the URL you cloned from
All of the repository’s files and commits are downloaded there
The default branch is checked out

For every branch foo in the remote repository, a corresponding remote-tracking branch refs/remotes/origin/foo is created in your local repository. You can usually abbreviate such remote-tracking branch names to origin/foo .

Fetching changes from a remote repository

Use git fetch to retrieve new work done by other people. Fetching from a repository grabs all the new remote-tracking branches and tags without merging those changes into your own branches.

If you already have a local repository with a remote URL set up for the desired project, you can grab all the new information by using git fetch *remotename* in the terminal:

$ git fetch REMOTE-NAME # Fetches updates made to a remote repository

Otherwise, you can always add a new remote and then fetch. For more information, see «Managing remote repositories.»

Merging changes into your local branch

Merging combines your local changes with changes made by others.

Typically, you’d merge a remote-tracking branch (i.e., a branch fetched from a remote repository) with your local branch:

$ git merge REMOTE-NAME/BRANCH-NAME # Merges updates made online with your local work

Pulling changes from a remote repository

git pull is a convenient shortcut for completing both git fetch and git merge in the same command:

$ git pull REMOTE-NAME BRANCH-NAME # Grabs online updates and merges them with your local work

Because pull performs a merge on the retrieved changes, you should ensure that your local work is committed before running the pull command. If you run into a merge conflict you cannot resolve, or if you decide to quit the merge, you can use git merge —abort to take the branch back to where it was in before you pulled.

Как обновить локальную ветку задачи если develop ветка обновилась?

Допустим я создал локальную ветку задачи branchTaskName от локальной develop ветки (предварительно ее обновив)
На задачу выделено несколько дней и в это время удаленная ветка develop несколько раз обновилась другими разработчиками и потом сделали релиз в master. Но моя ветка еще не готова.
Возникло несколько вопросов:
1. Нужно ли мне обновлять свою ветку задачи branchTaskName свежими изменениями? Подозреваю, это зависит от функционала который изменился. Или это нужно делать всегда, когда источник обновляется?
2. Как правильно обновить ветку задачи branchTaskName чтобы не было проблем при отправке своей ветки в удаленный репозиторий?
— обновить локальные ветки master и develop (git pull)
— зайти в свою ветку branchTaskName и смержить ее с develop (git merge develop) и продолжать с задачей?

Вопрос задан более года назад
2190 просмотров

1 комментарий

Простой 1 комментарий

scottparker

scottparker @scottparker

1. Нужно ли мне обновлять свою ветку задачи branchTaskName свежими изменениями? Подозреваю, это зависит от функционала который изменился. Или это нужно делать всегда, когда источник обновляется?

если пересечений по измененным файлам не было, то твоя ветка смержится норм. если есть — через интерфейс гита — не даст создать пулреквест. но лучше всегда обновлять. так безопастнее, не нужно следить за изменениями других.

2. Как правильно обновить ветку задачи branchTaskName чтобы не было проблем при отправке своей ветки в удаленный репозиторий?

можно обновить свою ветку сразу с удаленного репозитория git pull origin develop (или мастер). по сути обновлять локальные мастер и деволоп не обязательно

Решения вопроса 2

sergey-kuznetsov

Сергей Кузнецов @sergey-kuznetsov Куратор тега Git
Автоматизатор

Вы наверное не совсем понимаете логику работы гита, раз такой вопрос возник.
Репозиторий надо рассматривать как дерево состояний проекта. Каждый коммит это определённое состояние. Название ветки это лишь указатель на некоторое состояние.

создал локальную ветку задачи branchTaskName от локальной develop-ветки (предварительно ее обновив)

Точнее вы создали тематическую ветку не от другой ветки, а от конкретного состояния, на которое указывал в тот момент указатель develop в распакованной (checkout) в рабочий каталог ветке.

Нужно ли мне обновлять свою ветку задачи branchTaskName свежими изменениями?

Моё мнение — нужно. Ведь ваша задача состоит не в создании сферических файлов в вакууме, а в изменении файлов проекта. Причём изменений относительно уже устаревшего состояния. Желательно чтобы ваша работа опиралась на актуальный проект, а не на старую версию.

Как правильно обновить ветку задачи branchTaskName чтобы не было проблем при отправке своей ветки в удаленный репозиторий?

Тут тоже странное утверждение. У вас неоткуда взяться проблемам при отправке (push) изменений во внешний репозиторий. Проблемы могут возникнуть уже после, когда вашу ветку будут интегрировать (merge) с основной веткой (develop). Чтобы избежать этих проблем мы заранее предпринимаем определённые действия.

Способов собственно два:

1) Мы забираем новое состояние develop в свою тематическую ветку через коммит слияния. И для этого вовсе не обязательно переключаться в локальную develop, обновлять её (pull) а затем возвращаться к себе чтобы сделать git merge develop . Это бессмысленные манипуляции. Достаточно просто скачать к себе в локальный репозиторий обновления внешнего репозитория git fetch (Лайвхак: эту операцию можно автоматизировать. Настройте автоматическое выполнение fetch по расписанию, и у вас всегда будет под рукой доступ к актуальному проекту). Затем сделайте git merge origin/develop. Указатель origin/develop это и есть ссылка на состояние проекта на момент последнего скачивания (fetch). В принципе эти два шага эквивалентны одной команде git pull origin develop — внутри делается всё то же самое.

2) Второй способ — пересадить вашу ветку на новое актуальное состояние проекта (rebase). Выглядеть будет так, если бы вы начали работать над фичей вот только что, и тут точно не возникнет конфликтов, так как база ветки актуальная. Это делается тоже в два шага. Сначала убедимся что у нас всё актуально git fetch , затем собственно пересадим ветку на актуальное состояние git rebase develop . Последний вариант мне нравится тем, что история не засоряется коммитами слияния. Но тут предполагается, что тематическая ветка принадлежит только вам и никто больше в ней не работает. Так как после пересадки её придётся удалять из внешнего репозитория и создавать там заново через git push —force . Если работа над фичей ведётся совместно с коллегами, то такой рабочий процесс не очень подойдёт.

Если вы не коммитите напрямую в master и в develop, то держать их у себя локально (делать checkout в рабочий каталог) тоже нет смысла. Вы всегда можете начать новую тематическую ветку от актуального состояния, на которое ссылаются origin/master или origin/develop. Так вы не наступите на грабли, когда люди забывают переключиться из мастера и начинают коммитить туда. Нет мастера — нет проблем.