Github — GitHub использование


Содержание

Github — GitHub использование

/Maks/android-kernel-zzz
git init — инициализируем репозиторий
git add . — помечаем для выгрузки все файлы в

/Maks/android-kernel-zzz
git commit -m «first commit» — коммитим изменения, вместо first commit можно написать, что угодно.
git remote add origin https://github.com/твой_ник/имя_репозитория.git
git push -u origin master — после ввода команды попросит пароль.

Тема в стадии развития!

Сообщение отредактировал AndrewP_1 — 29.04.19, 12:01

Предложу альтернативу. :wink_kind:

Создаём новый пустой репозиторий с помощью командной строки:

Интеграция чужих наработок в свой репозиторий

  • git remote add name [url репозитория]
  • git fetch name
  • git cherry-pick [id коммита]

Где name это условное имя ветки (может быть каким угодно)

  • Git или Гит — система контроля и управления версиями файлов.
  • GitHub или Гитхаб — веб-сервис для размещения репозиториев и совместной разработки проектов.
  • Репозиторий Git — каталог файловой системы, в котором находятся: файлы конфигурации, файлы журналов операций, выполняемых над репозиторием, индекс расположения файлов и хранилище, содержащее сами контролируемые файлы.
  • Локальный репозиторий — репозиторий, расположенный на локальном компьютере разработчика в каталоге. Именно в нём происходит разработка и фиксация изменений, которые отправляются на удалённый репозиторий.
  • Удалённый репозиторий — репозиторий, находящийся на удалённом сервере. Это общий репозиторий, в который приходят все изменения и из которого забираются все обновления.
  • Форк (Fork) — копия репозитория. Его также можно рассматривать как внешнюю ветку для текущего репозитория. Копия вашего открытого репозитория на Гитхабе может быть сделана любым пользователем, после чего он может прислать изменения в ваш репозиторий через пулреквест.
  • Обновиться из апстрима — обновить свою локальную версию форка до последней версии основного репозитория, от которого сделан форк.
  • Обновиться из ориджина — обновить свою локальную версию репозитория до последней удалённой версии этого репозитория.
  • Клонирование (Clone) — скачивание репозитория с удалённого сервера на локальный компьютер в определённый каталог для дальнейшей работы с этим каталогом как с репозиторием.
  • Ветка (Branch) — это параллельная версия репозитория. Она включена в этот репозиторий, но не влияет на главную версию, тем самым позволяя свободно работать в параллельной. Когда вы внесли нужные изменения, то вы можете объединить их с главной версией.
  • Мастер (Master) — главная или основная ветка репозитория.
  • Коммит (Commit) — фиксация изменений или запись изменений в репозиторий. Коммит происходит на локальной машине.
  • Пул (Pull) — получение последних изменений с удалённого сервера репозитория.
  • Пуш (Push) — отправка всех неотправленных коммитов на удалённый сервер репозитория.
  • Пулреквест (Pull Request) — запрос на слияние форка репозитория с основным репозиторием. Пулреквест может быть принят или отклонён вами, как владельцем репозитория.
  • Мёрдж (Merge) — слияние изменений из какой-либо ветки репозитория с любой веткой этого же репозитория. Чаще всего слияние изменений из ветки репозитория с основной веткой репозитория.
  • Кодревью — процесс проверки кода на соответствие определённым требованиям, задачам и внешнему виду.

Введение в GitHub: как начать пользоваться?

Всем привет! Несмотря на такой долгую паузу после последней статьи о VestaCP, буду пробовать переходить на более интенсивный режим работы. С этого дня темы новых статей будут немного сменены, теперь вы увидите больше статей, связанных с вёрсткой сайтов. Я не беру на себя функцию обучить вас вёрстке, а, скорее, предоставляю вам миниконспект основ, к которому будет легко вернуться и повторить. Надеюсь, вам понравится и вы сможете эффективно использовать предложенную информацию. Хватит предисловий, приступим к работе.

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

Системы контроля версий

Древняя система контроля версий

Наверное, все когда-нибудь сохраняли 2 версии файла с небольшими отличиями под разными именами? К примеру, научка-вер1.txt и научка-вер1-проверил_Пушкин.txt. Первый файл вы отправили своему научному руководителю, он его проверил, внёс свои изменения и отравил вам второй файл. Такое может повторять вплоть до бесконечности, плодя множество файлов, названия которых ставятся все более и более странными. А ваша папка с версиями с «научкой» становится похожа на что-то дикое и сложное в понимании, и найти промежуточную версию становится очень и очень сложно.

Такой способ совершенно не приемлем* в мире разработки, особенно, если над проектом трудится много человек одновременно. И вот почему:

  • Возможны ошибки в назначении версии файла.
  • Неприменимо к множеству файлов.
  • Нет гарантий, что у вас самая последняя версия файла.
  • Невозможно работать одновременно группой разработчиков.

Современная система контроля версий

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

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

Цель такой системы — поддержание актуальной версии проекта у всех ее пользователей.

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

Виды современной системы контроля версий

Централизованная.

  1. Существует только один репозиторий.
  2. Простые номера версий файлов (1, 2, 3 и т.д.).
  3. У пользователей хранится только текущая версия проекта.
  4. Требуется подключение к интернету.
  5. Просто, но медленно.
  6. Сложности в одновременной работе над одним файлом.

Распределенная.

На один проект приходится много репозиториев.

  1. Каждый пользователь создает локальную копию всего репозитория на основе главного облачного.
  2. Номера версий сложные.
  3. Возможность работать офлайн.
  4. Работать быстро и удобно.
  5. Требуется синхронизация репозиториев, так как проект — один.

Теперь можно дать определение и слову Git.

Git — это инструмент для реализации работы распределённой системы контроля версий.

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

Как работает GitHub

Для работы с GitHub нам потребуется установить клиент контроля версий (в GitHub, это GitHub Desktop ) и создать репозиторий. Репозиторий можно создать, как через веб-сайт, так и через клиент.

Принципы работы с репозиторием GitHub

  1. С помощью клиента копируем весь репозиторий на свой компьютер (pull).
  2. Вносим различные правки, сохраняем, вносим правки и т.д. в различные файлы репозитория.
  3. Просим клиента внести изменённые файлы в репозиторий.
    Внесение измененных файлов в репозиторий называется фиксацией изменений или «коммитом» (commit).
  4. После коммита версия вашего локального репозитория изменилась.
  5. На данный момент изменения фиксированы только на локальном репозитории, чтобы они отобразились на сайте GitHub, требуется еще одна функция «синхронизация репозиториев» (push).
  6. Теперь ваш главный репозиторий, расположенный в GitHub, такой же, как на вашем компьютере.

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

Слияние, конфликт, разрешение конфликта

Для понимая нужен пример. Влад и Артем сделали копию репозитория (pull) с фалом версии 1 с GitHub, внесли разные изменения в этот файл, оба зафиксировали изменения (commit) → версии фала в локальных репозиториев изменились, у Влада версия 2, у Артем 2А. И затем Влад запушил (синхронизировал репозитории- push). Теперь на GitHub добавилась версия файла 2. Артем тоже решил запушить свои изменения, т. к. на GitHub есть версия которой нет у Артема (у него нет версии 2), система откажется принимать его репозиторий для сохранения версии 2.

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

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

Способы решения конфликта:

  1. Автоматическое слияние. Сравнивая построчно код Влада и Артема, GitHub может решить совместить куски кода в файле, при этой получится новая версия файла. При таком подходе в репозитории будут находиться версии 1, 2, 2А, и 3, а Артем теперь может запушить все отсутствующие версии файла.
  2. Разрешение конфликта вручную. Git пометит, какой код конфликтует, и вам нужно будет решить, какой вариант оставить или вообще внести третий. Создается версия 3, и Артем может запушить отсутствующие версии файла.

Master / не master, Fork, Pull request

Ветки — это своеобразные папки со всеми файлами проекта. Ветка Master — это самая главная папка вашего проекта, она всегда существует. Дополнительные ветки создаются под всякие дополнительные нужды.

Пример модели работы с ветками:

В Master лежит последняя стабильная версия, где вы можете вносить незначительные изменения; development — ветка для непосредственной разработки; dev-adaptive — ветка разработки, связанная с планируемым расширением функционала.

Что такое Fork? К примеру, на GitHub вам понравился какой-то проект, но вы заметили в нем ошибку и знаете, как ее решить, но доступа к редактированию чужого проекта у вас нет. Для этого вам нужно создать fokr. Теперь у вас есть доступ для редактирования файлов проекта. Вы справились с багом, но ваши труду пропадут даром т. к. изменения не отобразится в master ветке проекта. Чтобы такого не произошло и создан Pull request.

Pull request — это обращение к владельцам проекта с предложением внести в главную ветку ваши изменения.

На этом небольшое введение походит к концу. Не мучайтесь с допотопной системой версий, переходите на GitHub. Спасибо за внимание.

.3 Введение — Основы Git

Основы Git

Так что же такое Git в двух словах? Эту часть важно усвоить, поскольку если вы поймёте, что такое Git, и каковы принципы его работы, вам будет гораздо проще пользоваться им эффективно. Изучая Git, постарайтесь освободиться от всего, что вы знали о других СКВ, таких как Subversion или Perforce. В Git’е совсем не такие понятия об информации и работе с ней как в других системах, хотя пользовательский интерфейс очень похож. Знание этих различий защитит вас от путаницы при использовании Git’а.

Слепки вместо патчей

Главное отличие Git’а от любых других СКВ (например, Subversion и ей подобных) — это то, как Git смотрит на свои данные. В принципе, большинство других систем хранит информацию как список изменений (патчей) для файлов. Эти системы (CVS, Subversion, Perforce, Bazaar и другие) относятся к хранимым данным как к набору файлов и изменений, сделанных для каждого из этих файлов во времени, как показано на рисунке 1-4.

Рисунок 1-4. Другие системы хранят данные как изменения к базовой версии для каждого файла.

Git не хранит свои данные в таком виде. Вместо этого Git считает хранимые данные набором слепков небольшой файловой системы. Каждый раз, когда вы фиксируете текущую версию проекта, Git, по сути, сохраняет слепок того, как выглядят все файлы проекта на текущий момент. Ради эффективности, если файл не менялся, Git не сохраняет файл снова, а делает ссылку на ранее сохранённый файл. То, как Git подходит к хранению данных, похоже на рисунок 1-5.

Рисунок 1-5. Git хранит данные как слепки состояний проекта во времени.

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

Почти все операции — локальные

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

К примеру, чтобы показать историю проекта, Git’у не нужно скачивать её с сервера, он просто читает её прямо из вашего локального репозитория. Поэтому историю вы увидите практически мгновенно. Если вам нужно просмотреть изменения между текущей версией файла и версией, сделанной месяц назад, Git может взять файл месячной давности и вычислить разницу на месте, вместо того чтобы запрашивать разницу у СКВ-сервера или качать с него старую версию файла и делать локальное сравнение.

Кроме того, работа локально означает, что мало чего нельзя сделать без доступа к Сети или VPN. Если вы в самолёте или в поезде и хотите немного поработать, можно спокойно делать коммиты, а затем отправить их, как только станет доступна сеть. Если вы пришли домой, а VPN-клиент не работает, всё равно можно продолжать работать. Во многих других системах это невозможно или же крайне неудобно. Например, используя Perforce, вы мало что можете сделать без соединения с сервером. Работая с Subversion и CVS, вы можете редактировать файлы, но сохранить изменения в вашу базу данных нельзя (потому что она отключена от репозитория). Вроде ничего серьёзного, но потом вы удивитесь, насколько это меняет дело.

Git следит за целостностью данных

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

Механизм, используемый Git’ом для вычисления контрольных сумм, называется SHA-1 хешем. Это строка из 40 шестнадцатеричных символов (0-9 и a-f), вычисляемая в Git’е на основе содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так:

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

Чаще всего данные в Git только добавляются

Практически все действия, которые вы совершаете в Git’е, только добавляют данные в базу. Очень сложно заставить систему удалить данные или сделать что-то неотменяемое. Можно, как и в любой другой СКВ, потерять данные, которые вы ещё не сохранили, но как только они зафиксированы, их очень сложно потерять, особенно если вы регулярно отправляете изменения в другой репозиторий.

Поэтому пользоваться Git’ом — удовольствие, потому что можно экспериментировать, не боясь что-то серьёзно поломать. Чтобы узнать подробнее о том, как Git хранит свои данные и как восстановить то, что кажется уже потерянным, читайте главу 9.

Три состояния

Теперь внимание. Это самое важное, что нужно помнить про Git, если вы хотите, чтобы дальше изучение шло гладко. В Git’е файлы могут находиться в одном из трёх состояний: зафиксированном, изменённом и подготовленном. «Зафиксированный» значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит.

Таким образом, в проектах, использующих Git, есть три части: каталог Git’а (Git directory), рабочий каталог (working directory) и область подготовленных файлов (staging area).

Рисунок 1-6. Рабочий каталог, область подготовленных файлов, каталог Git’а.

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

Рабочий каталог — это извлечённая из базы копия определённой версии проекта. Эти файлы достаются из сжатой базы данных в каталоге Git’а и помещаются на диск для того, чтобы вы их просматривали и редактировали.

Область подготовленных файлов — это обычный файл, обычно хранящийся в каталоге Git’а, который содержит информацию о том, что должно войти в следующий коммит. Иногда его называют индексом (index), но в последнее время становится стандартом называть его областью подготовленных файлов (staging area).

Стандартный рабочий процесс с использованием Git’а выглядит примерно так:

  1. Вы вносите изменения в файлы в своём рабочем каталоге.
  2. Подготавливаете файлы, добавляя их слепки в область подготовленных файлов.
  3. Делаете коммит, который берёт подготовленные файлы из индекса и помещает их в каталог Git’а на постоянное хранение.


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

Как пользоваться GitHub на компьютере с Linux

GitHub — один из используемых сервисов размещения проектов для совместной разработки. Он поддерживает контроль версий, возможность отслеживания изменений кода, сравнение строк, а также он бесплатен.

В данной статье приведены примеры использования сервиса на компьютере под управлением операционных систем семейства Linux. Мы рассмотрим, как создать проект на локальном компьютере и залить его на сервис с помощью командной строки. Рассмотренные варианты использования git также можно применять на desktop системах, запустив окно терминала.

Цукерберг рекомендует:  Автоматическое резервное копирование базы данных

Установка git

Управление выполняется с помощью приложения git. Если его нет в системе, установку можно выполнить из репозитория.

Если используем CentOS / Red Hat:

yum install git-core

Если используем Ubuntu / Debian:

apt-get install git

Если мы хотим воспользоваться сервисом с компьютера Windows или Mac OS, необходимо скачать и установить desktop версию с официального сайта.

Синтаксис

Команды имеют следующий синтаксис:

* полный перечень опций, команд и аргументов можно получить командой man git.

Создание проекта на локальном компьютере

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

Инициализируем проект для git:

Мы получим ответ похожий на:

Initialized empty Git repository in /projects/.git/

Это означает, что репозиторий git создан.

Теперь добавим файлы в репозиторий:

* данной командой мы добавили папку и ее содержимое в репозиторий git.

Отправка данных на GitHub

Теперь можно отправить данные на сервис. Для этого у нас должна быть зарегистрированная учетная запись и создан репозиторий на GitHub.

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

Переходим на портал github.com и входим в систему или проходим несложную регистрацию:

Проходим процесс подтверждения, что мы не робот. Затем завершаем несколько шагов регистрации, нажимая Submit. В итоге мы получим письмо на адрес электронной почты, которую указали при регистрации. Необходимо будем подтвердить email, перейдя в письме по кнопке Verify email address.

Создаем репозиторий. Для этого кликаем по иконке профиля и переходим в раздел Your repositories:

И кликаем по кнопке New. В следующем окне даем название репозиторию и нажимаем Create repository:

Мы увидим страницу с путем к репозиторию:

Заливаем проект в репозиторий на GitHub

Добавляем комментарий к нашему проекту:

git commit -m «Очередное изменение проекта» -a

* где Очередное изменение проекта — произвольный комментарий; параметр -a указывает, что комментарий нужно применить ко всем измененным файлам.

Теперь подключаемся к созданному репозиторию:

git remote add origin https://github.com/dmosktest/project1.git

* где dmosktest — логин, который был указан при регистрации на github, а project1 — название, которое мы задали, когда создавали репозиторий.
* удалить удаленный репозиторий можно командой git remote rm origin.

Закидываем проект на GitHub:

git push origin master

* где master — ветка проекта (веток может быть несколько).

В нашем проекте на GitHub должны появиться файлы проекта:

Получение файлов с GitHub

