Решили наконец внедрить управление версиями в своей команде. Программистов всего 3 человека.
Сейчас у нас так: в офисе стоит сервер, на нем все разрабатываемые сайты. Работаем в Netbeans, подключаясь к серверу по SMB. Соответственно работать одновременно 2-ум программистам даже над одним модулем CMS невозможно, не говоря уже об одном файле.
Так вот вопрос: подскажите пожалуйста как лучше организовать работу с Git? При том так, что бы вся работа происходила встроенными в Netbeans инструментами, хотя терминала то же не боимся.
Мне кажется, важно уточнение: мы в основном занимаемся разработкой сайтов(корпоративные, интернет-магазины).
Ну для начала вам придётся поднять отдельную копию сайта каждому разработчику, а на сервере общая версия, куда будут сливаться все изменения и показываться заказчику.
Во-вторых все же принцип работы git в командной строке изучить надо — будет проще работать через gui понимая суть.
В третьих — в NetBeans есть модуль git, который хорошо работает, останется только наладить workflow, и deploy коммитов на сервер (на хабре были несколько вариантов решения)
У себя же в локальной копии разрабочик волен сам создавать нужные для себя ветки и делать коммиты, останется договориться о том, в какие ветки сливать наработки на сервер.
Вы немного не правильно трактуете идеологию VCS, и в частности Git. Основная идея Git как раз в возможности беспроблемно работать над локальными копиями проекта, и затем «сливать» их воедино, синхронизируя состояние веток между собой. Если во время синхронизации происходят конфликты, то их разрешает тот, кто еще не отправил коммит на сервер.
Для меня представляется проблемой нормальный git-workflow в винде (пробовал только Git for Windows). Но могу Вам порекомендовать Github для Windows как эталон рабочих процессов.
И по поводу проблемы с общим доступом к серверу: научившись использовать ветки git, попробуйте настроить себе capistrano для деплоя (как на локальный, так и на production сервер).
Прошу прощения, воспринял SMB как красную тряпку и решил, что Вы сидите на винде. Тогда Github for Mac, терминал и Git Real от Codeschool позволят быстро настроить всю команду на рабочий лад.
В netbeans довольно неплохая поддержка git, но практика показала: для того, чтобы гит действительно приносил команде пользу (а он это умеет, поверьте на слово), необходимо:
1. Чтобы каждый из членов команды понимал, что же там происходит — т.е. умел пользоваться гитом из консоли.
2. Чтобы в команде была принята какая-то определенная модель работы с ним.
На стадии «как лучше организовать работу с git?» я настоятельно рекомендую пройти курс(-ы, их там два) от Codeschool каждому члену команды, а также изучить вот этот список.
1. На Web-сервере у каждого разработчика есть аккаунт
2. В home директории разработчика есть папка Sites
3. Web-сервер с помощью VirtualDocumentRoot отображает запросы вида user.example.com в /home/user/sites/example.com — это и есть сайты разработчиков. От внешнего мира их легко закрыть http-авторизацией
4. Разработчики публикуют свои рабочие копии через realsync а не через git — есть статья на хабре
5. Есть сайт devel.example.com — он деплоиться git из ветки devel — это ветка подготовки релиза, после слияния изменений. Деплой — хуками в интеграционном репозитории, сам сайт — рабочая копия ветки devel
6. Есть сайт example.com — он деплоиться git из ветки master — это ветка продакшн-релиза. Деплой — хуками в интеграционном репозитории, сам сайт — рабочая копия ветки master
Все работает автоматически, каждый разработчик работает независимо. Разработчики пушат на сервер свои ветки, руководитель вливает в develop для тестирования.
Как деплоить релиз это уже дело десятое, капистрано крупноват на мой взгляд для простых сайтов и команд из 3-х разработчиков.
Но деплой сайтов разработчиков и интеграционной сборки — нужно делать realtime — лучше realsync тут что-то сложно придумать (ну еще можно конечно каждому в своей папке по samba работать — но будет работа с git медленней)
Да и деплой с помощью git это обычно git pull, для обычных сайтов где кроме скрипов и базы ничего нет — вполне себе (ну если миграции базы делаются отдельно вручную конечно)
Речь идет о деплое web-сайта не сервер разработки для отладки.
Нецелесообразно держать полное окружение на разработческой машине, да и не всегда это возможно.
Банально странички в браузере смотреть при верстке например. Но при этом иметь окружение ровно такое-же как в продакшене (база, web-сервер, всякие media-файлы и т.п.)
Для разработки как раз нужен рилтайм, кроме самого разработчика этот сайт все равно никто не увидит. И делать это лучше специализированными инструментами — лучший из них по моему мнению — realsync
То что Вы работаете на одном сервере выглядит нехорошо, тк если с этим сервером что-нибудь случится, то никто не сможет работать (а теперь оцените как дорого обойдется сгорание сервера перед срочным релизом), так что советую также посмотреть в сторону быстрого развертывания приложения как prod так и dev версий и работать отдельно.
То что Вы работали без контроля версий выглядит также нехорошо, тк узнать кто, что и почему делал в модуле или файле через несколько месяцев становится практически невозможно.
Под венду есть консольный клиент msysgit.github.com/, который Вам уже советовали, по мне он вполне удобен, есть также code.google.com/p/tortoisegit/, который Вам уже тоже советовали. Для eclipse есть плагин для гита, для ide от jetbrains поддержка гита из коробки, так что вероятнее всего в netbeans есть плагин. Как альтернативу можно глянуть Mercurial, тк он похож командами на гит и вроде с клиентами под венду у него проще, но сам не пробовал.
Если Вам не подходит приватный репозиторий на гитхабе или битбакете, то стоит делать бекапы на какой-нибудь сторонний сервер (или сервис, как google storage, amazon storage, google drive, dropbox), хотя вероятность того, что сгорит центральный сервер и тачки разработчиков с локальными версиями сильно уменьшается по сравнению с одним сервером или тачкой, тк гит это еще и бесплатная возможность бекапа.
TortoiseGit отвратительнейшее чудо. Быть может за пол года что-то поменялось, но когда в последний раз его использовал меня немного напрягал способ построения дерева коммитов. Даже думал свой Gitg написать под шиндоус, но пока обхожусь встроенным клиентом в PHPStorm. Так же неплохая штука SmartGit но дорогая и слишком уж много в ней всего.
Пользовался TortoiseSVN, TortoiseGit & SmartGit. С первого ушёл быстро, так как он запросто мог убить твои измененихя без всякого предупреждения. Перешёл с него на SyncroSVN. Второй наоборот мне очень понравился. Он предоставляет на порядок больше возможностей по сравнению со SmartGit. Единственное, что я нашёл в SmartGit и не нашёл в черепашке это привязывание удаленной ветки к локальной (Track). Почему-то черепашка не создает привязки если запушить новую ветку на сервер, хотя в обратную сторону это работает.
Не пытайтесь работать с Git на уровне интуиции, обязательно прочитайте толковую книжку/сайт/мануал сначала (только не HOWTO «Git за час», это понимания не даст), это позволит вам избежать кучи проблем и сэкономит в дальнейшем уйму времени.
и плюс видеокурсы/скринкасты от всех популярных программистких обучалок (CodeSchool, Pragmatic, Pluralsight, Lynda.com, destroyallsoftware, Tuts+ и т.д. — тысячи их)
