вторник, 30 октября 2012 г.

Установка Git на Windows и его использование совместно с GitHub

Установка Git в Windows очень проста.
У проекта msysGit процедура установки - одна из самых простых. Просто скачайте файл exe-инсталлятора со страницы Google Code и запустите его:

code.google.com/p/msysgit

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

После установки Git следует выполнить ряд разовых настроек. Это системные настройки, что означает, что их необходимо сделать лишь единожды.
Наберите в консоли:

git config --global user.name "Your Name"
git config --global user.email youremail@example.com

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

git init

Следующий шаг добавит файлы проекта в репозиторий. Есть незначительная сложность: Git по умолчанию отслеживает изменения всех файлов, но есть несколько файлов, которые мы не хотели бы отслеживать. Например, Rails создает log файлы, для записи поведения приложения; эти файлы часто изменяются, и мы не хотим, чтобы наша система управления версиями постоянно обновляла их. у Git есть простой механизм, чтобы игнорировать такие файлы: просто включите файл, названный .gitignore в корневой каталог Rails с небольшим количеством правил, которые говорят Git какие файлы следует игнорировать.

Дефолтный .gitignore создаваемый командой rails.

.bundle
db/*.sqlite3
log/*.log
tmp/**/*

Листинг заставляет Git игнорировать такие файлы как log файлы, Rails временные (tmp) файлы, и базы данных SQLite. (Например, чтобы игнорировать log файлы, которые живут в log/ каталоге, мы используем log/*.log, чтобы игнорировать все файлы, заканчивающиеся на .log.) Большинство этих игнорируемых файлов изменяются часто и автоматически, так что включать их в управление версиями неудобно; кроме того, при совместной разработке они могут вызвать конфликты.

Наконец, мы добавим файлы вашего проекта к Git, а затем закоммитим результаты. Можно добавить все файлы (кроме тех, которые соответствуют правилам игнорирования в .gitignore) следующим образом, набрав в консоли:

git add .

Здесь точка ‘.’ представляет текущий каталог, и Git достаточно умен, чтобы добавить файлы рекурсивно, таким образом, это автоматически включает все подкаталоги. Эта команда добавляет файлы проекта в зону ожидания, которая содержит незавершенные изменения вашего проекта; можно видеть, какие файлы находятся в зоне ожидания, используя команду status:

git status

Для того, чтобы сказать Git, что вы хотите сохранить изменения, используйте команду commit:

git commit -m "Moy perviy commit"

Метка -m позволяет вам добавлять сообщение для фиксации.

Важно отметить, что коммиты Git локальны, и записываются только на машине, на которой происходят коммиты. Что отличает его от популярной open-source системы управления версиями под названием Subversion, в которой коммит обязательно приводит к изменениям в удаленном репозитарии. Git делит коммит в стиле Subversion на два логических куска: локальная запись изменений (git commit) и отправка изменений в удаленный репозиторий (git push)..

Между прочим, вы можете увидеть список своих сообщений о коммитах, используя команду log:

git log

Чтобы выйти из log git, нажмите q.

Мы можем легко отменить изменения в файлах, получив из Git предыдущую фиксацию командой checkout (и флагом -f, чтобы инициировать перезапись текущих изменений):

git checkout -f

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

После регистрации на GitHub (github.com) вы увидите следующую страницу:

github_first_page

Щелкните создать репозиторий и заполните форму.

create_first_repository

После подтверждения формы отправьте свое первое приложение, набрав в консоли следующие команды:

git remote add origin git@github.com:<username>/your_app.git
git push origin master

Эти команды говорят Git, что вы хотите добавить GitHub как начальный адрес для вашей основной (master) ветки, а затем отправить ваш репозиторий на GitHub. Конечно, следует заменить <username> вашим фактическим именем пользователя. Например, команда, которую я запустил для railstutorial пользователя, была

git remote add origin git@github.com:railstutorial/first_app.git


Результатом является страница на GitHub для репозитория первого приложения (first application), с браузером файлов, полной историей коммитов.



github_repository_page

Git невероятно хорош в создании веток, которые фактически являются копиями репозитория, где мы можем произвести (возможно экспериментальные) изменения, не модифицируя родительские файлы. В большинстве случаев родительский репозиторий – master ветка, и мы можем создать новую рабочую ветку используя checkout с флагом -b:

git checkout -b izmenenie-README
git branch

Здесь вторая команда, git branch, только перечисляет все локальные ветки, а звездочка * указывает, какая ветка в настоящий момент включена.

Отметьте, что git checkout -b izmenenie-README одновременно и создает новую ветку и переключает на нее, на что указывает звездочка перед izmenenie-README веткой.

После внесения изменений в файлы мы могли бы использовать git add . , но Git предусматривает флаг -a как сокращение для (очень частого) случая фиксации всех изменений к существующим файлам (или файлов, созданных с использованием git mv, которые не считаются новыми для Git):

git commit -a -m "Uluchshenie fayla README"

Будьте осторожны с использованием флага -a; если вы добавили какие-либо новые файлы в проект после последней фиксации, вы должны сообщить Git о них используя сначала git add.Будьте осторожны с использованием флага -a; если вы добавили какие-либо новые файлы в проект после последней фиксации, вы должны сообщить Git о них используя сначала git add.

Теперь, когда мы закончили производить наши изменения, мы готовы объединить результаты с нашей master веткой:

git checkout master
git merge izmenenie-README

После того, как вы объединили изменения, вы можете почистить свои ветки, стерев тему ветки, используя git branch -d, если вы хотите, сделайте это так:

git branch -d izmenenie-README

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

Как упомянуто выше, вы также можете отказаться от изменений, относящихся к рабочей ветке, в таком случае используйте git branch -D:

# Только для иллюстрации; не делайте этого, если планируете в дальнейшем пользоваться веткой

git checkout -b topic-branch
git add .
git commit -a -m "Screwed up"
git checkout master
git branch -D topic-branch

В отличие от флага -d, флаг -D сотрет ветку даже если мы не объединили изменения.

Теперь, когда мы обновили README, мы можем отправить изменения в GitHub чтобы увидеть результат. Так как мы уже сделали одну отправку, на большинстве систем, мы теперь можем опустить origin master, и просто выполнить git push:

git push

На некоторых системах, эта команда выдает ошибку:

git push
fatal: The current branch master is not tracking anything.

В этом случае необходимо выполнить команду:

git push origin master

Комментариев нет:

Отправить комментарий