Для загрузки на компьютер файлов, создаем каталог с проектом и переходим в него:

Проводим начальную настройку локального репозитория:

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

git remote add origin https://github.com/dmosktest/project1.git

Скачиваем проект командой:

git pull https://github.com/dmosktest/project1.git master

Клонирование проекта

Например, использую наш репозиторий:

git clone https://github.com/dmosktest/project1.git

* данная команда создаст в текущей папке каталог project1 и инициализирует его как локальный репозиторий git. Также загрузит файлы проекта.

Возможные ошибки

1. При попытке отправить данные на GitHub, получаем ошибку:

error: src refspec master does not match any.
error: failed to push some refs to ‘https://github.com/dmosktest/project1.git’

* где dmosktest/project1.git — путь к нашему репозиторию.

Причина: проект ни разу не был зафиксирован (закоммичен).

Решение: добавляем комментарий к нашему проекту:

Использование git дома и на работе

Я новичок по git. Использую gitHub -как промежуточное звено, работаю в одной ветви (master). Периодически сталкиваюсь с проблемами, вроде конфликтов или вставок в рабочие файлы записей — >>>>>>

Я создал репозиторий, затем склонировал будучи на работе уже с gitHub, стал менять код, выполнять стандартные команды, затем снова «пушить», чтобы продолжить дома, но результат на лицо. В чем моя ошибка? Как правильно организовать последовательность выполнения команд или может быть что-то ещё?

1 ответ 1

Перед тем как что-то изменять в локальном репозитории на домашнем компьютере, вам над синхронизировать (обновить) свой локальный репозиторий.

Команда git fetch [remote-name] сходит в удаленный репозиторий remote-name и заберет для вас, все чего у вас нет. Т.е. теперь ваш локальный репозиторий полностью соответствует удаленному и конфликтов быть не должно.

После этого можете менять коммитить и пушить, но на работе надо так же сделать git fetch [remote-name] , чтобы изменения удаленного репозитория, сделанные дома, перенеслись на репозиторий на работе.

  1. git fetch [remote-name]
  2. Меняем что хотели
  3. git commit .
  4. git push

Совместная разработка в команде на GitHub

GitHub стал краеугольным камнем для всего программного обеспечения с открытым исходным кодом. Разработчики любят его, сотрудничают с ним и постоянно создают новые великолепные проекты с помощью него. Помимо хостинга вашего кода, главная привлекательность GitHub заключается в использовании его в качестве инструмента совместной работы. В этом уроке давайте рассмотрим некоторые из наиболее полезных функций GitHub, особенно полезных для работы в командах, что делает его еще более эффективным, продуктивным и, самое главное, забавным!

Github разработка в команде

Одна вещь, которую я считаю очень полезной, — это интеграция Github Wiki в основной проект исходного кода.

В этом руководстве предполагается, что вы уже знакомы с Git, распределенной системой управления версиями с открытым исходным кодом, созданной Линусом Торвальдсом в 2005 году. Если вам нужна ревизия или поиск в Git, посетите наш предыдущий курс скринкастов или даже несколько статей на эту тему. Кроме того, у вас уже должна быть учетная запись Github, а также некоторые базовые функции, такие как создание репозитория и внесение изменений в Github. Если нет, обратитесь к предыдущим учебникам.

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

  1. Добавление членов команды — организация и соавторы
  2. Pull Requests — Отправка и слияние
  3. Отслеживание ошибок — issues Github
  4. Аналитика — Графики и сети
  5. Управление проектами — Trello & Pivotal Tracker
  6. Непрерывная интеграция — Travis CI
  7. Ревью кода — комментарии к строкам и URL-запросы
  8. Документация — Wiki & Hubot

Предпочитаете скринкаст?

Если вы предпочитаете скринкаст, то прыгайте чуть ниже, чтобы просмотреть его, а этот учебник используйте в качестве сопутствующих заметок:

Инструмент 1 : Добавление членов команды

Как правило, существует два способа настройки Github для совместной работы:

  1. Организации. Владелец организации может создавать множество команд с разными уровнями доступа для различных репозиториев
  2. Сотрудники. Владелец репозитория может добавлять коллабораторов с доступом Read + Write для одного репозитория

Organizations

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

Чтобы получить доступ к странице команд для вашей Организации, вы можете просто перейти на http://github.com/organizations/[organization-name]/teams , чтобы просмотреть их или даже посетить https://github.com/organizations/[organization-name]/teams/new Для создания новых команд с тремя уровнями доступа, такими как:

  1. Pull Only: выборка и слияние с другим репозиторием или локальной копией. Доступ только для чтения.
  2. Push and Pull: (1) наряду с обновлением удаленного репозитория. Читайте + Запись.
  3. Push, Pull & Administrative: (1), (2) наряду с правами на информацию о выставлении счетов, созданием команд, а также удаление аккаунтов организации. Чтение + запись + доступ администратора

Соавторы

Коллабораторы (соавторы) используются для предоставления возможности «читать + писать» в один репозиторий, принадлежащий личной учетной записи. Чтобы добавить Collaborators (другие личные учетные записи Github), перейдите на страницу https://github.com/[username]/[repo-name]/settings/collaboration :

После этого каждый соавтор увидит изменение статуса доступа на странице репозитория. После того, как у нас есть доступ на запись к репозиторию, мы можем сделать git clone , поработать над изменениями, сделать git pull для извлечения и слияния любых изменений в удаленном репозитории и, в конечном счете, git push , для обновления удаленного репозитория с собственными изменениями:

Инструмент 2: Pull Requests

Pull Requests — отличный способ внести свой вклад в репозиторий, сделав его форк. В конце дня, если мы хотим, мы можем отправить pull request владельцу репозитория, чтобы объединить наши изменения кода. Сам pull request может включать обсуждение качества кода, функций или даже общей стратегии.

Давайте теперь рассмотрим основные шаги для pull request.

Инициирование pull request

В Github есть две модели для pull request:

  1. Модель Fork & Pull — используется в общедоступном репозитории, на который у вас нет push-доступа
  2. Share Repository Model — используется в частном репозитории, на который у нас есть push-доступ. В этом случае форк не требуется.

Здесь мы видим рабочий процесс между двумя пользователями ( repo-owner и forked-repo-owner ) для модели Fork and Pull:

    Определите репозиторий Github, в который вы хотите внести свой вклад, и нажмите кнопку «Fork», чтобы создать клон репозитория в вашей собственной учетной записи Github:

Слияние пул реквеста

Если вы являетесь владельцем оригинального репозитория, существует два способа слияния входящего пул реквеста:


    Слияние непосредственно на Github: если мы делаем слияние непосредственно на Github, то убедитесь, что нет конфликтов, и реквест готов к объединению в ведущую ветку. Владелец оригинального хранилища может просто щелкнуть зеленую кнопку «Слить запрос», чтобы сделать это:

Существуют различные модели создания веток, используемые для управления версиями в командах разработки программного обеспечения. Вот две популярные модели рабочего процесса git: (1) рабочий процесс Github, который имеет простую ветвящуюся модель и использует запросы на pull, и (2) Gitflow, который имеет более обширное разветвление. Модель, которая в конечном итоге будет выбрана, определенно будет меняться в зависимости от команды, проекта и ситуации.

Инструмент 3: Отслеживание ошибок

Pull Requests — отличный способ внести свой вклад в репозиторий сделав его форк.

В Github центр для отслеживания ошибок — это issues. Несмотря на то, что они в основном предназначены для отслеживания ошибок, также полезно использовать «Issues» следующими способами:

  • Ошибки: вещи, которые явно сломаны и нуждаются в исправлениях
  • Особенности: Удивительные крутые новые идеи для реализации
  • Список дел: контрольный список задач для завершения

Давайте рассмотрим некоторые особенности проблем:

  1. Labels: цветные категории для каждого issue. Они полезны для фильтрации.
  2. Milestones: они относятся к категориям, которые могут быть связаны с каждым issue, и полезны для определения того, какие проблемы необходимо обрабатывать для следующего релиза. Кроме того, поскольку этапы связаны с проблемами, то автоматически обновляется индикатор выполнения при закрытии каждой связанной проблемы.
  3. Search: Автокомплит поиска для issues и milestones

Инструмент 4: Аналитика

Понятно, что мы можем тесно связать наш список задач и обновления с нашими кодами.

Есть два инструмента, которые дают представление о репозитории — Graphs and Network. Графики Github отображает соавторов и их коммиты, в то время как Github Network обеспечивает визуализацию для каждого участника. Эти аналитики и графики становятся очень мощными, особенно при работе в командах.

Графики

Графики предоставляют подробную аналитику, такую как:

  • Contributors: кто был соавтором? И сколько строк кода они добавляли или удаляли?
  • Commit Activity: В какие недели произошли фиксации в прошлом году?
  • Code Frequency: сколько строк кода было зафиксировано на протяжении всего жизненного цикла проекта?
  • Punchcard: В какое время дня обычно совершаются коммиты?

Network

Github Network — это мощный инструмент, который позволяет вам видеть, как коммитит каждый участник и как они связаны друг с другом. Когда мы смотрим на визуализатор целиком, мы видим каждую фиксацию в каждой ветви каждого репозитория, принадлежащего сети. Очень круто!

Инструмент 5: Управление проектами

В то время как issues Github имеют возможности управления проектами с помощью Issues и Milestones, некоторые команды могут предпочесть другой инструмент из-за других функций или существующего рабочего процесса. В этом разделе мы увидим, как мы можем связать Github с двумя другими популярными инструментами управления проектами — Trello и Pivotal Tracker. С помощью сервисов Github мы можем автоматизировать задачу обновления с помощью коммитов, проблем и многих других действий. Эта автоматизация помогает не только экономить время, но и повышает точность обновлений для любой команды разработчиков программного обеспечения.

Github и Trello

Trello обеспечивает простой, визуальный способ управления задачами. Используя Agile Software Development, карточки Trello могут эмулировать простую виртуальную Kanban Board. В качестве примера мы автоматически создадим карточку Trello всякий раз, когда будет появляться новый пул реквест с помощью Github Service Hooks. Давайте пройдем через все шаги!

    Откройте свой аккаунт в Trello, если у вас его еще нет, и создайте новую доску Trello.

Github и Pivotal Tracker

Pivotal Tracker — еще один легкий гибкий инструмент управления проектами, в котором планирование на основе истории позволяет команде легко взаимодействовать, мгновенно реагируя на различные изменения и прогресс проекта. Основываясь на текущем прогрессе команды, он также может создавать диаграммы для анализа скорости команды, итераций разработки, релизов и прочего. В этом кратком примере мы автоматически доставим историю, связав ее с коммитом на Github!

    Создайте новый проект в Pivotal Tracker с новой Story которая должна быть сделана.

С примерами Trello и Pivotal Tracker ясно, что мы можем тесно связать наш список задач и обновления с нашими коммитами. Это огромная экономия времени при работе в команде, и это повышает точность при связывании задач с точными фиксациями. Хорошей новостью является то, что если вы уже используете другие инструменты управления проектами, такие как Asana, Basecamp и другие, вы также можете создать Service Hooks аналогичным образом. Если для вашего текущего инструмента управления проектами нет существующих сервисных хуков, вы даже можете их создать сами!

Инструмент 6: Непрерывная интеграция

Непрерывная интеграция (CI) является важной частью всех проектов разработки программного обеспечения, с которыми работают команды разработчиков. CI гарантирует, что, когда разработчик выкатывает свой код, автоматическая сборка (включая тесты) быстро обнаруживает ошибки интеграции. Это определенно уменьшает ошибки интеграции и делает быструю итерацию намного более эффективной. В этом примере мы увидим, как можно использовать Travis CI вместе с Github для CI для обнаружения ошибок, а также для рекомендаций слияния, когда проходят все тесты.

Настройка Travis CI

Мы будем использовать простой проект «hello world» для node.js вместе с grunt.js в качестве инструмента сборки для настройки Travis CI проекта. Вот файлы, находящиеся в проекте:

  1. Файл hello.js — это проект nodejs. Здесь мы намеренно не будем оставлять точку с запятой, чтобы грант не смог собрать билд:
  2. package.json определяет зависимости:
  3. Инструмент сборки gruntjs имеет для простоты только одну задачу (линтинг) :
  4. .travis.yml — это файл конфигурации Travis, который заставит Travis запускать наши тесты:
  5. Затем войдите в Travis со своей учетной записью Github и включите привязку репозитория под вкладкой репозитория.

Travis CI и пул реквесты

Раньше, без какого-либо CI в процессе пул реквеста, этапы выполнялись примерно так: 1) создание запроса (2) слияние (3), тестируем все ли работает. Когда Travis CI подключится к пул реквесам, мы сможем инвертировать шаги 2 и 3, что еще больше ускорит принятие решений о том, следует ли сливать изменения, так как Travis даст нам статус билда для каждого пул реквеста. Давайте посмотрим, как это сделать.

    Отправьте пул реквест с успешным билдом, и Travis сделает свою магию, чтобы вы знали, что слияние будет успешным еще даже до самого слияния

Travis CI с Github чрезвычайно полезен для команд из-за автоматических сборок и немедленного уведомления. Это, безусловно, делает цикл исправления ошибок намного короче. Если вы используете Jenkins, еще один популярный инструмент CI, то вы тоже можете настроить сервисные хуки Github.

Инструмент 7: Обзор кода

С каждой фиксацией изменений Github позволяет использовать чистый интерфейс для общих комментариев или даже конкретных комментариев к отдельной строчке кода. Возможность делать комментарии или задавать вопросы по каждой отдельной строке кода очень полезна при проведении обзоров строка за строкой. Чтобы просмотреть встроенные комментарии, установите флажок в верхней части каждой фиксации.

Давайте рассмотрим некоторые шаблоны URL-адресов, которые могут быть использованы, чтобы помочь нам в обзоре кода, быстро предоставив нам различия между фиксациями:

    Compare branches / tags / SHA1: используйте шаблон URL https://github.com/[username]/[repo-name]/compare/[starting-SHA1]. [ending-SHA1] . Вы можете сделать то же самое с веткой или тегами.

Инструмент 8 : документация

В этом разделе мы рассмотрим два метода создания документации:

  1. Формальная документация: Github Wiki для создания документации для исходного кода
  2. Неофициальная документация: Github Hubot документирует обсуждения между членами команды и автоматизирует поиск информации, взаимодействуя с бот-чатом!
  3. Упоминания, ярлыки и эмози

Github Wiki

В каждом репозитории может быть создана Github Wiki, и это может оказаться очень удобно иметь в одном репозитории как исходный код, так и документацию для него. Чтобы создать Wiki, просто перейдите на вкладку Wiki в главном заголовке, и вы готовы к созданию страниц с информацией. Сама Wiki имеет собственное управление версиями, и данные могут быть клонированы на наш локальный компьютер для обновлений или даже автономного доступа.

Одна вещь, которую я нахожу очень полезной, — это интеграция Github Wiki в основной проект исходного кода, так что мне не нужно поддерживать два отдельных проекта git. Для этого я добавляю Wiki git repo как субмодуль из ветки master. Если вы используете Travis CI или любой другой CI, убедитесь, что инструмент сборки игнорирует подмодуль wiki. Для файла Travis CI .travis.yml добавьте следующее:

Затем добавьте wiki-подмодуль git в основной репозиторий кода:

Теперь Wiki будет выглядеть как подмодуль в основном проекте с исходным кодом.

Github Hubot

Если коротко, Hubot может сделать процесс ведения документации гораздо приятнее, добавляя уведомление командных обсуждений о важных коммитах.

Hubot — это просто бот-чат, который может получать информацию или предоставлять уведомление при подключении к Github коммитам, issues или активности. В команде, которая стремится значительно сократить количество встреч или даже полностью устранить их, Hubot с интерфейсом чата среди членов команды помогает документировать каждую отдельную дискуссию. Это, безусловно, способствует гибкому графику работы, так как никто не должен присутствовать одновременно для обсуждения. Предупреждение: Hubot ужасно вызывает привыкание!

Итак давайте начнем с настройки Hubot, размещенным на Heroku, и ботом с интерфейсом чата Campfire! Для обоих и Heroku и Campfire есть бесплатные версии, с которым можно начать.

  1. Мы воспользуемся версией Hubot от Github’s Campfire. Если вы хотите, вы можете выбрать адаптеры для других чатов, таких как Skype, IRC, Gtalk и т.д.
  2. Откройте новую учетную запись Campfire только для Hubot, и эта учетная запись создаст новую комнату для чата, в которую все остальные будут приглашены позже.
  3. Разверните Hubot на Heroku с помощью этой инструкции, приведенной на Hubot Wiki. Не волнуйтесь, если URL-адрес приложения heroku дает сообщение Can not GET / , поскольку по умолчанию еще нечего делать.
  4. С учетной записью Hubot Campfire пригласите себя. Теперь войдите в свою учетную запись Campfire и выполните команду Hubot help . Эта команда предоставит вам все доступные команды для hubot.

Ознакомьтесь с другими скриптами Hubot, связанными с Github, или если вы хотите написать один, есть крутой учебник по этому поводу! Короче говоря, Hubot может значительно добавить веселья в документировании и уведомлении командных дискуссий о важных коммитах, проблемах и действиях, происходящих с нашими репозиториями на Github. Попробуйте его!

В качестве заключительной заметки о командной работе на Github, вот несколько советов по производительности:

  1. Упоминания. В любой текстовой области мы можем указать другого пользователя github с @user , и пользователь получит уведомление о комментарии
  2. Клавиши быстрого доступа — нажмите [shift] +? Для доступа к клавишам быстрого доступа Github на любой странице.
  3. Emoji — Используйте список Emoji, Github textareas также поддерживает вставку этих значков. Попробуйте их и повеселитесь со своими товарищами по команде!

Использование Github не для разработки

Большинство думает использовать Github только для программных проектов. В конце концов, Github был создан специально для создания кода. Но есть некоторые классные репозитории Github, которые используются для проектов, не связанных с кодом, и они были одинаково великолепны для сотрудничества и обсуждения. Поскольку эти проекты также доступны с открытым исходным кодом, и каждый может внести свой вклад, быстро исправлять ошибки, легко сообщать об ошибках и эффективно сотрудничать с единомышленниками. Просто ради интереса, вот некоторые из них:

  • Исправления для дома: отслеживание проблем в качестве инструмента мониторинга
  • Книги:Маленькая книга по MongoDB, Основы Backbone
  • Тексты песен: JSConfEU Тексты песен
  • Найти друга:boyfriend_require
  • Наставничество:Wiki
  • Геномические данные: эпидемия Ash Dieback
  • Блоги:CSS Wizardry

И интересно, что думает об этом команда Github?

«Мы кайфуем от использования GitHub»

Дополнительные ресурсы

  • Социальная разработка на GitHub, исследовательская работа Университета Карнеги-Меллона
  • Как Github использует Github для создания Github Зак Холман
  • Секреты Git и Github Зак Холман
  • Новые возможности в Github из блога Github
  • Github Help: пул реквесты, форки репозитория
  • Возможности Github для совместной работы
  • Учебники Nettuts +: Git и Github
  • Повелитель файлов: как Github приручил бесплатное программное обеспечение (и многое другое) Wired

Получайте больше удовольствия от совместной работы!

Таким образом, это был набор инструментов для совместной работы в Github. Большинство из них служат быстрыми аналитическими инструментами или даже автоматизацией, что помогает сэкономить время при работе с двумя или несколькими товарищами по команде. У вас есть больше советов Github для команд? Давайте поделимся ниже!

Что такое GitLab? Настройка и использование GitLab

Мы с вами уже говорили про Git и GitHub. В этой статье расскажем о том, что такое GitLab, как им пользоваться, какая настройка потребуется.

GitLab — это онлайн-сервис, предназначенный для работы с git-репозиториями. Его можно использовать непосредственно на официальном сайте (gitlab.com), зарегистрировав аккаунт, или установить и развернуть на своём сервере.

Возможности GitLab

GitLab — это отличный инструмент для разработчиков, который предоставляет следующие возможности: — управление публичными и приватными git-репозиториями; — управление пользователями и группами, правами доступа к git-репозиториям; — отслеживание ошибок, деплой, анализ кода; — интеграция с разными CI-системами CI (Jenkins и т. п.), организация самостоятельного процесса CI посредством встроенных средств.

Есть и другие возможности (функционал api, wiki страниц, доски задач и идей, отслеживание изменений, комментарии к проектам и прочие). Подробнее можно узнать из официальной документации.

GitLab и GitHub

Как известно, главный конкурент GitLab — это сервис GitHub. Появился он на три года раньше (в 2008), поэтому более популярен. Да что там говорить, GitHub сегодня — это сайт номер один по размещению open source-проектов. Они почти все на нём и размещаются.))) И у многих людей Git напрямую ассоциируется с сервисом GitHub.

Да, плюсов у GitHub много, но мы не будем сейчас сравнивать оба сервиса. Скажем только, что несмотря на повышенную популярность и огромнейшее комьюнити GitHub (26 млн. человек), наблюдается тенденция перехода крупных команд разработчиков на GitLab. Это происходит благодаря расширенным возможностям второго.

Как использовать GitLab? Настройка сервиса

1. Создание аккаунта

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

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

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

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

Для добавления проекта GitLab потребуется кликнуть по значку + , который находится в центре верхней панели. Далее нужно выбрать New Project:

Теперь вводим имя и описание репозитория, выбираем уровень доступа. Их существует три: — Private. Доступен только для вас; — Internal. К репозиторию смогут получить доступ все зарегистрированные пользователи; — Public. Свободный доступ для всех.

Также можно инициализировать репозиторий файлом README, поставив соответствующую галочку. Однако, если планируете залить файлы из уже существующего Git-репозитория, то не стоит этого делать.

Чтобы попасть на страницу репозитория, нажмите кнопку «Create repo». GitLab предложит первоначальный набор действий с целью проинициализировать ваш репозиторий. В итоге вы сможете создать файлы здесь либо загрузить их из своего ПК.

3. Загрузка файлов проекта

Теперь перейдём к созданию нового локального репозитория на ПК и загрузим содержимое на GitLab. Сначала создадим папку репозитория, назвав её, к примеру, test-repo. Теперь проинициализириуем в ней новый репозиторий, используя команду git:

Теперь создаём файл test.txt:

И фиксируем изменения:

Сейчас давайте добавим наш удалённый репозиторий с GitLab к нашему локальному, выполнив следующую команду:


Потом отправим изменения в удалённый репозиторий:

Чтобы отправить данные, введём пароль и логин на GitLab. После обновления страницы на GitLab, увидим наш файл:

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

4. SSH-ключи

При загрузке данных на GitLab требовалось ввести пароль и логин на сервере. Но есть и другой путь — SSH-ключи для авторизации. Для создания ключа выполните:

Потом вводим путь к файлу сохранения ключ и оставляем пароль пустым. В результате создаются 2 файла — закрытый ключ и открытый с расширением .pub. Нас интересует открытый, поэтому мы открываем его в текстовом редакторе и копируем содержимое в буфер обмена:

Потом возвращаемся GitLab-интерфейсу, кликаем по иконке профиля и выбираем настройки Settings:

Потом ищем на левой панели пункт SSH Keys. Далее находим Key и вставляем в соответствующее поле скопированный ключ. Всё, осталось лишь сохранить изменения.

Теперь возвращаемся в репозиторий, находим кнопку Clone (правый верхний угол) и кликаем по ней. Интересует адрес Clone with SSH:

Возвращаемся в локальный репозиторий, удаляем https, добавляем ssh:

На этом настройка ssh в GitLab закончена. С этого момента все действия выполняются по SSH, поэтому вводить логин и пароль не потребуется.

5. Ветки репозитория

Давайте посмотрим, как использовать GitLab при работе с ветками. По умолчанию репозиторий имеет лишь master-ветку. Однако разработку можно выносить и в отдельные ветки, что позволит реализовать дополнительные функции.

Ветки в GitLab-интерфейсе отображаются слева:

Для создания новой, кликаем по значку + и выбираем New branch. Также, если вы создадите ветку в git, а потом зальёте в репозиторий изменения, ветка появится там автоматически.

Если ветку по умолчанию нужно изменить, открываем настройки репозитория (Settings -> Repository), где выбираем нужную ветку в разделе Default branch:

5. Слияние веток

Иногда возникает необходимость выполнить слияние веток. Для этого используют Merge request gitlab — запросы слияния. Продемонстрируем это на ветке new-feature, где создадим файл new-feature с текстом:

Если мы после этого перейдём в новую ветвь с помощью интерфейса GitLab, мы увидим появившуюся кнопку Create merge request. Естественно, нажимаем:

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

Теперь запрос на слияние следует одобрить. Посмотреть изменения можно через терминал или, нажав кнопку Open IDE. Чтобы слить ветки, осталось нажать кнопку Merge.

7. Добавление пользователей

В GitLab можно работать с командой, добавляя неограниченное число разработчиков.

