Как удаленный master привести в состояние локального master?

push -f , будь мужиком )

Git push -f

Небольшой момент - никогда не использовать, если кроме тебя в мастере кто-то ещё ведет работу.

git pull
git rebase
git push

Секунду, перед тем как все это делать, я посмотрел статус. И вот что показывает:

$ git status
перемещение в процессе; над 532298f
Вы сейчас перемещаете ветку «master» над «532298f».
  (разрешите конфликты, затем запустите «git rebase --continue»)
  (используйте «git rebase --skip», чтобы пропустить этот патч)
  (используйте «git rebase --abort», чтобы перейти на оригинальную ветку)

Не слитые пути:
  (используйте «git reset HEAD <файл>…», чтобы убрать из индекса)
  (используйте «git add <файл>…», чтобы пометить разрешение конфликта)

        оба измены:     src/qmlCode/IndicatorPanel.qml

нет изменений добавленных для коммита
(используйте «git add» и/или «git commit -a»)

Да, кроме меня мастер никто не пользует.

А можно ли делать git push -f вот в таком состоянии: Как удаленный master привести в состояние локального master? (комментарий)

?

разберись с разницей между git pull/rebase/push и git push -f

эти операции обе _можно_ делать, но результат будет разный, и тебе надо выбрать, чего ты сам добиваешься

Вообще-то я сюда и пишу, чтобы точно узнать в чем разница между git pull/rebase/push и git push -f. Вначале я хотел сделать git push -f, но остановился и создал тему.

Но сейчас мне нужно понять, что делать с текущим состоянием: Как удаленный master привести в состояние локального master? (комментарий)

То есть, код в локальной ветке master меня сейчас устраивает. Но локальный репозитарий находится в состоянии незавершенного rebase. Вопрос в том, как отменить это состояние, но оставить код такой как есть и ветки такие как есть на картинке.

Просто у меня есть подозрение, что если я сейчас выполню:

git rebase --skip

или

git rebase --abort

то у меня текущее состояние разрушится.

Во-первых, читать логи git на русском языке - развлечение не для слабонервных. Терминология - это наше все, и слова pull и fetch например синонимичны, но являются совершенно разными операциями.

Точно также перевод слова rebase как «перемещение» - это можно только с пятого раза понять и если очень постараться. Хочешь помощи - используй LANG=C перед командой и не мучай людей.

Во-вторых, нет, ты начал rebase но не закончил. В таком состоянии с remote-ветками вообще никак нельзя работать.

Для меня русскоязычный выхлоп git - это манна небесная. Я хоть как-то начал понимать что происходит.

Я хоть как-то начал понимать что происходит.

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

Если действительно хочешь разобраться, почитай Pro Git, там описано (почти) всё, что тебе нужно знать, причём от простого к сложному. Текущая твоя задача — понять, что ты действительно хочешь. А хочешь ты или забыть изменения в origin/master, или смержить их с локальным master. В первом случае --force решит задачу, но знаний тебе не прибавит, во втором случае ты можешь в том числе дропнуть коммиты, которые тебе не нужны.

Разберись с git rebase сначала.

Никто не знает, что ты там натворил, но по идее тебе надо:

1) применить текущие изменения через

git add src/qmlCode/IndicatorPanel.qml git rebase --continue

2) все последующие изменения пропускать:

git rebase --skip

3) Запушить в конце в мастер

git push -f

git pull/rebase/push попытается тебе в локальную ветку смержить изменения из удаленной, а потом запушить назад. Потенциально все сломается и я бы такое не рекомендовал.

git push -f жестко перепишет удаленную ветку содержимым локальной ветки.

Я бы посоветовал сделать git checkoub -b test_branch и экспериментировать там с ребейзами и пушами в test_branch (git push -u origin test_branch)

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

Но я не уверен, что git checkout -b отработает корректно в текущем состоянии. Если совсем боишься потерять работу, то можно по старинке сделать архив zip текущего репозитория (c .git папкой в том числе), а потом уже играться-разбираться и восстанавливать вручную локальную копию в случае фейла.

Освой feature-ветки, сэкономишь себе нервов в будущем.

Прости, но не похоже :)

В гите надо понять принцип.

1) коммиты живут в дереве сами по себе, у каждого коммита есть его личный идентификатор - тот самый нечитаемый хеш, и родитель (или несколько).

2) ветка - это обман. На самом деле веток нет, есть только теги, то есть указатели на коммиты. Просто некоторые теги (неизменяемые) называются тегами, а некоторые (изменяемые) - ветками.

push, pull, branch и т.п. - это работа с указателями.

rebase это работа с деревом

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

Я сейчас прервал rebase, и у меня исчезло ветвление, которое было видно на картинке.

