Comments 50
О, пока вы тут. Подскажите, как правильно изменять историю коммитов (объединить несколько в один, например), чтобы потом не пришлось делать push с --force?
«git rebase -i HEAD~5» даст возможность переделать историю последних 5-ти коммитов (что-то выкинуть, объединить несколько в один, или поменять местами). Но перед тем как это делать, настоятельно рекомендуется прочитать мануал по rebase («git help rebase»). Причём весь, т.к. rebase — весьма обширная команда, с приципиально разными возможностями в интерактивном и неинтерактивном вариантах.
С большой вероятностью, первая попытка не сростётся, так что приготовтесь к «git rebase --abort» :) Но если цель избежать forced push — то перезапись истории в этом НЕ поможет.
И если вы задаёте вопрос таким образом, то возникает ощущение, что сами не знаете, что надо спросить :) Единственный вариант дать нормальный ответ/совет в такой ситуации — это если вы расскажете ваш use-case, и что хочется получить в результате (а не «а как сделать Х?»).
С большой вероятностью, первая попытка не сростётся, так что приготовтесь к «git rebase --abort» :) Но если цель избежать forced push — то перезапись истории в этом НЕ поможет.
И если вы задаёте вопрос таким образом, то возникает ощущение, что сами не знаете, что надо спросить :) Единственный вариант дать нормальный ответ/совет в такой ситуации — это если вы расскажете ваш use-case, и что хочется получить в результате (а не «а как сделать Х?»).
Нененене. Про rebase -i HEAD~5 я знаю. Проблема в том, что после того как я затираю часть коммитов (тем же fixup), вся эта конструкция отказывается заливаться обратно на сервер без --force.
Смотрите ниже
Посмотрите на вот такой вариант. Ключевым является
который мержит старый вариант вашей текущей ветки в новый вариант, полученный после rebase, но при этом никаких изменений не добавляет (т.е. мерж фиктивный, только чтобы иметь возможность это дело впушить обратно).
Такой способ позволяет сделать rebase, но сохранить возможность пушить без форса. Однако он больше подходит для ситуаций, когда действительно нужен rebase на обновленный upstream. Если же вам надо просто слепить несколько коммитов для более нарядного лога, то без форса не обойтись — как никак вы историю переписываете.
git merge -s ours old-featureкоторый мержит старый вариант вашей текущей ветки в новый вариант, полученный после rebase, но при этом никаких изменений не добавляет (т.е. мерж фиктивный, только чтобы иметь возможность это дело впушить обратно).
Такой способ позволяет сделать rebase, но сохранить возможность пушить без форса. Однако он больше подходит для ситуаций, когда действительно нужен rebase на обновленный upstream. Если же вам надо просто слепить несколько коммитов для более нарядного лога, то без форса не обойтись — как никак вы историю переписываете.
GIT — система децентрализированная. Поэтому самый правильный ответ — вы можете изменять историю комитов как хотите. Но только до того, как эти коммиты попали на сервер. Ибо после того, как они попали на сервер — их мог скачать кто-то другой. У него — ещё кто-то. И т.д. В результате, если вы перепишете историю на сервере ( а push --force) сделает именно это, то все другие юзеры будут иметь те самые проблемы с «git push problem: non fast forward». Потому что они не знают, что на сервере кто-то переписал историю.
Поэтому ещё раз — не меняйте историю, если вы уже успели запушить её куда-либо. Вы создадите кучу проблем другим.
Поэтому ещё раз — не меняйте историю, если вы уже успели запушить её куда-либо. Вы создадите кучу проблем другим.
Подписываюсь под каждым словом, с поправкой:
Изменять историю можно и после push, делая потом forced push. Но при этом надо чётко понимать, что и где будет происходить — как у вас, так и на сервере, а особенно — у других пользователей. И надо чётко осознавать количество и уровень проблем, которые принесёт такой шаг (push, изменение истории, forced push).
Иногда такой шаг и нужен, но лучше так действительно не делать. Особенно если ваш репозиторий публичный (например, на github).
Но на практике необходимость в этом возникает крайне редко. У вас ведь локальный ропзиторий. Вы там — единоличный хозяин, и никакие изменения в нём (пока вы их не обнародовали) не могут помешать другим участникам. Веток можно наплодить сколько угодно. И смоделировать любую ситуацию — например, что будет после пуша на сервер. Просто завести еще одну ветку, назвать её например server, и мерджить туда. Хоть мульйон раз. Проверить всё, досконально. И только потом — заливать на сервак по-настоящему.
Изменять историю можно и после push, делая потом forced push. Но при этом надо чётко понимать, что и где будет происходить — как у вас, так и на сервере, а особенно — у других пользователей. И надо чётко осознавать количество и уровень проблем, которые принесёт такой шаг (push, изменение истории, forced push).
Иногда такой шаг и нужен, но лучше так действительно не делать. Особенно если ваш репозиторий публичный (например, на github).
Но на практике необходимость в этом возникает крайне редко. У вас ведь локальный ропзиторий. Вы там — единоличный хозяин, и никакие изменения в нём (пока вы их не обнародовали) не могут помешать другим участникам. Веток можно наплодить сколько угодно. И смоделировать любую ситуацию — например, что будет после пуша на сервер. Просто завести еще одну ветку, назвать её например server, и мерджить туда. Хоть мульйон раз. Проверить всё, досконально. И только потом — заливать на сервак по-настоящему.
На первых парах работы с Гитом меня частенько интересовал этот вопрос: Что б*я такое «git push problem: non fast forward»?
Так что спасибо Вам от «меня из прошлого» :)
Так что спасибо Вам от «меня из прошлого» :)
Ну тогда сделайте «git fetch --all» и потом «gitk -a» — сразу станет видно, какова ситуация у вас и на сервере. Эта картинка должна прояснить ситуацию полностью. Если не прояснит — заливайте картинку куда-нибудь, давайте ссылку и будем разбираться.
PS: статью-то читали? ради ответа на такой вопрос она собственно и написана.
PS: статью-то читали? ради ответа на такой вопрос она собственно и написана.
Это ответ на habrahabr.ru/blogs/Git/136847/#comment_4554817
Как автор того самого вопроса — Что мне в итоге делать то =) статья замечательная но ответа на мой вопрос, почему мне говорит при пуше нон фаст форвард при том что пулить нечего я так и не понял
Проблема моя в том случае была такая — 2 человека работали в бранче девелопмент
1 из них залил изменения
потом «непонятным магическим образом» на сервере образовался мердж мастера и девелопмента от моего имени, хотя я абсолютно точно ничего такого не делал
Более того — с самого утра того дня когда присутствует мердж ничего не мог запулить с проблемой — описанной в вопросе
Решилось коммитом-отменой последнего мерджа с другого клона репозитория
1 из них залил изменения
потом «непонятным магическим образом» на сервере образовался мердж мастера и девелопмента от моего имени, хотя я абсолютно точно ничего такого не делал
Более того — с самого утра того дня когда присутствует мердж ничего не мог запулить с проблемой — описанной в вопросе
Решилось коммитом-отменой последнего мерджа с другого клона репозитория
Ну вы же взрослый человек, и прекрасно понимаете, что бывает только «непонятный» вариант, а «магическим образом», да ещё и «само» — не бывает :) Если ничего не делать — то ничего не поменяется. Если что-то поменялось, значит таки кто-то что-то сделал.
С одной стороны, все коммиты в git содержат всю информацию как об авторе (тот, кто создал исправление или новый код), так и о коммитере (тот, кто разместил это всё в истории проекта) — в общем случае, это могут быть разные люди.
С другой стороны, сам git не заморачивается такими вещами, как аутентификация и авторизация. И потому «прикинуться» кем-то не проблема: если кто-то в своём ~/.gitconfig указал ваши данные, то в истории всё будет выглядеть так, как будто коммит именно вы и сделали. Так что разбирайтесь.
PS: кстати, из последнего можно и выгоду извлечь. Например, можно в user/email указывать не свой реальный email, а username@host. Например, так: cub@moon, cub@saturn и т.д. Или так: cub+git.moon@gmail.com, cub+git.saturn@gmail.com — вариантов неограниченное количество. Таким образом, можно будет понять с какой именно машины в историю закоммитились отдельные коммиты.
С одной стороны, все коммиты в git содержат всю информацию как об авторе (тот, кто создал исправление или новый код), так и о коммитере (тот, кто разместил это всё в истории проекта) — в общем случае, это могут быть разные люди.
С другой стороны, сам git не заморачивается такими вещами, как аутентификация и авторизация. И потому «прикинуться» кем-то не проблема: если кто-то в своём ~/.gitconfig указал ваши данные, то в истории всё будет выглядеть так, как будто коммит именно вы и сделали. Так что разбирайтесь.
PS: кстати, из последнего можно и выгоду извлечь. Например, можно в user/email указывать не свой реальный email, а username@host. Например, так: cub@moon, cub@saturn и т.д. Или так: cub+git.moon@gmail.com, cub+git.saturn@gmail.com — вариантов неограниченное количество. Таким образом, можно будет понять с какой именно машины в историю закоммитились отдельные коммиты.
Это да, но админ гит сервера я и нас всего 4 человека, так что вариант с подставой отпадает я гарантируюю это
я вот думаю а не мог я как нибудь пушем сделать мердж? указав напримерно неверно таргет ветку или что то другое
я вот думаю а не мог я как нибудь пушем сделать мердж? указав напримерно неверно таргет ветку или что то другое
Вы для начала определитесь, когда у вас была ошибка (во время push или pull), и какая именно (т.к. pull про non-fast-forward ругаться не будет).
Предполагаю, что чуть выше вы ошиблись, и хотели написать «ничего не мог запушить».
В таком случае повторюсь — сервер таки делает мердж, но только с использованием fast-forward метода. А это значит, что никаких конфликтов быть не может, и у вас проблемы «ничего не мог запушить» не возникло бы.
Другое дело, если запушил кто-то, и вы не вытащили его апдейты, и попытались запушить свои. В таком случае вы 100% получите ошибку, и не какую-нибудь, а именно эту. Этот случай и способы его решения описаны в статье.
Но это всё градание на кофейной гуще. Давате факты (хотябы скриншот в «gitk -a») с историей, и будем говорить предметно.
Предполагаю, что чуть выше вы ошиблись, и хотели написать «ничего не мог запушить».
В таком случае повторюсь — сервер таки делает мердж, но только с использованием fast-forward метода. А это значит, что никаких конфликтов быть не может, и у вас проблемы «ничего не мог запушить» не возникло бы.
Другое дело, если запушил кто-то, и вы не вытащили его апдейты, и попытались запушить свои. В таком случае вы 100% получите ошибку, и не какую-нибудь, а именно эту. Этот случай и способы его решения описаны в статье.
Но это всё градание на кофейной гуще. Давате факты (хотябы скриншот в «gitk -a») с историей, и будем говорить предметно.
А какой комментарий был для этого мерджа? Уже не с кучей ли id-шников?
К автору статьи- очень интересно и подробно все расписано — а можете еще про stash так же рассказать =)
Мы сейчас отучиваем сотрудников от варианта а в пользу варианта б (git используется примерно полгода). Force push сделать невозможно (нет прав). В перспективе возможно ограничим на этапе push мерджи из Active в Active (вариант а).
Мы сейчас отучиваем сотрудников от варианта а в пользу варианта б (git используется примерно полгода). Force push сделать невозможно (нет прав). В перспективе возможно ограничим на этапе push мерджи из Active в Active (вариант а).
Мы сейчас отучиваем сотрудников от варианта а в пользу варианта б (git используется примерно полгода). Force push сделать невозможно (нет прав). В перспективе возможно ограничим на этапе push мерджи из Active в Active (вариант а).
Мы сейчас отучиваем сотрудников от варианта с merge в пользу варианта с rebase (git в компании используется примерно полгода). Force push сделать невозможно (нет прав). В перспективе возможно ограничим на этапе push мерджи из Active в Active (вариант а).
И получаете урезанный SVN с плюшкой в виде децентрализации? Однако :)
Похоже я привел недостаточно деталей:
— force push запрещен для разработчиков, чтобы избежать переписывания истории на сервере. При push-е ошибочных комитов рекомендуется push-ить откатывающие коммиты. Гипотетически, если историю все-таки нужно переписать на сервере (например удалить файл, который обязан отсутствовать в репозитории в принципе), нужно просить об этом админов
— у нас нет и не предвидится ограничений на создание feature/developer/release веток (есть только определенные ограничения на имена веток). Конечно, для подобных веток rebase после push не делается (это было бы переписыванием истории на сервере)
— для работы с активной веткой (master) не рекомендуется делать merge при pull в пользу rebase при pull. Это делается для того, чтобы избежать ничем неоправданных ромбиков в истории на сервере, которые сильно ухудшают ее читабельность.
Мне кажется не очень ограничительным запрет на переписывание опубликованных коммитов и рекомендации линеаризовывать неопубликованные изменения перед push. Все остальные плюшки остаются.
— force push запрещен для разработчиков, чтобы избежать переписывания истории на сервере. При push-е ошибочных комитов рекомендуется push-ить откатывающие коммиты. Гипотетически, если историю все-таки нужно переписать на сервере (например удалить файл, который обязан отсутствовать в репозитории в принципе), нужно просить об этом админов
— у нас нет и не предвидится ограничений на создание feature/developer/release веток (есть только определенные ограничения на имена веток). Конечно, для подобных веток rebase после push не делается (это было бы переписыванием истории на сервере)
— для работы с активной веткой (master) не рекомендуется делать merge при pull в пользу rebase при pull. Это делается для того, чтобы избежать ничем неоправданных ромбиков в истории на сервере, которые сильно ухудшают ее читабельность.
Мне кажется не очень ограничительным запрет на переписывание опубликованных коммитов и рекомендации линеаризовывать неопубликованные изменения перед push. Все остальные плюшки остаются.
Всем советую известную книжку Pro Git (http://progit.org/). Онлайн она бесплатна. Есть русский перевод на том же сайте, но я читал по-английски, поэтому о его качестве судить не могу.
Читается быстро, легко и с интересом. Правда.
Когда прочитаете, большинство вопросов отпадут сами собой.
Читается быстро, легко и с интересом. Правда.
Когда прочитаете, большинство вопросов отпадут сами собой.
Есть еще полезная практика, чтобы не порождать пачку мерджей делать git pull --rebase и потом уже push
В любом случае — хоть «git pull --rebase», хоть «git rebase origin/master» — будет выполняться операция rebase, которая для начинающих может оказаться сложной, а в случае конфликтов во время rebase — так и вообще неподъемной или черезмерно запутанной.
Вообще, на мой взгляд, натуральное применение для rebase — это в первую очередь приведение истории к «красивому» виду. И если а) вы новичок или б) вам «ехать, а не шашечки» — то про rebase можно вообще забыть и не использовать совсем.И ваши волосы... Ну, вы поняли :)
Вообще, на мой взгляд, натуральное применение для rebase — это в первую очередь приведение истории к «красивому» виду. И если а) вы новичок или б) вам «ехать, а не шашечки» — то про rebase можно вообще забыть и не использовать совсем.
как же вам отребейзить ваш бранч относительно текущего мастера, без git rebase origin/master
Как-то не понятно, а в чём суть вашего вопроса?
Если его понимать буквально, то ответ есть в статье. Но вы ведь в курсе, вы же статью прочитали?..
А если не буквально — так никто ж запрет на rebase не накладывал, это всего лишь рекомендации, это же очевидно.
Если его понимать буквально, то ответ есть в статье. Но вы ведь в курсе, вы же статью прочитали?..
А если не буквально — так никто ж запрет на rebase не накладывал, это всего лишь рекомендации, это же очевидно.
ну вы говорите что rebase сложен для новичка, но это базовый функционал, наравне с push, pull, merge
это как сказать
«вам «ехать, а не шашечки» — то про PUSH можно вообще забыть и не использовать совсем.» но звучит это как то странно… я просто не понимаю как можно обойтись без одной из основ гита… я лично делаю «git rebase -i origin/master» примерно так же часто как и «git push»
это как сказать
«вам «ехать, а не шашечки» — то про PUSH можно вообще забыть и не использовать совсем.» но звучит это как то странно… я просто не понимаю как можно обойтись без одной из основ гита… я лично делаю «git rebase -i origin/master» примерно так же часто как и «git push»
Может кто из знающих подскажет для Ubuntu аналог TortoiseGit. С такими же удобными инструментами просмотра лога, коммита и разрешения конфликтов.
Пока приходится использовать gitk и cola, но их интерфейс далеко не то, что мне нужно.
Пока приходится использовать gitk и cola, но их интерфейс далеко не то, что мне нужно.
Спасибо, очень хорошо описано.
Что могу из конструктивной критики сказать. Вот об этот фрагмент взгляд очень сильно спотыкается:
ИМХО можно как-то попроще переписать без «к которому», «с которым», «сливаемого». Например, используя термины «начальный коммит» и «конечный коммит»:
Он возможен только в том случае если начальный коммит «А» является предком конечного коммита «Б» («начальный» и «конечный» означают, что в результате merge мы хотим начальные исходники с цепочкой коммитов, заканчивающейся на «A», превратить в исходники с цепочкой коммитов, которая будет заканчиваться на «Б»)
Что могу из конструктивной критики сказать. Вот об этот фрагмент взгляд очень сильно спотыкается:
Он возможен только в том случае, если текущий коммит (тот, к которому будет происходить слияние, обозначим его А), является предком «сливаемого» коммита (тот, с которым будет происходить слияние, обозначим его Б):
ИМХО можно как-то попроще переписать без «к которому», «с которым», «сливаемого». Например, используя термины «начальный коммит» и «конечный коммит»:
Он возможен только в том случае если начальный коммит «А» является предком конечного коммита «Б» («начальный» и «конечный» означают, что в результате merge мы хотим начальные исходники с цепочкой коммитов, заканчивающейся на «A», превратить в исходники с цепочкой коммитов, которая будет заканчиваться на «Б»)
Mercurial смотрит на эту «проблему» с недоумением. Он просто спрашивает «эй, парень, ты уверен, что хочешь создать новую голову на удалённом репозитории? а то делай merge или rebase. или если очень надо, то форсируй (-f) (но и в этом случае совсем ничего не потеряется)». И термин «fast-forward» у него отстутствует за ненадобностью.
>Есть и третий вариант решения, и именно его предложил defuz — forced push, например так:
>git push origin +master
Страшные вещи вы говорите, получается кто то практикует forced push для master, это очен-очень -очень плохо, если только это не форс-мажор…
>git push origin +master
Страшные вещи вы говорите, получается кто то практикует forced push для master, это очен-очень -очень плохо, если только это не форс-мажор…
«Тем не менее, иногда бывают случаи, когда это именно та операция, которая вам необходима. Но если у вас именно такой случай, и вы это понимаете, то вероятно эта статья вам уже давно не нужна.»
Вы же дочитали до этого места?..
Как уже было упомянуто, Git — система децентрализованная, что тоже важно. Но если вы один на один со своим репозитарием — то конечно сам себе хозяин, и помешать кому-то ещё — тяжело :)
А для новичков, читающих статью для повышения своего уровня — да, рекомендация именно такая: по возможности не использовать forced push и rebase.
Вы же дочитали до этого места?..
Как уже было упомянуто, Git — система децентрализованная, что тоже важно. Но если вы один на один со своим репозитарием — то конечно сам себе хозяин, и помешать кому-то ещё — тяжело :)
А для новичков, читающих статью для повышения своего уровня — да, рекомендация именно такая: по возможности не использовать forced push и rebase.
вот я и говорю, формулировка «по возможности не использовать forced push и rebase» применительно к мастеру должна звучать примерно так «никогда не ребазируйте ветку master, слышите НИКОГДА! „
на счет других веток — “Ребейзь @ Мощно пуш» без ограничений ну и конечно надо коллег предупреждать если кто то с этой веткой ещё работает. Всё никаких больше ограничений.
на счет других веток — “Ребейзь @ Мощно пуш» без ограничений ну и конечно надо коллег предупреждать если кто то с этой веткой ещё работает. Всё никаких больше ограничений.
PS1: Для просмотра истории очень удобно использовать «gitk -a» (linux)
Почему только Linux? В Windows тоже прекрасно работает.
Ну я не использую Windows, потому не в курсе, и написал только о том, что точно знаю сам.
Спасибо за информацию, внёс в статью.
Спасибо за информацию, внёс в статью.
… И в OSX это тоже работает :). Кроссплатформенность, однако.
И это тоже добавил, спасибо.
Для OSX есть gitx, который симпатичнее и удобнее.
Sign up to leave a comment.
Что такое «git push problem: non fast forward»