Настройка проста: — открываем Settings ->Members; — в поле Select members to invite вводим никнеймы либо адреса электронной почты тех, кого приглашаем; — в поле Choose a role permission выбираем уровень их доступа; — нажимаем Add to project.

8. Удаление проекта

Настройки для удаления проекта с Gitlab: — открываем Settings -> General -> Advanced; — выбираем и нажимаем Remove Project внизу страницы; — вводим имя проекта, который нужно удалить.

Послесловие

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

Как пользоваться GIT – разбираемся за 30 минут

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

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

Основы основ работы с GIT

GIT — это определённый набор утилит командной строки, отслеживающих и записывающих изменения в файлах. При помощи его, возможно, восстанавливать предыдущие версии ваших программ, сравнивать, анализировать, совмещать изменения и многое другое. Такой процесс принято называть контроль версий. На сегодняшний день есть много систем контроля версий, выполняющих такую же работу. Вы могли уже слышать ранее о некоторых из них – SVN, Mercurial, Perforce, CVS, Bitkeeper.

GIT децентрализован, что означает его независимость от центрального сервера для сохранения старых версий ваших файлов. Он работает полностью локально, сохраняя данные в виде папки на вашем жестком диске, которая называется репозиторием. Но вы можете хранить копию репозитория так же и в «облаке» для взаимодействия между несколькими людьми, работающих над одним кодом. Как раз для таких целей используют GitHub и BitBucket .

1. Установка GIT

Установить GIT на ваш компьютер несложно:

  • Linux – просто откройте терминал и установите GIT через менеджер пакетов вашего дистрибутива. Команда для Ubuntu: sudo apt-get install git ;
  • Windows – можно воспользоваться установщиком на официально сайте или более лучший вариант GIT для Windows , так как он включает и графический клиент (GUI client), и эмулятор командной строки BASH;
  • OS X – легче всего воспользоваться homebrew и ввести команду brew install git в вашем терминале.

Если же вам не хотеться возиться с консолью или терминалом, то можно установить себе графический клиент GIT. Вот два наиболее популярных Sourcetree и GitHub Desktop , если поискать, то можно найти и другие не менее хорошие, чем эти. Но не стоит забывать, что умение работать с GIT-командами является хорошей практикой и в некоторых случаях это гораздо удобней, потому в оставшейся части урока мы с фокусируемся именно на этом.

2. Первоначальная настройка GIT

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

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

3. Создание нового репозитория – git init

Как упоминалось ранее, GIT хранит свои файлы и историю непосредственно как папка в вашем проекте. Чтобы создать новый репозиторий, откройте терминал, укажите адрес директории проекта и введите команду git init . Тем самым вы позволите GIT создать скрытый директорий .git для этой конкретной папки, в котором будут храниться история и конфигурация.

Для примера создайте папку на рабочем столе под названием git_exersice, откройте терминал и введите следующее:

Командная строка должна ответить подобным образом:

Это означает, что репозиторий успешно создан, но всё ещё пуст. А теперь создайте простой текстовый файл hello.txt и сохраните в папку git_exersice.

4. Проверка статуса – git status

GIT статус это ещё одна необходимая для изучения команда, которая возвращает информацию о текущем состоянии репозитория: всё ли сохранилось, что сохранилось нового, что поменялось и так далее. На команду git status в нашем новом репозитории должен прийти такой ответ:

Полученное сообщение показывает, что файл hello.txt не отслеживается. Это означает, что файл новый, и GIT ещё не знает, должен ли отслеживать вносимые в него изменения или же игнорировать. Для подтверждения файла следует его добавить в индекс.

5. Индексирование – git add

У GIT есть понятие «области индексирования». Его можно представить себе, как пустой холст для хранения изменений, которые вы хотели бы зафиксировать. Изначально область появляется пустой, но вы можете добавлять к ней файлы (или даже отдельные строки и части файлов) с помощью команды git add и, наконец, всё сохранить (создать своеобразный «скриншот») с помощью git commit .

В нашем случае у нас есть только один файл, поэтому его и добавим:

Если нам нужно добавить всё из каталога, мы можем воспользоваться командой:

Вновь проверив статус, мы должны получить уже другой ответ:

Файл готов для сохранения (создания коммита)! Это сообщение о статусе также говорит нам, что было изменено в отношении файлов в области индексирования, в данном случае о появлении нового файла (new file), но файл может показываться как modified или deleted, в зависимости от действий с ним с момента прошлой команды git add .

6. Сохранение изменений – git commit

Зафиксированные изменения показывают состояние репозитория в определённый момент времени. Как скриншот, с помощью которого мы просматриваем состояние вещей в прошлом.

Для создания новой сохранённой версии файлов нам нужно добавить как минимум одно изменение в область индексирования (мы только что это сделали с git add ) и ввести следующую команду:

Эта команда создаст новый «скриншот» со всеми сделанными изменениями (включая hello.txt). Часть -m «Initial commmit» – это краткий комментарий, написанный пользователем, к данной версии файлов. Хорошая привычка – регулярно фиксировать и всегда писать внятный комментарий.

Удалённые репозитории и GIT

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

1. Подключение к удалённому репозиторию – git remote add

Для того чтобы загрузить что-то в удалённый репозиторий, для начала нам нужно установить соединение с ним. Для этого урока наш адрес репозитория будет https://github.com/tutorialzine/awesome-project. Конечно лучше самому создать собственный пустой репозиторий на GitHub , BitBucket или другом сервисе. Регистрация и установка могут занять время, но все сервисы предлагают пошаговые инструкции в помощь вам.

Для соединения нашего локального репозитория с удалённым на GitHub, мы должны в терминале вести следующую строку:

Один проект может иметь несколько удалённых репозиториев одновременно. Для их разделения нужно дать им разные имена. Традиционно основной удалённый GIT-репозиторий называют origin.

2. Загрузка на сервер – git push

Настало время для перемещения наших локальных GIT-записей на сервер. Этот процесс называется push, и он выполняется каждый раз, когда мы хотим обновить удалённый репозиторий.

Команда GIT для push, git push , имеет два параметра – имя удалённого репозитория (мы назвали наш origin) и ветка для отправки (ветка по умолчанию для каждого удалённого репозитория – master).

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

3. Клонирование репозитория – git clone

После клонирования другие люди смогут увидеть и изучить ваш удалённый репозиторий на GitHub. Также будет возможно загрузить его локально и иметь полную рабочую копию вашего проекта с командой git clone :

Новый локальный репозиторий создаётся автоматически, с GitHub-версией, настроенной как удалённый репозиторий.

4. Получение изменений с сервера – git pull

Если вы обновите свой репозиторий, другие смогут загрузить внесённые изменения с командой pull.

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

Ветви в GIT

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

  • Исправная, стабильная версия кода не будет повреждена;
  • Люди могут безопасно разрабатывать собственные версии отдельно друг от друга;
  • Разработчики могут работать на своей ветви без опасения, что кто-то изменит их код;
  • Когда разработчики не уверены, как сделать лучше, они могут работать над своими версиями в отдельных ветвях, а затем сравнить результаты между собой.

1. Создание новых ветвей – git branch

Ветвь по умолчанию для каждого репозитория называется master. Для создания другой используйте команду git branch .

Тем самым вы создаёте новую ветвь, на данном этапе одинаковую с master.

2. Смена ветвей – git checkout

Теперь, когда мы выполнили команду git branch , мы получили доступ к двум опциям:

Master – текущая ветвь и помечена звёздочкой. Однако мы хотим работать над новыми замечательными версиями программы, поэтому нам нужно переключиться на другую ветвь. Это делается командой git checkout с указанием одного параметра – ветвь для переключения.

3. Объединение ветвей – git merge

Наша «новая версия» будет просто другим текстовым файлом под названием feature.txt. Мы создадим его, добавим и зафиксируем.

Далее мы вернемся в ветвь master.

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

Ветвь master обновлена, а ветвь awesome_new_feature branch больше не нужна и мы можем её удалить.

Продвинутый уровень GIT, ещё больше полезных команд

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

1. Просмотр отличий между сохранёнными версиями

Каждая зафиксированная версия программы имеет уникальный идентификационный номер в формате строки из чисел и символов. Для просмотра списка коммитов (сохранённых версий) с их идефикаторами мы можем использовать команду git log :

Как видите, >git show [commit] :

Просмотреть отличия двух любых коммитов можно с помощью команды git diff с указанием на требуемые версии: [commit-from]..[commit-to].

