Подписка

добавить на Яндекс

Наши проекты

Delphi+Google

Google API

Google API в Delphi - проект с открытым исходным кодом.

Chrono

Chrono

Хронометр - программа для ведения списка задач.

ODFProc

ODFProc

ODFProc - работа с документами OpenOffice в Lazarus и FreePascal.

Поддержка блога

А тут я коплю на лицензию Delphi XE на iPad =).
Сумма пожертвования не фиксирована.

Публикации

Год назад

Случайный пост

Последние

Сообщения форума

Комментарии

Социальные сети

Google

Facebook

Twitter

Опрос

Вы сейчас или в ближайшем обозримом будущем планируете разрабатывать кроссплатформенное приложение с использованием Firemonkey?



Loading ... Loading ...

Блоги и сообщества

Статьи по Delphi DelphiFeeds.ru - Все Delphi-блоги Рунета Сообщество умных людей VR-Online.RU Бесплатный журнал для программистов и всех, кто интересуется IT Статьи и уроки по Delphi Новостной блог о высоких технологиях
Система Orphus
Опубликовал Vlad 5 июля 2010 в 18:28.
Категории: Delphi в Web.


Не так давно проект "Google API в Delphi" успешно переехал на новый адрес и теперь находится под управлением распределенной системы контроля версий Git. Для чего и почему мы это сделали - это вопрос второстепенный, а вот работа с Git, по крайней мере для меня, стала основной. По сути этот пост ни что иное как шпаргалка для себя любимого по выполнению основных операций при работе Git, но может эта шпаргалка поможет кому-то как и мне начать работу с этой DVCS.
< ' ' >

Небольшое введение. О чем вообще пойдет речь

Git — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux.

То обстоятельство, что система создавалась "под Linux" уже как бы намекает на то, что без консоли нам не обойтись. Но не стоит махать руками и кричать "консоль отстой, git - в печь" и все такое. Поверьте - консоль Linux и консоль Windows имеют для обычного пользователя только одно общее свойство - чёрный экран при первом запуске. Команды Linux (ИМХО) просты и запоминаются без проблем, а работать с консолью не составляет особого труда даже для такого чайникак как я.

Самым главным, на мой взгляд, отличием Git от того же SVN является то, что в Git нет такого понятия как главный репозиторий. Каждый разработчик использует свою локальную версию репозитория в которую делает commit'ы и, при необходимости, синхронизирует все изменения с репозиторием, располагающимся на сервере.

Это обстоятельство и поставило меня в начале работы с Git в тупик.
Как этот так commit и не в центральный репозиторий?
Как правильно отправлять данные на сервер?
Как вообще начинать работу?

Эти и ещё многие другие вопросы посещали меня на сарте работы с Git. Сейчас я не буду углублятся далеко в теоретические вопросы Git, да и вообще любых систем контроля версия - всего этого полно в Сети. А затрону один практический момент - как начать работу вообще, чтобы потом не было мучительно больно за бесцельно потеряные исходники.

Качаем и устанавливаем софт

Для работы с Git под Windows имеются вполне работоспособные и юзабельные решения, например, msysgit. Однако если Вы ранее имели опыт работы с SVN и использовли в работе TortoiseSVN, то видимо, Вам захочется иметь аналог подоного интерфейса и для Git? Нет проблем вот аналог TortoiseSVN для Git - TortoiseGit.
По сути TortoiseGit по после нажатия команды из контекстного меню запускает консольную команду из MSysGit и рисует в окошко ее вывод. Если вы не хотите или просто не хватает времени детально разобраться в консольных командах Git, то TortoiseGit - то, что Вам нужно.
Итак, если Вы работаете под 32-х битной Windows, то Вам необходимо скачать следующий софт:
1. msysgit - качаем Git-1.7.1-previewXXXXXXXX.exe (11,6 Mb)
2. TortoiseGit. На момент написания статьи последней была версия TortoiseGit-1.5.2.0-32bit.msi (19.6 MB)
Получается, что скачать нам надо чуть больше 30 Mb.
Теперь устанавливаем скачанные программы.
Вначале ставим msysgit, а потом TortoiseGit.
При установке msysgit настройки по умолчанию можно не изменять.
При установке TortoiseGit выбираем в окне "Choose SSH Client" второе значение:

После успешной установки обоих продуктов работу над первым этапом можно считать завершенной. Приступим ко второму - получение доступа к репозиторию.

Получаем доступ к репозиторию

В качестве примера я буду рассматривать получение доступа к нашемо репозиторию, который располагается на github.com.
Распишем все операции по шагам.
1. Регистрация на GitHub'e.

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

Профиль на GitHub.com

