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


Содержание материала:

Введение в GitHub для разработчиков

GitHub — это веб-сайт, на котором размещены миллиарды строк кода. Ежедневно миллионы разработчиков собираются там для совместной работы и решения разного уровня задач в публичном режиме с открытым исходным кодом.

Короче говоря, это платформа для разработчиков программного обеспечения, основанная на GIT.

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

Почему GitHub?

Теперь вы знаете, что такое GitHub и наверняка задаетесь вопросам – зачем мне его использовать и как?

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

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

Со временем основные кодовые базы были перенесены из других систем контроля версий в GIT из-за его удобства. GitHub исторически находится в выгодном положении и прилагает много усилий для удовлетворения потребностей сообщества открытого исходного кода.

Сегодня, когда вы будете искать какую-либо библиотеку, вы в 99% случаев найдете ее на GitHub.

Помимо открытого исходного кода, многие разработчики также размещают частные репозитории на GitHub из-за удобства платформы.

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

GitHub Issues

GitHub Issues – одна из наиболее популярных в мире систем отслеживания багов.

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

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

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

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

Социальное кодирование

Несколько лет назад в логотип GitHub входил слоган «социального кодирования».

Что это значит? Важен ли сейчас этот слоган? Конечно.

Подписки (Follow)

На GitHub можно подписаться на разработчика или репозиторий, зайдя в профиль пользователя и нажав «Подписаться» или нажав кнопку «Следить» в репозитории.

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

Звезды (Stars)

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

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

Крупные проекты могут иметь десятки тысяч звезд.

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

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

Ответвления (Fork)

Последний важный сетевой индикатор проекта — это количество ответвлений.

Это ключ к тому, как работает GitHub. Ответвление — это основа запроса на включение (PR), который является предложением об изменении. Человек может добавить ответвление к вашему репозиторию, внести некоторые изменения, а затем создать запрос на включение, чтобы попросить вас объединить эти изменения в исходник.

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

Чем популярнее, тем лучше

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

Запросы на включение (Pull requests)

В предыдущем разделе я объяснил, что такое запрос на включение (PR). Повторим: человек может добавить расширение к вашему репозиторию, внести некоторые изменения, а затем создать запрос на включение, чтобы попросить вас объединить эти изменения.

Проект может иметь сотни PR. Как правило, чем популярнее проект, тем больше PR. Например, в проекте React:

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

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

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

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

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

Управление проектами (Project management)

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

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

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

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

Представив релизы, GitHub расширил функциональность тегов GIT.

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

Релиз GitHub построен на основе тегов GIT и представляет собой полную версию вашего кода, а также zip-файлы, заметки о выпуске и двоичные ресурсы, которые могут представить полностью рабочую версию конечного продукта кода.

Хотя тег GIT можно создавать программно (например, с помощью тега git из командной строки), создание релизов GitHub – это ручной процесс, который происходит в пользовательском интерфейсе GitHub. Вы, по сути, говорите GitHub создать новый релиз и сообщаете, к какому тегу вы хотите применить его.

Сравнение коммитов

GitHub предлагает множество инструментов для работы с кодом.

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

GitHub позволяет вам делать это с compare view: просто добавьте /compare в конец имени репозитория.

На рисунке ниже я сравниваю последнюю версию React v15.x с последней версией v16.0.0-rc, доступной на момент написания этой статьи, чтобы увидеть, что изменилось.

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

Webhooks и Services

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

Webhooks

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

Когда происходит событие, GitHub отправляет запрос POST на URL, который мы говорим ему использовать.

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

Мы отправляем команду push к GitHub, GitHub сообщает серверу об этом, и сервер извлекает данные из GitHub.

Services

Сервисы GitHub и новые приложения GitHub представляют собой сторонние интеграции, которые улучшают работу разработчика или предоставляют услуги.

Например, вы можете установить исполнитель тестов для автоматического запуска тестов каждый раз, когда вы делаете новые коммиты. Здесь поможет TravisCI .

Можно настроить непрерывную интеграцию с помощью CircleCI .

Можно создать интеграцию Codeclimate , которая анализирует код и предоставляет отчет «Техническая задолженность» и покрытие тестирования.

Заключение

GitHub — это замечательный инструмент и сервис, которым можно воспользоваться. Это настоящий драгоценный камень в современном наборе инструментов для разработчиков. Данное руководство поможет вам начать работу. Реальный опыт управления проектами с открытым или закрытым исходным кодом GitHub (как пользоваться им, показано во многих статьях) — это то, что нельзя упустить.

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

Полезные ссылки:

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

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

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

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

Работа с терминалом

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

Установка Git

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

Задание к уроку

Создайте новый проект в редакторе Atom. Выполните следующие действия:

  • установите локально значение для «user.name».
  • установите локально значение для «user.email».

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

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

Большое задание по курсу

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

Введение в 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. Спасибо за внимание.

Git для начинающих

Для людей естественно сопротивляться изменениям. Если Git не встретился вам, когда вы начинали работать с системами контроля версий, наверняка вы чувствуете себя комфортнее в системе Subversion (SVN) .

Часто люди говорят, что Git слишком сложен для новичков. Тем не менее, я позволю себе не согласиться с этим.

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

Топ-пост этого месяца:  Что такое Яндекс Радар и как он работает - найдётся всё

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

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

Установка Git

На официальном сайте Git есть детальная информация об его установке на Linux, Mac и Windows. В нашем случае, мы будем использовать в целях демонстрации Ubuntu 13.04 , где установим Git с помощью apt-get:

Начальная настройка

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

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

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

Важно отметить, что если вы не укажите свое имя и адрес электронной почты, то будут использованы значения по умолчанию. В нашем случае, значениями по умолчанию были бы имя пользователя donny и адрес электронной почты [email protected] .

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

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

Подготовка файлов для коммита

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

Проверить статус репозитория

