Способы командной работы с использованием Git. Поделитесь опытом.
Добрый день.
Всегда работал один и никогда не испытывал необходимости в инструменте контроля версий, особенно в контексте командной работы.
Для общего развития я конечно знакомился с git, консольными командами, ветками, решением конфликтов и прочим. (cкажем так, на крепкую троечку.)
Но попытки использовать это в работе, просто ради того лишь бы было, приводили скорее к усложнению процесса. (чего только стоит история, когда я с трудом наладил работу с кодом через github для одного сайта, а через пару месяцев все перестало работать и только через время заказчик признался, что мол ему захотелось что-то изменить, а у него же племянник учится на программиста, она дал доступы к фтп, тот что то делал, но ничего не вышло и решили никому и не говорить. Так что и так бывает.)
Ну и вот теперь наверное третий подход и попытка понять, как же этим люди пользуются и почему считают удобным.
Я опишу то, как я вижу процесс работы одновременно двоих разработчиков над одним проектом и почему мне это кажется «странным» и не жизнеспособным, а вы исправьте меня пожалуйста и поделитесь своим опытом.
Есть некий сайт, который уже работает и доступен пользователям (site.com)
Есть его копия, не доступная пользователям (dev.site.com)
Есть Programmer1 и Programmer2. В одно чудесное утро они получают задачу — на site.com нужен функционал Промокод для заказа и Гибкое управление скидками. Один берет одно, другой — другое.
И далее мне не совсем ясно. Предположим что у обоих IDE подключена к удаленному серверу dev.site.com На локальные компьютера каждого скачаны файлы и настроен автоматический деплой на сервер. И есть некий репозиторий на гитхабе откуда мы будем забирать код уже на site.com.
Где по правильному должен находится локальный репозиторий? На компьютерах разработчиков? Или на сервере dev.site.com? И что больше всего меня удивляет и вызывает вопросы — если мы одновременно работает с файлами dev.site.com, то стоит мне забыть поставить точку с запятой в моем коде, как сайт ляжет с фатальной ошибкой. и ляжет он и у второго программиста тоже. Он будет гадать что он сделал не так. Чтобы избежать этого вижу только совсем уж безумные варианты. Есть основной сайт, есть сайт для разработки, есть сайт для разработки у Каждого программиста. Тоесть каждый разработчик работает над своим вопросом на своей личной версии dev сайта, когда довел код до хорошего состояния, данные загоняются в какую то ветку — дев и пушаться в удаленый репозиторий. оттуда забираются на сайт dev.site.com. Когда второй разработчик на своей версии сайта(тоесть у нас по факту должно быть 4 версии одного сайта) довел до ума свой код, он тоже отправляет его в ветку дев в удаленный репозиторий, оттуда забирает на dev.site.com и проверям, как два функционала работают вместе и нет ли ошибок. (при условии что мы работали над промкодом и скидками а все это так или иначе связано с ценой). Если нет ошибок то перекидываем в ветку master и забираем на основной сервер.
Но это жесть какая-то…
Ну в общем, поделитесь правильными методами работы с гит. спасибо.
Всегда работал один и никогда не испытывал необходимости в инструменте контроля версий, особенно в контексте командной работы.
Для общего развития я конечно знакомился с git, консольными командами, ветками, решением конфликтов и прочим. (cкажем так, на крепкую троечку.)
Но попытки использовать это в работе, просто ради того лишь бы было, приводили скорее к усложнению процесса. (чего только стоит история, когда я с трудом наладил работу с кодом через github для одного сайта, а через пару месяцев все перестало работать и только через время заказчик признался, что мол ему захотелось что-то изменить, а у него же племянник учится на программиста, она дал доступы к фтп, тот что то делал, но ничего не вышло и решили никому и не говорить. Так что и так бывает.)
Ну и вот теперь наверное третий подход и попытка понять, как же этим люди пользуются и почему считают удобным.
Я опишу то, как я вижу процесс работы одновременно двоих разработчиков над одним проектом и почему мне это кажется «странным» и не жизнеспособным, а вы исправьте меня пожалуйста и поделитесь своим опытом.
Есть некий сайт, который уже работает и доступен пользователям (site.com)
Есть его копия, не доступная пользователям (dev.site.com)
Есть Programmer1 и Programmer2. В одно чудесное утро они получают задачу — на site.com нужен функционал Промокод для заказа и Гибкое управление скидками. Один берет одно, другой — другое.
И далее мне не совсем ясно. Предположим что у обоих IDE подключена к удаленному серверу dev.site.com На локальные компьютера каждого скачаны файлы и настроен автоматический деплой на сервер. И есть некий репозиторий на гитхабе откуда мы будем забирать код уже на site.com.
Где по правильному должен находится локальный репозиторий? На компьютерах разработчиков? Или на сервере dev.site.com? И что больше всего меня удивляет и вызывает вопросы — если мы одновременно работает с файлами dev.site.com, то стоит мне забыть поставить точку с запятой в моем коде, как сайт ляжет с фатальной ошибкой. и ляжет он и у второго программиста тоже. Он будет гадать что он сделал не так. Чтобы избежать этого вижу только совсем уж безумные варианты. Есть основной сайт, есть сайт для разработки, есть сайт для разработки у Каждого программиста. Тоесть каждый разработчик работает над своим вопросом на своей личной версии dev сайта, когда довел код до хорошего состояния, данные загоняются в какую то ветку — дев и пушаться в удаленый репозиторий. оттуда забираются на сайт dev.site.com. Когда второй разработчик на своей версии сайта(тоесть у нас по факту должно быть 4 версии одного сайта) довел до ума свой код, он тоже отправляет его в ветку дев в удаленный репозиторий, оттуда забирает на dev.site.com и проверям, как два функционала работают вместе и нет ли ошибок. (при условии что мы работали над промкодом и скидками а все это так или иначе связано с ценой). Если нет ошибок то перекидываем в ветку master и забираем на основной сервер.
Но это жесть какая-то…
Ну в общем, поделитесь правильными методами работы с гит. спасибо.
22 ноября 2019, 11:00
Комментарии: 13
А вот помогал бы сообществу, то и не было бы таких вопросов! Ты бы узнал, что совместная разработка ведётся не через деплой файлов, а через пулл реквесты (Pull Reqest, PR). Принял PR, если что-то сломалось, откатил назад. Это раз.
Новую функциональность принято разрабатывать в отдельных ветках. Тогда два твоих программиста не зависят друг от друга. Но всегда могут посмотреть, что у другого просто зафетчив другую ветку. Ну и базовая версия остается чистая. Только для хотфиксов. Это два.
В сообществе постоянно есть потребность протестировать тот или иной функционал. Там бы ты всё это и узнал. Ваня Климчук даже инструкцию сделал как работать с гитхабом. Правильно @Иван Бочкарев?
Многому тебя Шифу научил, да видно не всему ))
Новую функциональность принято разрабатывать в отдельных ветках. Тогда два твоих программиста не зависят друг от друга. Но всегда могут посмотреть, что у другого просто зафетчив другую ветку. Ну и базовая версия остается чистая. Только для хотфиксов. Это два.
В сообществе постоянно есть потребность протестировать тот или иной функционал. Там бы ты всё это и узнал. Ваня Климчук даже инструкцию сделал как работать с гитхабом. Правильно @Иван Бочкарев?
Многому тебя Шифу научил, да видно не всему ))
Конечно хотелось больше конкретики, но и на том спасибо.
Думаю что есть огромная разница между разработкой кода фреймворка и работы с существующим проектом. К примеру да, я не представляю как правильно вести поддержку сайта, пришедшего со стороны.
Берет директор на обслуживание и доработку сайт, скажем на битриксе, уже работающий три года проект, весом 150 гигабайт и базой данных в 17 000 000 записей. И говорит — а теперь мы все переделываем ( о как часто я слышу эту фразу). И начинается список задач, от задач по изменению и добавлению логики, так и визуальных — работы с версткой. И такие задачи не выполнишь просто с файлами, поскольку чтобы увидеть результат. сам сайт должен функционировать. Тоесть если мы меняем какую то логику работы с товарами, то чтобы понять получилось или нет — нужны товары, а товары это записи в базе данных.
Если не сложно, Сергей, можете написать именно цепочку конкретных действий, которую вы бы использовали вот для такой задачи.
1. Есть работающий «старый» сайт. Размещен на хостинге заказчика, весит сотню гигов, база данных огромна.
2. Руководителем ставится задача — теперь мы занимаемся обслуживанием и переработкой сайта и сразу например ряд задач (от изменения внешнего вида до изменения логики работы с заказами)
3. Есть два программиста, которые должны работать одновременно. Естественно на работающий сайт должны попадать уже только проверенные программные решения.
И проблемы, которые я предвижу ввиду своей неопытности:
1. Нужна как минимум одна копия сайта, с которой нужно вести работу. Проблема скорее не технического, а жизненного характера, поскольку заказчик на предложение докупить на своем выделенном сервере еще 150 гигов, скажет — а не пошли бы вы. Но это так, реалии жизни.
2. команда git clone не может быть выполнена не в пустой директории. А это означает, что для того чтобы взять под контроль версий работающий сайт, его файлы придется удалять. (причем удалить все, выполнить клонирование с удаленного репозитория, а затем восстановить файлы, которые не содержаться в репозитории). Может данную проблему уже научились решать или правильнее инициализировать репозиторий как раз на живом сайте… именно поэтому я и спрашиваю совета у вас более опытных.
3.
4. Опять таки, чтобы избежать проблем в пункте 3 я вижу только вариант, что у каждого разработчика есть еще и своя версия сайта (тоесть полноценно работающая, с базой данных и прочее), на которой он может проверить свой код.
ps.Кто такой Шифу?
pss Иван, а можно ссылку на ту инструкцию?
Думаю что есть огромная разница между разработкой кода фреймворка и работы с существующим проектом. К примеру да, я не представляю как правильно вести поддержку сайта, пришедшего со стороны.
Берет директор на обслуживание и доработку сайт, скажем на битриксе, уже работающий три года проект, весом 150 гигабайт и базой данных в 17 000 000 записей. И говорит — а теперь мы все переделываем ( о как часто я слышу эту фразу). И начинается список задач, от задач по изменению и добавлению логики, так и визуальных — работы с версткой. И такие задачи не выполнишь просто с файлами, поскольку чтобы увидеть результат. сам сайт должен функционировать. Тоесть если мы меняем какую то логику работы с товарами, то чтобы понять получилось или нет — нужны товары, а товары это записи в базе данных.
Если не сложно, Сергей, можете написать именно цепочку конкретных действий, которую вы бы использовали вот для такой задачи.
1. Есть работающий «старый» сайт. Размещен на хостинге заказчика, весит сотню гигов, база данных огромна.
2. Руководителем ставится задача — теперь мы занимаемся обслуживанием и переработкой сайта и сразу например ряд задач (от изменения внешнего вида до изменения логики работы с заказами)
3. Есть два программиста, которые должны работать одновременно. Естественно на работающий сайт должны попадать уже только проверенные программные решения.
И проблемы, которые я предвижу ввиду своей неопытности:
1. Нужна как минимум одна копия сайта, с которой нужно вести работу. Проблема скорее не технического, а жизненного характера, поскольку заказчик на предложение докупить на своем выделенном сервере еще 150 гигов, скажет — а не пошли бы вы. Но это так, реалии жизни.
2. команда git clone не может быть выполнена не в пустой директории. А это означает, что для того чтобы взять под контроль версий работающий сайт, его файлы придется удалять. (причем удалить все, выполнить клонирование с удаленного репозитория, а затем восстановить файлы, которые не содержаться в репозитории). Может данную проблему уже научились решать или правильнее инициализировать репозиторий как раз на живом сайте… именно поэтому я и спрашиваю совета у вас более опытных.
3.
Новую функциональность принято разрабатывать в отдельных ветках. Тогда два твоих программиста не зависят друг от друга.Программист 1 сделал свою работу, результатом которой есть некая ветка Ветка1 уже запушеная на гитхаб. Второе в тоже время закончил свою работу и результат Ветка2. Оба они идут на сервер, на котором расположен тестовый сайт, делают пулл своих изменений и переключаются на свои ветки. Но сервер то один, репозиторий то один, а значит в один момент времени может быть активная только одна ветка. Программист 1 включает свою ветку, начинает проверять работает ли его фича по заказам, но в этот момент программист 2 включает свою ветку — в итоге файлы на сайте меняются, у первого все перестало работать…
4. Опять таки, чтобы избежать проблем в пункте 3 я вижу только вариант, что у каждого разработчика есть еще и своя версия сайта (тоесть полноценно работающая, с базой данных и прочее), на которой он может проверить свой код.
ps.Кто такой Шифу?
pss Иван, а можно ссылку на ту инструкцию?
Кто такой Шифу — Мастер Ши́фу (англ. Master Shifu) — Малая панда — Учитель По и Неистовой Пятёрки. Сначала он не признавал По как Избранного и всячески мешал ему, но со временем понял свою ошибку, разработал собственную «методику» для обучения По и обрёл внутреннее спокойствие.
=)
=)
1. Не может сайт занимать 150 Г. Это же не Windows. Основной объем занимает база с 17 млн записей. Небось ещё и резервные копии там лежат. Вам для работы вполне хватит и тысячи записей. Поэтому весь сайт вполне уместиться даже на локалке. Один программист делает копию сайта, пушит её на гитхаб (или др. систему управления версиями). А другой тянет её себе. Тут сложно объяснить, если не знаешь матчасть.
2. Сохраняешь наработки, клонируешь, создаешь ветку, закидываешь старые файлы.
3. Ну вы же не конкуриренты. Вы должны согласовывать свои действия. Кто что делает.
4. Можно создать общий сайт разработки dev.site.ru, который подключить к рабочей БД только для теста!!! А программистам можно поднять свои локальные версии для работы.
2. Сохраняешь наработки, клонируешь, создаешь ветку, закидываешь старые файлы.
3. Ну вы же не конкуриренты. Вы должны согласовывать свои действия. Кто что делает.
4. Можно создать общий сайт разработки dev.site.ru, который подключить к рабочей БД только для теста!!! А программистам можно поднять свои локальные версии для работы.
ps.Кто такой Шифу?Спроси у Алисы. ))
Я писал цифры (150 гигабайт и 17 000 000) не имея ввиду что-то конкретное, но могу сказать что из 35 проектов, которые мы обслуживаем, около 5 имеют общий размер (файловой системы) без учета базы — от 100 до 200 гигов. Особенно этим страдают Битрикс и Джумла (и да да, такое тоже у нас есть ибо руководитель фирмы берет на обслуживание любые сайты).
— что все файлы сайта запихивать в репозиторий? Тут еще одно мое недопонимание. Я считаю что правильно в репозитории держать только те файлы, которые важны для разработки, все остальное оставляя в игноре. Но есть и огромные минусы такого моего подхода. Ну во первых не всегда ясно что понадобится, особенно если сайт представляет собой незнакомый движок или самописку и там один только автор знает где у него что. Ну и во вторых, имея такой репозиторий на основании его нельзя поднять полноценную копию сайта. Я помню мы как-то обсуждали этот вопрос с Артемом Зерновым и он сказал, что да — он добавляет в репозиторий сайт целиком. Поэтому вопрос, как поступаете вы?
— как изменения с удаленного репозитория попадают на действующий сайт? Мы не можем выполнить git clone изначально чтобы клонировать репозиторий на продакшен сервер. Клонирование может быть произведено либо в отдельную директорию имя которой мы укажем либо в текущую директорию при условии что она пуста. Но у нас там файлы сайта. И выход только один, все удалить, склонировать репозиторий, но! мы ведь в репозиторий не будем добавлять все директории и файлы сайта, а значит предварительно перед этой операций нужно сделать копию всех файлов сайта, затем после того как слонирован репозиторий вернуть недостающие файлы на сервер (и скорее всего это придется делать пофайлово и это займет не один час) и все это время сайт на продакшене будет недоступен.
Посетители не видят сайт, заказчик злой, плюс предварительно нужно отключить все рекламные компании по сайту и прочие приблуды… Звучит как репетиция ада и на самом деле примерно так и происходит в реальности. Я вот по этому и «насильно» у всех выпытываю как же они пользуются этим инструментом, но как правило в ответах только общие фразы и рассказ о том как удобно. Но наверное это происходит от того, что мало кто «страдает такой ерундой» как поддержка и переработка старых, пришедших от других разработчиков сайтов.
Можно создать общий сайт разработки dev.site.ru, который подключить к рабочей БД только для теста!!! А программистам можно поднять свои локальные версии для работы.Выходит что мои «страхи» оправданы? И для того чтобы корректно работать над одним сайтом двум разработчикам нужно иметь 4 версии сайта — Рабочая, тестовая и у каждого разработчика локальная. И тут конечно следующей волной накатывает проблема точного совпадения сред разработки сразу в 4 местах, но вы ответите мне словом Докер, а я морально не готов к этому)) поэтому пока опустим данный факт.
Один программист делает копию сайта, пушит её на гитхаб (или др. систему управления версиями). А другой тянет её себе. Тут сложно объяснить, если не знаешь матчасть.В техническом плане вопросов нет, но все же:
— что все файлы сайта запихивать в репозиторий? Тут еще одно мое недопонимание. Я считаю что правильно в репозитории держать только те файлы, которые важны для разработки, все остальное оставляя в игноре. Но есть и огромные минусы такого моего подхода. Ну во первых не всегда ясно что понадобится, особенно если сайт представляет собой незнакомый движок или самописку и там один только автор знает где у него что. Ну и во вторых, имея такой репозиторий на основании его нельзя поднять полноценную копию сайта. Я помню мы как-то обсуждали этот вопрос с Артемом Зерновым и он сказал, что да — он добавляет в репозиторий сайт целиком. Поэтому вопрос, как поступаете вы?
— как изменения с удаленного репозитория попадают на действующий сайт? Мы не можем выполнить git clone изначально чтобы клонировать репозиторий на продакшен сервер. Клонирование может быть произведено либо в отдельную директорию имя которой мы укажем либо в текущую директорию при условии что она пуста. Но у нас там файлы сайта. И выход только один, все удалить, склонировать репозиторий, но! мы ведь в репозиторий не будем добавлять все директории и файлы сайта, а значит предварительно перед этой операций нужно сделать копию всех файлов сайта, затем после того как слонирован репозиторий вернуть недостающие файлы на сервер (и скорее всего это придется делать пофайлово и это займет не один час) и все это время сайт на продакшене будет недоступен.
Посетители не видят сайт, заказчик злой, плюс предварительно нужно отключить все рекламные компании по сайту и прочие приблуды… Звучит как репетиция ада и на самом деле примерно так и происходит в реальности. Я вот по этому и «насильно» у всех выпытываю как же они пользуются этим инструментом, но как правило в ответах только общие фразы и рассказ о том как удобно. Но наверное это происходит от того, что мало кто «страдает такой ерундой» как поддержка и переработка старых, пришедших от других разработчиков сайтов.
Вспомнил и еще проблему, с которой приходится сталкиваться при попытке взять под контроль версий сайт на продакшене.
Как я писал выше, чтобы клонировать туда удаленный репозиторий, предварительно нужно скопировать и удалить, а затем частично восстановить файлы. И если на сайте присутствуют файлы, названные киррилицей, то скорее всего в процессе копирования их названия исказятся. И у 50% товаров исчезнут изображения, потому как менеджер залил файл «юбка белая.jpg» а после копирования и перезаливки файлов вернулся #!!&&& ***.jpg
Как я писал выше, чтобы клонировать туда удаленный репозиторий, предварительно нужно скопировать и удалить, а затем частично восстановить файлы. И если на сайте присутствуют файлы, названные киррилицей, то скорее всего в процессе копирования их названия исказятся. И у 50% товаров исчезнут изображения, потому как менеджер залил файл «юбка белая.jpg» а после копирования и перезаливки файлов вернулся #!!&&& ***.jpg
И если на сайте присутствуют файлы, названные киррилицей, то скорее всего в процессе копирования их названия исказятся. И у 50% товаров исчезнут изображения, потому как менеджер залил файл «юбка белая.jpg» а после копирования и перезаливки файлов вернулся #!!&&& ***.jpgЭто уже не доработка сайта, это фигня какая-то, если там всё так организовано. Я в подобных случаях пишу новый сайт, где всё делается «как надо».
И пачку скриптов импорта данных со старого, с конвертацией «как надо». Можно всё отполировать до блеска и выкатить в один день в продакшн новый проект. Запустить скрипты, поменять настройки Nginx — и люди видят всё новое, остаётся только авторизоваться.
Ну, это если заказчик не требует внести правки на живую вот прямо на этой неделе. С такими лучше просто не работать.
Согласен с вами во многом, но
— я не решаю с кем работать а с кем нет, я работаю на компанию и решает директор.
— я также часто агитирую о создании нового сайта, но не всегда это возможно. К примеру если существующий сайт создан на платной версии какого то движка. Заказчик не станет покупать еще раз лицензию на Битрикс или на движок CS CART (стоимость лицензии 150 000 рублей). Так же заказчик никогда не в состоянии полноценно описать, что его сайт умеет и приходится оценивать только на глаз. И ты такой сделал новый сайт, ориентируясь на то что видишь, а заказчик такой — ой забыла сказать — у нас же еще есть приложение для мобильного телефона на play market, оно же будет работать да? )) И таких нюансов море.
—
И три года меня не сильно беспокоили эти все моменты с гитом, поскольку работаю я один и о ужас, но по ftp мне гораздо быстрее перенести какую-то фичу с локального сайта на продакшен. Но скорее всего у нас появится новый разработчик и хотелось бы наладить более продуктивный процесс. Вот и получается что во вне рабочего времени пытаюсь испробовать различные способы работать совместно через гитхаб с уже существующими сайтами, пока что больно и приносит больше проблем чем выгоды.
— я не решаю с кем работать а с кем нет, я работаю на компанию и решает директор.
— я также часто агитирую о создании нового сайта, но не всегда это возможно. К примеру если существующий сайт создан на платной версии какого то движка. Заказчик не станет покупать еще раз лицензию на Битрикс или на движок CS CART (стоимость лицензии 150 000 рублей). Так же заказчик никогда не в состоянии полноценно описать, что его сайт умеет и приходится оценивать только на глаз. И ты такой сделал новый сайт, ориентируясь на то что видишь, а заказчик такой — ой забыла сказать — у нас же еще есть приложение для мобильного телефона на play market, оно же будет работать да? )) И таких нюансов море.
—
И пачку скриптов импорта данных со старого, с конвертацией «как надо»Круто! Моих знаний на это не хватит, особенно учитывая что мы не придерживаемся одного двух движков, чтобы изучить их настолько, чтобы писать скрипты для конвертации данных из одного в другое. Одновременное приходится работать с 7-8 движками.
И три года меня не сильно беспокоили эти все моменты с гитом, поскольку работаю я один и о ужас, но по ftp мне гораздо быстрее перенести какую-то фичу с локального сайта на продакшен. Но скорее всего у нас появится новый разработчик и хотелось бы наладить более продуктивный процесс. Вот и получается что во вне рабочего времени пытаюсь испробовать различные способы работать совместно через гитхаб с уже существующими сайтами, пока что больно и приносит больше проблем чем выгоды.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
20 ноября 2024, 16:25
В сниппете rcv3_html достаточно отложить загрузку через setTimeout (хотя кто-то делает через onClick). Не думаю что мой вариант самый правильный и что...
19 ноября 2024, 10:51
Решил свою проблему через имя пользователя, но хотелось бы через права пользователя «Неограниченные права»
<?php
/**
* Системное событие OnMan...
19 ноября 2024, 09:09
Спасибо, тоже очень интерестное решение.
18 ноября 2024, 15:21
'where' => [
'Data.price:!='=>'0'
]
18 ноября 2024, 14:19
miniShop2.Order.add('extfld_delivery_price','100', function() {
miniShop2.Order.getcost();
})
Это вот работает, но чтобы увид...
18 ноября 2024, 10:11
Благодарю за ответы.
16 ноября 2024, 21:12
Спасибо. Работает.
