Version control - make new branch from specific commit
Спрашиваю для системы контроля версий типа TFS или Azure DevOps, но также интересует вообще в принципе для любой системы.
Можно ли загрузить себе проект или начать новую ветку в состоянии определённого коммита? Похоже, что у Azure DevOps нельзя. Т.е. получается, что версия - это ветка, и можно загрузить лишь последнюю версию (т.е. последний коммит) ветки?
А если кто-то налажал и загадил ветку плохим коммитом? Всем придётся с ошибками грузить и исправлять самим?
Вообще, логичная задача вроде - загрузить с определённого коммита. А нельзя. Ну или не знаю как.
Насколько я понял, идея в Гите такая. Каждый загружает себе из репы-общака последнюю и типа отлаженную копию - которая без порожняков, подлян и лишнего базара. И после правок шхерит сначала у себя локально (локальный коммит), а потом шлёт маляву (пулл реквест) на слияние своей шняги (коммита) с общаком. Старшаки или смотрящие проверяют его маляву, и если она ровная и без подлян - дают добро на ввод его шняги в общак.
Так вот, некоторые кенты позволяют себе гнать порожняковые шняги в общак в обход маляв - сразу коммит в главную репу. Поэтому иногда паханы решают, что все такие потенциально порожняковые шняги должны быть сначала зашхерены в отдельных малых общаках (ветках). Пусть мол кент там гоняет любые порожняки, экспериментирует, а потом поглядим, сливать ли его малый общак в большой (мержить). Ну и раз мы защитились на уровне общаков (веток), то на уровне шняг (коммитов) создать новый общак нельзя. Или я неправильно понимаю?
Бранч я и так сделал давно. Но делать бранчи на каждый чих неудобно. А удобно было бы с любого коммита чекаутнуться. Я же написал, что допустим ошибся и сделал плохой коммит с ошибками, и не могу вспомнить всех мест, где эти ошибки сделал, чтобы откатить код "вручную", просто поправив его в нужных местах. Т.е. я хочу откатиться на коммит назад - на версию без ошибок. По вашей логике, я должен на каждый коммит новый бранч начинать.
Я хочу, чтобы было как в приложухах ctrl+z, только для коммитов. Так понятно?
Какой смысл иначе коммитов, если с любого из них нельзя получить версию репы до конкретно этого коммита? Просто задокументировать изменения?
Если система контроля версий знает, какие изменения были на каждом коммите, то она может мне весь проект на состоянии любого коммита предоставить. Так какого она это не делает?
Я прошу какую-то очевидную элементарщину. Почему этого нет из коробки?
Но делать бранчи на каждый чих неудобно
А в чем проблема то? Бранч на таску как раз самое то что надо
И что откатываться нужно по 10 раз на день у Вас?
Т.е. я хочу откатиться на коммит назад - на версию без ошибок
Ну так нет проблем, только потом оказываешься в "воздухе". И вот с этого то "воздуха" и нужно как то выйти
Вот тест сделал для наглядности.
Тест2 последний коммит, хочу вернутся на reformat
Возвращаемся через чекаут, хотя правильно было бы новый бранч сделать, хотя есть и другие варианты
Вот делаем изменения
Похоже, что у Azure DevOps нельзя
Как это?
https://azure.microsoft.com/en-us/services/devops
Видимо имеется в виду веб клиент для "Azure Repos". А кто заствляет именно им пользоваться?
Доки взаместо фени читать нужно...
Дед, вам семь знаков платят за знание, куда нужно ударить (по идее), а не за общие слова "читай мануалы". Я спросил, как скачать себе репу с конкретного коммита. Ок, пусть будет новая ветка, но с конкретного коммита. Куда ударить?
))
Но делать бранчи на каждый чих неудобноА в чем проблема то?
Ну в принципе да, логично - если ты начал что-то переписывать с конкретного коммита, то все коммиты выше же не будешь править из-за твоей правки (ну т.е. можно смерджить, но это, как я понимаю, отменяет все остальные коммиты в ветке, куда мерджишь свою? - т.е. теперь твоя ветка главная) - по-любому ты создаёшь свою ветку. Оно так и делается - каждое скачивание репы создаёт локальную ветку. Просто я привык всегда коммитить в мастер ветку и забыл про эти детали.
Возвращаемся через чекаут, хотя правильно было бы новый бранч сделать, хотя есть и другие варианты
А, т.е. с конкретного коммита - это именно чекаут. А я думал, там clone, или pull или ещё какая-то команда.
Да, мануалы я ещё плохо знаю, но я и не претендую пока на семь знаков - даю пока свободно вздохнуть разным дедам. А читал бы мануалы, в спину бы им дышал, нервишки бы им портил. ))
Видимо имеется в виду веб клиент для "Azure Repos". А кто заствляет именно им пользоваться?
А мне показалось, там больше опций, чем в гит-клиент, встроенный в Студию?
каждое скачивание репы создаёт локальную ветку
А что понимать под этим?
всегда коммитить в мастер ветку
Ужос. Никто не коммитит обычно в мастер ветку, только когда новая production версия.
Для этого есть или "своя" ветка или "девелор"
https://www.gitkraken.com/learn/git/best-practices/git-bra...
Да, мануалы я ещё плохо знаю
Не обязательно все гит команды знать, нужно просто "правильный" клиент пользовать.
там больше опций, чем в гит-клиент, встроенный в Студию
не имею понятия, ни тем ни другим не пользуюсь.
Куда ударить?
-----
В документацию, однако...
Сначала на предмет возможностей, затем на предмет параметров коими они достигаются и наконец вернутся сюда с вопросом почему в доках написано так, делаю так, а получается не то...
И не забудь про обновления винды...
Ужос. Никто не коммитит обычно в мастер ветку, только когда новая production версия.
Для этого есть или "своя" ветка или "девелор"
Я так понимаю, что нужно при этом изолировать код, над которым ты работаешь? Ведь если смержить потом, то код из одной ветки должен затереться кодом другой. Т.е. все должны договориться, что этот кусок не трогают, потому что Вася там эскпериментирует и кодит, и потом, если всё пойдёт удачно, мы его ветку смержим с главной? Или кто-то должен раздать права на редактирование.
При коммитах в одну ветку всё просто - самый последний коммит затирает все предыдущие. Не в смысле удаляет, а в смысле его изменения главные.
При коммитах в одну ветку всё просто - самый последний коммит затирает все предыдущие. Не в смысле удаляет, а в смысле его изменения главные.
Нет, система контроля версий так не работает.
когда несколько человек параллельно поработали над одним куском кода и конечная версия не у всех одинаковая, то при merge вылазит конфликт.
Сдаётся мне, товарич ищет (и не может найти) команду
git revert
чтобы "убрать изменения последнего коммита с ошибками".
А вообще, понимания что такое репозитори, коммит, бранч в его фенеподобной чуши не наблюдается. Ну так и немецких программиздов старше 50, которые понимают что и как надо делать в гите, процентов 10. Люди привыкли к Dimensions,Synergy или тому подобному уродству из 90-х :) То же самое - "а зачем мне бранч а если я там поправлю то же что и другой, это же катастрофа!" (да здравствуют локи из Synergy!)