Теперь, когда у нас есть несколько файлов в нашем репозитории, давайте посмотрим, как Git обращается с ними. Для того, чтобы проверить текущий статус репозитория, нужно воспользоваться командой git status :

Добавление файлов в Git для отслеживания

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

Добавляем файлы при помощи команды add :

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

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

Вы можете использовать git add рекурсивно, но будьте осторожны с этой командой. Существуют определенные файлы (например, скомпилированные файлы), которые обычно хранят вне репозитория Git .

Если вы будете использовать команду add рекурсивно, она добавит все такие файлы, если они существуют в вашем репозитории.

Удаление файлов

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

Но выполнение простой команды git rm удалит файл не только из Git , но также и из вашей локальной файловой системы! Чтобы

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

Коммит изменений

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

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

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

Избегайте слишком общих сообщений типа « Исправлены ошибки ». Если у вас есть трекер задач, вы можете добавлять сообщения в виде « Исправлена ошибка #234 ».

Хорошей практикой является использование имени ветки или имени функции в качестве префикса к сообщению коммита. Например, « Управление активами: добавлена функция для генерации PDF файлов активов » — это содержательное сообщение.

Git идентифицирует коммиты путем добавления длинного шестнадцатеричного числа к каждому коммиту. Как правило, не нужно копировать всю строку, для определения вашего коммита достаточно первых 5-6 символов.

Обратите внимание, что на скриншоте наш первый коммит определяется кодом 8dd76fc .

Дальнейшие коммиты

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

Вы можете проверить изменения в отслеживаемых файлах, сделанные в последнем коммите, с помощью команды git diff . Если вы хотите просмотреть изменения в определенном файле, используйте команду git diff :

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

Вы можете избежать использования этой команды, воспользовавшись префиксом -a для команды git commit , который добавит все изменения в отслеживаемые файлы.

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

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

После того, как вы разместили ваши файлы, можно приступить к коммиту. Я упоминал, что с каждым коммитом может быть ассоциировано сообщение, которое мы вводим с помощью префикса -m .

Однако существует возможность ввести сообщение в несколько строк, воспользовавшись командой git commit , которая открывает интерактивную форму для записи:

Управление проектом

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

Так будет показана вся история проекта, которая представляет собой список всех коммитов и информации по ним. Информация о коммите включает в себя хеш-код коммита, автора, время и сообщение коммита. Есть различные варианты git log , которые вы можете изучить, как только освоите понятие ветки (англ. branch) в Git .

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

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

Размещение кода в облаке

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

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

Если вы хотите разместить код в облаке, вы можете создать проект на GitHub , GitLab или BitBucket и поместить уже существующий код в репозиторий.

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

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

Заключение

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

Данная публикация представляет собой перевод статьи « Git for Beginners » , подготовленной дружной командой проекта Интернет-технологии.ру

Урок 1. Git и Github. Введение. Что такое Git и 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) — слияние изменений из какой-либо ветки репозитория с любой веткой этого же репозитория. Чаще всего слияние изменений из ветки репозитория с основной веткой репозитория.
  • Кодревью — процесс проверки кода на соответствие определённым требованиям, задачам и внешнему виду.

Знакомство школьников с git и github… Стоит ли? И с чего начать?

Я веду кружок Информатики и у меня есть идея во втором полугодии, когда школьники перейдут к своим проектам загнать их на github.
Проблемы:
1. Я ничего не знаю про git и github
2. Я не сталкивался с проектами использующими систему контроля версий
3. Работа с git и github тянет за собой шлейф знаний которых в школе не дают
Почему я все же хочу
1. Я думаю это будет детям полезно. В кружок ходят «будущие программисты»
2. Поскольку дети перейдут к практической работе над проектами время на теорию высвобождается.
3. Это круто.

Интересуют именно оценки «потянут — не потянут», а может сложность детских работ не такая чтобы огород городить и прочее.
Материалы я и сам найду. Вот например хорошая статья. habrahabr.ru/post/125799/

  • Вопрос задан более трёх лет назад
  • 10686 просмотров

1. Стоит однозначно.
2. Начать с локального репозитория под каждый проект. Показать как круто иметь лог всех изменений и откатиться на любую версию. Гитом в консоли я бы не торопился, лучше использовать средства IDE для работы с ним. Затем организовать совместную разработку, создать репозиторий с доступом на запись каждому(потому что проще). За одно и сами разберетесь в тонкостях. А там уж показать кузницу опенсорса: гитхаб, битбакет и т.п.

А какая задача стоит? Познакомить с гитхабом или с системами контроля версий?
git сложен.

И вам будет сложно объяснить плюсы таких систем, если вы с ними не работали. Поработав, вы уже не сможете их не использовать — так много плюсов они дают.

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

Применение на практике систем контроля версий в школьном курсе — это трудоёмко для преподавателя и трудно для освоения большинству школьников.

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

Преподавателю придётся:
* поддерживать работу специального программного обеспечения
* найти и адаптировать учебные материалы
* составлять учебные примеры среднего уровня, неизвестно откуда взяв показатели этого среднего уровня
* проводить контрольные работы, опять же ориентируясь на средний уровень. Если темы «Системы контроля версий» в программе нет, легко опротестовать результаты контрольной, как не утверждённой министерством образования для средней школы и потому не обязательной.

И опять о практике: что обычному школьнику в рамках школьного курса практически хранить в системах контроля версий? Даже самостоятельные работы, которые можно сдать в электронном виде, настолько мЕлки, что ради них бессмысленно поднимать CSV/SVN/GIT/Mercurial, не говоря уж о том, что школьники обычно сдают работы в рукописном виде.

Подробное введение в работу с Git

Сайт tproger.ru опубликовал перевод статьи «The Ultimate Beginner Git Cheatsheet».

Что такое Git и зачем он мне?