2. Генерируем ключ для доступа по SSH.
Вот тут хочешь-нехочешь, а надо запускать консоль. После учатновки msysgit у Вас на рабочем столе появился новый ярлык - Git Bush - вот с помощью него и запускаем консоль.

  1. Набираем в консоли следующую команду

    ssh-keygen -t rsa -C "E-Mail из Вашего профиля"

  2. На экране появится запрос "Enter file in which to save the key". Пока оставим значение по умолчанию. Жмем Enter.
  3. Нас попросят ввести пароль. Эту часть тоже пропускаем - впоследствии пароль можно будет установить, а пока - учимся. Жмем опять Enter.
  4. Сгенерируются два файла один из которых - публичный ключ для доступа.

Если Вы все делали с настройками по умолчанию то файлы будут располагаться в директории:

C:/Documents and Settings/UserName/.ssh/

Заходим в директорию, открываем с помощью "Блокнота" файл ida_rsa.pub и копируем все его содержимое в буфер обмена.

3. Заносим публичный ключ доступа в профиль.

Для записи публичного ключа в профиль:

  1. Заходим в свой профиль github и жмем ссылку Account Settings (сверху)
  2. Выбираем пункт "SSH Public Keys"
  3. Жмем ссылку "Add another public key"

Перед вами появится форма добавления нового публичного ключа. Вставляем из буфере весь скопированный ранее текст (из файла ida_rsa.pub) только в поле key - поле Title оставляем пустым.

На этом работа с публичными ключами закончена.

4. Просимся в проект.

Для этого достаточно найти наш проект на github и отправить одному из администраторов запрос на предоставление доступа к репозиторию. Или просто отправить мне email с логином на github. После того как вы будите записаны в список разработчиков проекта можно переходить к следующей фазе работы - получение исходников.

Работа со своим первым репозиорием Git

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

Итак, выбираем директорию на жестком диске где мы будем хранить все файлы. Далее действуем следующим образом:

1. Вызываем контекстное меню и выбираем пункт "TortoiseGit -- Settings":

В появившемся окне переходим сразу к пункту "Git - Config" и записываем свое имя и адрес элекронной почты. Эти данные должны в точности совпадать с теми, что записаны в Вашем аккаунте на github, иначе ваш ключ просто не подойдет.

2. Клонируем репозиторий. Для этого заходим на страницу проекта, и копируем в буфер адрес:

Теперь жмем правой кнопкой мыши на директории, в которой будем хранить исходники и в меню выбираем "Git Clone..":

В открывшемся окне в поле URL вставляем скопированный адрес и жмем "Ok":

Начнется процесс клонирования репозитория.

Всё вышесказанное можно было бы заменить всего двумя командами в консоли:

cd path/to/dir
git clone URL

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

3. Создаем свою ветку. Для этого жмем правую кнопку мыши на директории в которую мы клонировали репозиторий и выбираем в меню "TortoiseGit -- Create Branch":

В открывшемся оке задаем название новой ветки и указываем на основании какой ветки репозитория мы будем создавать новую. Жмем "Ок", подтверждая создание ветки. Теперь переключаемся на свой новый branch.

Выбираем в меню "TortoiseGit - Switch/Checkout...":

В открывшемся окне выбираем нашу новую ветку и жмем "Ок". Убеждаемся, что мы успешно переключились:

По сути, все что касалось создания нового branch'a в консоли решилось бы всего одной командой:

checkout -b new-branch

4. Программируем. Теперь, когда мы все настроили - открываем необходимый проект в Delphi, вносим свои коррективы, изменяем модули и т.д. Вобщем ведем нормальную плодотворную работу с проектом.

5. Вносим изменения в репозиторий. После того как внесены какие-то изменения нам необходимо их закрепить в Git. И здесь опять же проявляется отличие этой системы контроля версий от того же SVN. Дело в том, что Commit в Git не сбрасывается сразу на сервер. Для того, чтобы внести изменения в удаленный репозиторий используется команда PUSH. В общем виде работа может быть построена следующим образом:

1. Вносятся изменения в проект

2. Изменения закрепляюся в вашем локальном репозитории, используя команду Commit в меню или, используя консоль:

git commit

3. Когда Вам необходимо/удобно/требуется закрепить все изменения на сервере выполняем push в свою ветку (brunch). Команда консоли выглядит так:

git push origin <свое имя бранча>

Здесь стоит, наверное рассмотреть весь процесс на деле. К примеру, мы решили добавить в проект простой текстовый файл с описанием чего либо. Создаем файл, записываем в него данные и добавляем файл в индекс.

Для этого выбираем новый файл, вызываем меню и выбираем "Add...":

По рисунку можно видеть, что я вношу в индекс новый файл text.txt. Жмем "Ok".

После того как файл добавлен, можно сразу же сделать Commit - кнопка Commit появится в окне с выводом консоли. Жмем её и откроется окно для внесения Commit'a:

Заполняем поле с описанием, жмем "Ок"  и коммит готов. Если хотите сразу отправить эти изменения в репозиторий, то в окне с выводом консоли появится также кнопка PUSH. Если же Вас не устраивает таскать по 1 файлику туда-сюда или изменения столь незначительны, что их нет смысла отправлять на сервер, то просто продолжаете дальше кодить, а push выполним позднее.

