Интерактивные курсы по Git

Библиотека сайта или "Мой Linux Documentation Project"

Оригинал: Interactive Git Tutorials
Автор: Jacob Gube
Дата публикации: Dec 31 2014
Перевод: Н.Ромоданов
Дата перевода: январь 2015 г.

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

Благодаря наличию в интернете интерактивных учебных руководств и онлайн-курсов обучение Git оказалось для меня проще. Они сделали эту задачу более увлекательной и интересной, что, в свою очередь, повысило желание этим заниматься. Кроме того, для их прохождения не требуется, чтобы я устанавливал и настраивал Git на своем компьютере, так что я смог сразу начать обучение и экспериментирование.

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

Разработчики, которые воспользуются приведенными ниже руководствами, смогут изучить Git до необходимого для них уровня.

Try Git является интерактивным руководством, которое отлично подойдет для тех пользователей, которые впервые сталкиваются с Git. В нем рассматриваются самые важные команды Git — то, чем вы, скорее всего, будете пользоваться изо дня в день — например, при создании хранилища Git, фиксации изменений и работы с удаленными репозиториями.

Этот ускоренный курс спроектирован так, что его можно пройти за 15 минут.

Git Real является интерактивный курсом, созданным в рамках школы кодирования Code School. В нем приводятся видео инструкции и предлагаются практические интерактивные задачи.

Бесплатным является только первый уровень курса Git Real (который назван "Введение"), но в нем рассмотрены все основных сведения, которые вам желательно знать о Git. Подумайте об прохождении этого уровня, поскольку в нем Git рассмотрен более детально, чем в Try Git .

Что мне в целом нравится в курсе Git Real. то это то, что он сфокусирован на том, чем мы, скорее всего, будем пользоваться в процессе веб-разработки.

Что касается меня, то самые самыми сложными темами, касающимися Git, были дерево исходных кодов (source tree), обход дерева исходных кодов (source-tree traversal ) и ветвление (branching). Это интерактивное веб-руководство по Git оказалось меня чрезвычайно полезным.

Руководство Learn Git Branching (Изучаем ветвление в Git) состоит из пяти частей, которые упорядочены по возрастанию сложности усвоения материала, причем каждая часть имеет от двух до пяти модулей.

Следующий совет предназначен для тех, кто изучает Git с нуля и хочет на практике достичь уровня мастера.

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

Но то, что я изучал Git с помощью командной строки, действительно помогло мне понять абстрактные понятия Git, т. к. у меня не было никаких визуальных костылей, на которые я бы мог полагаться (например, диаграмм каталогов).

Использование интерфейса командной строки является более сложным, и это хорошо, поскольку это заставляет нас работать медленнее и по-настоящему осваивать материал.

Кроме того, когда вы освоитесь с интерфейсом командной строки, то это поможет вам в дальнейшем при использовании других веб-компонентов с открытым исходным кодом, таких как препроцессоры CSS, Node, Bower, Grunt и так далее.

Если что-то делать, то это следует делать хорошо.

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

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

Рассматривайте обучение Git как инвестиции.

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

То, что вы можете сделать прямо сейчас:

1. Клонируйте с GitHub на ваш компьютер проект с открытым кодом и внести в него изменения. Используйте ветвление для отслеживания ваших изменений.
2. Опубликуйте на GitHub небольшой проект с открытым исходным кодом. Это не обязательно должен быть полномасштабный веб-фреймворк для приложений или что-то подобное — на их создание потребуется много времени и это помешает вам достичь целей данного задания. Для начала прекрасным примером такого проекта можете быть простой компонент интерфейса, например, панель навигации или демонстрация использования CSS.
3. Попроситесь поучаствовать в проектах с открытым исходным кодом. Прежде чем делать это, важно ознакомится с этикетом работы с открытым исходным кодом и конкретными правилами работы с конкретным проектом. собственные руководящие принципы проекта, Для начала, вы можете попрактиковаться на моем репозитории GitHub в случае, если вы заметили что-нибудь, что должно быть исправлено (спасибо).

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

