Знакомство с git и github: руководство для начинающих

Порядок действий

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

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

How it works

At a high-level, Git can be thought of as a timeline management utility. Commits are the core building block units of a Git project timeline. Commits can be thought of as snapshots or milestones along the timeline of a Git project. Commits are created with the command to capture the state of a project at that point in time. Git Snapshots are always committed to the local repository. This is fundamentally different from SVN, wherein the working copy is committed to the central repository. In contrast, Git doesn’t force you to interact with the central repository until you’re ready. Just as the staging area is a buffer between the working directory and the project history, each developer’s local repository is a buffer between their contributions and the central repository.

This changes the basic development model for Git users. Instead of making a change and committing it directly to the central repo, Git developers have the opportunity to accumulate commits in their local repo. This has many advantages over SVN-style collaboration: it makes it easier to split up a feature into atomic commits, keep related commits grouped together, and clean up local history before publishing it to the central repository. It also lets developers work in an isolated environment, deferring integration until they’re at a convenient point to merge with other users. While isolation and deferred integration are individually beneficial, it is in a team’s best interest to integrate frequently and in small units. For more information regarding best practices for Git team collaboration read how teams structure their Git workflow.

URL de repositorios

Git admite numerosas formas de hacer referencia a un repositorio remoto. Una de las maneras más fáciles de acceder a uno de ellos es a través de los protocolos HTTP y SSH. El protocolo HTTP brinda un acceso sencillo, anónimo y de solo lectura a un repositorio. Por ejemplo:

Sin embargo, por lo general, no se pueden enviar confirmaciones a una dirección HTTP (de todos modos, no convendría permitir envíos anónimos). Para acceder con permisos de lectura y escritura, debes usar SSH en su lugar:

Necesitarás una cuenta SSH válida en el equipo host, pero, aparte de eso, Git admite el acceso autenticado mediante SSH listo para usarse. Las modernas y seguras soluciones de alojamiento de terceros, como Bitbucket.com, te proporcionarán estas URL.

Порядок действий

Сначала команда запускает команду для загрузки содержимого из указанного удаленного репозитория. Затем выполняется команда , осуществляющая слияние ссылок и указателей удаленного содержимого в новый локальный коммит. Чтобы лучше продемонстрировать процесс извлечения и слияния, рассмотрим пример. Предположим, у нас есть репозиторий с главной веткой master и удаленной веткой remote origin.

В этом сценарии команда загрузит все изменения, начиная с того места, где разошлись локальная и главная ветки. В данном примере это точка E. Команда получит удаленные коммиты из отходящей ветки (т. е. точки A‑B‑C). Затем в процессе запуска команды pull будет создан новый локальный коммит слияния, включающий содержимое новых удаленных коммитов из отходящей ветки.

На вышеприведенной схеме мы видим новый коммит H. Это коммит слияния, в который входит содержимое удаленных коммитов A‑B‑C и который имеет общее сообщение в журнале. Этот пример демонстрирует одну из нескольких стратегий слияния с помощью команды . Чтобы сделать перебазирование, а не коммит слитого содержимого, укажите для команды параметр . В следующем примере демонстрируется, как работает перебазирование с помощью команды pull. Предположим, что мы находимся в начальной точке нашей первой схемы и выполнили команду .

На этой схеме видно, что при перебазировании с помощью команды pull не был создан новый коммит H. Вместо этого удаленные коммиты A‑B‑C были скопированы и добавлены в историю в виде коммита в локальной ветке origin/master с перезаписью локальных коммитов E–F–G.

Коммит под любым другим именем…

• Имя ветки кода (branchname) — Как было сказано выше, имя любой ветки — просто псевдоним самого недавнего коммита в эту ветку. Это равносильно использованию слова HEAD при выборе данной ветки.
• Имя тэга (tagname) — Также, как и имя ветки — это имя коммита. Единственная разница — имя тэга никогда не меняется, в то время как имя ветки изменяется каждый раз при поступлении туда нового коммита.
• HEAD — Алиас названия текущего выбранного коммита. Если вы выбираете определенный коммит — вместо имени ветки, то HEAD ссылается исключительно на него, а не на имя ветки. Это — специальный случай, называемый “использование отделенной головы” (я уверен, что тут должна быть какая-нибудь шутка).
• c82a22c39cbc32… — К коммиту можно всегда обратиться по его полному, 40-символьному хэш-id Обычно это происходит во время копирования и вставки, т.к. обычно для этого есть другие, более удобные способы.
• c82a22c — Вам необходимо использовать только ту часть хэш-id, которая однозначно идентифицирует коммит в репозитории. Обычно для этого достаточно 6-7 цифр.
• name^ — Для ссылки на родителя любого коммита используется символ ^. В случае, когда у коммита более одного родителя (коммит слияния), берется первый из них. Если вам требуется n-ый родитель, то обратиться к нему можно как name^n
• name^^ — Родитель родителя данного коммита. Эту последовательность можно продолжить…
• name~10 — …. но не нужно. Чтобы обратиться к n-предку данного коммита используется ~n (что эквивалентно n символам ^ подряд)
• name:path — Для обращения к определенному файлу внутри дерева коммита, укажите имя файла после двоеточия. Это бывает полезно для команды show или для сравнения двух версий файла между коммитами:
• name^{tree} — Вы можете обратиться не к самому коммиту, а к содержащему его дереву.
• name1..name2 — Это и последующие наименования относятся к диапазону коммитов и очень полезны в командах типа log для просмотра изменений, сделанных в выбранный промежуток времени.
  В данном случае команда адресует все предшествующие коммиты начиная с name2 вплоть до (но не включительно!) name1. Если одно из этих имен будет опущено, то вместо него используется HEAD
• name1…name2 — Троеточие в диапазоне — совсем не то, что две точки. Для команд типа log оно обозначает все коммиты, на которые ссылаются или name1 или name2, но не оба сразу. Результат — это список уникальных коммитов в обеих ветках.
• —since=«2 weeks ago» — Адресует все коммиты, начиная с заданной даты
• —until=«1 week ago» — Адресует все коммиты, вплоть до заданной даты
• —grep=pattern — Адресует все коммиты, чье сообщение подходит под заданный шаблон регулярного выражения
• —committer=pattern — Адресует все коммиты, внесенные в репозиторий человеком, информация о котором подходит под заданный шаблон
• —author=pattern — Адресует все коммиты, информация об авторе которых подходит под заданный шаблон. Автор коммита — это создатель изменений, которые коммит представляет. Для локальной разработки это — тот же самый человек, который вносит коммит. Но когда патчи посылаются по почте, автор и человек, реально совершающий коммит обычно отличаются.
• —no-merges — Адресует все коммиты с единственным родителем, т.е. игнорирует коммиты слияния

Git commit vs SVN commit

While they share the same name, is nothing like . This shared term can be a point of confusion for Git newcomers who have a svn background, and it is important to emphasize the difference. To compare vs is to compare a centralized application model (svn) vs a distributed application model (Git). In SVN, a commit pushes changes from the local SVN client, to a remote centralized shared SVN repository. In Git, repositories are distributed, Snapshots are committed to the local repository, and this requires absolutely no interaction with other Git repositories. Git commits can later be pushed to arbitrary remote repositories.

Common options

Commit the staged snapshot. This will launch a text editor prompting you for a commit message. After you’ve entered a message, save the file and close the editor to create the actual commit.

Commit a snapshot of all changes in the working directory. This only includes modifications to tracked files (those that have been added with at some point in their history).

A shortcut command that immediately creates a commit with a passed commit message. By default, will open up the locally configured text editor, and prompt for a commit message to be entered. Passing the option will forgo the text editor prompt in-favor of an inline message.

A power user shortcut command that combines the and options. This combination immediately creates a commit of all the staged changes and takes an inline commit message.

This option adds another level of functionality to the commit command. Passing this option will modify the last commit. Instead of creating a new commit, staged changes will be added to the previous commit. This command will open up the system’s configured text editor and prompt to change the previously specified commit message.

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

Для начала определим, что такое система контроля версий.

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

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

Одна из самых популярных систем называется Git. Её отличие от других программ — отсутствие графической версии. Поэтому работа с Git ведётся через командную строку. В разных операционных системах свои программы для взаимодействия с Git.

В Windows их две: PowerShell и cmd.exe. В Ubuntu это Terminal. Самая популярная программа на macOS тоже называется Terminal. Если вам не подходит встроенная в систему программа для работы с командной строкой, вы можете поставить свою. Например, написанную на JavaScript программу Hyper, которая работает на любой операционной системе. На Windows популярны программы Cmder и Git Bash, а на macOS — iTerm.

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

Устанавливаем Git

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

Установка в Linux

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

• Если у вас 21 или более ранняя версия Fedora, используйте .
• Для 22 и последующих версий Fedora вводите .
• Для дистрибутивов, основанных на Debian, например, Ubuntu, используйте .

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

Установка на macOS

1. Скачиваем Git со страницы проекта.
2. Запускаем загруженный файл.
3. Система может показать окно с ошибкой, где будет написано, что файл скачан с неавторизованного сайта и инсталлятор не может быть запущен. В таком случае нужно зайти в «Системные настройки» — «Безопасность» (Security and Privacy), в появившемся окне будет сообщение об ошибке и кнопка Open anyway (Всё равно открыть). Нажимаем.
4. Система покажет окно, уточняющее хотите ли вы запустить установку. Подтверждаем действие.
5. Установщик проведёт через все необходимые шаги.

Установка в Windows

Скачайте exe-файл инсталлятора с сайта Git и запустите его. Это Git для Windows, он называется msysGit. Установщик спросит добавлять ли в меню проводника возможность запуска файлов с помощью Git Bash (консольная версия) и GUI (графическая версия). Подтвердите действие, чтобы далее вести работу через консоль в Git Bash. Остальные пункты можно оставить по умолчанию.

Проверим, что Git установлен

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

Настройка Git

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

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

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

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

Публикация в чистые репозитории

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

Использование git push

Публикация указанной ветки в удаленном репозитории <remote> вместе со всеми необходимыми коммитами и внутренними объектами. Эта команда создает локальную ветку в репозитории назначения. Чтобы предотвратить перезапись коммитов, Git не позволит опубликовать данные, если в репозитории назначения нельзя выполнить ускоренное слияние.

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

Публикация всех локальных веток в указанном удаленном репозитории.

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

Creación y modificación de configuraciones de git remote

El comando es también un método sencillo y útil para modificar el archivo de un repositorio. Los comandos que se presentan a continuación te permiten gestionar las conexiones con otros repositorios. Los siguientes comandos modificarán el archivo del repositorio. El resultado de dichos comandos también puede conseguirse editando directamente el archivo con un editor de texto.

Crea una nueva conexión a un repositorio remoto. Tras añadir el repositorio remoto, podrás usar <name> como un práctico atajo para <url> en otros comandos de Git.

Elimina la conexión con el repositorio remoto que lleva el nombre .

Cambia el nombre de una conexión remota de <old-name> a <new-name>.

Опасности перебазирования

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

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

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

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