Как настроить git

Git для начинающих. Урок 1.
Установка и базовая настройка git

Видеоурок. Часть 1. Практика. Установка и настройка git

Видеоурок. Часть 2

• Система подсказок и помощи Git
• Локальные настройки
• Почему первые 2 урока работаем в терминале
• Почему уроки в Windows
• Чем git bash отличается от стандартной командной строки
• Какие утилиты есть кроме git bash
• Что еще интересного есть на git-scm.com

Конспект урока

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Как установить git

В MacOS и Windows ставится через стандартные установщики, в Linux — командой в терминале. Например, если работаете в Debian/Ubuntu/Mint, то

 sudo apt install git 

Linux или MacOS

Git прекрасно работает в этих ОС и его функционал доступен из терминала (командной строки)

Windows

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

Графические инструменты Windows мы рассматривать не будем. Вместо них воспользуемся популярной IDE от JetBrains — PhpStorm.

Почему в уроках Windows

По одной причине — удобство записи видеоуроков. А так я предпочитаю работать в Linux Mint.

Командная строка

В Linux и Mac запускаем команды git из стандартного терминала. В Windows будем использовать утилиту git bash, которая поставляется вместе с установщиком git под Windows. Мы будем работать и в терминале, и в PhpStorm, но некоторые вещи проще делать именно в терминале.

Первые 2 урока (установка и репозитории) мы делаем только в терминале, потому что команд мало и они простые.

Базовая настройка git

Проверим корректность установки git, набрав в командной строке

 $ git --version git version 2.7.4 

Глобальные настройки git задаются командой

 git config --global parameter "value" 

Для начала нас интересуют только 2 настройки: имя и почта, под которыми нас будут видеть сам git и наши коллеги

 git config --global user.name "Aleksandr Shestakov" git config --global user.email "webdevkin@gmail.com" 

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

 $ git config --list user.name=Aleksandr Shestakov user.email=webdevkin@gmail.com 

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

Дружелюбность git

Git очень дружелюбен в плане подсказок в командной строке.

• git —help — общая документация по git
• git log —help — документация по конкретной команде (в нашем случае log)
• Опечатались — git подскажет правильную команду
• После выполнения команд — краткий отчет, что было сделано
• git подсказывает, что делать дальше

Конечно, все подсказки на английском.

Что могу посоветовать

• Работать в Linux или MacOS. В Windows вполне можно работать с git, но иногда бывают проблемы с кириллицей. К тому же я не знаю ни одного программиста, кто ушел с Windows и разочаровался в этом
• На первых порах работать с git в графическом интерфейсе PhpStorm, но пробовать и постепенно переходить на командную строку. Работа в терминале поможет лучше понять, как устроен git.
• Присмотреться к другим оболочкам, например, zsh
• Не заморачиваться с настройками git config. Базовые мы задали, остальные изучатся по мере необходимости
• Посмотреть на git-scm.com/downloads/guis, там много интересных графических утилит для работы с Git. Но попозже 🙂

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

Спасибо за внимание и до встречи!

Все уроки курса

• Вводный урок
• 1. Установка и базовая настройка git
• 2. Создание и клонирование репозитория git
• 3. Делаем первые изменения, git status и git diff
• 4. Коммиты и история коммитов, git commit, git log и git show
• 5. Подробнее об истории коммитов. Путешествие по истории
• 6. Работа с сервером, git push и git pull
• 7. Ветки — главная фишка git, git branch и git checkout
• 8. Работа с ветками на сервере, git fetch
• 9. Слияния или мерджи веток, git merge
• 10. Конфликты и их разрешение
• Платная часть курса. Презентация
• * 11. Работа с gitignore и git exclude
• * 12. Буфер обмена git, git stash
• * 13. Копирование коммитов, git cherry-pick
• * 14. Отмена и редактирование последнего коммита
• * 15. Отмена произвольного коммита, git revert
• 16. Склеивание коммитов, git rebase —interactive и git reflog
• * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
• * 18. Работа с git rebase. Отличия от merge
• * 19. Что такое git push —force и как с ним работать
• * 20. Ищем баги с помощью git, git bisect
• * 21. Как и зачем работать с тегами git
• * 22. Процессы: github flow и git flow
• * 23. Псевдонимы в git
• 24. Мердж-реквесты
• * 25. Форки