Но если вы почувствуете, что уровень ваших знаний английского языка все же недостаточен для прохождения предлагаемых курсов или если вы вообще не знаете английского языка, то можно пойти другим путем — поискать с помощью Google материалы о Git на русском языке. В сети выложено достаточно много материалов о Git на многих языках, однако первое, с чем советуют сразу ознакомиться практически на всех сайтах, рассказывающих о Git, это прочитать книгу Pro Git book. С ней можно ознакомиться абсолютно бесплатно: она переведена на многие языки, в том числе и (увы, частично) на русский язык ( http://git-scm.com/book/ru/v2 ). Обратите внимание, что это уже второе издание книги (2014 г.) и она распространяется по свободной лицензии Creative Commons Attribution-NonCommercial-ShareAlike 3.0.

Есть еще один способ первоначального ознакомления с Git (впрочем, как и с многими другими технологиями) — поискать на youtube подходящее видео. Для первоначального ознакомления с Git можно посоветовать следующие видео на русском языке:

Эта статья еще не оценивалась

Вы сможете оценить статью и оставить комментарий, если войдете или зарегистрируетесь .
Только зарегистрированные пользователи могут оценивать и комментировать статьи.

Установка GIT и настройка GitHub: полное руководство (Windows, Linux) (: Система контроля версий GIT )

Здесь описывается практическая часть вопроса использования Git - его установка и регистрация на сервере GitHub.com.

GitHub.com - это сервис, предлагающий хранение вашего кода и данных с использованием системы контроля версий Git. GitHub предоставляет бесплатный тарифный план для хранения 300Мб данных в открытом виде. Это значит, что любой пользователь интернета может скачать себе ваши данные. На GitHub можно разместить и закрытые для других репозитарии, заплатив 7$ в месяц. На бесплатном аккаунте GitHub, по-умолчанию, никто не сможет изменить ваши данные (могут только читать). Но вы можете настоить, кто из пользователей системы GitHub, имеет право на запись.

В статье подробно рассказывается, как делать настройку Git в ОС Windows и в ОС Linux.

Установка Git под Linux

Пользователям Linux, думаю, нет смысла объяснять, как устанавливать Git - в каждой системе это делается по-разному. В системе Debian (которая стоит у меня), для установки Git, можно использовать команду:

apt-get install git

Установка Git под Windows

Идем на официальную страницу Git http://git-scm.com. кликаем на Download for Windows. В открывшемся окне кликаем на Full installer for official Git. Запускаем полученный exe-шник.

В процессе инсталляции будет задан такой вопрос:

Я рекомендую выбрать "Run Git from the Windows Command Prompt". Все остальные опции можно оставлять по-умолчанию. После установки Git нужно перегрузиться или завершить сеанс пользователя и снова войти, чтобы применились изменения в системной переменной PATH.

Далее нужно проверить, доступен ли Git для работы. В любом каталоге даем команду:

Если получаем информацию о версии, то Git установлен и работает. Если получаем информацию что программа git не найдена, разбираемся что сделали не так.

Перед тем, как регистрироваться на GitHub, следует вначале сгенерировать SSH-ключ шифрования. Этот ключ необходим, чтобы быстро устанавливать соединение с GitHub, не вводя пароля. Без такого ключа GitHub просто не будет работать.

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

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

Настройка SSH-ключей в Linux

В операционной системе Linux вначале нужно заглянуть в каталог

/.ssh. Если там есть файлы id_rsa и id_rsa.pub то это и есть SSH-ключи. Если такого каталога или таких файлов нет, то ключи нужно сгенерировать. Даем команду:

ssh-keygen -t rsa -C 'myemail@mail.ru'

Вместо myemail@mail.ru нужно указать свой email. В процессе генерации ключа у вас спросят куда положить файлы, в ответ просто нажимаем Enter. При запросе пароля просто нажимаем Enter. После генерации, в каталоге

/.ssh должны появиться файлы id_rsa и id_rsa.pub. они нам пригодятся в дальнейшем.

Настройка SSH-ключей в Windows

В операционной системе Windows генератор SSH-ключей включен в комплект поставки Git. Для генерации ключей необходимо запустить на выполнение файл C:\Program Files\Git\Git bash.vbs. Его можно запустить как обычный exe-шник. Откроется программа "Консоль git". В ней надо дать команду:

ssh-keygen -t rsa -C "myemail@mail.ru"

Будьте внимательны, в этой консоли подглючивает копи-паст, прощще ввести команду вручную. В качестве email указываем свой почтовый ящик. На запрос " Enter file in which to save the key " просто нажимаем Enter. При запросе пароля " Enter passphrase " и " Enter same passphrase again " просто нажимаем Enter. В процессе генерации ключей в консоли будет выдаваться примерно следующая информация:

Generating public/private rsa key pair.
Enter file in which to save the key (/c/Documents and Settings/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /c/Documents and Settings/username/.ssh/id_rsa.
Your public key has been saved in /c/Documents and Settings/username/.ssh/id_rsa.pub.
The key fingerprint is:
51:db:73:e9:31:9f:51:a6:7a:c5:3d:da:9c:35:8f:95 myemail@mail.ru

После выполнения этой программы, в каталоге C:\Documents and Settings\username\.ssh будут лежать файлы id_rsa и id_rsa.pub. они нам пригодятся в дальнейшем.

Регистрация на GitHub.com

Теперь всё готово для регистрации. Переходим на стартовую страницу GitHub.com. Интерфейс немного замороченный, поэтому приведу пару скриншотов где что нажимать. Дизайн и верстку могут в любой момент сменить, так что описываю логику действий на данный момент.

В верхнем меню находим пункт "Pricing and Signup " и нажимаем на него:

Откроется страница выбора тарифного плана. Выбираем бесплатный аккаунт "Create a free account ":

Далее появится страница регистрации, на которой надо ввести имя пользователя, свой настоящий email и задать пароль. После регистрации сразу попадаем на личную страничку.

Установка SSH-ключа в GitHub

Сразу после регистрации необходимо прописать в системе GutHub свой публичный ключ шифрования (открытый SSH-ключ). Для добавления ключа, надо в правом верхнем углу нажать "Account Settings ":

В открывшемся окне нужно кликнуть на пункт меню "SSH Public Keys ", и нажать "Add Another Public Key ". Появится два поля - название ключа (Title ) и содержимое ключа (Key ).

В поле Title можно написать название компьютера, на котором сгенерирован публичный ключ. Можно писать по-русски.

В поле Key надо вставить содержимое файла id_rsa.pub. Помните, в каком каталоге они находятся? Переходим в этот каталог, открываем любым текстовым редактором файл id_rsa.pub (именно с расширением .pub. не перепутайте). Выделяем весь текст, копируем, и вставляем на странице GitHub в поле Key .

После добавления ключа, компьютер может соединяться с GitHub через программу git, и никаких ошибок не должно возникать.

Создание репозитария на GitHub

Теперь пришло время создать свой первый репозитарий на GitHub. Репозитарий можно рассматривать просто как директорию, в которой будут лежать синхронизируемые файлы и поддиректории. Создавать репозитарий нужно в web-интерфейсе GitHub, а наполнять его файлами и работать с ним можно будет уже с помощью программы git на своем компьютере.

Для создания репозитария, нужно в правом верхнем углу нажать "Dashboard ". В открывшемся окне вы увидите пункт "Create A Repository ":

Так вот, этот пункт нам не нужен! Данный пункт открывает не диалог создания репозитария, а страничку помощи. Вместо клика по этому пункту, ищем ниже на странице малоприметную ссылку "Create A Repository ". Она и откроет диалог добавления нового репозитария.

В диалоге добавления нового репозитарию нужно заполнить, как минимум, поле названия проекта "Project Name ". В названии проекта лучше не использовать кириллицу, так как имя проекта - это по факту имя директории. Для избежания проблем лучше, чтобы имя проекта содержало только латиницу. После нажатия кнопки "Create Repository ", репозитарий будет создан.

Рабочая ссылка на репозитарий в системе GitHub формируется так. Если вы зарегистрировались под именем username. и ваш репозитарий называется reponame. то для доступа к этому репозитарию можно использовать следующие ссылки:

В синтаксисе Git:

В синтаксисе Https:

Работа с репозитарием на GitHub через программу Git

Начиная с этого момента, пляски вокруг web-интерфейса GitHub можно считать законченными. Далее можно работать только используя программу git.

Вначале нужно сделать небольшую настройку программы git: указать локальной системе git имя пользователя и email. Это делается следующими командами, которые можно выполнить, находясь в любом каталоге:

git config --global user.name "YourFullName"
git config --global user.email myemail@mail.ru

где вместо YourFullName нужно написать свое имя, а вместо myemail@mail.ru - свой email. Эти значения используются для логина на GitHub. Поэтому на месте YourFullName нужно указать ваш логин на GitHub-е, а на месте myemail@mail.ru нужно указать email, который вы вводили при генерации ключей шифрования.

После этих настроек, можно заливать свои файлы в репозитарий. Переходим в каталог со своим проектом, и даем команды:

git commit -a -m 'first commit'

git remote add origin git@github.com:username/reponame.git

git push -u origin master

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

Моя шпаргалка по работе с Git

Некоторое время назад я открыл для себя Git. И знаете, я проникся. То есть, по-настоящему проникся. Теперь я использую Git не только на работе (где я с ним, собственно, познакомился), но и для своих проектиков, которые я стал хранить на BitBucket. Последний начал поддерживать Git относительно недавно. В отличие от GitHub BitBucket позволяет совершенно бесплатно создавать как открытые, так и закрытые репозитории.

Главное отличие Git от Subversion заключается в том, что Git — распределенная система контроля версий. Звучит ужасающе, но на практике это означает очень простую вещь. Каждый разработчик держит у себя на диске отдельный репозиторий. Обратите внимание — не копию репозитория, не некоторые бранчи. а тупо отдельный и при этом абсолютно полноценный репозиторий.

Пока мы работаем в рамках своего репозитория, все происходит в точности, как в Subversion. Мы коммитим и откатываем изменения, создаем, мерджим и удаляем бранчи, разрешаем конфликты и тд. Помимо этого, предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает мердж локальных изменений в удаленный репозиторий, а «git pull» — наоборот, мердж изменений из удаленного репозитория в локальный. Обмен данными по сети обычно происходит с использованием протокола SSH.

В результате имеем:

• Git присущи все те же преимущества от использования VCS, что мы получаем в Subversion .
• Git дает нам нормальное шифрование «из коробки», безо всяких танцев с бубнами, как в случае с Subversion.
• Если сервер с «главным» репозиторием, куда пушат свои изменения все разработчики (хотя формально в Git нет никакого «главного» репозитория), вдруг прилег — ничего страшного. Делаем коммиты в локальный репозиторий и ждем, когда сервер вернется.
• Даже если сервер доступен, все равно удобнее сделать пяток локальных коммитов, а затем отправить их на сервер одним пушем.
• Сервер вообще не нужен. Вы можете использовать Git только локально. И не обязательно для работы с исходниками. Например, можно использовать Git для того, чтобы иметь возможность откатиться к предыдущим версиям файлов (каких-нибудь электронных таблиц) или вернуть случайно удаленные.
• Git не раскидывает по каталогам служебную информацию (помните «.svn»?). вместо этого она хранится только в корне репозитория.
• Git нынче очень моден (хотя это далеко не единственная распределенная система контроля версий, например, есть Mercurial и Darcs), в связи с чем растет число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме или собрать команду разработчиков, знакомых с этой VCS.
• Существует множество полезных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
• Git поддерживают многие хостинги репозиториев (GitHub. BitBucket. SourceForge. Google Code. … ) — есть из чего выбрать.
• Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.

Я использовал Git при написании программы из заметки Генерация почти осмысленных текстов на Haskell. сидя под своей любимой FreeBSD. Вот как примерно выглядела моя работа с Git.

В первую очередь необходимо поставить Git:

Затем создаем пару ssh ключей, если не создавали ее ранее :

Иногда требуется создать копию репозитория или перенести его с одной машины на другую. Это делается примерно так:

mkdir -p / tmp / git-copy
cd / tmp / git-copy
git clone --bare git @ example.com:afiskon / cpp-opengl-tutorial1.git
cd cpp-opengl-tutorial1.git
git push --mirror git @ example.com:afiskon / cpp-opengl-tutorial2.git

Следует отметить, что Git позволяет использовать короткую запись хэшей. Вместо «d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4» можно писать «d8578edf» или даже «d857».

Дополнение: Также в 6-м пункте Мини-заметок номер 9 приводится пример объединения коммитов с помощью git rebase. а в 10-м пункте Мини-заметок номер 11 вы найдете пример объединения двух репозиториев в один без потери истории.

Более подробно сабмодули и зачем они нужны объясняется в заметке Простой кроссплатформенный OpenGL-проект на C++. Здесь упомянем самое главное.

git submodule add https: // github.com / glfw / glfw glfw

git submodule init

Обновление сабмодулей, например, если после git pull поменялся коммит, на который смотрит сабмодуль:

git submodule update

Удаление сабмодуля производится так:

1. Скажите git rm --cached имя_сабмодуля ;
2. Удалите соответствующие строчки из файла .gitmodules;
3. Также грохните соответствующую секцию в .git/config;
4. Сделайте коммит;
5. Удалите файлы сабмодуля;
6. Удалите каталог .git/modules/имя_сабмодуля;

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

Как обычно, любые замечания, дополнения и вопросы категорически приветствуются. И кстати, с наступающим вас!

Руководства по GIT на русском языке

Руководств по Git на английском языке великое множество, но на русском их на порядок меньше. Я, конечно, согласен с тем, что нужно учить английский и читать в оригинале, но у меня с этим есть небольшие проблемы. И если есть возможность найти эту-же информацию на русском языке, то для меня выбор очевиден.

Я выбрал три хороших руководств для изучающих Git на русском языке, которыми хочу поделиться с вами:

1. Git the simple guide — простое руководство по работе с git.
   Но для кого-то этого материала может не хватить, поскольку там описано все очень кратко и только основные моменты.
2. Pro Git — исчерпывающая книга по Git, которую можно купить на Амазоне или читать онлайн / скачать бесплатно.
3. Git How To — это интерактивный тур, который познакомит вас с основами Git. Тур создан с пониманием того, что лучшим способом научиться чему-нибудь — сделать это своими руками. </ol> Очень понравился ресурс Git the simple guide и Git How To. У меня уже был опыт работы с Git, но только через GUI. Поэтому первый ресурс мне очень подошел. Кстати если вас не привлекает работа через терминал, то в конце Git the simple guide есть полезные ссылки с программами для работы c Git через графические интерфейсы (GUI) и несколько руководств.

Git инструкция на русском

В апреле 2006 года идея хранить исходный код пакетов в git-репозитории была реализована с помощью утилиты, которая 27-го апреля получила имя gear. Напомню вкратце:

Основной смысл хранения исходного кода пакетов в git-репозитории заключается в более эффективной и удобной совместной разработке, а также минимизации трафика и места на диске для хранения архива репозитория за длительный срок. Идея gear заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки которых достаточно git +sed ) можно было собирать пакеты из произвольно устроенного git-репозитория, по аналогии с hasher. который был задуман как средство собирать пакеты из произвольных srpm-пакетов.

За время, прошедшее с конца апреля, многие из вас успели освоиться с gear. появилась базовая документация, семейство вспомогательных утилит и опыт эксплуатации. Поэтому весьма вероятно, что те из вас, кому только предстоит осваивать gear, пройдут этот путь гораздо легче и быстрее чем я. ) Например, одна только утилита gear-srpmimport позволяет на начальном этапе вообще не интересоваться синтаксисом файла .gear-rules.

