GIT как правильно пользоваться?

Здравствуйте, только начинаю писать сайты, нас 3-е человек хотим написать простую сайт визитку(в целях научится все делать правильно)
Для этого купили VPS с ubuntu. поставили туда apache,php,mysql
У нас только базовые знания php,html,css,js
Никогда с git не работали
Хочется сразу начать делать правильно
Собственно я правильно понимаю нам нужно:
1)Каждый на своем компе(у нас Windows) ставит то же самое что и на VPS - php,mysql,apache
Тут у каждого будет тестовый вариант сайта
2)Каждый на своем компе ставит git
3)???
4)???
Нужно и ли ставить git на VPS-Сервер?
Учитывает ли GIT изменения в MySql?Если кто то допустим добавит новую таблицу
Нужен ли github?Или другие подобные сайты
Как вообще все это организовать?
В интернете толком не нашел примеров использования с нуля на боевых проектах
Обычно просто ставят git и показывают на txt файлах как он работает

Т.е можно какоую-нибудь пошаговую инструкцию, типа
ставите каждый у себя это...
на гитхабе у вас будет это....
И в 2-ух словах описать как нам совместно организовать работу
  • Вопрос задан
  • 5166 просмотров
Решения вопроса 1
@xfg
Github Flow за 5 минут.

1. Создал ветку для фичи/фикса
2. Сделал в ветку несколько коммитов
3. Отправил пулл риквест
4. Обсудил с коллегами пулл риквест и при необходимости внес правки
5. Прогнал ветку через тесты.
6. Влил в master
7. Выкатил master на продакшн

Если фича ветка долго не мержится и начинает расходиться с master веткой, то вливаем master в фичу ветку и продолжаем.

Если кто-то из команды хочет руками потестить новую фичу, то может сделать
git checkout -b new-feature origin/new-feature
И потестить руками локально на своей дев машине.

Update: Если sql база, то пишут миграции. Можно посмотреть в любом фреймворке что это и как использовать. После каждого git pull пробуем накатить миграции через консоль (можно хук для гита написать) и если есть новые миграции, то они применятся к локальной базе. Если nosql база типа mongo, то ничего не надо, они schemaless.

На продакшине, вытягиваем код из гита в отдельную директорию. Применяем миграции к базе, затем симлинк переключаем с директории со старой версией проекта на директорию с новой версией проекта. Если миграции ломают старую версию проекта, то предварительно нужно выключить проект, чтобы у пользователей не сыпались всякие непойманные исключения. Это вкратце, для всего этого нужно подобрать себе уже готовый инструмент деплоя, который это все автоматически будет делать.
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
DmitriyEntelis
@DmitriyEntelis
Думаю за деньги
Очень советую все таки прочитать https://git-scm.com/book/ru/v2
Ответ написан
sabramovskikh
@sabramovskikh
Вкратце (могу ошибиться в некоторых пунктах)
1)Каждый ставит что ему удобно (denwer, xampp, openserver (под виндой рекомендую openserver))
2) Ставите каждому git
3) Регаешься на битбакете. Регаешься на битбакете, создаешь команду, пока вас трое там бесплатно будет. Создаешь там пустой проект
4) Создаешь проект на VPS (на нем уже стоит гит обычно)
5) делаешь init git на VPS и пушишь в проект на битбакете
6) Каждому сливаешь с сервера файлы и каждый делает у клон репа с гита
7) Работаете, делаете комиты, пишите на битбакет.
8) Потом пулить с битбакета на VPS
Ответ написан
Нужно и ли ставить git на VPS-Сервер?

Не обязательно, зависит от того, какой вариант доступа вы выберете - через SSH, по HTTP или вообще поставите какой-нибудь Gitlab или Stash (только тут уже зависит от мощностей вашего VPS, не факт что хватит). Гуглите инструкции по установке (git over ssh, git over http), и смотрите, что вам нужно на сервере.

Учитывает ли GIT изменения в MySql?Если кто то допустим добавит новую таблицу

Git к реляционным СУБД прямого отношения не имеет, и непосредственно учитывать изменения в БД он не может в принципе. Git работает с файлами и файловой системой, фактически это многоверсионная файловая система поверх обычной ФС, с ветвящимся версионированием. Для ветвящегося версионирования непосредственно в БД сейчас нет распространенных решений (существует пара реализаций, но вы не захотите с ними иметь дело). Поэтому разработчики решают задачу версионирования и обновления данных и схемы с помощью специальных скриптов - "миграций", которые хранят в обычных текстовых файлах в Git. Это могут быть как обыкновенные SQL-скрипты, так и скрипты под конкретный фреймворк/библиотеку для работы с БД. При разработке проекта каждый раз когда необходимо изменить схему или начальные данные в БД, пишется миграция, которая обновляет схему или данные в БД при деплое проекта. Гуглите "PHP migrations" и обрящете.

Нужен ли github?Или другие подобные сайты

Вам решать. Если у вас есть VPS и вы готовы настроить там Git для совместной работы, то гитхаб вам не обязателен. Если не хотите париться, и вам проще заплатить за приватную репу - пожалуйста. Если приватность репозитория вам не нужна - можете прямо сейчас создать организацию на гитхабе и пользоваться.

Как вообще все это организовать?

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

В интернете толком не нашел примеров использования с нуля на боевых проектах

Использования чего? Git? А что вам осталось непонятным?

Т.е можно какоую-нибудь пошаговую инструкцию, типа

1. Ставите на рабочих станциях клиент Git.
2. Настраиваете доступ к общему репозиторию на сервере.
3. Совместная работа организуется путём выбора существующей или выработки своей методики версионирования проекта и ветвления состояния репозитория. Git Flow обычно советуют как достаточно простую и универсальную модель, с которой лучше всего начать. Как поймёте, что такое Git на самом деле, поймёте и что вам от него нужно и как это получить (и выработаете эту модель сами).
В любом случае так или иначе всё сводится к ветвлению/слиянию веток, а как конкретно это делать - см. выше. Гит лишь предоставляет концепцию ветвления и концепцию локальных/удалённых веток, т.е. децентрализованный репозиторий.
Ответ написан
VGrabko
@VGrabko
Golang, Php, Js
На все вопросы про Git ответ один: git flow
Ответ написан
@apletnev
Так как с целью научится то:
1. отключаешься от VPS;
2. настраиваешь окружение через VM - docker (лучше сразу нормально научится);
3. комитишь структуру проекта с dockerfile (dockercompose) либо в bitbucket, либо в github;
4. боевые товарищи форкают проект и делаю pull requests;
5. если сайт сделали, и нужно его кому-то показать, то только тогда покупаете VPS.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы