mas.to is one of the many independent Mastodon servers you can use to participate in the fediverse.
Hello! mas.to is a fast, up-to-date and fun Mastodon server.

Administered by:

Server stats:

12K
active users

#rebase

0 posts0 participants0 posts today

Я вроде бы уже спрашивал, но что-то не нашел у себя заметок на эту тему. Все чаще вижу, что люди везде и всюду используют #git #rebase вместо #git #merge.

tl;dr Нужен очень подробный и детальный мануал по переезду с merge на rebase.

У всех основная и чуть ли не единственная причина использования rebase - красота истории. Меня красота истории не волнует, меня полностью устраивает линейность и последовательность merge. Я несколько раз пробовал использовать rebase, но это вызывает то фантомные боли, то утерянные изменения. И оказывается, что для красоты истории надо прикладывать усилия с перемещениями и сжатиями коммитов. В моем мировоззрении все только в пользу merge. В заметках осталась ссылка о том, что merge полезнее, но сайт больше не доступен - itnan.ru/post.php?c=1&p=340558

Но я в очередной раз наткнулся на фразу "я перешел на сторону тех, кто использует только rebase" и в очередной раз хочу попробовать rebase. Но мне нужен очень хороший разбор что делать в ситуации А, а что делать в ситуации Б. Хочу выработать новую привычку в разработке, но самостоятельно не получается. Базовые сравнения merge vs rebase, которые легко гуглятся, мне не помогают.

Находил статью по использованию rebase update-ref, там реально интересные случаи описаны и полезная причина использовать так andrewlock.net/working-with-st

В общем @tech помогай, пожалуйста.

Я честно хочу научиться работать с ветками как сейчас модно, через #git #rebase. Но я сломался даже на порядке аргументов.
Читаю всякие мануалы, там надо переключиться на ветку to и сделать ребейз из ветки from. Вроде ок, но происходит какая-то херня. Через раз ловлю, что у меня перекрученный статус в ветке: 1 впереди, 1 позади. Читаю официальную документацию, там надо делать наоборот: надо из ветки from вызвать на ветку to. Вообще ничего не происходит, up to date. Думаю, ладно, сделаю самым правильным способом git rebase <from|to> <to|from>.
Начал искать в каком порядке ставить ветки и вообще не нашел информации. В одном случае надо первым аргументом ставить origin, а вторым аргументом ветку to. В другом случае from to, в третьем случае to from. Я просто запутался во всем этом. Зачем эта "красивая" история коммитов? Что там надо спрятать? В чем сакральный смысл? Есть абсолютно нормальный merge. Вот отсюда отсоединились, вот сюда присоединились, вот такие коммиты были. Граф можно строить, видеть процесс работы в ветке.

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

I'm working for the first time on a project where our team prefers to rebase instead of merge commits.

It seems cool, but the more I use this workflow, though, the less I like it.

Example: I'm on a feature branch with 3-4 commits. I need to sync with main. Rebase applies commits one at a time, so I now have to resolve conflicts 3-4 times. I'm now repeating this error-prone process multiple times instead of once.

I'm trying to keep an open mind. So, What am I missing?

Another update regarding the 3.7.1 rebase from your local @gperson:

Unfortunately, I've decided that our light and dark themes will not be re-added during the initial rebase. I'm quite done dealing with upstream's theming system, which has only gotten...better, I guess?

Instead, they'll be added once the theme system rewrite is complete. That way, themes will be much easier to deal with.

Prochain webinaire "Git rebase" jeudi 19 décembre 2024 de 13h30 à 14h !

Je tente le format court pour faciliter la participation. Ça sera intense et chargé d'exemples lives.

C'est gratuit, et pour les inscriptions, c'est par ici :

linkedin.com/events/webinaireg

(Je tente linkedIn live, en attendant de trouver chaussure à mon pied dans l'univers du libre pour le live streaming).

www.linkedin.comWebinaire Git : comprendre et bien utiliser "git rebase" | LinkedInLa commande rebase est le couteau suisse de Git. Son potentiel est cependant méconnu, voire incompris. Faisons ensemble un petit tour d'horizon de son potentiel.

Git rebase is awesome. At most companies I worked for, git was used as a backup tool more than a version manager / collaboration tool. So I never really learned it well. The past few days I’ve been reading the pro git book. Yesterday I played around with interactive git rebase to squash a few commits and reword the message of the remaining commit. It’s actually not that difficult, you just need to take a little time and not rush through concepts #git #rebase #programming

I just lost an entire #script I had written and added to my #git repository not realising that I was in #rebase mode and did a `git rebase --abort`. I didn't appear in `git reflog`, simply lost.

`sudo grep -ab "someurl.project" /dev/mapper/data` gave me the offset and `sudo dd if=/dev/mapper/data bs=1 skip=$((1462413094-2000)) count=5000` gave me the files content.

#linux#dd#grep

Some items added to the Basket of Goods are Air Fryers, Delivery Charges, and Milk and Meat Substitutes. Some items that have been removed include Landline Telephones, Swiss Rolls, and E-readers. cso.ie/en/releasesandpublicati
#CSOIreland #Ireland #CPI #ConsumerPrices #Inflation #Deflation #Prices #BusinessStatistics #Business #BusinessNews #IrishBusiness #Rebase

Warm take: I'm pretty much done with #git rebase.

I get the argument that the merge commits represent a cluttering of history, but ultimately I don't agree.

To me, the act of updating my branch with the latest from master represents a change, and I want that change recorded.

Not saying I'd refuse if a team I was on ever DEMANDED I rebase, just saying that for my money it's a bucket of faff for zero actual gain.

#git #philosophy #rebase #sucks :)