Относился не очень, и сознательно не включил математику в список дисциплин, за которые вручают премию имени его. По слухам, из-за того, что какой-то математик успешно приударил за Нобелевской женой.
Ну, не всегда это проблема. Если вливаемая ветка находится в последней редакции и после мержа будет удалена, то rebase возможен и иногда приветствуется. Просто надо отчётливо представлять, что при этом произойдёт. А сформировать такое представление без практики ребейза вряд ли получится. :)
В нашем случае две ветки ориентированы на разные версии Unity, 2018.4 и 2019.4. Практика показала, что если попробовать переключиться с 2018 на 2019 Editor просто будет долго думать, а при переходе с 2019 на 2018 проще удалить всю папку и зачекаутить её — иначе возникает множество глюков, не всегда заметных с первого взгляда. Дешевле в плане времени загрузки просто держать их в разных папках.
Есть несколько моментов. Если пытаться работать одновременно с несколькими ветками и делать stash в нескольких, то после переключения на исходную ветку сильно задумываешься, что нужно применить вместо git stash pop. Если стешить совсем небольшие изменения, то можно вообще не вспомнить, что делал стеш, и потом сидишь и удивляешься, почему результат не тот. А окончательно я решил для себя вопрос, когда как-то раз stash сохранил изменения только в модифицированных файлах, а те которые были untracked — безвовратно протерялись (про то, что их надо было отдельно включать через --include-untracked я тогда не знал). Так что текущие изменения в ветке, которые в любом случае в неё попадут, проще сразу коммитить, пусть даже во временный коммит.
А вот stash удобно пользоваться для хранения хаков, которые можно применить к любой ветке и потом не жалко откатить перед "настоящим" коммитом.
"wip" — аббревиатура от "work in progress", используется как плейсхолдер и на гит никак не завязано. Да, это я как-то погорячился, упомянув его без расшифровки.
А вот интересно было бы послушать, на самом деле. Про "базовые" лайфхаки много пишут, а про продвинутые меньше. У гита есть ещё порох много заначек; про тот же git commit --fixup я например только из этой статьи узнал.
Вам спасибо за поднятие интересной и полезной темы.)
В этом-то и задумка. А ещё если локальные изменения не пересекаются с входящими (затронуты разные файлы, и в вашей ветке сверху нет незапушенных коммитов), то по идее такой pull должен прокатывать как fast-forward.
Этот подход успешно работает вместе с правилом: что бы ни делал (ну, за исключением коммитов на одну строчку) — создавай новую ветку. Пришла пора вмержить основную к себе или свою в основную — да пожалуйста. Надо срочно переключиться на основную не вливаясь — делаешь в текущей сверху коммит wip в который включаешь все текущие изменения, спокойно переключаешься на основную. А когда возвращаешься, этот wip откатываешь и продолжаешь как ни в чём не бывало.
А про fetch, кстати, многие забывают или не знают про такую классную опцию как --prune — вместе с выкачиванием новых веток/коммитов, она удаляет те, которые были удалены на сервере (имеются в виду remote-ветки. Ваши локальные чекауты останутся нетронутыми).
Странно, что совсем не упомянуты хуки. Инструмент, которым я пользуюсь каждый день — привычка называть ветки единообразно, типа "my_feature_PRJ-001", где PRJ-001 — номер задачи в жире/редмайне, плюс миниатюрный скрипт commit-msg, который номер задачи подставляет в начало сообщения коммита. Если есть интеграция с ишью трекером, очень удобно смотреть что делают другие и вспоминать, а что делал сам.
О, о, а ещё есть такая суперская вещь как git update-index --assume-unchanged <path to file> — изменённый файл перестаёт отображаться как изменённый и соответственно нигде в гите не всплывает до тех пор, пока не приходят коммиты с этим же файлом или вы не решаете отредактировать его ещё раз. Очень помогает, если в вашем репозитории есть отслеживаемые конфиги, а вы у себя хотите держать их альтерированную версию и не хотите, чтобы они мозолили вам глаза.
Я обожаю гит и его возможности для упрощения себе жизни, простите. >_<
Есть потрясающая опция git config --global pull.ff only — пулл делает только fast-forward и фейлится, если он этого не может сделать. Это избавляет от необходимости контролировать каждый fetch+merge и при этом защищает от пулла не в ту ветку.
Первая серия понравилась, но чем дальше тем страньше. Ладно ещё все эти теории заговоров; когда показали чудо-машину, которая может просканировать объект вплоть до квантовых состояний — стало понятно, что с "научностью"/обоснованностью покончено. Они ведь за одну только её могли получить Нобелевскую премию и их бы даже никто не спросил, а зачем она им нужна. (А может получили? Деньги-то у компании откуда-то были.)
Ох, лучше бы Грега Игана экранизировали. Есть мнение, что им и вдохновлялись, но в таком случае лучше бы придерживались ближе к тексту. Его "Карантин" хоть и с противоположного конца заходит к квантовой физике, зато обладает более внятной завязкой и проработанным миром. Даже если перенести только идею без сеттинга целиком, можно было бы практически при то же визуальном оформлении сделать более интересный и обоснованный сюжет. А ещё есть "Синглтон", в котором вопрос свободы воли идёт главной темой.
Пачка спойлеров
"Карантин": В мозгу (не чьём-то конкретном, а вообще) находят некую железу, которая отвечает за "схлопывание" квантовой функции, в результате чего мы постоянно живём в одном-единственном мире. Внезапно, если эту железу выключить, человек получает возможность сознательно выбирать любой из исходов квантовой ситуации вплоть до того, что он может пройти через закрытые двери (замки на которых случайно ломаются), мимо нескольких охранников (отвернулись) и камер наблюдения (помехи во весь экран). Бэкграунд описывать не буду, сами почитайте.
"Синглтон": А тут наоборот, люди не умеют выбирать и по умолчанию выбирают все варианты одновременно, рождая бесконечность Вселенных по каждому вопросу. Чтобы обрести подлинную Свободу Воли (tm), изобретают т.н. квасп, который волновую функцию сознания хранит в себе и каким-то образом (не помню каким именно) даёт на выходе единственный вариант выбора в любой из возможных Вселенных.
Вот вам например утилита для Windows от довольно-таки распространённого производителя SSD. В своё время переносил систему ей, причём на свой страх и риск делал это из под этой же системы, не загружаясь с внешней флешки.
Наверняка есть и другие, для SSD других производителей/других ОС и так далее.
Для SSD распространены всякие утилиты, которые позволяют клонировать существующий раздел, даже если они отличаются размерами. Можно перенести всё что есть без переустановки, самое главное не ошибиться с буковками, чтобы новый диск остался старым c:\ и пути не слетели
Я тут ввиду самоизоляции начал пользоваться домашним ноутом как рабочим и внезапно обнаружил, что Win10 + Unity + Visual Studio кушают все 8 Гб оперативки и даже запускать браузер становится опасно, тормозит всё. Докупил оперативки, 8 Гб превратились в 32 ещё и большей частоты, и теперь я могу держать несколько открытых солюшенов, юнити, браузер, и ещё остаётся, и при этом ничего не тормозит! Я, честно говоря, охренел что так можно было.
Я вот сейчас рискую сказать глупость, но идея интересная. А ещё более глупое интересное, что с айтишным подходом можно написать юнит-тесты для конституции и для законов вообще. Если в достаточной мере их формализовать, можно в виде тестов оформить тезисы, которые должны будут выполняться, и при нарушениях которых можно быстро понять, что с законами что-то не так.
На правах рандомного примера. Тезис (== статья конституции): "Каждое убийство должно быть наказано". Если какая-либо комбинация законов позволяет этот тезис нарушить, значит конституция не работает.
Б-же, а представляете, что может стать доступным? Удобная навигация по законам, статический анализ, подсветка в VS Code, автодополнение, простите, я замечтался.
Проблема в том, что ограничено количество лайков за период времени, соответственно, если лайкать всех подряд, то половина лайков уйдёт на заведомо неподходящие варианты.
Относился не очень, и сознательно не включил математику в список дисциплин, за которые вручают премию имени его. По слухам, из-за того, что какой-то математик успешно приударил за Нобелевской женой.
Ну, не всегда это проблема. Если вливаемая ветка находится в последней редакции и после мержа будет удалена, то
rebaseвозможен и иногда приветствуется. Просто надо отчётливо представлять, что при этом произойдёт. А сформировать такое представление без практики ребейза вряд ли получится. :)Да, была такая опечатка, к настоящему моменту уже исправлена.
В нашем случае две ветки ориентированы на разные версии Unity, 2018.4 и 2019.4. Практика показала, что если попробовать переключиться с 2018 на 2019 Editor просто будет долго думать, а при переходе с 2019 на 2018 проще удалить всю папку и зачекаутить её — иначе возникает множество глюков, не всегда заметных с первого взгляда. Дешевле в плане времени загрузки просто держать их в разных папках.
Вот-вот, поддерживаю.
А вот не всё так однозначно.
Есть несколько моментов. Если пытаться работать одновременно с несколькими ветками и делать stash в нескольких, то после переключения на исходную ветку сильно задумываешься, что нужно применить вместо
git stash pop. Если стешить совсем небольшие изменения, то можно вообще не вспомнить, что делал стеш, и потом сидишь и удивляешься, почему результат не тот. А окончательно я решил для себя вопрос, когда как-то раз stash сохранил изменения только в модифицированных файлах, а те которые были untracked — безвовратно протерялись (про то, что их надо было отдельно включать через--include-untrackedя тогда не знал). Так что текущие изменения в ветке, которые в любом случае в неё попадут, проще сразу коммитить, пусть даже во временный коммит.А вот stash удобно пользоваться для хранения хаков, которые можно применить к любой ветке и потом не жалко откатить перед "настоящим" коммитом.
"wip" — аббревиатура от "work in progress", используется как плейсхолдер и на гит никак не завязано. Да, это я как-то погорячился, упомянув его без расшифровки.
А вот интересно было бы послушать, на самом деле. Про "базовые" лайфхаки много пишут, а про продвинутые меньше. У гита есть ещё
порохмного заначек; про тот жеgit commit --fixupя например только из этой статьи узнал.Вам спасибо за поднятие интересной и полезной темы.)
Я знаю точный текст этого сообщения —
(i % 2)В этом-то и задумка. А ещё если локальные изменения не пересекаются с входящими (затронуты разные файлы, и в вашей ветке сверху нет незапушенных коммитов), то по идее такой pull должен прокатывать как fast-forward.
Этот подход успешно работает вместе с правилом: что бы ни делал (ну, за исключением коммитов на одну строчку) — создавай новую ветку. Пришла пора вмержить основную к себе или свою в основную — да пожалуйста. Надо срочно переключиться на основную не вливаясь — делаешь в текущей сверху коммит
wipв который включаешь все текущие изменения, спокойно переключаешься на основную. А когда возвращаешься, этотwipоткатываешь и продолжаешь как ни в чём не бывало.А про
fetch, кстати, многие забывают или не знают про такую классную опцию как--prune— вместе с выкачиванием новых веток/коммитов, она удаляет те, которые были удалены на сервере (имеются в виду remote-ветки. Ваши локальные чекауты останутся нетронутыми).Странно, что совсем не упомянуты хуки. Инструмент, которым я пользуюсь каждый день — привычка называть ветки единообразно, типа "
my_feature_PRJ-001", где PRJ-001 — номер задачи в жире/редмайне, плюс миниатюрный скриптcommit-msg, который номер задачи подставляет в начало сообщения коммита. Если есть интеграция с ишью трекером, очень удобно смотреть что делают другие и вспоминать, а что делал сам.О, о, а ещё есть такая суперская вещь как
git update-index --assume-unchanged <path to file>— изменённый файл перестаёт отображаться как изменённый и соответственно нигде в гите не всплывает до тех пор, пока не приходят коммиты с этим же файлом или вы не решаете отредактировать его ещё раз. Очень помогает, если в вашем репозитории есть отслеживаемые конфиги, а вы у себя хотите держать их альтерированную версию и не хотите, чтобы они мозолили вам глаза.Я обожаю гит и его возможности для упрощения себе жизни, простите. >_<
Есть потрясающая опция
git config --global pull.ff only— пулл делает только fast-forward и фейлится, если он этого не может сделать. Это избавляет от необходимости контролировать каждый fetch+merge и при этом защищает от пулла не в ту ветку.Первая серия понравилась, но чем дальше тем страньше. Ладно ещё все эти теории заговоров; когда показали чудо-машину, которая может просканировать объект вплоть до квантовых состояний — стало понятно, что с "научностью"/обоснованностью покончено. Они ведь за одну только её могли получить Нобелевскую премию и их бы даже никто не спросил, а зачем она им нужна. (А может получили? Деньги-то у компании откуда-то были.)
Ох, лучше бы Грега Игана экранизировали. Есть мнение, что им и вдохновлялись, но в таком случае лучше бы придерживались ближе к тексту. Его "Карантин" хоть и с противоположного конца заходит к квантовой физике, зато обладает более внятной завязкой и проработанным миром. Даже если перенести только идею без сеттинга целиком, можно было бы практически при то же визуальном оформлении сделать более интересный и обоснованный сюжет. А ещё есть "Синглтон", в котором вопрос свободы воли идёт главной темой.
"Карантин": В мозгу (не чьём-то конкретном, а вообще) находят некую железу, которая отвечает за "схлопывание" квантовой функции, в результате чего мы постоянно живём в одном-единственном мире. Внезапно, если эту железу выключить, человек получает возможность сознательно выбирать любой из исходов квантовой ситуации вплоть до того, что он может пройти через закрытые двери (замки на которых случайно ломаются), мимо нескольких охранников (отвернулись) и камер наблюдения (помехи во весь экран). Бэкграунд описывать не буду, сами почитайте.
"Синглтон": А тут наоборот, люди не умеют выбирать и по умолчанию выбирают все варианты одновременно, рождая бесконечность Вселенных по каждому вопросу. Чтобы обрести подлинную Свободу Воли (tm), изобретают т.н. квасп, который волновую функцию сознания хранит в себе и каким-то образом (не помню каким именно) даёт на выходе единственный вариант выбора в любой из возможных Вселенных.
Вот вам например утилита для Windows от довольно-таки распространённого производителя SSD. В своё время переносил систему ей, причём на свой страх и риск делал это из под этой же системы, не загружаясь с внешней флешки.
Наверняка есть и другие, для SSD других производителей/других ОС и так далее.
Ну, загрузка ОС — это самое первое впечатление. А так быстрее работает
вообщевсё.А вообще — работает, ну и ладно.
Для SSD распространены всякие утилиты, которые позволяют клонировать существующий раздел, даже если они отличаются размерами. Можно перенести всё что есть без переустановки, самое главное не ошибиться с буковками, чтобы новый диск остался старым
c:\и пути не слетелиЯ тут ввиду самоизоляции начал пользоваться домашним ноутом как рабочим и внезапно обнаружил, что Win10 + Unity + Visual Studio кушают все 8 Гб оперативки и даже запускать браузер становится опасно, тормозит всё. Докупил оперативки, 8 Гб превратились в 32 ещё и большей частоты, и теперь я могу держать несколько открытых солюшенов, юнити, браузер, и ещё остаётся, и при этом ничего не тормозит! Я, честно говоря, охренел что так можно было.
Я вот сейчас рискую сказать глупость, но идея интересная. А ещё более
глупоеинтересное, что с айтишным подходом можно написать юнит-тесты для конституции и для законов вообще. Если в достаточной мере их формализовать, можно в виде тестов оформить тезисы, которые должны будут выполняться, и при нарушениях которых можно быстро понять, что с законами что-то не так.На правах рандомного примера. Тезис (== статья конституции): "Каждое убийство должно быть наказано". Если какая-либо комбинация законов позволяет этот тезис нарушить, значит конституция не работает.
Б-же, а представляете, что может стать доступным? Удобная навигация по законам, статический анализ,
подсветка в VS Code, автодополнение, простите, я замечтался.Проблема в том, что ограничено количество лайков за период времени, соответственно, если лайкать всех подряд, то половина лайков уйдёт на заведомо неподходящие варианты.
Вот именно, много где, но не в
nano.)