Git — это распределённая система контроля версий, которая позволяет сохранять все изменения, внесённые в файлы, хранящиеся в репозитории. Изменения хранятся в виде снимков, называемых коммитами, которые могут размещаться на многих серверах. Считайте это стандартным облаком для бэкапов на стероидах — вы не только можете восстановить код в случае сбоя, но и откатить код до любого из предыдущих сохранённых состояний. Также вы легко можете взаимодействовать с другими разработчиками — опять же, как несколько человек могут работать над одним файлом в Google Docs, так и разработчики могут одновременно работать над одним репозиторием и сохранять свои изменения.

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

Как работать с Git

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

С Git можно работать как через командную строку, так и через графический интерфейс вроде GitHub Desktop. Хотя начинающих разработчиков командная строка может отпугнуть, её всё равно лучше изучить, ведь она предоставляет больше возможностей, чем многие инструменты с интерфейсом.

Как правило, команды Git принимают вид git , где аргументом может быть путь к файлу. У команд также могут быть опции, которые обозначаются как — или — . Они позволяют более детально настроить действия команды. В этой статье команды будут представлены в общем виде, поэтому всё, что находится в <> , вам нужно будет заменить на собственные значения.

Если вы не знаете, как использовать команду, то можете открыть руководство с помощью git help , а если вам просто нужно напоминание, используйте git -h или git —help ( —help и -h эквивалентны).

Подготовка Git

Установка Git

Пользователи Windows могут скачать его отсюда.

В macOS (OS X) Git поставляется как часть инструментов командной строки XCode, поэтому нужно их установить. Чтобы проверить наличие Git, откройте терминал и введите git —version для проверки версии.

Если вы пользуетесь Linux, то используйте команду sudo apt install git-all (дистрибутивы на основе Debian) или sudo dnf install git-all (на основе RPM).

Настройка конфигурационного файла

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

Вы можете либо напрямую отредактировать файл .gitconfig с помощью текстового редактора, либо с помощью команды git config —global —edit , а также можете отредактировать отдельные поля, используя команду git config —global — нас интересуют поля user.name и user.email .

Также можно настроить текстовый редактор для написания сообщений коммитов, используя поле core.editor . Изначально используется системный редактор по умолчанию, например, vi для Linux/Mac. Поле commit.template позволяет указать шаблон, который будет использоваться при каждом коммите.

Есть множество других полей, однако одно из самых полезных — это alias , которое привязывает команду к псевдониму. Например, git config —global alias.st «status -s» позволяет использовать git st вместо git status -s

Команда git config —list выведет все поля и их значения из конфигурационного файла.

Создаём Git-репозиторий

Для инициализации нового репозитория .git можно использовать команду git init или, если вы хотите скопировать существующий, git clone .

История коммитов в Git

Git хранит данные в виде набора легковесных «снимков», известных как коммиты. Они хранят состояние файловой системы в определённый момент времени, а также указатель на предыдущий(-ие) коммит(-ы). Каждый коммит содержит уникальную контрольную сумму — идентификатор, который Git использует, чтобы ссылаться на коммит. Чтобы отслеживать историю, Git хранит указатель HEAD, который указывает на первый коммит (мы следуем по цепочке коммитов в обратном порядке, чтобы попасть к предыдущим коммитам).

Мы можем ссылаться на коммит либо через его контрольную сумму, либо через его позицию относительно HEAD, например HEAD

4 ссылается на коммит, который находится 4 коммитами ранее HEAD.

Файловая система Git

Git отслеживает файлы в трёх основных разделах:

  • рабочая директория (файловая система вашего компьютера);
  • область подготовленных файлов (staging area, хранит содержание следующего коммита);
  • HEAD (последний коммит в репозитории).

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

Просмотр изменений в файловых системах

Команда git status отображает все файлы, которые различаются между тремя разделами. У файлов есть 4 состояния:

  1. Неотслеживаемый (untracked) — находится в рабочей директории, но нет ни одной версии в HEAD или в области подготовленных файлов (Git не знает о файле).
  2. Изменён (modified) — в рабочей директории есть более новая версия по сравнению с хранящейся в HEAD или в области подготовленных файлов (изменения не находятся в следующем коммите).
  3. Подготовлен (staged) — в рабочей директории и области подготовленных файлов есть более новая версия по сравнению с хранящейся в HEAD (готов к коммиту).
  4. Без изменений — одна версия файла во всех разделах, т. е. в последнем коммите содержится актуальная версия.

Примечание Файл может быть одновременно в состоянии «изменён» и «подготовлен», если версия в рабочей директории новее, чем в области подготовленных файлов, которая в свою очередь новее версии в HEAD.

Мы можем использовать опцию -s для команды git status , чтобы получить более компактный вывод (по строке на файл). Если файл не отслеживается, то будет выведено ?? ; если он был изменён, то его имя будет красным, а если подготовлен — зелёным.

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

  • git diff — сравнение рабочей директории с областью подготовленных файлов;
  • git diff —staged — сравнение области подготовленных файлов с HEAD.

Если использовать аргумент , то diff покажет изменения только для указанных файлов/папок, например git diff src/ .

Обновление файловых систем

Команда git add обновляет область подготовленных файлов версиями файлов/папок из рабочей директории.

Команда git commit обновляет HEAD новым коммитом, который делает снимки файлов в области подготовленных файлов.

Действие команды git reset состоит из трёх потенциальных шагов:

  1. Переместить указатель HEAD на (например, при откате коммита в рабочей директории и области подготовленных файлов будут более новые версии файлов, чем в HEAD). Также указатель HEAD ветки будет перемещён на этот коммит.
  2. Обновить область подготовленных файлов содержимым коммита. В таком случае только в рабочей директории будут новейшие версии файлов.
  3. Обновить рабочую директорию содержимым области подготовленных файлов. С этим нужно быть осторожнее, поскольку в итоге будут уничтожены изменения файлов.

По умолчанию команда git reset выполняет только шаги 1 и 2, однако её поведение можно изменить с помощью опций —soft (только 1 шаг) и —hard (все шаги).

Если передать путь к файлу/папке, то команда будет выполнена только для них, например git reset —soft HEAD

