push не master ветки с rebase без --force

Ты хочешь master ребейзить на feature??

Обычно ты делаешь наоборот. Заходишь в feature, ребейзишь на мастер. Получаешь конфликты, фиксишь их, делаешь rebase --continue. После этого можно делать merge обратно в мастер и мастер ни у кого не поломается

rebase я делаю в самом feature. Мерджу коммиты и тд. Потом уже всё это дело буду мерджить в мастер.

Вопрос в том, сломается ли мастер из-за того, что я уже делал rebase в feature.

Вопрос в том, сломается ли мастер из-за того, что я уже делал rebase в feature.

Нет

смерджить
rebase

facepalm.tar.z

Прочитать тему полностью слабо?

Не пойму негодование того анонима. Разве в конце не следует merge в любом случае? (когда фича закончена)

Вопрос: сломается ли master (нельзя будет сделать pull) у всех, у кого есть копия репозитория, если я сделаю merge ветки с rebase?

Нет.

И как вообще поступать в случае, когда нужно делать rebase в feature ветках?

Так и поступать - причёсывать ветку как душе угодно, потом вмержить в master.

То есть ничего страшного в использовании push -f не на master нету?

Правила одинаковые для всех веток. Если из ветки кто-то обновляется, нельзя переписывать её историю (в данном случае значит делать rebase и push -f), поскольку это создаст проблемы при обновлении. Если из master обновляются, не ребейзи мастер. Если из твоей ветки обновляются, не ребейзи свою ветку. Если не обновляются, можешь ребейзить что хочешь. Мерж не переписывает историю ветки в которую мержат, поэтому мержить всегда можно что угодно.

push -f страшен когда история ветки расшаривается с кем-то ещё

поэтому он категорически запрещен для мастера

Для feature-ветки же всё зависит от того как ты её используешь:

Если это _твоя_ ветка, никто кроме тебя её не выгружал никогда, то push -f никакой проблемы не составляет и наоборот рекомендуется, чтобы приводить в порядок историю ветки перед выкаткой на ревью.

Если же это ветка команды, которая работает над фичей, то есть по сути «мастер этой фичи», то за push -f туда тебе оторвут руки.

Нет.

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

хочу причесать коммиты, через rebase, но это приведёт к использовать push -f.

/0

ОП, можешь плз пояснить откуда такие выводы?

нужно делать rebase

линейная история не нужна

Пусть лучше в репозитории половина коммитов будет мерджами?

У нас вот в проекте есть пачка любителей всё разрабатывать прям в мастере, а потом делать until git pull && git push; do echo «Retrying...»; done из-за чего мой git log --first-parent выглядит как говно.

А как иначе? Если бранчу отребейзить на мастер, то бранча на сервере разойдётся с локальной. Соответственно, чтобы эту бранчу отправить на сервер — нужно делать push -f.

Я в таком случае делаю push -f origin HEAD, чтобы запушилась только текущая ветка и ничего другого случайно не попало.

Форс пушить свою ветку это нормально. Это никому не мешает. Все так делают

Пусть лучше в репозитории половина коммитов будет мерджами?

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

всё разрабатывать прям в мастере, а потом делать until git pull && git push; do echo «Retrying...»; done

Эти неосиляторы (git fetch; git rebase) пытаются сделать линейную историю, а я за feature branches.

Так о чём ты тогда спрашиваешь?

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

Вопрос: сломается ли master (нельзя будет сделать pull) у всех, у кого есть копия репозитория, если я сделаю merge ветки с rebase?

ОП хочет поребейзить свою ветку на мастер и запушить свои патчи в мастер.

Кто-нибудь здесь вообще читал вопрос ОПа?

rebase я делаю не на мастере. А после rebase уже будет merge на мастер.

push -f лучше не делать никогда.

Если нужно поменять свою ветку, то git push origin +HEAD:feature_branch (плюсик перед веткой это таком микро --force для единственной ветки).

Переписывать общие ветки тоже можно, но это нужно делать, когда хорошо понимаешь, что ты делаешь, зачем и к чему это приведет, а тогда вопросов на форумах ты задавать не станешь, т.к. и там сам все знаешь.

А как эта фича называется, чтобы загуглить.

На мастере можно делать только пулл.

Варианта два:

 
git checkout my-branch
git rebase master
# fix possible issues
git push origin my-branch --force
# create pull request on github or use `git review` or ask commiter to merge

Если можешь и хочешь пушить в мастер:

git checkout my-branch
git rebase master
#fix possible issues
git push origin my-branch:master # NO FORCE!

Тогда история будет ровная и линейная и никто не будет бить по рукам за поломаный мастер

git push origin my-branch:master

Это что за чудо такое?

Я хочу сделать вот что: у меня есть devel бранч с десятью коммитами. Я хочу, допустим, превратить их в 5 и уже эти 5 влить в мастер.

В общем есть у меня Cargo.toml, в котором я прописываю git зависимости, пока сижу в devel, потом, перед merge, я меняю зависимости на стабильные. Вот я и не хочу, чтобы в master оказался коммит, в котором Cargo.toml содержит git зависимости.

А как эта фича называется, чтобы загуглить.

Не знаю, как называется, но гуглить нужно так: git push --help в самом начале описываются OPTIONS и вторая опция <refspec>.

P.S. man сейчас недооценивают.

git push origin my-branch:master

Это что за чудо такое?

У меня такое ощущение, что мы с тобой про разные git говорим. Когда я его осваивал, «это чудо» было первым о чем я узнал. Тут написано git push <remote_name> <local_branch_name>:<remote_branch_name>. Все что в скобках - опциональное. Более того, раньше ветку на сервере можно было удалить только через :remote_branch_name.

поребейзить свою ветку на мастер

Форс пушить свою ветку это нормально.

Ну вот, собственно.

Вот я и не хочу, чтобы в master оказался коммит, в котором Cargo.toml содержит git зависимости.

О, при таком подходе он там стопроцентно окажется. Не в этот раз, так в следующий.

Надо держать отдельную конфигурашку, только у себя. И указывать, какую из них программа должна использовать, через опции командной строки или что-то вроде. И твоя локальная конфигурация вообще никогда не должна попадать ни в один коммит, никогда. Хорошо бы вообще в .gitignore её добавить.

У нас используется typesafe config, который позволяет заинклудить основную конфигурацию и переписать отдельные параметры. TOML, вроде бы, так не умеет, там надо всё копировать, а лучше скриптом собирать.

Если я собрал с git версией, а залил со стабильной, то у меня CI не пройдёт. Ему тоже нужен git. Вот эти пляски и хотелось бы исключить из истории.

То есть если кто-то потом попробует собрать этот коммит, то он будет собирать уже со стабильными зависимостями, который уже давно были добавлены в репозиторий. А если там останутся git зависимости, то есть шанс, что текущий master сильно отличается от той древней версии.

Хз как лучше это организовать.

Я конкретно про «my-branch:master». Я такую запись почти не встречал.