Да зачем вообще сайты. Чего стесняться то. Оставить только кремлин — пусть по любым адресам открывается. И все. А дармоедов в лице роскомнадозора уволить — как раз сокращение планировалось.
Но один пункт я бы добавил — делегируйте полномочия.
Когда все тащишь и контролируешь сам и это становится нормой, то очень сложно выпустить направление из рук «в свободное плавание». К тому же самостоятельного, ответственного сотрудника, на которого можно это направление переложить еще тоже нужно найти и в результате упираешься в барьер и топчешься на месте.
Когда же до них дойдет, что надо все заблокировать. Хорошо бы к тому времени доллар еще раза в два вырос, а жрать стало бы совсем нечего.
Может тогда 86% разглядит, наконец-то, конечную цель этого увлекательного роад трипа.
Насчет SVN — очень похоже на то.
Пока мы работали с одной веткой — все было довольно неплохо. Но когда стали вести параллельный процесс (несколько пользователей пилят сразу несколько фич), то сведение превратилось в сущий ад.
Процесс в git у нас сейчас такой же — несколько параллельных веток, которые регулярно сводятся. Но благодаря ребэйсу (ежедневному и обязательному) и правильной организации задач все годаздо проще.
У нас тоже сейчас такого нет )
Это было время «поиска workflow» — тогда пытались каждую фичу делать в отдельной ветке и затем мерджить. Получалось не очень )
Сейчас git workflow (master | hotfix | release | develop), роль временных веток + код ревью играет gerrit, сама история — плоский мастер с периодическими вливаниями из hotfix / release. develop обычно переносится в release. Все сводится ребэйсом.
У разработчиков локально могут быть любые ветки, но обычно каждый работает над одной фичей в один момент времени.
Вот спасибо, наконец-то хоть кто-то прояснил.
В таком свете — да, понятен и смысл веток и процесс.
Сразу захотелось пощупать.
В Git — да, к такому и приходишь (по крайней мере у нас по процессу именно так — несколько постоянных веток и много разовых). В чем-то тут мерк удобнее, в чем-то удобнее гит.
Интересно, а если мерджить результат мерджа (который тоже может быть результатом мерджа,...), то какая ветка укажется в окончательном мердже?
Ну тогда особой разницы (помимо идеологической) не вижу.
В git действительно, при мердже не сохраняется имя ветки, кроме как в описании (дефолтно подставляется). Что, в принципе, и понятно. Возможно кого-то это действительно напрягает — меня нет.
А что будет в мерке, если удалить ветку после мерджа? В самом мердже ее имя останется?
Что будет если после удаления повторно создать ветку с таким же именем? Будет считаться, что смердженные коммиты пришли из нее?
Много ли в мерке делается веток?
В git ветку можно (и нужно) создавать на каждый чих, и так же легко с ними расставаться.
Может вам история совсем не нужна? Поэтому и наплевать, что там будет?
Непрерывный проект — что значит? Как часто в нем правки? Может и 30 тыс. коммитов там от того, что «забыл запятую», «поставил запятую», «запятая оказалась лишней»,…?
Но один пункт я бы добавил — делегируйте полномочия.
Когда все тащишь и контролируешь сам и это становится нормой, то очень сложно выпустить направление из рук «в свободное плавание». К тому же самостоятельного, ответственного сотрудника, на которого можно это направление переложить еще тоже нужно найти и в результате упираешься в барьер и топчешься на месте.
Когда же до них дойдет, что надо все заблокировать. Хорошо бы к тому времени доллар еще раза в два вырос, а жрать стало бы совсем нечего.
Может тогда 86% разглядит, наконец-то, конечную цель этого увлекательного роад трипа.
Пока мы работали с одной веткой — все было довольно неплохо. Но когда стали вести параллельный процесс (несколько пользователей пилят сразу несколько фич), то сведение превратилось в сущий ад.
Процесс в git у нас сейчас такой же — несколько параллельных веток, которые регулярно сводятся. Но благодаря ребэйсу (ежедневному и обязательному) и правильной организации задач все годаздо проще.
Это было время «поиска workflow» — тогда пытались каждую фичу делать в отдельной ветке и затем мерджить. Получалось не очень )
Сейчас git workflow (master | hotfix | release | develop), роль временных веток + код ревью играет gerrit, сама история — плоский мастер с периодическими вливаниями из hotfix / release. develop обычно переносится в release. Все сводится ребэйсом.
У разработчиков локально могут быть любые ветки, но обычно каждый работает над одной фичей в один момент времени.
В таком свете — да, понятен и смысл веток и процесс.
Сразу захотелось пощупать.
В Git — да, к такому и приходишь (по крайней мере у нас по процессу именно так — несколько постоянных веток и много разовых). В чем-то тут мерк удобнее, в чем-то удобнее гит.
Интересно, а если мерджить результат мерджа (который тоже может быть результатом мерджа,...), то какая ветка укажется в окончательном мердже?
Мне кажется, сейчас стало лучше )
В git действительно, при мердже не сохраняется имя ветки, кроме как в описании (дефолтно подставляется). Что, в принципе, и понятно. Возможно кого-то это действительно напрягает — меня нет.
А что будет в мерке, если удалить ветку после мерджа? В самом мердже ее имя останется?
Что будет если после удаления повторно создать ветку с таким же именем? Будет считаться, что смердженные коммиты пришли из нее?
Много ли в мерке делается веток?
В git ветку можно (и нужно) создавать на каждый чих, и так же легко с ними расставаться.
У нас была на порядок «шире».
Разве не достаточно знать кто и по какой задаче добавил код?
Какие, например, у вас названия веток?
Непрерывный проект — что значит? Как часто в нем правки? Может и 30 тыс. коммитов там от того, что «забыл запятую», «поставил запятую», «запятая оказалась лишней»,…?