Команда git checkout HEAD приводит к тому же результату, что и git reset —hard HEAD — перезаписывает версию файла в области подготовленных файлов и в рабочей директорией версией из HEAD, то есть отменяет изменения после последнего коммита.

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

Наконец, git rm отменяет отслеживание файла и удаляет его из рабочей директории, опция —cached позволит сохранить файл.

Игнорирование файлов

Зачастую нам не нужно, чтобы Git отслеживал все файлы в репозитории, потому что в их число могут входить:

  • файлы с чувствительной информацией вроде паролей;
  • большие бинарные файлы;
  • файлы сборок, которые генерируются после каждой компиляции;
  • файлы, специфичные для ОС/IDE, например, .DS_Store для macOS или .iml для IntelliJ IDEA — нам нужно, чтобы репозиторий как можно меньше зависел от системы.
Топ-пост этого месяца:  Вывод подкатегорий из основной категории

Для игнорирования используется файл .gitignore . Чтобы отметить файлы, которые мы хотим игнорировать, можно использовать шаблоны поиска (считайте их упрощёнными регулярными выражениями):

  • /___ — позволяет избежать рекурсивности — соответствует файлам только в текущей директории;
  • __/ — соответствует всем файлам в указанной директории;
  • *___ — соответствует всем файлам с указанным окончанием;
  • ! — игнорирование файлов, попадающих под указанный шаблон;
  • [__] — соответствует любому символу из указанных в квадратных скобках;
  • ? — соответствует любому символу;
  • /**/ — соответствует вложенным директориям, например a/**/d соответствует a/d , a/b/d , a/b/c/d и т. д.