Мы сравнили первый коммит с последним и увидели все изменения, когда-либо внесённые. Обычно это проще сделать, используя команду git difftool , которая покажет все различия между началом и концом в графическом клиенте.

2. Возвращение файла в предыдущую версию

GIT позволяет нам вернуть любой выбранный файл назад в одно из сохранённых его состояний. Это делается через команду git checkout , которую мы уже использовали для смены ветвей, но она также может переключать версии (достаточно часто в GIT одна команда используется для нескольких кажущихся совершенно не связанных между собой действий).


В следующем примере мы отменим абсолютно все изменения в файле hello.txt, сделанные после первой фиксации. Нам необходимо указать идентификатор версии, к которой мы хотим вернуться, а также полный путь к нашему файлу.

3. Исправление коммита

Если вы заметили, что вы сделали опечатку в своей команде к сохранению, или вы забыли добавить файл, и заметили сразу после фиксации, вы можете легко исправить это с помощью команды git commit —amend . Она добавит всё из последней версии обратно в область индексирования и попытается создать новую фиксацию. Это дает вам возможность исправить вашу неправильную команду или добавить дополнительные файлы в область индексирования.

Для корректировок потруднее, которые должны быть не в последней версии (или вы уже успели отправить свои изменения на сервер), используйте команду git revert . Она отменит все изменения в этой фиксации и создаст новую, которая будет полностью противоположна исходной.

Ей может быть присвоено имя HEAD.

В подобных случаях лучше всего использовать id-номер.

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

4. Разрешение конфликтов объединения

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

Давайте посмотрим на пример, где мы будем пытаться объединить две ветви, называющиеся john_branch и tim_branch. И Джон, и Тим записывают в одном и том же файле функцию, которая отображает все элементы в массиве.

Джон использует цикл for:

Тим же предпочёл forEach:

Они оба фиксируют свой код на собственных ветвях. Теперь, если они попытаются объединить эти две ветви, то увидят следующее сообщение об ошибке:

GIT не смог объединить ветви автоматически, так что разработчикам придётся вручную разрешить конфликт. Если они откроют файл с конфликтом, они увидят, что GIT пометил проблемные строки.

Выше черты из знаков «равно» мы видим текущую фиксацию HEAD и ниже -конфликтующую. Таким образом, мы можем четко видеть различия и решить, какая версия лучше, или же вовсе написать новую. В данной ситуации мы пойдём до последнего и перепишем все это, удаляя маркеры, чтобы GIT знал, что мы закончили.

Как только всё будет отлажено, должна появиться объединённая фиксация.

Как видите, процесс достаточно утомительный, а в больших проектах справиться с конфликтом может быть чрезвычайно трудно. Большинство разработчиков предпочитают разрешать конфликты с помощью графического клиента , значительно упрощающего действия. Для его запуска воспользуйтесь командой git mergetool .

5. Настройка .gitignore

Во многих проектах присутствуют файлы или папки, которые мы не хотим фиксировать. Мы можем «железно» заблокировать их включение в наш git add –A созданием файла .gitignore:

  • Вручную создайте текстовый файл и назовите его .gitignore, сохраните в каталоге своего проекта;
  • В файле пропишите имена всех файлов/каталогов, которые должны игнорироваться, каждое название с новой строки;
  • .gitignore должен самостоятельно добавиться, зафиксироваться и отправиться на сервер, как любой другой файл в проекте.

Хорошие примеры игнорируемых файлов:

  • лог-файлы;
  • сборщик задач;
  • папка node_modules в проектах node.js;
  • папки, созданные такими IDE (интегрированные среды разработки), как Netbeans и IntelliJ;
  • личные примечания разработчика.

Файл .gitignore блокирует всё вышеуказанное примерно подобным образом:

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

Заключение

Наш урок на тему того, как пользоваться GIT, подходит к концу. Мы старались преподнести вам лишь самую важную информацию так коротко и чётко, как это возможно.

GIT достаточно сложен и имеет кучу функций и трюков. Если вы хотите узнать больше, то ниже мы перечислили некоторые рекомендуемые обучающие ресурсы:

  • Официальная документация GIT, включая полную книгу и видеоуроки ;
  • Получение прав GIT– коллекция уроков и статей Atlassian ;
  • Список графических клиентов ;
  • Памятка о GIT (PDF) ;
  • Создать .gitignore файл онлайн .

2. Основы работы с Git¶

Введение¶

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

Основы работы с удаленным репозиторием¶

git clone — создание копии (удаленного) репозитория¶

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

Клонируем репозиторий, используя протокол http:

Клонируем репозиторий с той же машины в директорию myrepo :

Клонируем репозиторий, используя безопасный протокол ssh:

У git имеется и собственный протокол:

Импортируем svn репозиторий, используя протокол http:

-s – понимать стандартные папки SVN (trunk, branches, tags)

git fetch и git pull — забираем изменения из центрального репозитория¶

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитория.

Возможно также использовать синонимы для адресов, создаваемые командой git remote :

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

Естественно, что после оценки изменений, например, командой git diff , надо создать коммит слияния с основной:

Команда git pull сразу забирает изменения и проводит слияние с активной веткой.

Забрать из репозитория, для которого были созданы удаленные ветки по умолчанию:

Забрать изменения и метки из определенного репозитория:

Как правило, используется сразу команда git pull .

git push — вносим изменения в удаленный репозиторий¶

После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.

Отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию:

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

В удаленном репозитории origin удалить ветку experimental:

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

Отправить метки в удаленную ветку master репозитория origin:

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

Работа с локальным репозиторием¶

Базовые команды¶

git init — создание репозитория

Команда git init создает в директории пустой репозиторий в виде директории .git , где и будет в дальнейшем храниться вся информация об истории коммитов, тегах — о ходе разработки проекта:

git add и git rm — индексация изменений

Следующее, что нужно знать — команда git add . Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит. Примеры использования:

индексация измененного файла, либо оповещение о создании нового:

внести в индекс все изменения, включая новые файлы:

Из индекса и дерева проекта одновременно файл можно удалить командой git rm :

хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:

внести в индекс все удаленные файлы:

Сбросить весь индекс или удалить из него изменения определенного файла можно
командой git reset :

сбросить весь индекс:

удалить из индекса конкретный файл:

Команда git reset используется не только для сбрасывания индекса, поэтому дальше
ей будет уделено гораздо больше внимания.

git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы

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

Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и
файлы, игнорируемые git.

git commit — совершение коммита

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

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

Есть несколько ключей, упрощающих работу с git commit :
совершит коммит, автоматически индексируя изменения в файлах проекта. Новые файлы при этом индексироваться не будут! Удаление же файлов будет учтено.
комментируем коммит прямо из командной строки вместо текстового редактора.
внесет в индекс и создаст коммит на основе изменений единственного файла.

git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»

Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).

«Мягкий» (с ключом —soft ) резет оставит нетронутыми ваши индекс и все дерево файлов и директорий проекта, вернется к работе с указанным коммитом. Иными словами, если вы обнаруживаете ошибку в только что совершенном коммите или комментарии к нему, то легко можно исправить ситуацию:

  1. git commit — некорректный коммит
  2. git reset —soft HEAD^ — переходим к работе над уже совершенным коммитом, сохраняя все состояние проекта и проиндексированные файлы
  3. edit WRONGFILE
  4. edit ANOTHERWRONGFILE
  5. git add .
  6. git commit -c ORIG_HEAD — вернуться к последнему коммиту, будет предложено редактировать его сообщение. Если сообщение оставить прежним, то достаточно изменить регистр ключа -с:

Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.

Естественно, можно вернуться и на большую глубину коммитов,

«Жесткий» резет (ключ —hard ) — команда, которую следует использовать с
осторожностью. git reset —hard вернет дерево проекта и индекс в состояние,
соответствующее указанному коммиту, удалив изменения последующих коммитов:

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

Для команд слияния или выкачивания последних изменений с удаленного репозитория
примеры резета будут приведены в соответствующих разделах.

git revert — отмена изменений, произведенных в прошлом отдельным коммитом

Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным коммитом. git revert создает новый коммит, накладывающий обратные изменения.

Отменяем коммит, помеченный тегом:


Отменяем коммит, используя его хэш:

Для использования команды необходимо, чтобы состояние проекта не отличалось от состояния, зафиксированного последним коммитом.

git log — разнообразная информация о коммитах в целом

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

