Взяли второго прогера, надо понять как нам наладить совместную работу. Мы работаем над сайтом, поэтому Github не устраивает, я хочу чтобы тестовый билд можно было открыть в браузере. В GIT ведь можно настроить, чтобы пуш на сервер происходил в определённую директорию, куда будет ссылаться виртуальный хост Апача? Второй момент. До сегодняшнего дня я был уверен, что GIT умеет отправлять на тестовый сервер, а потом на боевой, т.е. в продакшн. Походу я ошибался, судя по мануалам что я нашёл, там есть только пуш в какой-то один репозиторий. То есть, после тестирования, мне надо будет в ручную копировать в продакшн, например так? Код (Text): yes | cp -rf /test/* /production Третий момент. Я использую PhpStorm. Каков вообще правильный порядок действий при совместной работе с одним репозиторием? Допустим я сделал какие-то изменения, хочу их закомитить и запушить. Но тем временем, второй прогер запушил другие изменения. То есть, если я запушу свои изменения, то изменения второго прогера потрутся? Или мне надо pull перед этим делать? А pull не потрёт мои локальные изменения? Сложнааааа...
Git пытается смержить изменения, и предупреждает о невозможности. Но в один и те же файлы лазить одновременно всей командой - не хорошо. Пуш можно в несколько репозиториев, но обычно у меня репозиторий, в который я пушу, а потом пулю проверенные изменения на продакшене
То есть, это не проблема настроить на Убунте два репозитория - тестовый и боевой? У этих репозиториев будет разный URL что-ли? --- Добавлено --- Там что-то писать ещё надо? Я думал в PhpStorm всё делается из меню VCS и вот этими кнопками. --- Добавлено --- Ну, учитывая что у нас один файл длиной 13к строк, это нереально. Если мы будем делать изменения в разных методах одного класса, то должно смерджить нормально? Например я работал над методом aaa(), а второй прогер над bbb(). Он запушил первым, то есть у меня осталась старая bbb(). Если я запушу свои изменения с aaa(), то получается я также перезапишу bbb() на старую версию? Или GIT поймёт что это старая версия и не возьмёт её?
делается, но я рекомендую писать. --- Добавлено --- ты не запушишь нихрена, пока не обновишься. При обновлении могут вылезти конфликты, если автоматом смержить изменения не вышло. Тогда придётся руками выбирать, что оставить, а что заменить. --- Добавлено --- поэтому привет тесты, чтобы не проглядывать глазами код. поэтому привет ооп.
Трындец, что могу ещё сказать Дай Бог, чтоб мне никогда деланный вами сайт не попался на сопровождение или доработку. Хотя, увидев файл в 13 тысяч строк я и не возьмусь за заказ. Не потому что 13 тысяч строк, а потому что они в одном файле.
тс у вас каша в голове связанная с различиями назначений системы непрерывной интеграции и системы контроля версий. Устаканьте их.
Ну вот, мы добрались до сути. Значит правильно сначала делать commit, потом pull, потом push? А я думал Git решает и то и то. Разве нет?
Почитал что это такое: То есть, по сути это та же самая работа через GIT, только с частыми пушами, чтобы мерджить как можно меньшее количество изменений. Я в принципе так и собирался работать.
любая работа через git, это не обсуждаемо. Речь о том непрерывная интеграция это не просто подход к разработке софта а конкретные системы. Погуглите в сторону teamcity, jenkins, Bamboo
ты можешь делать как хочешь, но система версий не даст тебе сделать действие без предыдущего. За исключением того момента, что ты можешь перезаписать случайно свои несохранённые изменения, но IDE обычно предлагает их куда-то сложить. Соотв, когда ты хочешь свой коммит пихнуть в общую репу, то система версий сама сходит и узнает, как там че сейчас в репе, и только потом делает вывод о том, можно ли заливать твой туда. Соотв, если она увидит, что там ветка ушла вперёд, и есть коммиты после твоего последнего обновления - она тебе об этом скажет явно и заливать коммит откажется вообще. В этот момент ты обновляешься с репы, система версий радостно говорит тебе, что всё помержилось автоматом, либо рапортует о конфликтах, и ты в IDE можешь нажать "resolve conflicts" и поехал выбирать одно из двух. Когда закочил - заливаешь. не. У всех разный конвеер, соотв и CI у всех разная. Но Git даёт возможность повесить хуки на события. Типа ты можешь повесить хук на коммит перед коммитом, или там велеть прогонять тесты перед мержем, а если тесты зафейлились - не давать мержить. Соотв, при удачном мерже допустим хук, который новый код зафигарит на тестовый сервак живой и там погоняет уже ченить реальное. Или контейнер докера пересоберёт. Ну короче CI реализуется хуками на Git потому что Git вызывается в важные моменты программистского творчества - при фиксации изменений. И большего не требуется.
Короче как я понял, эти штуки мерджат лучше чем Git? Я думаю, мы для начала Git освоим, будем им мерджить и стараться не ковырять одни и те же методы одновременно. Но непрерывную интеграцию замутим обязательно. Teamcity заинтересовала, она от JetBrains, наверно там ещё есть какая-нибудь интеграция с PhpStorm.
CI, чтобы было понимание, далеко не только, а может и не столько пул изменений репозитория в конкретную версию проекта. Что и как может делаться в т.ч. с использованием упомянутых инструментов подскажет документация. Описаний концепции непрерывной интеграции едва ли не больше чем описаний MVP.
По части синхронизации работы.. А что сложного в том, чтобы сделать 4 ветки? Stable, beta и по одной на разработчика? Ветки разработчиков независимые, являются клонами Stable. В них каждый пишет свое, пиля каждый свою фичу. Когда у каждого фича работает, происходит мерж в beta-ветку. Она тестируется. Если все прошло отлично и проблем нет, бета мержится в Stable. Если проблемы есть, решаем проблемы либо в Beta, либо локально в dev-ах, в зависимости от причин проблем. При этом Beta откатываем назад. Потом повторяем цикл. После успешного мерджа в stable, синхроним dev-ы со stable, чтобы у обоих было однородное содержимое. Повторять, пока не кончится фич-лист. При этом Stable деплоится на продакшен, Beta на закрытый сервер, dev-ы крутятся у каждого локально.
Меня тут второй прогер (прогерша) пытается обучать гиту. У меня по поводу одного вопроса сомнения, можете пояснить правильно ли она всё говорит? У нас на сервере два репозитория - html это боевой и dev это для тестов. Я как бэ думал, что мы будем пушить только в dev постоянно, а в html например раз в неделю. Но она говорит, что так не делают. [29.05.2017 13:53:28] Nerd: можешь скинуть примеры записей? просто чтобы понять как отличается пуш в html и в dev [29.05.2017 13:53:49] Pilya,yO!: они там не отличаются [29.05.2017 13:54:45] Pilya,yO!: git pull origin master git push origin master работают на html, dev, и наших компах одинаково [29.05.2017 13:57:14] Nerd: а это разумно? зачем пушить в html то что ещё тестируется? понятно что пока мы там не сделаем push, изменения не вступят в силу но всё таки - вдруг в папке html что-то накроется, например мы файлик зальём туда вместо тестового и надо будет откатить изменения, мы ведь уже не сможем сделать checkout [29.05.2017 13:58:29] Nerd: есть способ делать pull только в dev или только в html? или так в принципе не делают? [29.05.2017 13:59:23] Pilya,yO!: это разумно, по такой схеме делают везде [29.05.2017 13:59:58] Pilya,yO!: просто в html все будет заливаться только через гит [29.05.2017 14:00:32] Pilya,yO!: и в html будем делать pull только с ветки master
К посту выше - я думал что checkout откатывает изменения. Имелось в виду, откатить изменения не сможем.
Так, всё, мы вроде договорились. На сервере у нас будет две ветки - html и dev. Когда я начинаю новую задачу, я у себя на локалке создаю ветку, например new_task. Потом мерджу её у себя же с dev. Пушу dev на сервер. Делаю в репозитории dev на сервере: git pull origin dev Когда начальник дал добро чтобы выложить изменения с dev на боевой, мы делаем на сервере из ветки master: git merge dev Встало 3 вопроса: Имеет ли смысл пушить все наши локальные ветки разработки на сервер? Может есть какая-то тулза, которой мы потом сможем вывести визуально весь наш путь разработки? Какой программой пользоваться, чтобы не делать всё из консоли? Мы пробовали GitHub Desktop, сейчас будем пробовать такую и ещё такую. Кто чем пользуется, поделитесь? Использовать наш сервер как хранилище главного репозитория или использовать gitlabs?
наоборот. чаще так и делают. а как еще то?) а конфиги в гит и не надо совать, они у каждого свои. в гит можно положить пример конфига и ридми, чтоб новые члены команды могли сами все настроить у себя. 1. несовсем понятно что за локальные. если таски индивидуальные то как закончил и проетстил минимально - можно пушить на серв. если группповые таски, то как только запилил фишку, пушиш чтоб другие могли себе это слить тоже. 2. никакой. делай в консоли. это мой тебе совет. привыкнешь быстро. зато и у себя потом сможешь и на любом сервере удаленно все делать. а всякие десктоп утилитки - ну только красиво рисовать лог веток могут. и то не все. 3. делай как вам удобно. по мне, лучше юзать готовые хранилища.
git_ignore и нет проблем. Все, окромя конфигов утекает на сервер. Тыщщу лет уже существует TortoiseGit. Кроссплатформенно. Черепаха - отличная штука. Есть также черепаха под SVN и Hg.
Так и шторм неплохо вроде справляется с гитом, хотя иногда я в командную строку хожу. Хотя в больших командах я не работал
Ну тут уж дело привычки, но да. Но с репами я привык через черепаху работать. А вот тот же phpMyadmin в 95% случаев шторм мне заменяет без проблем. Удобно до одури. Плюс, когда к нему БД подцеплена, он начинает автокомплитить по ней в телах запроса. Даже непосредственно внутри .php-файлов. Умеет сопоставлять данные и колонки. Тыкнул на имя колонки в инсерте, в запросе подсветились имена переменных, стоящих на месте необходимых данных. Крутота же. Мб и на контроль версий на нем перейду. Тогда вообще должен быть шикардос.