Мы даже можем использовать шаблоны поиска при указании файла/папки в других командах. Например, git add src/*.css добавит все файлы .css в папке src .

Коммиты

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

Команда git commit откроет текстовый редактор для ввода сообщения коммита. Также эта команда принимает несколько распространённых аргументов:

  • -m позволяет написать сообщение вместе с командой, не открывая редактор. Например git commit -m «Пофиксил баг» ;
  • -a переносит все отслеживаемые файлы в область подготовленных файлов и включает их в коммит (позволяет пропустить git add перед коммитом);
  • —amend заменяет последний коммит новым изменённым коммитом, что бывает полезно, если вы неправильно набрали сообщение последнего коммита или забыли включить в него какие-то файлы.

Несколько советов, к которым стоит прислушаться:

  • Коммитьте часто: вы не сможете откатить изменения, если откатывать не к чему.
  • Одно изменение — один коммит: не помещайте все не связанные между собой изменения в один коммит, разделите их, чтобы было проще откатиться.
  • Формат сообщений: заголовок должен быть в повелительном наклонении, меньше 50 символов в длину и должен логически дополнять фразу this commit will ___ (this commit will fix bugs — этот коммит исправит баги). Сообщение должно пояснять, почему был сделан коммит, а сам коммит показывает, что изменилось. Здесьподробно расписано, как писать сообщения для коммитов.
  • (Опционально) Не коммитьте незначительные изменения: в большом репозитории множество небольших коммитов могут засорить историю. Хорошим тоном считается делать такие коммиты при разработке, а при добавлении в большой репозиторий объединять их в один коммит.

Просмотр изменений в истории

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

  • -p показывает изменения в каждом коммите;
  • —stat показывает сокращённую статистику для коммитов, например изменённые файлы и количество добавленных/удалённых строк в каждом их них;
  • -n показывает n последних коммитов;
  • —since=___ и —until=___ позволяет отфильтровать коммиты по промежутку времени, например —since=»2020-01-01″ покажет коммиты с 1 января 2020 года;
  • —pretty позволяет указать формат логов (например, —pretty=oneline ), также можно использовать —pretty=format для большей кастомизации, например —pretty=format:»%h %s» ;
  • —grep и -S фильтруют коммиты с сообщениями/изменениями кода, которые содержат указанную строку, например, git log -S имя_функции позволяет посмотреть добавление/удаление функции;
  • —no-merges пропускает коммиты со слиянием веток;
  • ветка1..ветка2 позволяет посмотреть, какие коммиты из ветки 2 не находятся в ветке 1 (полезно при слиянии веток). Например, git log master..test покажет, каких коммитов из ветки test нет в master (о ветках поговорим чуть позже).
  • —left-right ветка1. ветка2 показывает коммиты, которые есть либо в ветке 1, либо в ветке 2, но не в обеих; знак обозначает коммиты из ветка1 , а > — из ветка2 .Обратите внимание: используется три точки, а не две;
  • -L принимает аргумент начало,конец:файл или :функция:файл и показывает историю изменений переданного набора строк или функции в файле.

Другой полезной командой является git blame , которая для каждой строки файла показывает автора и контрольную сумму последнего коммита, который изменил эту строку. -L , позволяет ограничить эту команду заданными строками. Это можно использовать, например, для выяснения того, какой коммит привёл к определённому багу (чтобы можно было его откатить).

Наконец, есть команда git grep , которая ищет по всем файлам в истории коммитов (а не только в рабочей директории, как grep ) по заданному регулярному выражению. Опция -n отображает соответствующий номер строки в файле для каждого совпадения, а —count показывает количество совпадений для каждого файла.

Примечание Не путайте git grep с git log —grep ! Первый ищет по файлам среди коммитов, а последний смотрит на сообщения логов.

Удалённые серверы

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

Команда git remote -v выводит список удалённых репозиториев, которые мы отслеживаем, и имена, которые мы им присвоили.

При использовании команды git clone мы не только загружаем себе копию репозитория, но и неявно отслеживаем удалённый сервер, который находится по указанному адресу и которому присваивается имя origin.

Наиболее употребляемые команды:

  • git remote add — добавляет удалённый репозиторий с заданным именем;
  • git remote remove — удаляет удалённый репозиторий с заданным именем;
  • git remote rename — переименовывает удалённый репозиторий;
  • git remote set-url — присваивает репозиторию с именем новый адрес;
  • git remote show — показывает информацию о репозитории.

Следующие команды работают с удалёнными ветками:

  • git fetch — получает данные из ветки заданного репозитория, но не сливает изменения;
  • git pull — сливает данные из ветки заданного репозитория;
  • git push — отправляет изменения в ветку заданного репозитория. Если локальная ветка уже отслеживает удалённую, то можно использовать просто git push или git pull .

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

Ветвление

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

Это ведёт нас ключевой особенности Git — ветвлению, возможности работать над разными версиями проекта. Это значит, что вместо одного списка с упорядоченными коммитами история будет расходиться в определённых точках (что делает её похожей на дерево). Каждая ветвь в Git содержит легковесный указатель HEAD на последний коммит в этой ветке, что позволяет без лишних затрат создать много веток. Совет: называйте ветку в соответствии с разрабатываемой в ней функциональностью. Ветка по умолчанию называется master.

Итак, у нас есть общий указатель HEAD и HEAD для каждой ветки. Таким образом, переключение между ветками предполагает только перемещение HEAD в HEAD соответствующей ветки.

  • git branch — создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент , то команда выведет список всех локальных веток;
  • git checkout — переключается на эту ветку. Можно передать опцию -b , чтобы создать новую ветку перед переключением;
  • git branch -d — удаляет ветку.

Как наш локальный репозиторий, так и удалённый, могут иметь множество ветвей, поэтому когда вы отслеживаете удалённый репозиторий, на самом деле отслеживается удалённая ветка ( git clone привязывает вашу ветку master к ветке origin/master удалённого репозитория).

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

  • git branch -u / — привязывает текущую ветку к указанной удалённой ветке;
  • git checkout —track / — аналог предыдущей команды;
  • git checkout -b / — создаёт новую локальную ветку и начинает отслеживать удалённую;
  • git branch —vv — показывает локальные и отслеживаемые удалённые ветки;
  • git checkout — создаёт локальную ветку с таким же именем, как у удалённой, и начинает её отслеживать.

В общем, git checkout связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как git reset перемещает общий HEAD.

Прятки и чистка

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

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

Однако порой у вас есть незавершённые изменения, которые нельзя фиксировать. В такой ситуации их можно сохранить и «спрятать» с помощью команды git stash . Чтобы вернуть изменения, используйте git stash apply .

Возможно, вместо этого вы захотите стереть все внесённые изменения. В таком случае используйте команду git clean . Опция -d также удалит неотслеживаемые файлы. Совет: добавьте опцию -n , чтобы увидеть, что произойдёт при запуске git clean без непосредственного использования.

Совмещение веток

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

Слияние

Оно включает в себя создание нового коммита, который основан на общем коммите-предке двух ветвей и указывает на оба HEAD в качестве предыдущих коммитов. Для слияния мы переходим на основную ветку и используем команду git merge .

Если обе ветви меняют одну и ту же часть файла, то возникает конфликт слияния — ситуация, в которой Git не знает, какую версию файла сохранить, поэтому разрешать конфликт нужно собственноручно. Чтобы увидеть конфликтующие файлы, используйте git status .

После открытия таких файлов вы увидите похожие маркеры разрешения конфликта:

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

Перемещение

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

Для перемещения используется команда git rebase , которая воспроизводит изменения тематической ветки на основной; HEAD тематической ветки указывает на последний воспроизведённый коммит.

Перемещение vs. слияние

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

Так зачем нужно слияние, если можно всё время пользоваться перемещением? К сожалению, перемещение не панацея от запутанных логов, так как перемещённые коммиты на самом деле отличаются от оригинальных, хотя и имеют одного и того же автора, сообщение и изменения.

  • В своей ветке вы создаёте несколько коммитов и сливаете их в мастер-ветку.
  • Кто-то ещё решает поработать на основе ваших коммитов.
  • Вы решаете переместить ваши коммиты и отправить их на сервер.
  • Когда кто-то попытается слить свою работу на основе ваших изначальных коммитов, в итоге мы получим две параллельные ветки с одним автором, сообщениями и изменениями, но разными коммитами.

Поэтому вот совет:

Перемещайте изменения только на вашей приватной локальной ветке — не перемещайте коммиты, от которых зависит ещё кто-то.

Откат коммитов — revert и reset

Похожие дебаты по поводу того, что лучше использовать, возникают, когда вы хотите откатить коммит. Команда git revert создаёт новый коммит, отменяющий изменения, но сохраняющий историю, в то время как git reset перемещает указатель HEAD, предоставляя более чистую историю (словно бы этого коммита никогда и не было). Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!

Резюмируем

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

GitHub

GitHub — это платформа, которая хранит Git-репозитории на своих множественных серверах. Как пользователь GitHub вы можете хранить свои удалённые репозитории на их серверах, а также вносить вклад в другие open-source репозитории. GitHub дополняет использование Git некоторыми новыми возможностями.

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

После этого вам может понадобиться слить тематическую ветку вашего удалённого репозитория в основную ветку оригинального. Для этого вы можете создать новый Pull Request — запрос на внесение изменений, где GitHub проверяет наличие конфликтов прежде чем повзолить вам провести слияние. Зачастую существуют и другие проверки перед слиянием, например просмотр и одобрение кода или даже запуск тестов. В запросе можно обсудить код, а все коммиты, которые вы отправляете в удалённую тематическую ветку, будут автоматически добавлены в запрос, даже если он был создан до этих коммитов.

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

Вы можете с удобством управлять областью подготовленных файлов (например при фиксации нескольких небольших коммитов вместо одного большого) с помощью интерактивной консоли, которую можно запустить git add -i . В ней доступны 8 команд:

  • status — показывает для каждого файла краткое описание того, что (не)подготовлено;
  • update — подготавливает отслеживаемые файлы;
  • revert — убрать один или несколько файлов из подготовленной области;
  • add untracked — подготавливает неотслеживаемый файл;
  • patch — подготавливает только часть файла (полезно, когда вы, например, изменили несколько функций, но хотите разбить изменения на несколько коммитов). После выбора файла вам будут показаны его фрагменты и представлены возможные команды: Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? . Можно ввести ? , чтобы узнать, что делает каждая команда;
  • diff — показывает список подготовленных файлов и позволяет посмотреть изменения для каждого из них;
  • quit — выходит из интерактивной консоли;
  • help — показывает краткое описание каждой команды.

Символ * рядом с файлом означает, что команда изменит его статус (подготовлен/неподготовлен в зависимости от того, происходит ли обновление или откат). Если нажать Enter, не введя ничего ни в одном из под-меню команды, то все файлы перейдут в (не)подготовленное состояние.

Обратите внимание, что создание патчей (подготовка только части файла) доступно не только в интерактивной консоли, но и через команду git add -p .

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

Для большего контроля над историей коммитов локальной ветки можно использовать команду git rebase -i HEAD

n , которая откроет интерактивную консоль для перемещения набора последних n коммитов, перечисленных в порядке от старых к новым (то есть в том порядке, в котором они будут перемещены). Таким образом вы можете «редактировать историю», однако помните, что оригинальные коммиты нельзя изменить, только переместить.

Вы можете поменять порядок коммитов, изменив порядок, в котором они перечислены.

Измененяем сообщение коммита/разбиваем коммиты

Для указания коммита, который вы хотите изменить, используется команда edit . Затем, когда Git будет проводить перемещение, он остановится на этом коммите. После этого вы можете использовать git commit —amend , чтобы изменить сообщение или подготовить забытые файлы. Если вы хотите разделить коммит, после остановки введите git reset HEAD^ (в результате HEAD будет перемещён на один коммит назад и все изменённые в этом коммите файлы перейдут в статус неподготовленных). Затем вы сможете зафиксировать файлы в отдельных коммитах обычным образом.

После завершения редактирования введите git rebase —continue .

Перезапись нескольких коммитов

Иногда вам может потребоваться перезаписать несколько коммитов — в таких случаях можно использовать git filter-branch . Например, чтобы удалить случайно зафиксированный файл, можно ввести git filter-branch —tree-filter ‘git rm -f ‘ HEAD . Однако учтите, что при этом вся история перемещается.

Объединение нескольких коммитов

Во время работы над новой функцией в проекте вы можете постепенно фиксировать даже малейшие изменения в тематической ветке. Однако из-за этого история засоряется такими небольшими коммитами, что может противоречить правилам проекта. Это можно исправить, объединив несколько коммитов в один большой. Для этого сначала используйте команду pick для выбора первого коммита, а затем squash для последующих. Git применит все изменения в одном коммите и попросит отредактировать сообщение общего коммита.

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

Кроме слияния/перемещения всех коммитов в тематической ветке, вас может интересовать только определённый коммит. Допустим, у вас есть локальная ветка drafts, где вы работаете над несколькими потенциальными статьями, но хотите опубликовать только одну из них. Для этого можно использовать команду git cherry-pick . Чтобы получить определённые коммиты, из которых мы хотим выбирать, можно использовать git log .. .

Обратите внимание, что таким образом создаётся новый коммит, который только повторяет diff выбранного коммита (то есть разницу между этим коммитом и предыдущим), но не его состояние.

Заключение

Вот мы и рассмотрели основные концепции Git. Вы можете использовать эту статью в качестве краткого справочника, а можете почитать книгу «Pro Git», которая гораздо больше (

450 страниц) и описывает Git более глубоко.

Введение в GitHub для разработчиков

GitHub — это веб-сайт, на котором размещены миллиарды строк кода. Ежедневно миллионы разработчиков собираются там для совместной работы и решения разного уровня задач в публичном режиме с открытым исходным кодом.

Короче говоря, это платформа для разработчиков программного обеспечения, основанная на GIT.

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

Почему GitHub?

Теперь вы знаете, что такое GitHub и наверняка задаетесь вопросам – зачем мне его использовать и как?

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

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

Со временем основные кодовые базы были перенесены из других систем контроля версий в GIT из-за его удобства. GitHub исторически находится в выгодном положении и прилагает много усилий для удовлетворения потребностей сообщества открытого исходного кода.

Сегодня, когда вы будете искать какую-либо библиотеку, вы в 99% случаев найдете ее на GitHub.

Помимо открытого исходного кода, многие разработчики также размещают частные репозитории на GitHub из-за удобства платформы.

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

GitHub Issues

GitHub Issues – одна из наиболее популярных в мире систем отслеживания багов.

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

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

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

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

Социальное кодирование

Несколько лет назад в логотип GitHub входил слоган «социального кодирования».

Что это значит? Важен ли сейчас этот слоган? Конечно.

Подписки (Follow)

На GitHub можно подписаться на разработчика или репозиторий, зайдя в профиль пользователя и нажав «Подписаться» или нажав кнопку «Следить» в репозитории.

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

Звезды (Stars)

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

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

Крупные проекты могут иметь десятки тысяч звезд.

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

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

Ответвления (Fork)

Последний важный сетевой индикатор проекта — это количество ответвлений.

Это ключ к тому, как работает GitHub. Ответвление — это основа запроса на включение (PR), который является предложением об изменении. Человек может добавить ответвление к вашему репозиторию, внести некоторые изменения, а затем создать запрос на включение, чтобы попросить вас объединить эти изменения в исходник.

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

Чем популярнее, тем лучше

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

Топ-пост этого месяца:  Правила обработки пользовательских данных интернет-магазинами

Запросы на включение (Pull requests)

В предыдущем разделе я объяснил, что такое запрос на включение (PR). Повторим: человек может добавить расширение к вашему репозиторию, внести некоторые изменения, а затем создать запрос на включение, чтобы попросить вас объединить эти изменения.

Проект может иметь сотни PR. Как правило, чем популярнее проект, тем больше PR. Например, в проекте React:

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

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

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

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

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

Управление проектами (Project management)

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

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

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

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

Представив релизы, GitHub расширил функциональность тегов GIT.

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

Релиз GitHub построен на основе тегов GIT и представляет собой полную версию вашего кода, а также zip-файлы, заметки о выпуске и двоичные ресурсы, которые могут представить полностью рабочую версию конечного продукта кода.

Хотя тег GIT можно создавать программно (например, с помощью тега git из командной строки), создание релизов GitHub – это ручной процесс, который происходит в пользовательском интерфейсе GitHub. Вы, по сути, говорите GitHub создать новый релиз и сообщаете, к какому тегу вы хотите применить его.

Сравнение коммитов

GitHub предлагает множество инструментов для работы с кодом.

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

GitHub позволяет вам делать это с compare view: просто добавьте /compare в конец имени репозитория.

На рисунке ниже я сравниваю последнюю версию React v15.x с последней версией v16.0.0-rc, доступной на момент написания этой статьи, чтобы увидеть, что изменилось.

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

Webhooks и Services

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

Webhooks

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

Когда происходит событие, GitHub отправляет запрос POST на URL, который мы говорим ему использовать.

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

Мы отправляем команду push к GitHub, GitHub сообщает серверу об этом, и сервер извлекает данные из GitHub.

Services

Сервисы GitHub и новые приложения GitHub представляют собой сторонние интеграции, которые улучшают работу разработчика или предоставляют услуги.

Например, вы можете установить исполнитель тестов для автоматического запуска тестов каждый раз, когда вы делаете новые коммиты. Здесь поможет TravisCI .

Можно настроить непрерывную интеграцию с помощью CircleCI .

Можно создать интеграцию Codeclimate , которая анализирует код и предоставляет отчет «Техническая задолженность» и покрытие тестирования.

Заключение

GitHub — это замечательный инструмент и сервис, которым можно воспользоваться. Это настоящий драгоценный камень в современном наборе инструментов для разработчиков. Данное руководство поможет вам начать работу. Реальный опыт управления проектами с открытым или закрытым исходным кодом GitHub (как пользоваться им, показано во многих статьях) — это то, что нельзя упустить.

Изучаем JavaScript

Урок 5. Работа с Git

  • Получить ссылку
  • Facebook
  • Twitter
  • Pinterest
  • Электронная почта
  • Другие приложения

Git позволяет работать с github, а github хранить свои файлы в репозитории и работать над ними вместе с кем-то.

Дополнено 13.06
Как клонировать существующий репозиторий и отслеживать в нём изменения через git

1. Склонировать репозиторий

3. Проверить текущий статус
$ git status

Запускаем команду, показывающую список всех настроек

$ git config —list // список всех настроек

Последовательно вводим команды

git config —global user.name «name» // записываем в настройки свое имя
git config —global user.email «[email protected]» // записываем в настройки свой e-mail

Создаём репозиторий на гитхабе, создаём папку проекта на компьютере, открываем её через git, вводим команду

В папке проекта появляется скрытая папка .git

Затем нам нужно связать папку проекта с репозиторием. Вводим команду

$ git remote add origin https://github.com/irinainina/test

Теперь создаём в репозитории какие-то файлы и вводим команду

$ git add «название файла»

Файл стал отслеживаться

Если введём команду

отслеживаемые файлы будут выделены зелёным цветом

Вводим команду

$ git commit -m «название файла»

Добавляем файл в репозиторий

$ git push -u origin master

Команда добавляющий все новые и изменённые файлы в отслеживаемые:

Добавляет изменения в репозиторий команда

git config —list — список всех настроек
git config —global user.name «John Doe» — записываем в настройки свое имя
git config —global user.email «[email protected]» — записываем в настройки свой e-mail

git status — проверяем какие файлы были изменены/добавлены/удалены
git add index.html — готовим файл index для коммита
git add . — готовим все измененные файлы для коммита
git checkout index.html — отменяем внесенные изменения в файл до последнего коммита
git commit — комитим изменения в репозиторий
git push — загружаем изменения в удаленный репозиторий
git pull — скачиваем изменения из удаленного репозитория

git branch test-case — создаем ветку test-case
git checkout test-case — переходим в ветку test-case
git checkout master — переходим в главную ветку
git checkout -b test-case — создаем ветку test-case и сразу переходим в нее
git merge test-case — слияние ветке test-case
git branch — список веток
git branch -d test-case — удаление ветки test-case

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

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

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

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

В состав Git’а входит утилита git config , которая позволяет просматривать и устанавливать параметры, контролирующие все аспекты работы Git’а и его внешний вид.

Эти параметры могут быть сохранены в трёх местах:

  • Уровень системы: файл /etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске git config указать параметр —system , то параметры будут читаться и сохраняться именно в этот файл.
  • Уровень пользователя: файл

/.gitconfig хранит настройки конкретного пользователя. Этот файл используется при указании параметра —global .

  • Уровень проекта: конфигурационный файл в каталоге Git’а ( .git/config ) в том репозитории, где вы находитесь в данный момент. Эти параметры действуют только для данного конкретного репозитория. Настройки на каждом следующем уровне подменяют настройки из предыдущих уровней, то есть значения в .git/config перекрывают соответствующие значения в /etc/gitconfig .
  • В системах семейства Windows Git ищет файл .gitconfig в каталоге $HOME ( C:\Documents and Settings\$USER или C:\Users\$USER для большинства пользователей). Кроме того Git ищет файл /etc/gitconfig , но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git, когда запускали инсталлятор.

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

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

    Вы указали своё имя, и теперь можно выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git’е. По умолчанию Git использует стандартный редактор вашей системы, обычно это Vi или Vim. Если вы хотите использовать другой текстовый редактор, например, Emacs, можно сделать следующее:

    Я в своей работе использую Vim, поэтому верну обратно этот редактор

    Другая полезная настройка, которая может понадобиться — встроенная diff-утилита, которая будет использоваться для разрешения конфликтов слияния. Например, если вы хотите использовать vimdiff:

    Git умеет делать слияния при помощи kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge и opendiff, но вы можете настроить и другую утилиту.

    Если вы хотите проверить используемые настройки, можете использовать команду git config —list , чтобы показать все, которые Git найдёт:

    Некоторые ключи (названия) настроек могут появиться несколько раз, потому что Git читает один и тот же ключ из разных файлов (например из /etc/gitconfig и

    /.gitconfig). В этом случае Git использует последнее значение для каждого ключа.

    Также вы можете проверить значение конкретного ключа, выполнив git config <ключ>:

    Для создания Git-репозитория существуют два основных подхода. Первый подход — импорт в Git уже существующего проекта или каталога. Второй — клонирование уже существующего репозитория с сервера.

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

    Эта команда создаёт в текущем каталоге новый подкаталог с именем .git содержащий все необходимые файлы репозитория — основу Git-репозитория. На этом этапе ваш проект ещё не находится под версионным контролем. Это отчетливо видно, если выполнить команду

    В моем случае вывод команды такой:

    Это означает, что я нахожуть в ветке, под названием master (ветка по-умолчанию), был выполнен автоматический коммит пустой директории (об этом говорит фраза “Initial commit”), и перечислен спискок файлов и директорий, которые сейчас не находятся под контролем Git. А также, сказано, что мы еще не подготовили данные для коммита.

    К тому же, если выпонить комманду

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

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

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

    Таким образом, в проектах, использующих Git, есть три части:

    • каталог Git’а (Git directory),
    • рабочий каталог (working directory),
    • область подготовленных файлов (staging area).

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

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

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

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

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

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

    Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит проиндексировать эти файлы и осуществить первую фиксацию изменений. Осуществить это вы можете с помощью команды git add <индексируемый файл>, а затем git commit:

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

    Вывод результатов выполнения команд в Git крайне лаконичен и информативен. В данном случае было сказано что мы выполнили коммит в ветку “master”, этот коммит является первым (root-commit), хеш коммит (его краткая запись) — “f234b65”, commit-message — “Initial project version”, статистика о добавленной информации: суммарное количtство измененных файлов, добавленных и удаленных строк в них, а также перечень созданных файлов.

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

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

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

    Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда git status. Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого:

    Это означает, что у вас чистый рабочий каталог, другими словами — в нём нет отслеживаемых изменённых файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. И наконец, команда сообщает вам на какой ветке (branch) вы сейчас находитесь. Пока что это всегда ветка master — это ветка по умолчанию. Предположим, вы добавили в свой проект новый файл, простой файл CHANGELOG. Если этого файла раньше не было, и вы выполните git status, вы увидите свой неотслеживаемый файл вот так:

    Понять, что новый файл CHANGELOG неотслеживаемый можно по тому, что он находится в секции «Untracked files» в выводе команды status. Статус «неотслеживаемый файл», по сути, означает, что Git видит файл, отсутствующий в предыдущем снимке состояния (коммите); Git не станет добавлять его в ваши коммиты, пока вы его явно об этом не попросите. Это предохранит вас от случайного добавления в репозиторий сгенерированных бинарных файлов или каких-либо других, которые вы и не думали добавлять. Мы хотели добавить CHANGELOG, так давайте сделаем это. Для того чтобы начать отслеживать (добавить под версионный контроль) новый файл, используется команда git add. Чтобы начать отслеживание файла CHANGELOG, вы можете выполнить следующее:

    Если вы снова выполните команду status, то увидите, что файл CHANGELOG теперь отслеживаемый и индексированный:

    Вы можете видеть, что файл проиндексирован по тому, что он находится в секции “Changes to be committed”. Если вы выполните коммит в этот момент, то версия файла, существовавшая на момент выполнения вами команды git add, будет добавлена в историю снимков состояния. Как вы помните, когда вы ранее выполнили git init, вы затем выполнили git add (файлы) — это было сделано для того, чтобы добавить файлы в вашем каталоге под версионный контроль. Команда git add принимает параметром путь к файлу или каталогу, если это каталог, команда рекурсивно добавляет (индексирует) все файлы в данном каталоге.

    Давайте модифицируем файл, уже находящийся под версионным контролем. Если вы измените отслеживаемый файл README и после этого снова выполните команду git status, то результат будет примерно следующим:

    Файл README находится в секции “Changes not staged for commit” — это означает, что отслеживаемый файл был изменён в рабочем каталоге, но пока не проиндексирован. Чтобы проиндексировать его, необходимо выполнить команду git add (это многофункциональная команда, она используется для добавления под версионный контроль новых файлов, для индексации изменений, а также для других целей, например для указания файлов с исправленным конфликтом слияния). Выполним git add, чтобы проиндексировать README, а затем снова выполним git status:

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

    Теперь README отображается как проиндексированный и непроиндексированный одновременно. Как такое возможно? Такая ситуация наглядно демонстрирует, что Git индексирует файл в точности в том состоянии, в котором он находился, когда вы выполнили команду git add. Если вы выполните коммит сейчас, то файл README попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду git add, а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения git commit. Если вы изменили файл после выполнения git add, вам придётся снова выполнить git add, чтобы проиндексировать последнюю версию файла:

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

    Первая строка предписывает Git’у игнорировать любые файлы заканчивающиеся на .o или .a — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (

    ), которая используется во многих текстовых редакторах, например Emacs, для обозначения временных файлов. Вы можете также включить каталоги log, tmp или pid; автоматически создаваемую документацию; и т.д. и т.п. Хорошая практика заключается в настройке файла .gitignore до того, как начать серьёзно работать, это защитит вас от случайного добавления в репозиторий файлов, которых вы там видеть не хотите.

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

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

    Если вам нужна помощь при использовании Git’а, есть три способа открыть страницу руководства по любой команде Git’а:

    Например, так можно открыть руководство по команде config:

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

    Добавить комментарий