На всякий случай рекомендую установить/обновить пакет gear. а также освежить в своей памяти содержимое файлов /usr/share/doc/gear-1.4.0/QUICKSTART.ru.html и /usr/share/doc/git-1.5.5.3/tutorial.html

Как уже было сказано, gear не накладывает ограничений на внутреннюю организацию git-репозитория (не считая файла с правилами). Тем не менее, у меня есть несколько соображений о том, как более эффективно и удобно организовывать git-репозитории, предназначенные для хранения пакетов:

• Одна сущность — один репозиторий. Не стоит помещать в один репозиторий несколько разных пакетов, за исключением случаев, когда у этих пакетов есть общий пакет-предок. Соблюдение этого правила облегчает совместную работу над пакетом, поскольку не перегруженный репозиторий легче клонировать и в целом инструментарий git больше подходит для работы с такими репозиториями. Отрицательная сторона. несколько сложнее делать «push» и «pull» в случае, когда репозиториев, которые надо обработать, много. Впрочем, push/pull в цикле выручает.
• Несжатый исходный код. Сжатый разными архиваторами исходный код (как правило это tarball’ы) лучше хранить в git-репозитории в несжатом виде. Изменение файлов, которые помещены в репозиторий в сжатом виде, менее удобно отслеживать штатными средствами (git-diff ). Поскольку git хранит объекты в сжатом виде, двойное сжатие редко приводит к экономии дискового пространства. Наконец, алгоритм, применяемый для минимизации трафика при обновлении репозитория по протоколу git, заметно более эффективен на несжатых данных. Отрицательная сторона. поскольку некоторые виды сжатия одних и тех же данных могут приводить к разным результатам, может уменьшиться степень первозданности (нативности) исходного кода.
• Распакованный исходный код. Исходный код, запакованный tar/cpio/…, лучше хранить в git-репозитории в распакованном виде, по тем же причинам (заметно удобнее отслеживать изменения, существенно меньше трафик при обновлении). Отрицательная сторона. поскольку git из информации о владельце, правах доступа и дате модификации файлов хранит только исполняемость файлов, любой архив, созданный из репозитория, будет по этим параметрам отличаться от первозданного. Помимо потери нативности, изменение прав доступа и даты модификации может теоретически повлиять на результат сборки пакета. Впрочем, такие пакеты, если они будут обнаружены, всё равно надо править.
• Аккуратный changelog. В changelog релизного commit’а стоит включать соответствующий текст из changelog’а пакета, как это делают утилиты gear-commit (обёртка к git-commit. специально предназначенная для этих целей) и gear-srpmimport. В результате можно будет получить представление об изменениях в пакете, не заглядывая в spec-файл самого пакета.

