Здравствуйте, Hobbes, Вы писали:

vsb>>А почему должна быть одна? checkout просто вытаскивает указанный коммит. Ветка это указатель на коммит.
H>Какой воркфлоу предполагает вытаскивание отдельных коммитов? Все работают с ветками.
Много каких. Например, если есть production-ветка и туда надо замерджить hotfix из dev-ветки вот прямо сейчас.

Ну и весь workflow с pull request'ами, фактически, тоже работает с отдельными коммитами.

M>Есть два типа программистов:
M>
M>те, кто пользуется консолью и для них git, cmake и много что еще проще запустить через консоль и не понимают, зачем нужен GUI для git,

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

НС> Не понимаю этого надрачивания на историю.

Потому что не надо на нее надрачивать

ИМХО: мне лично рибейс нужен, когда я что-то пилю в своем бранче, а в основную ветку уже смерджили какие-то сторонние изменения. Мне банально проще сделать rebase своего бранча, чтобы нормально разрулить мердж-конфликты (если они есть) только моих изменений, а не гадать, где мои изменения косячат, где чужие, где гит не понял, что делать. То есть использую эквивалетно

git checkout <основная ветка>
git pull
git checkout -b <новая ветка>
git cherry-pick <коммиты моих изменений>
git push

Это особенно хорошо помогает, когда что-то разрабатывается с нуля несколькими людьми, и изменения и рефакторинги могут затрагивать одни и те же куски кода. Меньше шансов остаться с кусками неправильно смердженных кусков.

M>>Есть два типа программистов:
M>>
M>>те, кто пользуется консолью и для них git, cmake и много что еще проще запустить через консоль и не понимают, зачем нужен GUI для git,

M>Среди этого типа по странному стечению обстоятельств находится большинство закостенелых и зашоренных, но тем не менее считающих себя элитой и пупами земли.

Я бы поспорил, где больше "закостенелых и зашоренных", среди тех, кто пользуется только GUI, ибо не осилил консоль или среди пользователей консоли. Но, во-первых, это оффтоп, а, во-вторых, вряд ли это будет полезный конструктивный разговор.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Я не защитник hg, но ребейзом и в гите не пользуюсь. Не понимаю этого надрачивания на историю.

Слышал вариант, что упрощает формирвоание changelog для новой версии.

Здравствуйте, Sharov, Вы писали:

S>Слышал вариант, что упрощает формирвоание changelog для новой версии.

Ченджлог надо не по истории гита делать, а по трекеру.

Здравствуйте, alexzzzz, Вы писали:

A>Как в Fork внутри изменившихся файлов отмечать индивидуальные изменения, какие включать в следующий коммит, а какие оставить на потом? В TortoiseHg можно галочками прямо внутри текста.

Я не советую TortoiseHG сравнивать с другими оболочками Git-а.
Невероятно, но уровень TortoiseHG просто недостижим все оставльным.
Уже перепробовал практически всё, что можно.
Осталось только платных попробовать (Tower, SmartGit, GitKraken) и разочароваться полностью получить хоть какое-то подобие.

Из реально удобного это Git Extensions, но он только винда и периодические баги с падениями.

Здравствуйте, ·, Вы писали:

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

Bookmarks похоже на то как работает Git.
Уникальностью названий веток на сервере нужна и в Git-е, когда работают с центральным репозиторием.

·>Многоголовость веток — вообще тихий ужас, если требуются distribtued сценарии использования.
Было дело, наткнулись на такое
В последних версиях починили и стало получше, но всё равно у нас правилом хорошего тона считается закрывать ветки слияниям в мусорную ветку.

Здравствуйте, Hobbes, Вы писали:

H>Какой воркфлоу предполагает вытаскивание отдельных коммитов? Все работают с ветками.

Ни разу не делал черрипик при выпуске хотфиксов?

Здравствуйте, ·, Вы писали:

·>Они были кривыми потому что основывались на svn и hg соответсвенно, которые из-за своих корявостей не могли обеспечить полноценную distributed разработку. Так что github победил как раз благодаря git. Gitlab не успел, т.к. банально появился позднее и всегда был в догоняющих.
У Gitlab сейчас своя ниша есть: это сервер на стороне клиента. У Github такого же нет. Особенно актуально для России.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Я не защитник hg, но ребейзом и в гите не пользуюсь. Не понимаю этого надрачивания на историю.
1. Или ты никогда не ошибаешься.
2. Или у тебя есть коммиты, которые не собираются (или имеют другие проблемы, которые легко исправить с помощью git rebase).

Первый пункт можно исключить, остается не очень хорошая история в духе: "Fix previous commit"

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ченджлог надо не по истории гита делать, а по трекеру.
Трекер вторичен к системе контроля версий, например github/azure умеет автоматически закрывать задачи при вливании пулл-реквеста.

Здравствуйте, Skorodum, Вы писали:

S>Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>Я не защитник hg, но ребейзом и в гите не пользуюсь. Не понимаю этого надрачивания на историю.
S>1. Или ты никогда не ошибаешься.
S>2. Или у тебя есть коммиты, которые не собираются (или имеют другие проблемы, которые легко исправить с помощью git rebase).

S>Первый пункт можно исключить, остается не очень хорошая история в духе: "Fix previous commit"
Из-за безоглядного rebase + push --force много начинающих программистов теряют недельный труд.
Поэтому появились защищённые ветки, где историю менять нельзя и там внезапно появляются коммиты исправления исправлений

Здравствуйте, _NN_, Вы писали:

_NN>Из-за безоглядного rebase + push --force много начинающих программистов теряют недельный труд.
Так ведь rebase и не меняет историю основной (master) ветки. Тем более, если для сервера стоит only fast-forward.
А недельный труд всё равно остаётся в reflog.

Здравствуйте, Clerk, Вы писали:

C>Здравствуйте, _NN_, Вы писали:

_NN>>Из-за безоглядного rebase + push --force много начинающих программистов теряют недельный труд.
C>Так ведь rebase и не меняет историю основной (master) ветки. Тем более, если для сервера стоит only fast-forward.
Для мастера додумались делать защищённую ветку по умолчанию.
Только это функция сервера, а не клиента.

C>А недельный труд всё равно остаётся в reflog.
Да, но всё равно неприятно. К тому же не все это знают

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ни разу не делал черрипик при выпуске хотфиксов?

Нет, не делал. Ветка с релизом и фиксами мерджится в мастер. Либо ветка с отдельным хотфиксом мерджится в мастер и ветку релиза.

Здравствуйте, _NN_, Вы писали:

_NN>Только это функция сервера, а не клиента.
Вроде можно и на клиенте:
git config --global merge.ff only

Здравствуйте, Skorodum, Вы писали:

НС>>Ченджлог надо не по истории гита делать, а по трекеру.
S>Трекер вторичен к системе контроля версий,

Зато больше подходит к задаче.

S> например github/azure умеет автоматически закрывать задачи

Лучше скажи кто не умеет этого делать.

Здравствуйте, Skorodum, Вы писали:

НС>>Я не защитник hg, но ребейзом и в гите не пользуюсь. Не понимаю этого надрачивания на историю.
S>1. Или ты никогда не ошибаешься.
S>2. Или у тебя есть коммиты, которые не собираются (или имеют другие проблемы, которые легко исправить с помощью git rebase).

Зачем их исправлять? Это реальная история изменения кода, она имеет определенную ценность.

Здравствуйте, _NN_, Вы писали:

_NN>Из-за безоглядного rebase + push --force много начинающих программистов теряют недельный труд.

Это ж насколько надо не знать и не уметь Git, чтобы 1) потерять данные такими командами, 2) вообще их запускать там, где что-то может быть не сохранённым?

Хотя я согласен с наличием проблемы в том, что обычные хаутушки по Git, написанные ламерами для чайников, упускают принципиальные моменты в построении рабочей обстановки. Это как раз случай "кто не умеет работать — учит".

_NN>Поэтому появились защищённые ветки, где историю менять нельзя и там внезапно появляются коммиты исправления исправлений

"Поэтому" не следует в эти ветки пихать промежуточные результаты локальной возни.