DR
При rebase есть шанс потерять что-нибудь из изменений. Но если понимать что делаешь и количество изменений не большое - то rebase сильно улучшает читаемость истории
Size: a a a
2021 June 10
DR
Нет, не совсем про одно. Rebase хорош, скажем, чтобы подтянуть в feature-ветку свежие изменения из мастера
AK
а, интересно
DR
Если использовать merge - получится каша из коммитов. А если rebase - будет лаконично.
DR
Но в конечном итоге feature-ветка именно мержится в мастер
AK
а можно вообще тогда от merge отказаться?
DR
Теоретически можно. Но за историей будет сложно следить: она будет плоской
AK
получается на master ты merge используешь, а для этого rebase?
DR
rebase я использую чтобы получить в feature-ветке изменения, которые за время разработки фичи произошли в мастере
DR
Например чтобы избавиться от конфликтов или погонять тесты
AK
да, это и имел ввиду
AK
паиба
B
C3W3
Проверьте, пожалуйста, работу
https://www.coursera.org/learn/unsupervised-learning/peer/ATLR5/vizualizatsiia-dannykh/review/2juIbcmqEeuLdw6WH3pXnw
Проверьте, пожалуйста, работу
https://www.coursera.org/learn/unsupervised-learning/peer/ATLR5/vizualizatsiia-dannykh/review/2juIbcmqEeuLdw6WH3pXnw
AD
достаточно часто принята практика при merge ветки в мастер схлопывать все коммиты в один
AD
особенно, если большой репозиторий и большая команда
AD
типа, создали ветку, в ней поработали, создали кучу коммитов, но когда мерджим в мастер - хотим чтобы оно попало туда одним коммитом
AD
вот чтобы это было возможно - можно в feature-ветке использовать только reabse, но не merge
AD
при merge ты сравниваешь изменения из двух меток, и вливаешь их одним отдельным коммитом
AD
а в rebase ты по сути правишь каждый из коммитов, но не создаешь новый
AD
это два разных инструмента - которые приводят к однму результату с точки зрения кода в репозитории, но разным с точки зрения истории изменений (коммитам) - и выбирать следует исходя как раз из того, чтобы история изменений была понятной - в одних случаях это должен быть merge, в других - rebase