Already up to date git что это
Перейти к содержимому

Already up to date git что это

Помогите расколдовать проблему с веткой в git.

Значит такая ситуация. Создал я как то ветку, в своём простом локальном репозитории( от ветки master). Менял код, вёртску. Не помню чего страшного я сделал(git исп-ю не часто), появилась у меня такая вот ситуация:

Ты видимо откатился на определенный коммит. Типа того:

Простой вариант — копируешь все файлы в другой каталог (кроме .git), а потом делаешь git checkout <имя ветки, что тебе нужна>. После этого убиваешь все файлы, кроме .git и копируешь забекапленые. Потом их коммитишь.

Минус подхода — ты теряешь историю своих изменений.

Если предположить, что ты был в ветке xxxxx, а потом просто сделал git checkout <коммит yyyyyyyyyyyyyy> и далее коммитил, то тебе будет достаточно сделать git merge xxx, чтобы вернуть изменения в xxx.

git checkout <коммит yyyyyyyyyyyyyy> переводит тебя в detached head, т.е. ты как бы в неназванном бренче, который ты отделил от какого-то коммита. Твое состояние можно идентифицировать по номеру последнего коммита в git log (который в самом начале). Вернуться в это состояние всегда можно через git checkout с тем номером коммита. В такой бренч можно делать коммиты, но ты их потеряешь, если уйдешь с бренча и забудешь номер коммита.

появилась у меня такая вот ситуация:

Это detached state. Это означает то, что твой коммит находится вне бранча.

Причём я делал git push/git pull в ответ «Everything up-to-date»/«Already up-to-date» соответственно

Логично, потому как пушить нечего (HEAD’ы локальный бранчей не отличаются от HEAD’ов ремоутных бранчей).

Крайне не хочу потерять изменения. Помогите разобраться!

Нужно сделать следующее:
— застэшить изменения (ресетнуть коммит через git reset —soft, перевести из их в unstage, сделать git stash);
— перепрыгнуть на коммит, на который указывает HEAD интересующего бранча (git co master);
— git stash pop

Есть и другое решение.
— запомнить хэши коммитов
— перепрыгнуть в нужный бранч
— почерепикать коммиты друг за дружкой (man git-cherry-pick)

Не могу сделать push в чужой репозиторий: "already up-to-date"

Меня добавили в репозиторий (дали права на коммит, пуш).

Сделал клон этого репозитория, создал ветку, закоммитил изменения.

Пытаюсь сделать git push , чтобы на удалённом появилась моя новая ветка со всеми изменениями.

Ввожу мэйл, пароль, в ответ приходит «already up-to-date». Данных на удаленном нет.

Что я делаю не так?

user avatar

Это означает что:

  1. На том сервере, куда вы пушите, уже есть такая ветка
  2. И эта ветка находится в таком же состоянии (т.е. точно на тот же коммит смотрит).

Вы пушите не туда (а в какой-то другой репозиторий). Проверяется командой

Вы пушите не то что нужно (а например свою ветку master ). Предположим, нужные коммиты у вас в ветке mybranch :

Можно обойтись без checkout и сразу выбрать, что и куда пушить:

Вы сделали коммиты не в ту ветку.

создал ветку, закоммитил изменения.

Довольно частая ситуация: разработчик создал ветку, но не переключился на неё. Проверяется просто:

Если оказалось, что коммиты, например, в master , а должны быть в mybranch :

Git Merge сообщает «Уже в актуальном состоянии», хотя есть разница

У меня есть git-репозиторий с 2 ​​ветками: master и test.

Существуют различия между основной и тестовой ветками.

Обе ветви имеют все зафиксированные изменения.

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

Но получите сообщение «Уже в курсе»

Тем не менее, проверка файлов в каждой отдельной ветви четко показывает различия.

В чем здесь проблема и как мне ее решить?

Сообщение «Уже обновлено» означает, что все изменения из ветви, которую вы пытаетесь объединить, уже объединены с веткой, в которой вы находитесь. Более конкретно, это означает, что ветвь, которую вы пытаетесь объединить, является родителем вашей текущей ветки . Поздравляю, это самое легкое слияние, которое ты когда-либо делал. 🙂

Используйте, gitk чтобы взглянуть на ваш репозиторий. Метка для «тестовой» ветви должна быть где-то ниже вашей «основной» ветки.

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

Согласно Чарльзу Дрейку в комментарии к этому ответу, одним из решений этой проблемы является:

Это возвращает его к уровню «теста».

чтобы заставить изменения вернуться к центральному репо.