Чтобы выполнить команду push можете поступить следующим образом:

1. Зажимаем Shift и вызываем контекстное меню. В меню должны появится дополнительные команды:

Выбираем команду Push. Перед Вами откроется окно следующего содержания:

Все, что от Вас требуется на данном этапе - нажать на кнопку (на рисунке она выделена красным) найти в списке удаленную ветку в которую вы делаете push и два раза нажать Ok. Все изменения, произведенные Вами в локальном репозитории отправятся в Сеть.

Вот пожалуй все, что мне пока потребовалось использовать при работе с новой для меня системой контроля версий. Надеюсь эта мини-шпаргалка поможет кому-нибудь кроме меня. А если Вас заинтересовала работа с консолью, то как раз сейчас я изучаю Вот такие топики на habrahabr.ru:
1. Git Workflow.
2. Git Wizardry
Статьи написаны понятным простым языком и касаются как раз работы с Git с нуля.

--------------------------------------
Очень интересно узнавать что-то интересное и новое для себя и проводить тем самым развитие личности, развивать свой кругозор, как например в приведенном выше посте - узнать то, о чем раньше и не подозревал...
--------------------------------------
Понравилась статья? Тогда:
Делись! Загружай! Плюсуй!
   Отправить PDF на   
Читай ещё статьи на WebDelphi.ru

Комментарии (13)

WP_Cloudy
  • Opportune Flander пишет:

    Здравствуйте.
    Очень полезная заметка-памятка.

    В повседневной работе использую Svn. С Git’ом работаю от случая к случаю. И хоть такой «случай работы» был довольно давно (пол-года назад, не меньше), считаю эту систему контроля версий очень удобной.

    Сейчас уже точно не опишу суть проблемы, но при работе с Git стоит заранее разобраться с вопросом выставления символов окончания строки (параметр autocrlf). А то у меня однажды возникла ситуация, что в половине файлов исходников стояли LF, а в оставшейся CRLF. Из моего опыта, возникновение данной проблемы было обусловлено тем, что работа над одним проектом велась сразу в двух системах контроля версий — Svn и Git. Так что, если проект живёт только в Git, возможно такая ситуация и не произойдёт.

    И еще могу порекомендовать следующую статью о командной работе в Git:
    http://m-ivanov.livejournal.com/7988.html

  • Vlad пишет:

    Opportune Flander, да с символом перевода строки могут быть проблемы. Но, т.к. я больше ориентировался в статье на то, чтоб меньше грузить непосвященных в эту технологию пользователей тонкосями, то про LF и CRLF ничего не сказал. Все дело в том, что TortoiseGit сам правильно выставляет эти опции, поэтому упоминать в статье этого не стал :). За ссылку спасибо. Полезная штука.

  • BGoode пишет:

    Спасибо, а то заебался маленько))

  • Vlad пишет:

    С чем, если не секрет? :)

  • Alexo пишет:

    Незнаешь как изменить настройки openssh клиента?
    У меня порт SSH сервера изменент, и из за этого не могу подключиться.

  • Vlad пишет:

    Этого не знаю — пока ещё не приходилось сталкиваться

  • Nook пишет:

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

  • Илья Сергеевич пишет:

    отличное введение для новичков ЯЩЕТАЮ!!!
     
    единственный наглядный и подробный гид в картинках, который я смог быстро нагуглить, чтобы показать коллеге!

  • Mike пишет:

    Спасибо, прям очень помогло. Выручил =)

  • Евгений пишет:

    Добрый день!
    Подскажите как быть, хочу использовать Git для совместных разработок в Delphi7, но боюсь что часто будут возникать конфликты из-за того что двое разработчиков чуть форму сдвинут и поменяется Top, Left в файле описания формы.
    Можно ли как-то игнорировать изменения в определенных строчках?

  • Vlad пишет:

    Я вообще не спец по DVCS — отсюда и название поста, собственно :) Мы в свое время поделили проект на части — каждый работает над своим куском кода и в чужой не лезет — никаких конфликтов. Ещё можно просто перед каждой отправкой данных в репозиторий обновляться, в этом случае, по-моему тоже конфликтов быть не должно и данные не потеряются (те которые вы внесете в исходник ДО Pull’а)

  • Евгений пишет:

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

  • Гимаев Наиль пишет:

    http://githowto.com/ — на русском

Ваш ответ

Внимание: Все комментарии модерируются, и это может вызвать задержку их публикации. Отправлять комментарий заново не требуется.

Пожалуйста, заключайте исходный код в тэги [code][/code].
Если код большой, то воспользуйтесь Вставкой кода на отдельной странице и оставьте в комментарии ссылку на исходник

   


Покори мужчину - подари ему завод - Подарок мужчине. --|--. оценка земли