git: обновление текущей ветки

Question

Есть 2 репозитория git, A и B

В обоих случаях есть только основная ветвь, и оба проверяются локально и работают над ними.

Я нажимаю на главную ветвь B от A и получаю это сообщение:

warning: updating the current branch
warning: Updating the currently checked out branch may cause confusion,
warning: as the index and work tree do not reflect changes that are in HEAD.
warning: As a result, you may see the changes you just pushed into it
warning: reverted when you run 'git diff' over there, and you may want
warning: to run 'git reset --hard' before starting to work to recover.
warning: 
warning: You can set 'receive.denyCurrentBranch' configuration variable to
warning: 'refuse' in the remote repository to forbid pushing into its
warning: current branch.
warning: To allow pushing into the current branch, you can set it to 'ignore';
warning: but this is not recommended unless you arranged to update its work
warning: tree to match what you pushed in some other way.
warning: 
warning: To squelch this message, you can set it to 'warn'.
warning: 
warning: Note that the default will change in a future version of git
warning: to refuse updating the current branch unless you have the
warning: configuration variable set to either 'ignore' or 'warn'.

Если я работаю с проверенной главной веткой B, как я могу ее обновить, чтобы увидеть изменения A?

Что если в локальной проверке мастера на B уже есть изменения, которые еще не зафиксированы?

Примечание: я не очень понимаю сообщение Git выше. Означает ли это «путаницу», это плохо и может привести к потере данных? Или это просто означает, что с такой ситуацией нелегко справиться, но я, как обычно, могу поверить, что все мои изменения каким-то образом сохранятся, и я смогу разрешать конфликты, если это необходимо. Что означает "увидеть изменения отменены"? Мена ли некоторые изменения потеряны?

Для меня как иностранца этот язык не очень понятен.

Редактировать: я просто добавил файл на А и перенес его на Б. На Б я получаю статус, что файл удален.

Каким будет простой рабочий процесс, чтобы справиться с ситуацией?

Answer 1

Вид сбоя, который может быть вызван следующим образом: предположим, что вы добавляете много файлов в коммите для A master и помещаете это в B master.Затем, если вы перейдете в рабочее дерево репозитория B и запустите git status, он скажет, что все эти файлы, которые вы только что добавили, были удалены.Конечно, они не были удалены - вы только что обновили текущую ветку и рабочее дерево, пока индекс не был затронут.Я думаю, что это смущает многих людей!(Это также означает, что сообщение означает «видеть изменения отмененными» - из состояния git это выглядит так, как будто вы отменили только что отправленные коммиты, просто потому, что рабочее дерево и индекс теперь находятся за веткой.)

В этом случае, если вы уверены , что git status в B было чистым до того, как вы нажали на свою основную ветвь, вы можете сбросить рабочее дерево и индекс, чтобы соответствовать новой позицииветви с git reset --hard.

Однако, если у вас были незафиксированные или неотмеченные изменения в B, это внезапно становится вдвойне запутанным, так как эти реальные изменения будет трудно отличить от "изменений", вызванныхтолкать - распутывать их может быть очень сложно.

Итак, если вы понимаете, что происходит, и вы счастливы справиться с этой ситуацией, все в порядке.Лично я почти всегда стараюсь избегать этого одним из следующих способов:

• Вместо этого вытащить из A в B
• Переместить в пустой репозиторий из A, а затем вытащить из B
• Нажатие непосредственно на другую ссылку в B из A, как объяснил в этой записи git FAQ , и слияние с этой ссылки

Я предполагаю, что один изПервые два - это то, что вы хотите.

Answer 2

Вы получаете сообщение об ошибке, потому что вы вставляете в не-пустой репозиторий;см. FAQ по Git для некоторых деталей.Короткое решение: не вставляйте в git-репозиторий с рабочим каталогом;но используйте пустой репозиторий в качестве посредника.

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

В вашем примере это означает следующее:

• Первоначально A и B имеют одну и ту же основную ветвь
• Вы добавляете файл F в основную ветвь A, фиксируете это изменение и помещаете его в основную ветвь B
• Теперь главная ветвь B (которая проверена в данный момент) содержит F. Но поскольку git не касался рабочего каталога B, F там не существует
• Следовательно, в B git сообщает о файле F какудалено: оно присутствует в коммите HEAD, но отсутствует в рабочем каталоге.

Что касается вашего вопроса о потере данных: вы не потеряете никакие данные при таком нажатии.Но, если у вас были какие-либо изменения в вашем рабочем каталоге, их было бы трудно определить, так как git diff теперь показывает разницу с новым состоянием ветвления.Таким образом, некоторые изменения являются реальными, некоторые из них отображаются только потому, что оформление заказа никогда не обновлялось до текущей версии

Answer 3

machineB извлечено somebranch, и вы переносите изменения в somebranch с machineA на machineB, без обновления machineB рабочей копии или индекса .Дерево, которое было проверено на machineB, все еще будет в точке до всех изменений, которые вы нажали.

Теперь, если вы перейдете к machineB и внесете изменения и сделаете коммит безвыполнив сначала git reset --hard, эти изменения сформируют новый коммит , который не включает в себя все изменения, которые вы сделали на machineA и somebranch будут расходиться.Если вместо фиксации вы сделали git diff somebranch, то в дифференциале должны отображаться все изменения, которые вы сделали на machineA, будучи отмененным на machineB, потому что ваша проверка не находится в начале ветви.

Answer 4

Я думаю, проблема в том, что ваш удаленный репозиторий 'A' также работает в основной ветке. Если вы добавите новые изменения в одну и ту же ветку, git запутается. У вас есть 2 варианта:

• Повторно создайте хранилище A как «голое»: git init --bare

• Оформить еще одну ветку в A (git checkout another_branch), а затем снова попытаться оттолкнуться от B