Это часто случается со мной, когда я знаю, что на удаленном мастере есть изменения, поэтому я пытаюсь объединить их, используя git merge master . Однако это не сливается с удаленным мастером, а с вашим локальным мастером.

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

Допустим, у вас есть ветка master со следующей историей коммитов:

Теперь вы создаете тест ветки, работаете над ним и делаете 4 коммита:

master голова указывает на D, а test голова указывает на H.

Сообщение «Уже обновлено» появляется, когда HEAD ветви, с которой вы объединяетесь, является родителем цепочки коммитов ветви, которую вы хотите объединить. Это тот случай, здесь: D является родителем E .

Там нет ничего слияния с test к master , так как ничего не изменилось по master с тех пор. То, что вы хотите сделать здесь, это буквально сказать Git, чтобы master голова указывала на H, поэтому ветвь master имеет следующую историю коммитов:

Это работа для команды Git reset . Вы также хотите, чтобы рабочий каталог отражал это изменение, поэтому вы сделаете полный сброс:

Что работает для меня, скажем, у вас есть branch1, и вы хотите объединить его в branch2.

Вы открываете командную строку git, идете в корневую папку branch2 и набираете:

Если у вас есть конфликты, вам не нужно делать git push, но сначала решите конфликты, а затем нажмите.

Слияние всегда происходит между текущим HEAD и одним или несколькими коммитами (обычно это заголовок ветви или тег),
и файл индекса должен соответствовать дереву коммитов HEAD (т. Е. Содержимому последнего коммита), когда он начинается.
Другими словами, git diff —cached HEAD должен сообщить об отсутствии изменений.

Объединенный коммит уже содержится в HEAD . Это самый простой случай, который называется «Уже в курсе».

Это должно означать, что коммиты в тесте уже объединены с мастером, но, поскольку другие коммиты выполняются на мастере, git diff test все равно будут иметь некоторые различия.

Это происходит потому, что ваша локальная копия ветви, которую вы хотите объединить, устарела. Я получил свою ветку, позвонил MyBranch и хочу слить ее ProjectMaster .

Но я знаю, что есть изменения, которые необходимо объединить!

Вот что, когда я git merge ProjectMaster печатаю, git просматривает мою локальную копию этой ветви, которая может быть не текущей . Чтобы увидеть, так ли это, я сначала говорю Git проверить и проверить, не устарели ли мои ветки, и извлечь какие-либо изменения, если это так, используя fetch . Затем я прыгаю в ветку, которую хочу объединить, чтобы посмотреть, что там происходит .

Ах-ха! Моя локальная копия устарела на 85 коммитов, это все объясняет! Теперь я Pull внесу изменения, которые мне не хватает, затем перепрыгиваю MyBranch и пытаюсь снова объединиться.

И теперь у меня есть еще одна проблема, чтобы исправить .

Это случилось со мной, потому что странно GIT думал, что локальный филиал отличается от удаленного филиала. Это было видно на графике ветвей: он отображал две разные ветви: remotes / origin / branch_name и branch_name.

Решение состояло в том, чтобы просто удалить локальное хранилище и повторно клонировать его из удаленного. Таким образом, GIT поймет, что remotes / origin / branch_name> и branch_name действительно одинаковы, и я могу выдать git merge branch_name .

git merge origin/master вместо этого git merge master работал для меня. Таким образом, чтобы объединить мастер в ветку функций, вы можете использовать:

Обязательно сначала извлеките ветку, которую хотите объединить, а затем извлеките ее (чтобы ваша локальная версия соответствовала удаленной версии).

Затем вернитесь в свою ветку, на которой вы хотите выполнить слияние, и ваш git merge должен работать.

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

Поэтому я ранее слил его, но я намеренно исключил некоторые конкретные изменения во время этого слияния, поэтому он явно имеет некоторые различия между ветвями. Затем я пытался повторно объединить его, потому что я осознал / забыл, что должен был и хотел добавить конкретное изменение / файл, который я ранее исключил, и я надеялся, что при повторном слиянии все изменения, которые я исключил ранее, будут показаны. , но я ошибся и вместо этого получаю сообщение «Уже обновлено».

Прочитав комментарий / ответ @ Bombe, он прав, и я думаю, что git ведет себя так, поэтому я сделал резервное копирование файлов в тестовой ветви, затем извлек мастер-ветку, вручную вставил в нее файлы и зафиксировал это как если бы это были новые изменения.

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

Добавить комментарий

Ваш адрес email не будет опубликован.