Для преодоления барьеров вида «админ закрыл наружу всё и оставил только прокси» ssh на git.altlinux.org доступен также и на порту 443, что можно использовать.

По всем вопросам, связанным с этой частью инструкции, пишите на join@.

Клонировать к себе на компьютер свой репозиторий с git.altlinux.org:

Клонировать к себе на компьютер чужой репозиторий с git.altlinux.org:

Залить на git.alt свой ранее созданный git-репозиторий:

Представим, что некий foo сделал какие-либо изменения для нашего пакета bar в бранче bar-bugfree и выложил их на git.alt. Узнаем, как называется его этот бранч:

Далее зафетчим этот бранч к нам с одноименным названием:

Дальше работаем с ним как хотим ;)

Удалить бранч на git.alt (задав пустое имя локального бранча):

Копирование файлов из одного бранча в другой:

и устаревший способ:

> Слить сорцы из git'а, сделать патч и отправить автору (да, в мире существуют
> другие git-репозитории, помимо git.a.o). Совершенно обычный use-case для того
> типа пользователя, кого сейчас в инфраструктуре совершенно игнорируют: casual
> mantainers, которых почти всё устраивает, но иногда хочется написать патчик и
> отправить обратно.

В принципе, даже той информации, которая есть в бинарном пакете сейчас, уже достаточно для casual mantainers:

1. В установленном бинарном пакете есть % (виден по rpmquery -i), из которого однозначно вычисляется имя исходного пакета.

2. Далее, в установленном бинарном пакете есть % (виден по rpmquery --lastchange).

3. По именам мантейнера (MAINT) и исходного пакета (PKG) можно с очень высокой вероятностью предположить, что если пакет был собран из git-репозитория, то этот репозиторий называется http://git.altlinux.org/people/MAINT/packages/?p=PKG.git

Там правда апстрим git-овый, но это сути не меняет. gear-rules там состоит из одной строчки - вот такой:

@name@ и @version@ берутся из спека. @name@ - это liblazy. а @version@ - это 0.1

На ветке upstream присутствует тег liblazy-0.1. Поэтому апстримный тарбол будет браться из этого тега.

При переезде на новую версию надо будет всего лишь:

1. Поставить нужный тег на апстримной ветке (например liblazy-0.2).
2. Смержить этот тег в master с -s ours
3. Заменить в спеке версию с 0.1 на 0.2.
4. Выполнить gear-update-tag -ac
5. Дописать changelog

Пакет, который давно не собирался или заброшен, или его мейнтейнер не пользуется git.alt, можно найти в архиве Сизифа. Архив Сизифа содержит последние версии когда-либо собиравшихся в Сизиф пакетов (с историей) и доступен по ssh git.alt в каталоге /archive. Для удобства хранилища собраны в двухуровневое дерево (по первой букве), без различия мейнтейнеров.

Таким образом на сегодняgit-clone git.alt:/archive/m/mkimage отдаст хранилище, соответствующее текущему пакету mkimage в Сизифе, кто бы его ни собрал на этот раз.

Совместная работа над пакетами в git строится по следующей схеме:

При дальнейшей работе сценарий повторяется, за исключением того, что B не клонирует репозиторий A/X, а подтягивает (pull) из него новые изменения.

Как это реализуется на практике?

Для поиска репозитория для клонирования используется команда find-package.

Склонировать репозиторий можно с помощью команды clone.

Эта команда создаст вашу копию репозитория на сервере git.alt. Для работы с ним необходимо склонировать этот репозиторий на локальную машину:

С этим git-репозиторием можно работать как обычно: править, делать commit и так далее. Поскольку для склонированного репозитория создаётся remote с названием origin, то git-push тоже работает:

Нотификации производятся вручную - почтой или через bugzilla. Аналога pull request из github или gitorious на git.alt пока что нет.

Втягивание чужих изменений производится стандартными git-средствами: добавлением remote

и отправкой в git.alt.

Если вы хотите удалить ветку из репозитория, располагающегося не на вашей машине — сделайте в него push из «никакой» ветки:

или если хотите удалить тег:

Полная форма push выглядит так:

где <local branch> — имя локальной ветки, из которой берутся данные, а <remote branch> — имя ветки в удалённом репозитории, куда происходит их передача с замещением имеющегося. Привычный вид git push <remote repo> <remote branch> является лишь одной из реализаций этой полной формы.

