Да, так и есть. Этот тот самы git push origin branch --force.
Представьте, вы работаете над фичёй, пушите туда изменения, а кто-то «добрый» взял и принудительно переписал общую ветку своей историей, да ещё и старой. Ваша работа и работа других пропала. Точнее локально оно осталось, но теперь вам надо всё перестраивать. Я бы возненавидел такой сюрприз. Но если бы меня предупредили заранее, что ветка будет перестраиваться — я бы принял меры и, например, ничего пока не делал бы с ней.
Я кстати, немного поспешил с ответом. Посмотрел репозиторий и историю.
Да в этом случае, как описали вы и показали на гитхабе, результат будет неправильным.
Ради интереса сделал:
создал файл, в master написал 2+2=4 (в столбик)
потом создал ветку исправил 2*3=5 (в столбик)
в master исправил 2*2=4 (в столбик)
и всё прекрасно слилось воедино. git ругнулся на то что есть конфликт, но kdiff3 его прекрасно разрулил без участия человека.
Rebase и Merge дали один и тот же результат. Кстати, вброшу ка я:
rebase и merge в 95% дают один и тот же результат, если конечно во время ребэйза чего-нибудь кардинально не менять.
Вообще и merge, и rebase опасны тем, что это объединение двух историй, а значит вероятны конфликты, неправильно принятые решения и т.д. Тут уже всё зависит от человека, а не от VCS.
$ git checkout master
Switched to branch «master»
$ git rebase feature
First, rewinding head to replay your work on top of it…
HEAD is now at 9bfac0a feature1
Applying file2
Одному мне кажется, что ребэйзить мастер на что-то не очень хорошая идея?
не, это не холивар :) Оба старика хороши и мы оба это знаем.
Порадовало, что во втором сделали минимум изменений по рассам/юнитам, зато очень хорошо проработали удобства игры, управления и графики.
Нужен неслабенький моторчик или редуктор.
Большая шестерня диаметром 200 на телевизор. маленькая, диаметром 10 на мотор (ну или редуктор посложнее).
Ну и чтобы сохранять вертикальность/горизонтальность, нужно сделать два концевика-упора в граничных положениях.
Не понимаю о какой «скорости» идёт речь?
Гонка поднять Jenkins (whatever tool) за час или за два?
Да хоть за целый день поднимай и настраивай. Важно, что это будет поднято в обозримые сроки (день-два) и будет работать намного дольше (год, например).
Кстати, поднять jenkins с «джентльменским набором плагинов» — это 30 минут. При этом, там тоже всё очень просто.
Если настройка CI серверов (не процесса) у вас занимает больше двух дней — вы делаете что-то не так, пора открыть доки ;)
По существу, вам в проекте не только ведь build нужен. Кстати, если не хочется ставить плагин — можно не ставить. Всё равно всё сводится к msbuild.exe myproject.sln
Есть ещё 100500 задач, которые возлагаются на CI+CD (Continues Integration + Continues Delivery). Может оказаться, что коммерческое решение не способно быстро адаптироваться под ваши задачи или предоставить workaround.
Кстати, возник вопрос про две задачи: msbuild (который идёт 2 минуты)+asp.build (20 минут) и плюсуем сюда какие-нибудь интеграционные тесты, которые вы тоже захотите запускать, которые будут идти час. Ситуация:
1. Dev1 коммитит код -> запускается msbuild
2. Запускается asp.net следом
3. Dev1 опять коммит (asp.net не собрался ещё)
4. Dev2 Dev3 и Dev4 тоже коммитят с интервалом в 5 минут
У вас выстраивается очередь на сборку всех коммитов в asp build или только последний. Сам столкнулся с этой ситуацией.
Если есть довольно длинный «build pipeline» в конечной точке будет накапливаться очередь и можно прийти к тому, что коммиты будут идти чаще чем система сможет их собирать.
Я решил эту проблему разрывом pipeline и запуском следующих стадий через интервал больший, чем требует стадия.
ПС. Современные инструменты на сегодняшний день уже достаточно мощные и многое умеют. Поэтому, куда больший интерес представляет выработанные процессы на проекте. Branching workflow, Deployment workflow, Testing workflow, QA Releases, Hotfixes, Rollbacks. От проекта к проекту эти вещи сильно отличаются.
Попробую изложить несколько другую точку зрения к подходу.
Да, как сказали, основы/алгоритмы/указатели/типы данных — это хорошо.
Но, если цель стоит вырастить хорошего технаря надо научить ученика:
1. Искать нужную информацию и выбирать правильные инструменты
2. Работать в коллективе (класс разбить на пары/тройки и т.п.)
3. Рассказать про системы контроля версий. Это же как черновик и чистовик.
4. Аккуратность и понятность кода. Откройте любую методичку, даже по паскалю. Там мало рассказывают что такое unit и зачем они нужны, что объявления процедур и функций, это не прихоть учителя, это помогает, это упрощает работу. А
разбиение на подзадачи поможет системно мыслить и добиваться большего.
Сам лично видел, как студенты приносили курсовые:
Задача (упрощённо): прочитать файл, обработать, сделать поиск по 2ум критериям (вводится с клавиатуры запрос).
Открываешь код, а там один единственный `int main()`, простыня переменных от a до z и куча говнокода в котором даже сам студент не разбирается. Дело даже до алгоритмизации не доходит.
Администрировать базу — это одно, а обновить базу до состояния, которое необходимо приложению — это другое.
Почти каждый раз, когда выходит билд по приложению в readme.txt можно увидеть «выполните вот эту пачку скриптов».
Туда входят и вставка/удаление данных, тригера, процедуры, пакеты, вьюхи и т.д.
Когда это не автоматизировано, постановка нового билда может превратится в ад на 8 и более часов.
Какие скрипты нужно выполнить? Какие не нужно? Какая версия приложения? Какой билд по базе к нему подойдёт?
Вещи намного упрощаются, когда app сам себя трекает. Админу только лишь нужно проследить, что миграция базы прошла без ошибок.
Я для наведения порядка в базе использовал: dbmaintain library
Она очень хорошо подходит для крупных проектов с множеством баз данных, условиями выполнения и т.д.
Мне не хватало для счастья preprocessing phase, поэтому форкнул проект и дописал. Можно взять тут, ветка «preprocessing».
ну, кому как. Например, когда я пишу коммент на habrahabr к топику про vim и хочу рассказать про то, что я использую вместо control+shift capslock, то переключаю раскладку не менее 5и раз.
И тут уже даже не важно vim это, или emacs, или opera, или чат. Значительно удобнее и быстрее.
Думаю, ещё это сильно зависит от вида деятельности ;)
Кстати, про control. Я для переключения раскладки использую capslock — и это очень очень удобно.
Но из-за этого не могу в emacs кнопку control поставить на capslock, т.к. будет конфликт для меня.
Я когда поставил себе emacs для знакомства (к этому времени уже очень хорошо знал vim) первым делом полез делать туториал. После его прохождения я понял: до чего же не удобные эти кнопки pgUp pgDown, Home, End.
Отвыкнуть уже не могу, но emacs пока до конца не осилил. Перенастроил все ИДЕ на поведение emacs.
У меня лет 7 назад был такой случай:
чел закрывал работу программы мастер-паролем.
Мастер-паролем хранился в файле. Вместо того чтобы придумать сколь угодно простенькое шифрование он решил записывать пароль plain-текстом, но задом наперёд.
А в качестве мастер-пароля он использовал слово-палиндром!
минусуют те, кто считает, что выход новых версий windows слишком частый, в плане работы с desktop-ом постоянно приходят всякие полезные обновления и фичи, или те, кто считает что возможностей у Desktop Manager-ов поменьше чем у рабочего стола Windows?
Если мы говорим о возможностях Desktop Manager-ов, то говорим, про них.
Если спорим о Windows vs Linux, то я пас.
Я бы сказал, что другие ОС, а точнее desktop manager'ы предоставляют куда больше различных средств для управления и навигации.
Но, конечно, есть задачи, для которых нужен Windows и с этим приходится считаться.
Но в Windows такие новшества появляются крайне редко (или приходится искать программы). И с виду обычную фичу Windows-пользователи ждут по несколько лет и очень радуются её появлению
git push origin branch --force.Представьте, вы работаете над фичёй, пушите туда изменения, а кто-то «добрый» взял и принудительно переписал общую ветку своей историей, да ещё и старой. Ваша работа и работа других пропала. Точнее локально оно осталось, но теперь вам надо всё перестраивать. Я бы возненавидел такой сюрприз. Но если бы меня предупредили заранее, что ветка будет перестраиваться — я бы принял меры и, например, ничего пока не делал бы с ней.
Да в этом случае, как описали вы и показали на гитхабе, результат будет неправильным.
создал файл, в master написал 2+2=4 (в столбик)
потом создал ветку исправил 2*3=5 (в столбик)
в master исправил 2*2=4 (в столбик)
и всё прекрасно слилось воедино. git ругнулся на то что есть конфликт, но kdiff3 его прекрасно разрулил без участия человека.
Rebase и Merge дали один и тот же результат. Кстати, вброшу ка я:
rebase и merge в 95% дают один и тот же результат, если конечно во время ребэйза чего-нибудь кардинально не менять.
Вообще и merge, и rebase опасны тем, что это объединение двух историй, а значит вероятны конфликты, неправильно принятые решения и т.д. Тут уже всё зависит от человека, а не от VCS.
Одному мне кажется, что ребэйзить мастер на что-то не очень хорошая идея?
Порадовало, что во втором сделали минимум изменений по рассам/юнитам, зато очень хорошо проработали удобства игры, управления и графики.
Просто приятно играть.
По багам на эту тему: летающие dark templars или psionics, которые идут по карте напрямую.
Надо будет проверить второй на эту тему.
Большая шестерня диаметром 200 на телевизор. маленькая, диаметром 10 на мотор (ну или редуктор посложнее).
Ну и чтобы сохранять вертикальность/горизонтальность, нужно сделать два концевика-упора в граничных положениях.
Гонка поднять Jenkins (whatever tool) за час или за два?
Да хоть за целый день поднимай и настраивай. Важно, что это будет поднято в обозримые сроки (день-два) и будет работать намного дольше (год, например).
Кстати, поднять jenkins с «джентльменским набором плагинов» — это 30 минут. При этом, там тоже всё очень просто.
Если настройка CI серверов (не процесса) у вас занимает больше двух дней — вы делаете что-то не так, пора открыть доки ;)
По существу, вам в проекте не только ведь build нужен. Кстати, если не хочется ставить плагин — можно не ставить. Всё равно всё сводится к msbuild.exe myproject.sln
Есть ещё 100500 задач, которые возлагаются на CI+CD (Continues Integration + Continues Delivery). Может оказаться, что коммерческое решение не способно быстро адаптироваться под ваши задачи или предоставить workaround.
Кстати, возник вопрос про две задачи: msbuild (который идёт 2 минуты)+asp.build (20 минут) и плюсуем сюда какие-нибудь интеграционные тесты, которые вы тоже захотите запускать, которые будут идти час. Ситуация:
1. Dev1 коммитит код -> запускается msbuild
2. Запускается asp.net следом
3. Dev1 опять коммит (asp.net не собрался ещё)
4. Dev2 Dev3 и Dev4 тоже коммитят с интервалом в 5 минут
У вас выстраивается очередь на сборку всех коммитов в asp build или только последний. Сам столкнулся с этой ситуацией.
Если есть довольно длинный «build pipeline» в конечной точке будет накапливаться очередь и можно прийти к тому, что коммиты будут идти чаще чем система сможет их собирать.
Я решил эту проблему разрывом pipeline и запуском следующих стадий через интервал больший, чем требует стадия.
ПС. Современные инструменты на сегодняшний день уже достаточно мощные и многое умеют. Поэтому, куда больший интерес представляет выработанные процессы на проекте. Branching workflow, Deployment workflow, Testing workflow, QA Releases, Hotfixes, Rollbacks. От проекта к проекту эти вещи сильно отличаются.
Да, как сказали, основы/алгоритмы/указатели/типы данных — это хорошо.
Но, если цель стоит вырастить хорошего технаря надо научить ученика:
1. Искать нужную информацию и выбирать правильные инструменты
2. Работать в коллективе (класс разбить на пары/тройки и т.п.)
3. Рассказать про системы контроля версий. Это же как черновик и чистовик.
4. Аккуратность и понятность кода. Откройте любую методичку, даже по паскалю. Там мало рассказывают что такое unit и зачем они нужны, что объявления процедур и функций, это не прихоть учителя, это помогает, это упрощает работу. А
разбиение на подзадачи поможет системно мыслить и добиваться большего.
Сам лично видел, как студенты приносили курсовые:
Задача (упрощённо): прочитать файл, обработать, сделать поиск по 2ум критериям (вводится с клавиатуры запрос).
Открываешь код, а там один единственный `int main()`, простыня переменных от a до z и куча говнокода в котором даже сам студент не разбирается. Дело даже до алгоритмизации не доходит.
Почти каждый раз, когда выходит билд по приложению в readme.txt можно увидеть «выполните вот эту пачку скриптов».
Туда входят и вставка/удаление данных, тригера, процедуры, пакеты, вьюхи и т.д.
Когда это не автоматизировано, постановка нового билда может превратится в ад на 8 и более часов.
Какие скрипты нужно выполнить? Какие не нужно? Какая версия приложения? Какой билд по базе к нему подойдёт?
Вещи намного упрощаются, когда app сам себя трекает. Админу только лишь нужно проследить, что миграция базы прошла без ошибок.
Она очень хорошо подходит для крупных проектов с множеством баз данных, условиями выполнения и т.д.
Мне не хватало для счастья preprocessing phase, поэтому форкнул проект и дописал. Можно взять тут, ветка «preprocessing».
Остался доволен, надеюсь кому-нибудь пригодится.
И тут уже даже не важно vim это, или emacs, или opera, или чат. Значительно удобнее и быстрее.
Думаю, ещё это сильно зависит от вида деятельности ;)
Но из-за этого не могу в emacs кнопку control поставить на capslock, т.к. будет конфликт для меня.
Вот ведь дилемма…
Отвыкнуть уже не могу, но emacs пока до конца не осилил. Перенастроил все ИДЕ на поведение emacs.
чел закрывал работу программы мастер-паролем.
Мастер-паролем хранился в файле. Вместо того чтобы придумать сколь угодно простенькое шифрование он решил записывать пароль plain-текстом, но задом наперёд.
А в качестве мастер-пароля он использовал слово-палиндром!
Просто полезно выслушать все мнения.
В возможностях Linux DM я не сомневаюсь, т.к. пробовал очень многое. В Windows с этим похуже и фичей там куда меньше. Вот и всё что я хотел сказать.
Если мы говорим о возможностях Desktop Manager-ов, то говорим, про них.
Если спорим о Windows vs Linux, то я пас.
Но, конечно, есть задачи, для которых нужен Windows и с этим приходится считаться.
Но в Windows такие новшества появляются крайне редко (или приходится искать программы). И с виду обычную фичу Windows-пользователи ждут по несколько лет и очень радуются её появлению