LINUX.ORG.RU

А как вы работаете с ГИТом?

 , ,


1

2

Доброго всем времени суток.
Хотел узнать, кто как из местных web-девелоперов настроил работу с гитом. Возможно кто-то сможет и мне помочь.
Подскажите, как лучше реализовать тестовый стенд для разработчика.
У разработчика есть тестовая машина с веб сервером, по идее, хотелось, чтобы он там что-то делал\тестировал и коммитил в гит.
А уже из гита оно будет выкладываться на прод.
Но проблема пришла оттуда, откуда не ждали. Разработчики хотят работать с графическим клиентом гит. Единственный рабочий вариант, который я придумал, это пробросить папку корня директории веб-сервера на машину разработчика. Но графическая консоль, жутко тормозит. Простые операции(git status) выполняет 2-3 минуты.
Пробовал по самбе, нфс, etc.
Консоль показывал, они ее испугались...
Как можно прикрутить графический клиент, к удаленному серверу?

Вот это вот необычный юзкейс для гита, я бы даже сказал смешной. Пускай у себя gui клиент запускают и тянут репу на локальный комп, а там уже комитят и пушат в репу на сервере.

pi11 ★★★★★ ()

Выгонять нафиг таких разработчиков.

Кстати, а современные ИДЕ не позволяют работать с системами контроля версий?

PunkoIvan ★★★★ ()

git-flow во все поля. И да хотят работать с гуями гита пусть форкают локально и успехов.

init_6 ★★★★★ ()

Не надо так делать. git создан, чтобы работать локально, а для удалённых серверов есть команда push.

Miguel ★★★★★ ()
Ответ на: комментарий от Miguel

Локально не очень вариант поднимать веб-сервер. Идея была к тестовому веб серверу прикрутить гуй гит.
Насколько я вас понял, не получится цветочек аленький?

telepuz ()

Консоль показывал, они ее испугались...

Уволь этих идиотов.

PPP328 ★★★★ ()

Консоль показывал, они ее испугались...

У вас поддельные разработчики.

entefeed ☆☆☆ ()
Ответ на: комментарий от telepuz

Локально не очень вариант поднимать веб-сервер.

ну пусть каждый клонирует репу себе, а для тестирования синхронизирует код на удаленный веб-сервер (rsync или IDE имеет функцию сохранения deploy on save)

kiotoze ★★★★ ()
Последнее исправление: kiotoze (всего исправлений: 1)

Во многих IDE (в частности от https://www.jetbrains.com/) есть функция деплоя кода на удаленный сервер. То есть тебе надо сделать стенд, показать куда синхронизировать код разработчикам и включить им автодеплой всех изменений. В итоге при изменении кода статика будет деплоиться на стенд и там разработчики смогут всё проверять. Если код готов, то просто локально у себя пушить, ну а дальше уже в прод выкатывай из мастера (ну или как у вас там).
Ну это готовая схема, если у вас на какомнибудь php пишут. Если что-то компилируемое, то схему чуть доработать надо.

v9lij ★★★★★ ()

- Разделить тестовый/девелоперский git от продового - Пушить в продовый можно и через gui

anonymous ()

Разработчик работает с гитом локально в своей ветке каким угодно способом. Когда он готов к тестированию на стенде, он создает pull-request в центральный реп.

У центрального репа есть CI-система, которая при появлении пулл-реквеста автоматом выкатывает эту ветку на тестовый стенд. Либо можно на ручном приводе: разработчик триггерит выкатку на стенд в интерфейсе того же дженкинса указав имя ветки, которую хочет протестировать.

Если тестовый стенд централизованный (а не свое локальное окружение у каждого), то и управление им централизованное должно быть.

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 1)

Консоль показывал, они ее испугались...

Не кровати двигай, а девиц меняй.

Noob_Linux ★★★ ()

Пусть разработчики подотрут сопли и освоят консоль. А ты тем временем разверни какой-нибудь гитлаб и потихоньку прикручивай CI — для веб-разработки там даже готовые шаблоны были, ЕМНИП

XMs ★★★★★ ()
Ответ на: комментарий от telepuz

Локально не очень вариант поднимать веб-сервер

Работа с репозиторием ≠ работа с веб-сервером. Хотя не вижу особой проблемы через тот же докер поднимать окружение или просто интерпретатор нужной версии, чтобы перед пушем хотя бы что-то проверить

XMs ★★★★★ ()

есть куча графических клиентов в чем проблема?

разработчики не мотивированы относительно проекта?

гитом удобно пользоваться в magit - посмотрите ролики

если этого нет, то удобнее в консоле, ничего страшного, хотя есть редакторы/IDE со встроенной поддержкой гита