Установка git в Windows (на этот раз подробно)

Судя по всему, многие из посетителей приходят на этот блог в поисках руководства по установке Git в Windows. И, что самое печальное, всё что они находят — куцая страничка со ссылкой на англоязычный скринкаст. Пришло время исправить это недоразумение??

Итак, установка git. Сразу оговорюсь что мы будем ставить msysgit. и заодно произведём необходимые действия для подключения к GitHub. Конечно, можно использовать git и в одиночку, для себя — но здесь, как и с играми, в онлайне намного интереснее??

Идём на страницу git. в раздел Download и ищем там msysgit для Windows. Сайт git отправляет нас на Google Code. Берём Full Installer for official Git .

Запускаем, устанавливаем. При установке будет предложено выбрать тип запуска Git:

• Git bash only. git ставится и вызывается командой контекстного меню «Git bash here»/»Git gui here»
• Run from the Windows command prompt. Устанавливает Git и прописывает путь к консольной версии в PATH. Команду ‘Git Bash here’ всё равно можно использовать.
• Run Git and tools from Windows Command Prompt. то же что предыдущий вариант, но дополнительно прописывает в Windows путь к различным Unix-утилитам типа find и sort. Git предупреждает нас что при этом вместо windows-приложений с соответствующими именами будут вызываться unix-аналоги

Я предпочитаю второй вариант, т.к. использую git исключительно из командной строки. Так что это руководство будет по большей части консольным??

Продолжаем установку. В конце git предложит просмотреть файл примечаний к релизу. Собственно, на этом установка заканчивается?? Теперь идём в командную строку (если Вы выбрали этот вариант) и вводим свои данные в git. чтобы он нормально подписывал коммиты.

Не забудьте подставить своё имя/ник и email?? Параметр --global говорит нам что мы изменяем глобальные настройки. Чтобы изменить настройки только одного репозитория, перейдите в его папку и сделайте то же без --global :

Кстати, создаётся репозиторий командой git init в нужной папке. Всё, git можно пользоваться в локальном режиме??

Давайте теперь что нибудь утянем с Github. Идём туда, делаем поиск или Explore Github, открываем понравившийся проект. Прямо под названием проекта будет Clone URL:

Жмём, копируем команду. Получится примерно что то такое:

Переходим в каталог куда мы хотим положить проект, и выполняем команду. Имейте в виду, git создаст для проекта каталог чтобы его туда положить. То есть, если мы выполним эту команду в D:\Source. проект будет в папке D:\Source\jquery-builds .