Настройка Git

At the heart of GitHub is an open-source version control system (VCS) called Git. Git is responsible for everything GitHub-related that happens locally on your computer.

С помощью Git

Для работы с Git в командной строке необходимо скачать, установить и настроить Git на компьютере. Также вы можете установить GitHub CLI для работы с GitHub из командной строки. Дополнительные сведения см. в разделе «AUTOTITLE».

Если вы хотите работать с Git локально, но не хотите использовать командную строку, вы можете скачать и установить клиент GitHub Desktop . Дополнительные сведения см. в разделе «AUTOTITLE».

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

• Создание репозитория
• Создание вилки репозитория
• Управление файлами
• Взаимодействие с сообществом

Настройка Git

1. Установите на устройство с Chrome OS эмулятор терминала, например Termux, из Google Play Маркет.
2. Установите Git из установленного эмулятора терминала. Например, в Termux введите apt install git и затем y при появлении запроса.

Проверка подлинности с помощью GitHub из Git

При подключении к репозиторию GitHub из Git необходимо пройти проверку подлинности в GitHub с использованием протокола HTTPS или SSH.

Примечание. Для проверки подлинности в GitHub можно использовать GitHub CLI для HTTP или SSH. Дополнительные сведения см. в разделе gh auth login .

Подключение по протоколу HTTPS (рекомендуется)

При клонировании по протоколу HTTPS вы можете кэшировать учетные данные GitHub в Git с помощью вспомогательного приложения для управления учетными данными. Дополнительные сведения см. в разделе «[AUTOTITLE» и «Сведения об удаленных репозиториях](/get-started/getting-started-with-git/caching-your-github-credentials-in-git)».

Подключение по протоколу SSH

При клонировании по протоколу SSH необходимо создать ключи SSH на каждом компьютере, который будет использоваться для отправки или извлечения данных из GitHub. Дополнительные сведения см. в разделе «[AUTOTITLE» и «Сведения об удаленных репозиториях](/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent)».

Следующие шаги

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

• Создание репозитория для проекта позволяет хранить код на GitHub. Таким образом вы получаете резервную копию результатов работы, которую можно предоставить другим разработчикам. Дополнительные сведения см. в разделе Создание репозитория..
• Создание вилки репозитория позволит вносить изменения в другой репозиторий, не затрагивая исходный. Дополнительные сведения см. в разделе «AUTOTITLE».
• Каждый репозиторий на GitHub принадлежит пользователю или организации. Вы можете взаимодействовать с людьми, репозиториями и организациями, подписавшись на них на GitHub. Дополнительные сведения см. в разделе «AUTOTITLE».
• У GitHub большое сообщество поддержки, где можно обратиться за помощью и поговорить с людьми со всего мира. Присоединиться к беседе можно в GitHub Community.

8.1 Настройка Git — Конфигурация Git

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

Конфигурация Git

В главе Введение кратко упоминалось, что вы можете настроить Git, используя команду git config . Первое, что вы делали, это установили своё имя и e-mail адрес:

$ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com

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

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

Следующее место, куда смотрит Git — это файл ~/.gitconfig (или ~/.config/git/config ), который хранит настройки конкретного пользователя. Вы можете указать Git читать и писать в него, используя опцию —global .

Наконец, Git ищет параметры конфигурации в файле настроек в каталоге Git ( .git/config ) текущего репозитория. Эти значения относятся только к текущему репозиторию и доступны при передаче параметра —local команде git config . (Если уровень настроек не указан явно, то подразумевается локальный.)

Каждый из этих уровней (системный, глобальный, локальный) переопределяет значения предыдущего уровня, например, значения из .git/config важнее значений из /etc/gitconfig .

Примечание

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

Базовая конфигурация клиента

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

$ man git-config

Эта команда выведет список доступных настроек с довольно подробным описанием. Так же, соответствующую документацию можно найти здесь https://git-scm.com/docs/git-config.html.

core.editor

По умолчанию, Git использует ваш редактор по умолчанию ( $VISUAL или $EDITOR ), если значение не задано — переходит к использованию редактора vi при создании и редактировании сообщений коммитов или тегов. Чтобы изменить редактор по умолчанию, воспользуйтесь настройкой core.editor :

$ git config --global core.editor emacs

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

commit.template

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

Например, предположим что вы создали файл ~/.gitmessage.txt , который выглядит так:

Subject line (try to keep under 50 characters) Multi-line description of commit, feel free to be detailed. [Ticket: X]

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

Чтобы заставить Git отображать содержимое этого файла в редакторе каждый раз при выполнении команды git commit , следует установить значение параметра commit.template :

$ git config --global commit.template ~/.gitmessage.txt $ git commit

Теперь, при создании коммита, в вашем редакторе будет отображаться сообщение изменённого вида:

Subject line (try to keep under 50 characters) Multi-line description of commit, feel free to be detailed. [Ticket: X] # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use "git reset HEAD . " to unstage) # # modified: lib/test.rb # ~ ~ ".git/COMMIT_EDITMSG" 14L, 297C

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

core.pager

Данная настройка определяет какая программа будет использована для разбиения текста на страницы при выводе такой информации как log и diff . Вы можете указать more или любую другую (по умолчанию используется less ), а так же выключить совсем, установив пустое значение:

$ git config --global core.pager ''

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

user.signingkey

Если вы создаёте подписанные аннотированные теги (как описано в разделе Подпись главы 7), то установка GPG ключа в настройках облегчит вам задачу. Установить ключ можно следующим образом:

$ git config --global user.signingkey

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

$ git tag -s

core.excludesfile

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

Однако, иногда вам нужно игнорировать определённые файлы во всех ваших репозиториях. Если на вашем компьютере работает Mac OS X, вероятно вы знакомы с файлами .DS_Store . Если вы используете Emacs или Vim, то вы знаете про файлы, имена которых заканчиваются на ~ или .swp .

Данная настройка позволяет вам определить что-то вроде глобального файла .gitignore . Если вы создадите файл ~/.gitignore_global с содержанием:

*~ .*.swp .DS_Store

… и выполните команду git config —global core.excludesfile ~/.gitignore_global , то Git больше не потревожит вас на счёт этих файлов.

help.autocorrect

Если вы ошибётесь в написании команды, Git покажет вам что-то вроде этого:

$ git chekcout master git: 'chekcout' is not a git command. See 'git --help'. The most similar command is checkout

Git старается угадать, что вы имели ввиду, но при этом команду не выполняет. Если вы установите help.autocorrect в значение 1, то Git будет выполнять эту команду:

$ git chekcout master WARNING: You called a Git command named 'chekcout', which does not exist. Continuing under the assumption that you meant 'checkout' in 0.1 seconds automatically. 

Обратите внимание, что команда выполнилась через «0.1» секунды. help.autocorrect — это число, указываемое в десятых долях секунды. Поэтому, если вы установите значение 50, то Git даст вам 5 секунд изменить своё решение перед тем, как выполнить скорректированную команду.

Цвета в Git

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

color.ui

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

$ git config --global color.ui false

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

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

color.*

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

color.branch color.diff color.interactive color.status

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

$ git config --global color.diff.meta "blue black bold"

Для установки цвета доступны следующие значения: normal , black , red , green , yellow , blue , magenta , cyan , или white . Для указания атрибутов текста, как bold в предыдущем примере, доступны значения: bold , dim , ul (подчёркнутый), blink и reverse (поменять местами цвет фона и цвет текста).

Внешние программы слияния и сравнения

Хоть в Git и есть встроенная программа сравнения, которая описывается в этой книге, вы можете установить вместо неё другую. Вы также можете настроить графический инструмент разрешения конфликтов слияния вместо того, чтобы разрешать конфликты вручную. Мы покажем как настроить Perforce Visual Merge Tool (P4Merge) для разрешения конфликтов слияния, так как это прекрасный и бесплатный инструмент.

Если у вас есть желание попробовать P4Merge, то она работает на всех основных платформах, так что у вас должно получиться. В примерах мы будем использовать пути к файлам, которые работают в системах Linux и Mac; для Windows вам следует изменить /usr/local/bin на путь к исполняемому файлу у вас в системе.

Для начала скачайте P4Merge. Затем, создайте скрипты обёртки для вызова внешних программ. Мы будем использовать путь к исполняемому файлу в системе Mac; в других системах — это путь к файлу p4merge . Создайте скрипт с названием extMerge для вызова программы слияния и передачи ей заданных параметров:

$ cat /usr/local/bin/extMerge #!/bin/sh /Applications/p4merge.app/Contents/MacOS/p4merge $*

Скрипт вызова программы сравнения проверяет наличие 7 аргументов и передаёт 2 из них в скрипт вызова программы слияния. По умолчанию, Git передаёт следующие аргументы программе сравнения:

path old-file old-hex old-mode new-file new-hex new-mode

Так как вам нужны только old-file и new-file , следует использовать скрипт, который передаст только необходимые параметры.

$ cat /usr/local/bin/extDiff #!/bin/sh [ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"

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

$ sudo chmod +x /usr/local/bin/extMerge $ sudo chmod +x /usr/local/bin/extDiff

Теперь можно изменить файл конфигурации для использования ваших инструментов слияния и сравнения. Для этого необходимо изменить ряд настроек: merge.tool — чтобы сказать Git какую стратегию использовать, mergetool..cmd — чтобы сказать Git как запускать команду, mergetool..trustExitCode — чтобы сказать Git как интерпретировать код выхода из программы, diff.external — чтобы сказать Git какую команду использовать для сравнения. Таким образом, команду конфигурации нужно запустить четыре раза:

$ git config --global merge.tool extMerge $ git config --global mergetool.extMerge.cmd \ 'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"' $ git config --global mergetool.extMerge.trustExitCode false $ git config --global diff.external extDiff

или вручную отредактировать файл ~/.gitconfig добавив соответствующие строки:

[merge] tool = extMerge [mergetool "extMerge"] cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED" trustExitCode = false [diff] external = extDiff

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

$ git diff 32d1776b1^ 32d1776b1

Вместо отображения вывода diff в терминале Git запустит P4Merge, выглядеть это будет примерно так:

Рисунок 142. P4Merge

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

Используя скрипт обёртку для вызова внешних программ, вы можете легко изменить вызываемую программу. Например, чтобы начать использовать KDiff3 вместо P4Merge, достаточно изменить файл extMerge :

$ cat /usr/local/bin/extMerge #!/bin/sh /Applications/kdiff3.app/Contents/MacOS/kdiff3 $*

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

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

$ git mergetool --tool-help 'git mergetool --tool=' may be set to one of the following: emerge gvimdiff gvimdiff2 opendiff p4merge vimdiff vimdiff2 The following tools are valid, but not currently available: araxis bc3 codecompare deltawalker diffmerge diffuse ecmerge kdiff3 meld tkdiff tortoisemerge xxdiff Some of the tools listed above only work in a windowed environment. If run in a terminal-only session, they will fail.

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

$ git config --global merge.tool kdiff3

Если выполнить эту команду вместо настройки использования файлов extMerge и extDiff , то Git будет использовать KDiff3 для разрешения конфликтов слияния, а для сравнения — стандартную программу diff.

Форматирование и пробелы

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

core.autocrlf

Если вы программируете в Windows и работаете с людьми, которые не используют её (или наоборот), рано или поздно, вы столкнётесь с проблемами переноса строк. Это происходит потому, что Windows при создании файлов использует для обозначения переноса строки два символа «возврат каретки» и «перевод строки», в то время как Mac и Linux используют только один — «перевод строки». Это незначительный, но невероятно раздражающий факт кроссплатформенной работы; большинство редакторов в Windows молча заменяют переносы строк вида LF на CRLF или вставляют оба символа, когда пользователь нажимает клавишу ввод.

Git может автоматически конвертировать переносы строк CRLF в LF при добавлении файла в индекс и наоборот — при извлечении кода. Такое поведение можно включить используя настройку core.autocrlf . Если у вас Windows, то установите значение true — при извлечении кода LF окончания строк будут преобразовываться в CRLF:

$ git config --global core.autocrlf true

Если у вас система Linux или Mac, то вам не нужно автоматически конвертировать переносы строк при извлечении файлов; однако, если файл с CRLF окончаниями строк случайно попал в репозиторий, то Git может его исправить. Можно указать Git конвертировать CRLF в LF во время коммита, но не наоборот, установив настройке core.autocrlf значение input :

$ git config --global core.autocrlf input

Такая конфигурация позволит вам использовать CRLF переносы строк в Windows, при этом в репозитории и системах Mac и Linux будет использован LF.

Если вы используете Windows и программируете только для Windows, то вы можете отключить описанный функционал задав значение false , сохраняя при этом CR символы в репозитории:

$ git config --global core.autocrlf false

core.whitespace

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

Те, что включены по умолчанию — это blank-at-eol , что ищет пробелы в конце строки; blank-at-eof , что ищет пробелы в конце файла; и space-before-tab , что ищет пробелы перед символом табуляции в начале строки.

Те, что выключены по умолчанию — это indent-with-non-tab , что ищет строки с пробелами вначале вместо символа табуляции (и контролируется настройкой tabwidth ); tab-in-indent , что ищет символы табуляции в отступах в начале строки; и cr-at-eol , которая указывает Git на валидность наличия CR в конце строки.

Указав через запятую значения для настройки core.whitespace , можно сказать Git какие из этих опций должны быть включены. Чтобы отключить ненужные проверки, достаточно удалить их из строки значений или поставить знак — перед каждой из них. Например, чтобы включить все проверки, кроме space-before-tab , выполните команду (при этом trailing-space является сокращением и охватывает как blank-at-eol , так и blank-at-eof ):

$ git config --global core.whitespace \ trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

Или можно указать только часть проверок:

$ git config --global core.whitespace \ -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

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

$ git apply --whitespace=warn

Так же можно указать Git автоматически исправлять эти проблемы перед применением патча:

$ git apply --whitespace=fix

Эти настройки так же применяются при выполнении команды git rebase . Если проблемные пробелы попали в коммит, но ещё не отправлены в удалённую ветку, можно выполнить git rebase —whitespace=fix для автоматического исправления этих проблем.

Конфигурация сервера

Для серверной части Git не так много настроек, но есть несколько интересных, на которые стоит обратить внимание.

receive.fsckObjects

Git способен убедиться, что каждый объект, отправленный командой push , валиден и соответствует своему SHA-1-хешу. По умолчанию эта функция отключена; это очень дорогая операция и может привести к существенному замедлению, особенно для больших объёмов отправляемых данных или для больших репозиториев. Вы можете включить проверку целостности объектов для каждой операции отправки, установив значение receive.fsckObjects в true :

$ git config --system receive.fsckObjects true

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

receive.denyNonFastForwards

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

Для запрета перезаписи истории установите receive.denyNonFastForwards :

$ git config --system receive.denyNonFastForwards true

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

receive.denyDeletes

Политику denyNonFastForwards можно обойти, удалив ветку и создав новую с таким же именем. Для предотвращения этого, установите receive.denyDeletes в значение true :

$ git config --system receive.denyDeletes true

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

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

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

Для работы с Git можно скачать готовые GUI — наглядные графические интерфейсы для управления репозиторием, например GitKraken или GitHub Desktop. Это отличное решение для новичка, но потом все, как правило, переходят на консоль.

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

Как установить Git

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

На iOS он чаще всего идёт из коробки: чтобы найти его, нужно открыть терминал и набрать git —version:

Если вдруг его у вас нет, можно воспользоваться менеджером недостающих пакетов для macOS — Homebrew. Для установки пропишите в консоли brew install git.

Чтобы использовать Git на системе Linux, нужно поставить пакет Git. Например, для установки на Ubuntu нужно будет прописать sudo apt install git.

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

После того как скачаете его, запустите установщик:

Для скорости можно не менять дефолтные настройки и прокликать Next:

Теперь вы можете использовать на Windows такую же консоль, как и на iOS:

Все описанные ниже команды будут работать как в терминале на iOS и Linux, так и в Windows.

Регистрация в Git

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

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

git config —global user.name «user-name»

git config —global user.email email@example.com

Вместо user-name подставьте логин, который указывали при регистрации. В нашем случае это test-github-04, а вместо email@example.com — адрес вашей электронной почты. В нашем примере — testgithub@gmail.com.

Если вы всё сделали по инструкции, то при выполнении команды git config —list отобразится ваше имя пользователя:

Не забудьте верифицировать аккаунт: откройте первое письмо на почте от GitHub и пройдите по ссылке. Иначе вы не сможете создавать репозитории.

Как опубликовать первый проект на Git

Зайдите в ваш профиль: для этого кликните по иконке в правом верхнем углу и нажмите Your Profile:

Теперь создайте репозиторий: перейдите во вкладку Repositories и кликните по кнопке New:

Задайте имя репозитория. Мы придумали название проекта test-github и сделали его публичным, чтобы его могли просматривать все пользователи. Далее нажмите кнопку Create repository:

Пока проект пустой, но мы можем поместить в него наши файлы с локальной машины.

Будем использовать протокол HTTPS — с ним проще работать с Git, чем с SSH. Подробнее про различия протоколов можно прочитать в документации.
Github предлагает несколько вариантов создания проекта:

• клонировать папку по выбранному протоколу;
• создать проект с нуля — сегодня мы рассмотрим именно этот способ;
• опубликовать уже созданный проект;
• скопировать проект.

Создание проекта с нуля

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

Команда echo «# test-github» >> README.md добавляет новый файл в проект. Его также можно создать вручную в папке.

git init — инициализирует проект. После инициализации создаётся специальная скрытая папка для Git:

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

git add README.md — добавляет изменённые файлы к коммиту. Также это можно сделать при помощи команды git add . — в таком случае вы добавите не конкретные файлы, а все изменённые, если их много:

git status поможет проверить, что происходит с изменёнными файлами. В нашем случае, например, файлы не прикреплены к коммиту:

git commit -m «first commit» добавляет сообщение к коммиту — то, что будет отображаться в истории. В скобках можно указать любой текст. Как правило, в нём кратко описывают, что делали в коммите.

Теперь снова посмотрим, что скажет git status. Сейчас он пустой, так как все изменённые файлы мы прикрепили к только что созданному коммиту:

git log показывает историю коммитов:

git branch позволяет просмотреть ветки. В нашем примере текущая ветка называется master. Но с 2020 года GitHub выступает за то, чтобы главная ветка называлась main (по политическим причинам) и рекомендует переименовать ветку с помощью команды git branch -M main.

Команда git remote add origin https://github.com/test-github-04/test-github.git добавляет сервер, где origin — это имя сервера, а url — это адрес.

У вас может быть несколько удалённых серверов, с которыми работает проект. Проверить добавленные сервера можно командой git remote -v (fetch — откуда забирать, push — куда отправлять изменения).

git push -u origin main позволяет запушить (отправить) ветку main на сервер origin. Тут вам, скорее всего, потребуется связать приложение и GitHub, повторно залогинившись через браузер.

И теперь вас можно поздравить с первым опубликованным проектом!

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