anonymous ()
Ответ на: комментарий от telepuz

Локально не очень вариант поднимать веб-сервер.

Я тебя не очень понял. Идея в том, чтобы разработчик работал на своей машине, при этом веб-сервер работал на другой машине, тестовой, а затем уже готовый код аплоадился в продакшен? Т.е., тестовая машина — не та, на которой разработчик работает?

Если так, то, опять-таки, гит должен работать на машине разработчика, а готовый код — деплоиться на тестовую машину.

Miguel ★★★★★ ()

не читал ни ОП ни комменты.
гит лишь можно приспособить для автоматизации хороших практик в деле разработки и вообще версионирования. остальное - вода.
ЗЫ да, работаю.

mos ★★☆☆☆ ()
Ответ на: комментарий от telepuz

Пушьте на bitbucket там есть бесплатные приватные репы.

pawnhearts ★★★★★ ()

Странно. Я вот не разработчик, но с гитом работать более или менее умею.
Кто все эти люди кто пишет код за деньги?

ritsufag ★★★★★ ()

Разработчик, который не осиливает консольный интерфейс git... Такие должны быть доступны за пять копеек за пучок. Я надеюсь, твоя зарплата раза в 3 выше, чем у этих ленивых разработчиков и окупает хрень, которой тебе приходится заниматься. Иначе - ты просто неудачник, за копейки разгребающий чужие задачи, про которые никто другой даже думать не хочет.

anonymous ()

не совсем понял, что ты спрашиваешь.

«что-то делал\тестировал и коммитил в гит»
«с графическим клиентом гит»

так пусть коммитят в локальный гит репо. если «из гита оно будет выкладываться на прод», то надо пушить в дефолтный в другой репозиторий (центральный грубо говоря), команда (git push).

непосредственную выкладку не обязательно не привязывать к событиям гита, можно просто сделать каком-нибудь сервере ручной скрипт, который из удаленного репозитория в который они пушили перекладывал бы непосредственно на прод (в svn есть export в гите тоже что-то такое есть)

т.е. он закомитил, потом запушил на сервер, потом пошел на сервер и запустил скрипт.

neschastnyjj86 ()
Ответ на: комментарий от kiotoze

rsync или IDE имеет функцию сохранения deploy on save

так можно делать только есть рсинк обернуть в баш-обертку (ее тоже положить в репо) и предупредить, что лучше ее не править без обсуждения. иначе рсинк с программистского компьютера на продакшн плохо кончится, т.к. они в лучшем случае накидают на продакшн мусора, или даже затрут на продакшене неверсионированные файлы (конфиги, файлы данных и т.п.)

neschastnyjj86 ()
Ответ на: комментарий от ritsufag

Кто все эти люди кто пишет код за деньги?

В разработке такая нехватка кадров, что туда берут всех подряд. Вот они и разленились в конец, потому что их носят на руках и пылинки сдувают. В результате зарплата Jun'a уровня «умею писать хелло_ворлд» равна зарплате квалифицированного админа с 5-7 годами опыта. Самое сложное в трудоустройстве - это не послать рекрутера с его заморочками и провокациями куда ему не хочется, т.е. нужно улыбаться и махать.

IMHO, лучшее, что можно сделать, работая админом - прочитать «философию Java» и что-нибудь по программированию под Android и через пол года самостоятельного набирания опыта уйди в разработку с ростом в зарплате (возможно, на фриланс).

anonymous ()
Ответ на: комментарий от neschastnyjj86

так можно делать только есть рсинк обернуть в баш-обертку (ее тоже положить в репо) и предупредить, что лучше ее не править без обсуждения. иначе рсинк с программистского компьютера на продакшн плохо кончится, т.к. они в лучшем случае накидают на продакшн мусора, или даже затрут на продакшене неверсионированные файлы (конфиги, файлы данных и т.п.)

Ваять костыли и чинить их, когда сломаются, потому что разработчики слишком ленивы, чтобы освоить инструмент, с которым работают постоянно. Блин, как это по сисадмински...

Пинка под зад таким разработчиками и самому на их место. За пару месяцев можно освоить их сферу деятельности (вряд ли настолько ленивые программеры много умеют). Через год можно будет поискать другую контору с ростом зарплаты раза в 2.

Ну, или можно лет до 30 изготавливать костыли для программеров, а потом понять, что сисадмин за 30 никому не нужен, разве что за еду.

anonymous ()
Ответ на: комментарий от i-rinat

Только мержишь ветки?

С матами и оскорблениями, да. :3

r3lgar ★★★★★ ()
Ответ на: комментарий от neschastnyjj86