Чтобы хранить свой проект в GitHub, надо ещё немного покопаться с настройкой?? Нам понадобится пара ключей SSH. Открываем консоль Git bash, всё равно где. В msysgit процесс генерации пары ключей упрощён почти до предела. Делаем:

У Вас спросят куда положить ключи (не потеряйте их, лучше выбрать предлагаемое программой место), дважды спросят пароль (passphrase). Пароль должен быть сложным. После этого Вы получите два файла и RSA fingerprint примерно такого вида:

Теперь идём и регистрируемся на Гитхабе, в бесплатном варианте.

Внимание, бесплатный аккаунт на GitHub — аккаунт для Open-Source проектов. Вы не сможете закрыть свой код, или скрыть его от других. Не используйте его для проприетарного кода и рабочих проектов!

В поле SSH Public Key вставляем содержимое файла id_rsa.pub. или как Вы его там назвали при создании ключей. Если Вы создали ключи в своей папке пользователя, ssh самостоятельно его найдёт. Иначе, надо будет добавить ключи вручную:

Завершаем регистрацию. Теперь можно уже проверить что получилось. В простой командной строке подключаемся к серверам github:

В ответ должно прийти:

Это значит что всё в порядке.

Если Вы видите No supported authentication methods available. значит Git не может найти программу, способную достучаться до сервера Гитхаба. Строка вызова используемой программы хранится в переменной GIT_SSH. Чтобы использовать программу ssh (самый простой способ), надо сделать в командной строке:

Имейте в виду, после перезагрузки эта переменная вернётся в начальное состояние.

Спасибо, у меня вопрос:

Изначально у меня был один репозиторий в аккаунте на github — spasalon-mvc.git

Потом я создал еще один — testJavaGit.git

Набрал в git bash следующие строки:
—
cd testJavaGit ( моя локальная папка, тут все нормально )

git commit -m «initial commit»

git remote add origin git://github.com:EVOSandru6/spasalon-mvc.git ( тут я перепутал название репозитория. )

git push origin master ( ввел данные от кабинета, вошел )

git commit -m «more changes to index»

git push origin master

Как теперь удалить файлы из репозитория «spasalon-mvc.git» и связать папку testJavaGit с репозиторием testJavaGit.git

Пробовал проделать все действия выше повторно, но только со строкой

Но пишет ругательство remote origin already exist

Удалить репо (и все файлы) можно по моему прямо из аккаунта на Github — заходите там в свой репозиторий, потом Settings и внизу Delete this repository.

EDIT: А, надо сменить remote. git remote set-url origin правильный_url

Спасибо, команда сработала, теперь когда я набираю

git push origin master. выходит ошибка :

unable to look up github.com (port EVOSandru6) (Тут в скобках Всякие Крякозябры)

Потому что правильно git remote set-url origin git://github.com/EVOSandru6/spasalon-mvc.git

Так в файл конфига прописалось

[remote «origin»]
url = git://github.com/EVOSandru6/testJavaGit.git
fetch = +refs/heads/*:refs/remotes/origin/*

Не работает именно git push origin master команда, выходит ошибка.

И еще вопрос, что делать если файл gitignore отсутствует.

Я по книжке дошел до сего места с игнорированием файлов

В документации смотрел, что вроде это какой то файл, но в .git такого нет. Как правильно задать команды для игнорирования в таком случае или сперва нужно переключиться

сd ` какой либо файл/каталог ` (explode нашел, там чиркнуто пару строк
# git ls-files —others —exclude-from=.git/info/exclude
# Lines that start with ‘#’ are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *

Если .gitignore отсутствует, его надо создать.

прописал в gitbush:

$ git remote add orign git@github.com :EVOSandru6/git-basics.git

$ git remote -v
orign git@github.com :EVOSandru6/git-basics.git (fetch)
orign git@github.com :EVOSandru6/git-basics.git (push)

Т.е. они вроде как проинициализировались.

$ git push -u origin master

Ошибки такие вот:

fatal: ‘origin’ does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

В чем может быть дело?

URL’ы репозиториев неправильные. Между github.com и EVOSandru6 должен быть / вместо.

Добрый день!
При вводе git config —global user.name у меня выходит ошибка error: could not lock config file p://.gitconfig: Permission denied. Как можно разрешить доступ?