Мне сейчас нужно откатиться до определенного коммита, и продолжить с него. И чтобы это продолжение было веткой master. А все что было нагорождено после этого коммита, оставить в виде ветки masterToGridLayout для истории.

Сейчас состояние репозитария выглядит так:

http://i.piccy.info/i9/32817094d66f529052d46da3e53593e6/1517319158/159749/120...

Откатиться нужно до коммита, выделенного синей линией.


PS: GitPro я читаю, обложился и другими мануалами, но много вещей непонятны, по причине того что не пишут что вообще происходит со всеми элементами, которые затронуты в процессе выполнения команды. Один только git reset --soft чего стоит.

ветка - это обман. На самом деле веток нет, есть только теги, то есть указатели на коммиты. Просто некоторые теги (неизменяемые) называются тегами, а некоторые (изменяемые) - ветками.

Ну да. Веток нет, есть просто именные указатели. Именной указатель «ИмяВетки» - это указатель на последний коммит в какой-то цепочке коммитов. При добавлении коммитов в эту цепочку, он автоматически перемещается на последний коммит. Это я понимаю.

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

А мне нужно откатиться до коммита, разветвиться, и продолжить новую ветку так, чтобы она называлась master.

Вот это я не могу понять как сделать.

https://stackoverflow.com/questions/1628563/move-the-most-recent-commits-to-a...

git push -f

Это из серии: «Позволь я погуглю за тебя»

Точнее вот: https://stackoverflow.com/a/6796816

Откатиться нужно до коммита, выделенного синей линией.

откат ветки к комиту всегда git reset --hard

git checkout master
git branch savedHistory
git reset --hard <hash>
git push -f origin master

Это то что тебе надо? Или что-то другое?

берешь мастер мастер тот что есть сейчас

git checkout master

делаешь от него ветку «для истории»

git checkout -b history

потом возвращаешься к мастеру

git checkout master

сидя на мастере переставляешь указатель master на нужный коммит

git reset --hard <target-commit>

Это всё локально.

Затем чтобы статус локального мастера синхронизировать с мастером в remote-репе тебе надо туда в апстрим запушить свою локальную ветку при этом перезатерев все что апстрим о ней когда-то слышал.

git push --force

git reset --hard <target-commit>
Затем чтобы статус локального мастера синхронизировать с мастером в remote-репе тебе надо туда в апстрим запушить свою локальную ветку при этом перезатерев все что апстрим о ней когда-то слышал.
git push --force

Здесь тонкий момент. Можно ли между этими двумя командами делать коммиты в master? Просто я уже так пробовал делать: сделал хард-ресет, сделал пробный коммит, потом push (без force) и мне в ответ:

 ! [rejected]        master -> master (non-fast-forward)
error: не удалось отправить некоторые ссылки в «MobileIndicator»
подсказка: Обновления были отклонены, так как верхушка вашей текущей ветки
подсказка: позади ее внешней части. Заберите и слейте внешние изменения 
подсказка: (например, с помощью «git pull …») перед повторной попыткой отправки
подсказка: изменений.
подсказка: Для дополнительной информации, смотрите «Note about fast-forwards»

Да, то что надо.

Вроде все прошло правильно. Но не пойму, почему gitk теперь две ветки не показывает. Вроде должен.

верхушка вашей текущей ветки позади ее внешней части

не, ну я не могу это читать :)

Ты понимаешь что стандартные сообщения гита все люди в лицо узнают просто по очертаниям куска текста в терминале, а ты предлагаешь какую-то чепуху?

Но на самом деле там все правильно написано, предупреждение другое потому что этот частный конкретный случай выглядит подозрительно. У тебя «там» больше коммитов чем «тут» и git переспрашивает. Но тебе все равно нужен --force

gitk --all а лучше посмотри как пользовать git log

Я имею в виду что gitk использует те-же опции командной строки что и git log

git push -f полностью перепишет историю на удаленном сервере той, что у тебя локально.

В общем, написал заметку себе на будущее:

Не бойся хардресета! Он твой друг и помощник.

Дескать, она полностью обнуляет историю откаченных коммитов, и вернуть их невозможно.

Такое могут говорить люди только непонимающие гит вообще. Ни rebase, ни hard reset (через который, сюрприз, работает rebase) не являются необратимыми. Даже без использоване «архивной» ветки или тэга. Гугли git reflog.

Ну точнее тут есть одна оговорка - вся история в гите восстанавливаема если не закончился период для GC.

Ну и не восстанавливаются вещи, не попадавшие в историю никогда, например текущие изменения из рабочего каталога, не добавленные в индекс на момент ресета

Ну это и так, я думаю, очевидно=)