Простейший пример использования, в котором приводится короткая справка по всем
коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении
подробно узнать можно ниже, в разделе «Ветвления и слияния»):

Получить подробную информацию о каждом в виде патчей по файлам из коммитов
можно, добавив ключ -p (или -u):

Статистика изменения файлов, вроде числа измененных файлов, внесенных в них
строк, удаленных файлов вызывается ключом —stat :

За информацию по созданиям, переименованиям и правам доступа файлов отвечает ключ
—summary :

Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра
его имя (кстати, в моей старой версии git этот способ не срабатывает,
обязательно добавлять » — » перед «README»):

или, если версия git не совсем свежая:

Далее будет приводится только более современный вариант синтаксиса. Возможно
указывать время, начиная в определенного момента («weeks», «days», «hours», «s»
и так далее):

изменения, касающиеся отдельной папки:

Можно отталкиваться от тегов.

Все коммиты, начиная с тега v1:

Все коммиты, включающие изменения файла README, начиная с тега v1:

Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:

Интересные возможности по формату вывода команды предоставляет ключ —pretty .

Вывести на каждый из коммитов по строчке, состоящей из хэша (здесь — уникального идентификатора каждого коммита, подробней — дальше):

Лаконичная информация о коммитах, приводятся только автор и комментарий:

Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:

В принципе, формат вывода можно определить самостоятельно:

Определение формата можно поискать в разделе по git log из Git Community Book
или справке. Красивый ASCII-граф коммитов выводится с использованием ключа
—graph .

git diff — отличия между деревьями проекта, коммитами и т.д.

Своего рода подмножеством команды git log можно считать команду git diff ,
определяющую изменения между объектами в проекте — деревьями (файлов и
директорий).

Показать изменения, не внесенные в индекс:

Изменения, внесенные в индекс:

Изменения в проекте по сравнению с последним коммитом:

Можно сравнивать «головы» веток:

или активную ветку с какой-либо:

git show — показать изменения, внесенные отдельным коммитом

Посмотреть изменения, внесенные любым коммитом в истории, можно командой git show :

git blame и git annotate — команды, помогающие отслеживать изменения файлов

При работе в команде часто требуется выяснить, кто именно написал конкретный
код. Удобно использовать команду git blame , выводящую построчную информацию о
последнем коммите, коснувшемся строки, имя автора и хэш коммита:

Можно указать и конкретные строки для отображения:

Аналогично работает команда git annotate , выводящая и строки, и информацию о
коммитах, их коснувшихся:

git grep — поиск слов по проекту, состоянию проекта в прошлом

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

Поиск слова tst в проекте:

Подсчитать число упоминаний tst в проекте:

Поиск в старой версии проекта:

Команда позволяет использовать логическое И и ИЛИ.

Найти строки, где упоминаются и первое слово, и второе:

Найти строки, где встречается хотя бы одно из слов:

Ветвление¶

git branch — создание, перечисление и удаление веток

Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде:

Просто перечислить существующие ветки, отметив активную:

Создать новую ветку new-branch:

Удалить ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:

Удалить ветку в любом случае:

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

git checkout — переключение между ветками, извлечение файлов

Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:

Создаст ветку, в которую и произойдет переключение

Если в текущей ветке были какие-то изменения по сравнению с последним коммитом в ветке(HEAD), то команда откажется производить переключение, дабы не потерять произведенную работу. Проигнорировать этот факт позволяет ключ -f :

В случае, когда изменения надо все же сохранить, следует использовать ключ -m . Тогда команда перед переключением попробует залить изменения в текущую ветку и, после разрешения возможных конфликтов, переключиться в новую:

Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:

Вернуть somefile к состоянию последнего коммита:

Вернуть somefile к состоянию на два коммита назад по ветке:

git merge — слияние веток (разрешение возможных конфликтов)

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

Попробовать объединить текующую ветку и ветку new-feature:

В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.

Например, конфликт возник в файле TROUBLE , что можно увидеть в git status .

Произошла неудачная попытка слияния:

Смотрим на проблемные места:

Индексируем наши изменения, тем самым снимая метки:

Совершаем коммит слияния:

Вот и все, ничего сложного. Если в процессе разрешения вы передумали разрешать конфликт, достаточно набрать (это вернёт обе ветки в исходные состояния):

Если же коммит слияния был совершен, используем команду:

git rebase — построение ровной линии коммитов

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

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

Предположим, имеется две ветки, master и topic, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.

Вариант, в котором явно указывается, что и куда накладывается:

на master накладывается активная в настоящий момент ветка:

После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования — разрешения конфликтов — файлы следует внести в индекс командой git add и продолжить наложение следующих коммитов командой git rebase —continue . Альтернативными выходами будут команды git rebase —skip (пропустить наложение коммита и перейти к следующему) или git rebase —abort (отмена работы команды и всех внесенных изменений).

С ключом -i ( —interactive ) команда будет работать в интерактивном режиме. Пользователю будет предоставлена возможность определить порядок внесения изменений, автоматически будет вызывать редактор для разрешения конфликтов и так далее.

git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом

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

Изменения, внесенные указанным коммитом будут применены к дереву, автоматически проиндексированы и станут коммитом в активной ветке:

Ключ -n показывает, что изменения надо просто применить к дереву проекта без индексации и создания коммита

Прочие команды и необходимые возможности¶

Хэш — уникальная идентификация объектов

В git для идентификации любых объектов используется уникальный (то есть с огромной вероятностью уникальный) хэш из 40 символов, который определяется хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты, файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла, то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки в сорок символов.

Больше всего нас интересует тот факт, что хэши идентифицируют коммиты. В этом смысле хэш — продвинутый аналог ревизий Subversion. Несколько примеров использования хэшей в качестве способа адресации:

найти разницу текущего состояния проекта и коммита за номером… сами видите, каким:

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

Иногда хватает и четырех символов:

Читаем лог с коммита по коммит:

Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно поэтому были введены другие объекты — тэги.

git tag — тэги как способ пометить уникальный коммит

Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может оставлять на таких тегах собственную цифровую подпись.

Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.

Создать «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:

Пометить определенный коммит:

Создать тэг для последнего коммита, заменить существующий, если таковой уже был:

После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff , git log и так далее:

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

Создать обычный тэг для последнего коммита; будет вызван текстовый редактор для составления комментария:

Создать обычный тэг, сразу указав в качестве аргумента комментарий:

Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.

Относительная адресация

Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один механизм — относительную адресацию. Например, можно обратиться прямо к предку последнего коммита ветки master:

Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:

найти изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки:

Аналогично, тильдой можно просто указывать, насколько глубоко в историю ветки нужно погрузиться:

что привнес «дедушка» нынешнего коммита:

Обозначения можно объединять, чтобы добраться до нужного коммита:

файл .gitignore — объясняем git, какие файлы следует игнорировать

Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status . Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.

Заставить git status игнорировать определенные файлы можно, создав в корне или глубже по дереву (если ограничения должны быть только в определенных директория) файл .gitignore . В этих файлах можно описывать шаблоны игнорируемых файлов определенного формата.

Пример содержимого такого файла:

Существуют и другие способы указания игнорируемых файлов, о которых можно узнать из справки git help gitignore .

Серверные команды репозитория¶

; git update-server-info : Команда создает вспомогательные файлы для dumb-сервера в $GIT_DIR/info и $GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки и пакеты есть на сервере.

; git count-objects : Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.
; git gc : Переупаковка локального репозитория.

Рецепты¶

Создание пустого репозитория на сервере

Импорт svn репозитория на Git-сервер

Урок 1. Git и Github. Введение. Что такое Git и Github

Дата публикации: 15-08-2020

От автора: иногда, при разработке больших проектов, возникает необходимость вернуться в некоторое состояние проекта в прошлом. Например, вы в какой-то момент времени начали разработку некоторого функционала для сайта. Несколько дней работали над реализацией этого функционала, после чего стало понятно, что выбранное решение не подходит и нужно найти другое. В этот момент полезно «откатиться» к исходному состоянию проекта, до внесения изменений и искать другой вариант реализации. Это один из вариантов, когда нам может быть полезен git.

В данном уроке мы с вами поговорим о том, что такое git и что такое github. Узнаем, как они устроены, для чего предназначены и как работают. Узнаем преимущества работы с git. Из урока у вас будет понимание того, как работать с git и как он устроен, и вы сможете определить для себя, стоит ли вам его использовать в своем проекте или проектах.

Цукерберг рекомендует:  Сеть - как создать карту сети в C#
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих