Как переходить при использовании удаленной ветви - PullRequest
2 голосов
/ 12 февраля 2020

Я из Perforce и новичок в Git. У меня есть частный сервер Gitlab и работаю с командой. Я понимаю основные понятия c ветви Git, но все еще не могу найти рабочий процесс по умолчанию при синхронизации ветви. Представьте, что у меня есть следующая структура ветви

$ git branch -a
master
remotes/origin/HEAD -> origin/master
remotes/origin/feature
remotes/origin/my-first-feature

my-first-feature является производным от feature. Когда я теперь извлекаю ветку локально, я должен работать непосредственно с этой локальной копией и отправлять ее обратно в эту ветку на сервере? Или я должен сделать другую ветку локально, которая происходит от feature?

$ git checkout my-first-feature
vi do-i-work-directly-here-and-push-back?

Ответы [ 3 ]

2 голосов
/ 12 февраля 2020

Хорошо, в git более полезно думать немного по-другому.

Git на самом деле не имеет ветвей. Все, что у него есть, - это много коммитов, и между этими коммитами есть родительские отношения. Коммит также может иметь двух родителей (это происходит при слиянии). Не уверен насчет более чем 2 родителей, не видел этого на практике.

"Ветви" в git на самом деле просто указатели на коммиты. Они похожи на понятные человеку псевдонимы для определенного c идентификатора коммита.

Однако, по соглашению, есть много команд, которые автоматически работают с ними. Например, когда вы фиксируете некоторые изменения в ветке, git создает новый коммит с его родительским установленным в том коммите, на который в данный момент указывает ветка. Затем он обновляет эту ветку, указывая на новый коммит.

Теперь, когда вы клонируете репозиторий, git копирует не только все коммиты, но и все ветви. Но вместо того, чтобы сохранять их имена, он меняет их на remotes/origin/<original name>. Это опять-таки просто соглашение - эти ветви ни в коем случае не являются особенными, это просто ветви с именем в указанном формате c.

Теперь, когда вы будете sh работать с одним из эти ветви локально, традиция требует, чтобы вы сначала сделали локальную копию ветви: git checkout -b my-first-feature --track remotes/origin/my-first-branch. Для этого также есть сокращение, которое вы можете найти в документации.

Это создает новую локальную ветвь и указывает на тот же коммит, что и на удаленную ветвь. Кроме того, в новой локальной ветке он отмечает, что «эта локальная ветвь отслеживает эту удаленную ветвь». Это имеет значение, когда вы набираете sh и тянете, мы скоро к этому вернемся Обратите внимание, что это все еще локальная операция. Git не связывался с удаленным репозиторием, чтобы увидеть, куда указывает my-first-branch. Он просто проверяет локальную ветвь remotes/origin/my-first-branch.

Теперь у вас есть новая локальная ветвь, с которой вы можете играть, как считаете нужным.

Когда вы выполняете операцию pu sh, git подключается к удаленному репозиторию и пытается заставить удаленный my-first-branch указывать на тот же коммит, что и ваш локальный my-first-branch. Для этого он загружает все новые коммиты и пытается обновить указатель удаленной ветви. Если на сервере есть новые коммиты (в my-first-branch), он откажется. Он обнаруживает это, проверяя, является ли коммит, на который указывает ваш локальный my-first-branch, потомком коммита, на который указывает удаленный my-first-branch. Если это не так, вы не можете pu sh. Затем вам нужно выполнить операцию извлечения, которая получит все новые коммиты, обновить локальный remotes/origin/my-first-branch, чтобы он соответствовал серверу, а затем объединить my-first-commit с remotes/origin/my-first-commit. Это создает новый коммит, являющийся потомком удаленного my-first-branch. Теперь вы можете успешно выполнить pu sh.

Существуют и другие способы игры с коммитами, но понять их все проще, если вы будете думать с точки зрения коммитов, а не ветвей. Ветки просто псевдонимы для удобства. Граф фиксации - вот что важно.

2 голосов
/ 12 февраля 2020

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

Я обычно создаю Моя функция разветвляется локально, а затем отправляет их в удаленное хранилище. Но в равной степени допустимо создавать ветви на удаленном компьютере, а затем git fetch и git checkout локально, чтобы выполнять работу в этой ветви. Так что да, работа непосредственно над выбранной веткой функций - это хороший способ выполнить свою работу.

1 голос
/ 12 февраля 2020

При использовании Git вы правы в том, что имеете ответвление от основной ветви "Feature". Некоторые переименовали бы это, чтобы разработать, а затем разветвить ветку разработки для вашей «my-first-feature».

Вы не должны разветвляться из вашей локальной ветки из-за того, что если вы извлекаете / обновляете свою локальную ветку Могут возникнуть проблемы слияния веток my-first-feature.

  1. отделение функции
  2. создание ветки my-first-feature
  3. Когда все будет готово sh локально обратно в ветку "my-first-feature"
  4. После того, как все изменения будут выполнены, объединитесь с веткой "feature / development"

Надеемся, что ответят на ваши вопросы

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