чушь собачья. дальше не читал

Базар фильтруй.

По сравнению с квалифицированными админами, разработчиков найти в разы сложнее. Сисадмин ищется закидыванием вакансии на hh, время поиска - неделя. Для найма разработчиков используют рекрутинговые агенства (вакансии на hh разработчики даже не читают, поэтому и откликов не будет), причем сразу несколько агенств и платят на успешный найм 2-3 месячных оклада (время поиска минимум 2 месяца).

Но твое мнение, конечно, самое правильное. Впрочем, квалифицированных программистов, готовых работать за еду, конечно, не хватает.

anonymous ()
Ответ на: комментарий от anonymous

то что я предложил - это никак не костыль, а грамотное корректное решение. я уж не знаю, сколько тебе там лет (ты ж начал про возраст), но если ты компетентен тебе должно быть ясно, что ключей ноутбуков разработчиков на продакшен сервере быть *не должно*, им там в общем случае нечего делать. доступ они туда конечно могут иметь и в т.ч. по ключам, но ежедневный процесс, скрипты и пр. не должно на это опираться, особенно в виде рсинка с dst в качестве продакшена или вообще, как кто-то вышел предложил, какую-то IDE говно-фичу.

neschastnyjj86 ()
Ответ на: комментарий от anonymous

Сисадмин ищется закидыванием вакансии на hh
найма разработчиков используют рекрутинговые агенства

вообще странная чушь какая-то

сравнению с квалифицированными админами, разработчиков найти в разы сложнее

я вижу ровно обратную картину

neschastnyjj86 ()
Ответ на: комментарий от telepuz

Локально не очень вариант поднимать веб-сервер.

Расшарь файловую систему.

yvv ★★☆ ()
Ответ на: комментарий от neschastnyjj86

Разрабы пушат в гит на гит-сервере. Оттуда код автоматически деплоится на тестовый сервер и при релизе в прод из соответствующих веток. Никаких ключей ни у кого на серверах нет.

shell-script ★★★★★ ()
Последнее исправление: shell-script (всего исправлений: 1)
Ответ на: комментарий от anonymous

Зачем ты смешиваешь в одну кучу эникеев, админов и жабоджунов?

leave ★★★★★ ()
Ответ на: комментарий от shell-script

перечитай тред. 1. костыли в виде обертки над рсинком я пердложил только тем, кто обязательно хочет деплоить с прям с лаптопа разработчика. 2. мое оригинальное решение подразумевает пуш на удаленный репо, после чего ручной запуск скрипта, который из удаленного репо уже деплоит на продакшн. при этом во-первых деплой скрипта тебе всё равно не избежать (если конечно ты не статическую html-ку деплоишь); автоматический деплой по событию пуша это плохо.

neschastnyjj86 ()
Ответ на: комментарий от neschastnyjj86

Не по событию пуша, а по мержу в мастер, например. Разумеется, что пушат все в какой-нибудь дев. Тут уже упоминали волшебные слова git-flow и CI.

shell-script ★★★★★ ()
Последнее исправление: shell-script (всего исправлений: 1)

не вижу ничего необычного

всё как на гитхабе: центральный bare репозиторий. из него чекаутить на нужные машины.. кому нужно - редактируют свою локальную репу и делают push в центральную. кому нужно - тянут (pull) изменения из центральной репы.

з.ы. RTFM!

anonymous ()
Ответ на: комментарий от LongLiveUbuntu

ну вот, в чём проблема тогда?

Разработчики не осилили ИДЕ, разработчики не осилили консоль, хотя бы пару команд. Как такое вообще возможно в 2017 году?

PunkoIvan ★★★★ ()

привык держать весь код на удаленном хранилище с доступом по ssh. Подключаю его через встроенный в бубунту механизм (после чего он становится доступен всем приложениям в виде обычной папки). дак вот, раньше частенько в качестве гуя для гита использовал смартгит - ну нравится мне писать коммит меседжи в гуе да и браузер изменений там удобный. Но пол года назад прилетело обновление, и теперь с такими «удаленными» репозиториями смартгит отказывается работать. Попробовал какойто другой хипстерский клиент - выдает туже ошибку. видимо чтото изменилось в самом гите. жаль, пришлось полностью переехать в консоль и это нифига не удобно в некоторых случаях.

genryRar ★★ ()

Один не смог загуглить: «Git — распределённая система управления версиями.» Другие (аж целые разработчики) не умеют cli. Кто вас понарожал?

erfea ★★★★★ ()
Ответ на: комментарий от Shadow

Меня тоже. Но консоль меня совсем не пугает.

v9lij ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.