Перейти на ветку в git через linux

Обновлено: 05.07.2024

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

Переключение веток аналогично переключению старых коммитов и файлов, в которых рабочий каталог обновляется в соответствии с выбранной веткой/ревизией; вместе с тем новые изменения сохраняются в истории проекта, то есть это не просто операция чтения.

Переключение веток

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

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

Иногда команду git checkout можно спутать с командой git clone . Разница между этими двумя командами заключается в том, что при клонировании (clone) выполняется извлечение кода из удаленного репозитория, тогда как при переключении (checkout) происходит переключение между версиями кода, который уже находится в локальной системе.

Использование: существующие ветки

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

В вышеприведенном примере показано, как просмотреть список доступных веток с помощью команды git branch и переключиться на конкретную ветку (в данном случае — на ветку feature_inprogress_branch ).

Новые ветки

Команда git checkout часто используется вместе с командой git branch . С помощью команды git branch можно создать новую ветку. Когда вы захотите начать работу над новой функцией, создайте новое ответвление от ветки main с помощью команды git branch new_branch . Затем переключитесь на новую ветку с помощью команды git checkout new_branch . Команда git checkout также принимает аргумент -b , который действует как вспомогательный метод, позволяя создать новую ветку и сразу переключиться на нее. Вы можете работать сразу с несколькими функциями в одном репозитории, переключаясь между ними с помощью git checkout .

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

По умолчанию команда git checkout -b создает ветку новая-ветка от текущего указателя HEAD . Команде git checkout можно передать необязательный параметр с указанием ветки. В приведенном выше примере передается ＜ существующая-ветка> , поэтому новая-ветка будет создана от ветки существующая-ветка , а не от текущего указателя HEAD .

Переключение веток

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

Git отслеживает историю операций переключения в журнале ссылок reflog. Чтобы просмотреть эту историю, выполните команду git reflog .

Переключение на удаленную ветку

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

В современных версиях Git переключение на удаленную ветку не отличается от переключения на локальную ветку.

В старых версиях Git необходимо создавать новую ветку на основе удаленного репозитория ( remote ).

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

Открепленные указатели HEAD

Теперь, когда мы рассмотрели три основных варианта использования команды git checkout на ветках, важно обсудить состояние detached HEAD , или состояние открепленного указателя HEAD. Помните, что HEAD — это указатель на текущий снимок в Git. По сути дела, команда git checkout просто обновляет указатель HEAD , чтобы он ссылался на указанную ветку или коммит. Когда HEAD указывает на ветку, Git молчит, но при попытке переключиться на коммит система переходит в состояние detached HEAD (открепленный указатель HEAD).

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

Резюме

Эта страница посвящена использованию команды git checkout при смене веток. В общем и целом при использовании команды git checkout на ветках происходит изменение ссылки в указателе HEAD . Эту команду можно использовать для создания веток, переключения между ветками и удаленными ветками. Команда git checkout — важный инструмент при стандартной работе в Git. Она представляет собой аналог команды git merge . Команды git checkout и git merge — критически важные инструменты для реализации рабочих процессов Git .

Перевод статьи «Git Switch Branch – How to Change the Branch in Git».

Пользуясь Git, вам очень часто придется перемещаться по веткам. Для этого используется команда git checkout.

Как создать новую ветку в Git и перейти в нее

Чтобы создать новую ветку, нужно использовать команду git checkout с флагом -b и указанием имени ветки. Таким образом вы создадите ответвление той ветки, в которой находитесь. История новой ветки начнется с момента ответвления.

Допустим, вы находитесь в ветке master :

Вы видите, что была создана новая ветка с именем my-feature . Она является ответвлением master . После создания новой ветки вы автоматически перешли в нее.

Как перейти в уже существующую ветку в Git

Чтобы перейти в уже существующую ветку, используйте ту же команду git checkout , но без добавления флага -b . Команде нужно передать имя ветки, в которую вы хотите перейти:

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

Как переместиться к определенному коммиту

Чтобы перейти к определенному коммиту, используйте ту же команду git checkout , но вместо имени ветки передайте ей SHA коммита.

Ветки по сути являются просто указателями трекерами отдельных коммитов в истории Git.

Как найти SHA коммита

В первой строке каждого коммита после слова commit есть длинная строка букв и цифр: 94ab1fe28727…

Вот она и называется SHA. Это уникальный идентификатор, генерируемый для каждого коммита.

Чтобы перейти к определенному коммиту, вам нужно лишь передать его SHA в качестве параметра команды git checkout :

Примечание: обычно можно использовать всего несколько первых символов SHA, потому что первые 4-5 символов скорее всего образуют уникальную комбинацию в рамках проекта.

Что такое detached HEAD (отсоединенный указатель HEAD)?

В результате перехода к конкретному коммиту вы указываетесь в «состоянии отсоединенного указателя HEAD» (« detached HEAD state »).

[a detached HEAD state] означает, что HEAD направлен на конкретный коммит, а не на именованную ветку.

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

«Вы в состоянии detached HEAD. Можете осмотреться, внести какие-нибудь экспериментальные изменения и закоммитить их. Если затем вы переключитесь обратно на ветку, вы сбросите все коммиты, сделанные в этом состоянии, никак не задев никакие ветки».

Исходя из этого, у вас есть два варианта:

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

Для возвращения в предыдущую ветку (со сбросом всех изменений) используйте команду git switch - .

Если вы все же хотите сохранить свои изменения, внесенные в состоянии detached HEAD, и продолжить работу с этого места, можете использовать git switch -c <имя-новой-ветки> , чтобы создать новую ветку из этой точки.

Заключение

Итак, вы получили задание: сделать форк вашего репозитория в GitHub, создать ветку и начать работу. Что за GitHub, какие команды, зачем, а главное, как всем этим пользоваться? Давайте разбираться.

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

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

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

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

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

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

Git — важный навык веб-разработчика

А лучший способ научиться программировать — профессия «React-разработчик». В программе три интенсива, прокачка навыков и оплачиваемая стажировка.

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

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

Установка в Windows

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

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

Установка в Linux

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

Если у вас 21 или более ранняя версия Fedora, используйте yum install git .
Для 22 и последующих версий Fedora вводите dnf install git .
Для дистрибутивов, основанных на Debian, например, Ubuntu, используйте apt-get: sudo apt-get install git .

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

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

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

Настройка Git

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

Откройте терминал и используйте следующую команду, чтобы добавить своё имя: git config --global user.name "ваше имя"

Для добавления почтового адреса вводите: git config --global user.email адрес

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

Что такое GitHub?

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

Чтобы начать работу с GitHub, нужно зарегистрироваться на сайте, если вы ещё этого не сделали. За дело.

Переходим на сайт GitHub. Cтартовая страница GitHub.
Для начала регистрации:
- Нажимаем кнопку Sign up (зарегистрироваться), попадаем на страницу регистрации, где вводим обязательные данные: имя пользователя, адрес электронной почты и пароль. После заполнения полей проходим верификацию. Первый шаг регистрации профиля на стартовой странице GitHub.
- После заполнения данных и успешного прохождения верификации нажимаем на кнопку Select a plan. Второй шаг регистрации профиля на стартовой странице GitHub.
Третий шаг — небольшой опрос от GitHub, который вы можете пройти, заполнив все поля и нажать Submit или пропустить, нажав skip this step. Опрос на третьем шаге регистрации.
После прохождения всех этапов на сайте, на указанный при регистрации ящик вам придёт письмо от GitHub. Откройте его и подтвердите свой почтовый адрес, нажав Verify email address (подтвердить электронный адрес) или скопируйте вспомогательную ссылку из письма и вставьте её в адресную строку браузера. Подтверждение электронного адреса.
После верификации GitHub предложит создать новый репозиторий, организацию или узнать больше о GitHub. Этот пункт пока можно пропустить и перейти в профиль. Переход в ваш профиль. Так выглядит ваш профиль после регистрации.

Теперь у вас есть профиль на GitHub.

Устанавливаем SSH-ключи

Git установлен, профиль на GitHub создан. Осталось добавить SSH-ключ и можно приступать к работе с проектом.

Что такое SSH-ключ и зачем он нужен?

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

Каждый SSH-ключ содержит пару: открытый (публичный) и закрытый (приватный) ключ. Открытый ключ отправляется на сервер, его можно не прятать от всех и не переживать, что кто-то его увидит и украдёт. Он бесполезен без своей пары — закрытого ключа. А вот закрытый ключ — секретная часть. Доступ к нему должен быть только у вас.

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

Чтобы пройти авторизацию по SSH-ключу, его надо сгенерировать или найти уже ранее созданный ключ на своём компьютере.

Сначала проверим, есть ли уже на компьютере ключ. По умолчанию SSH-ключи хранятся в каталоге

/.ssh , поэтому нужно проверить содержимое этого каталога.

Открываем консоль.
Вводим cd

Открываем консоль и вводим команду: Указываем тот адрес электронной почты, который вводили при регистрации на GitHub. Генерируем ключ.
Далее нужно указать расположение файла для сохранения ключа. Если вы не введёте путь до файла и просто нажмёте Enter, ключ сохранится в файле, указанном в скобках.
Теперь нужно установить пароль к вашему ключу и дважды ввести его. Если вы не хотите вводить пароль каждый раз, когда используете ключ, пропустите этот шаг, нажав «Enter», и ничего не вводите. Указываем расположение ключа и вводим пароль.

В Сmder для запуска ssh-agent можно использовать команду start-ssh-agent .

Если проблема осталась, рекомендуем работать в Git Bash.

/.ssh/config файл, чтобы автоматически загрузить ключи в ssh-agent и хранить пароли.

Вы можете добавить свой приватный ключ в ssh-agent и сохранить пароль к нему с помощью команды ssh-add -K

/.ssh/id_rsa . Если у вашего ключа другое имя, не забудьте заменить id_rsa в команде на правильное название.

/.ssh права доступа командой chmod 700

Можно пойти другим путём, открыть файл id_rsa.pub прямо в папке и просто скопировать содержимое оттуда.

Нажимаем кнопку New SSH key (новый SSH-ключ). Вводим имя ключа (можно придумать абсолютно любое) в поле Title (название), а в Key (ключ) вставляем сам ключ из буфера обмена. Теперь нажимаем Add SSH key (добавить SSH-ключ).

Добавляем в свой профиль SSH-ключ.

Если всё сделано верно, в списке появится новый ключ.

Теперь, наконец-то, мы можем начать работу с самим проектом.

Работа с репозиториями

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

Это рабочая директория с вашим проектом. По сути, это та же папка с HTML, CSS, JavaScript и прочими файлами, что хранится у вас на компьютере, но находится на сервере GitHub. Поэтому вы можете работать с проектом удалённо на любой машине, не переживая, что какие-то из ваших файлов потеряются — все данные будут в репозитории при условии, что вы их туда отправите. Но об этом позже.

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

Как сделать форк мастер-репозитория?

Заходим в нужный репозиторий, нажимаем на «вилку» с надписью fork. Форк репозитория создан и находится в вашем профиле на GitHub.

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

Открываем консоль, переходим в директорию, где хотим сохранить папку с проектом, и вводим команду:

Если вы правильно настроили SSH-ключи, Git начнёт процесс копирования репозитория на ваш компьютер. Если вы видите ошибку, в которой написано Error: Permission denied (publickey) , скорее всего, вы ошиблись где-то при выполнении инструкции по настройке SSH-ключа. Вернитесь на несколько абзацев ранее и попробуйте повторить процесс настройки.

Если вы не хотите вручную вводить адрес репозитория, вы можете зайти на страницу проекта, нажать зелёную кнопку Clone or download (клонировать или скачать), выбрать Clone with SSH (клонировать по SSH) и скопировать адрес, который находится в текстовом поле. Этот адрес вы можете вставить в команду git clone .

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

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

Чтобы начать работу с проектом, надо оказаться в его директории. Для этого используем команду cd , после которой указываем название проекта на вашем компьютере: cd your-project

Сделали копию репозитория.

Создадим новую ветку. Открываем терминал, вводим команду git branch . Она показывает список веток, с которыми мы работаем в проекте, и выделяет текущую. Если мы находимся в master создаём новую ветку: git checkout -b имя-новой-ветки .

Новая ветка.

Если текущая ветка не master , сначала переключимся в основную ветку: git checkout master . Мы делаем это, чтобы новая ветка содержала свежую, на момент создания, рабочую версию проекта.

Эта команда позволяет переключаться между существующими ветками в проекте, после git checkout надо указать название нужной ветки.

Переключаемся между ветками.

Если вы ошиблись в названии, например, допустили опечатку, вы можете изменить название ветки с помощью команды: git branch -m старое-имя-ветки новое-имя-ветки .

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

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

Состояние ветки.

Перед тем, как зафиксировать изменения отдельных файлов, нужно добавить файлы в набор этих изменений. Воспользуйтесь командой git add имя-файла . Если название очень длинное, вы можете начать его писать, затем нажать Tab и консоль сама предложит вам продолжение пути к файлу.

Если вы хотите сохранить все изменения разом, вводите git add -A .

Делаем коммит.

Сохранения зафиксированы, всё? Они теперь в репозитории и видны коллегам? Пока нет. Те изменения, которые мы внесли и сохранили, пока локальны. Их нужно послать на GitHub.

Отправляем изменения.

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

Любое предложение можно принять или отвергнуть. Так же и с пулреквестом. После его создания, он должен получить ревью и одобрение так называемого коллаборатора — пользователя GitHub, который имеет права администратора в мастер-репозитории. Им может быть ваш коллега-разработчик, техлид, наставник. Если к вашему коду нет вопросов, пулреквест принимается и изменения из вашей ветки попадают в master главного репозитория. Если в код нужно внести изменения, пулреквест отклоняется, и вам нужно снова пройти по цепочке локальные изменения — сохранение — коммит — пуш, только пулреквест заново делать не нужно. Если вы продолжаете вести работу в той же ветке и пулреквест ещё не принят, все ваши изменения автоматически добавятся в пулреквест, созданный из этой ветки после команды git push origin название-текущей-ветки .

Вы исправили код, наставник или техлид одобрил ваши правки и принял пулреквест. Теперь код в мастер-репозитории обновился, а в вашем форке нет, вы ведь не обновляли свою версию репозитория с тех пор, как клонировали её себе на компьютер. Приведём форк в актуальное состояние.

В локальном репозитории вводим команду git checkout master , переходим в master .
Теперь забираем (подтягиваем) изменения из ветки master мастер-репозитория git pull academy master . Academy здесь — сокращённое название мастер-репозитория, такое имя используется в проектах студентов Академии, вы можете выбрать любое другое название. Забираем изменения из мастер-репозитория. Если консоль выдаёт ошибку и говорит, что не знает директории с таким именем, нужно добавить ссылку на этот репозиторий: Вместо academy указывайте своё название и оно закрепится за этим репозиторием.
Теперь отправьте изменения уже из своей ветки master в ваш форк на GitHub с помощью команды git push origin master . Отправляем изменения в форк.

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

В этом материале я хочу поделиться с вами тем, что узнала, осваивая Linux и Git.

Основные команды Linux

pwd : эта команда применяется для вывода сведения о рабочей директории.

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

cd : данная команда предназначена для смены каталога.

Эксперименты с командами Linux

cp : эта команда предназначена для копирования файлов и папок.

mv : с помощью данной команды можно переименовывать или перемещать файлы и папки.

touch : эта команда применяется для создания пустых файлов и для изменения временной метки файлов.

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

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

Пример использования команды tree

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

echo : эта команда применяется для вывода передаваемых ей данных на экран.

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

tail : с помощью этой команды можно вывести 10 последних строк файла.

Примеры использования команд grep и cat

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

Пример использования конвейера

ssh : данная команда позволяет работать с ssh-клиентом, который используется для подключения к удалённым системами и для выполнения команд на них. Протокол SSH направлен на организации безопасного взаимодействия компьютеров.

rm : эта команда используется для удаления файлов и папок. Например, её вызов в виде rm file приводит к удалению файла, а в виде rm -r director y — к удалению директории и всего её содержимого.

Структура директорий Linux

В Linux используется древовидная структура директорий. Начало этой иерархической структуры находится в корневой директории. В эту директорию вложены все остальные директории. Для разделения имён директорий при указании путей к файлам и папкам используется прямая косая черта ( / ).

Вот как может выглядеть структура файловой системы в Linux-системе.

Структура директорий в Linux

Вот — характеристика некоторых важных папок.

Путь к директории	Примечания
	Корневая директория.
	Директория, в которой хранятся материалы пользователя.
	Тут хранятся файлы, необходимые для запуска Linux.
	Здесь находятся исполняемые файлы.
	Содержит различные файлы, используемые системой и установленными в ней программами. Это могут быть файлы журналов, базы данных, кешированные материалы веб-страниц.

Абсолютная и относительная адресация

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

Относительные пути задаются относительно текущей директории.

Эксперименты по работе с путями

Существуют особые относительные пути, сведения о которых приведены в следующей таблице.

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

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

Мягкие и жёсткие ссылки на файлы

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

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

Для создания жёстких и мягких ссылок на файлы используется команда ln . Вот пример создания с её помощью символической ссылки:

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

Поведением команд Linux можно управлять, передавая им при их вызове аргументы (ключи, опции, флаги) командной строки. Они обычно выглядят как дефис ( - ), за которым идёт однобуквенное имя ключа (такая конструкция может выглядеть, например, как -a ). Они могут выглядеть и как два дефиса ( -- ), за которыми идёт более длинное имя ключа (вроде --all ).

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

Справка по команде ls

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

NAME (имя). Тут содержится имя команды и краткое описание того, что она делает.
SYNOPSIS (сводка по синтаксису команды). Здесь показана схема использования команды.
DESCRIPTION (описание). В этом разделе приводится подробное описание команды и поддерживаемых ей ключей командной строки.

Использование команды ls -l

На предыдущем изображении вы могли заметить конструкции вида drwxr-xr-x . Это — описание прав доступа к файлам.

Права доступа к файлам

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

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

Первый символ указывает на то, с чем именно мы имеем дело. А именно, если здесь стоит знак ( - ), то перед нами — файл. Буква ( d ) указывает на директорию. Буква ( l ) — на ссылку.
Три следующих символа позволяют узнать о том, какими разрешениями по работе с данным файлом обладает его владелец: r — чтение, w — запись, x — выполнение. Полный набор разрешений представлен последовательностью rwx , если некое разрешение отсутствует, вместо него в соответствующей позиции ставится символ ( - ).
Следующая последовательность из трёх символов указывает на то, какие разрешения на работу с файлом есть у группы пользователей (как правило, у группы владельца файла). Её содержимое читается по тем же правилам, что и описание прав владельца файла.
Последняя последовательность из трёх символов, устроенная так же, как две предыдущих, описывает права всех пользователей кроме его владельца и тех пользователей, которые входят в группу файла.

Поговорим о некоторых особенностях настройки прав доступа к файлам с помощью chmod . Так, для назначения некоего разрешения всем пользователям используются конструкции, похожие на вышеописанную +x . Оператор ( + ) применяется для добавления разрешений, оператор ( - ) позволяет убирать разрешения, оператор ( = ) используется для установки определённых прав для пользователя-владельца файла ( u , user), для группы ( g , group), для остальных пользователей ( o , others) и для всех пользователей ( a , all). Делается это в конструкциях вида chmod u=rwx,g=rx,o=rx filename .

При назначении разрешений часто используют их запись в числовом виде. Определённым правам соответствуют восьмеричные коды. Так, x соответствует код 1 , w соответствует код 2 , а r соответствует код 4 . Код 0 соответствует полному отсутствию разрешений на работу с файлом. Права на файл описываются трёхзначным числом, порядок цифр в котором соответствует вышеописанному порядку расположения групп разрешений. То есть — первая цифра описывает разрешения владельца файла, вторая — разрешения группы, третья — разрешения остальных пользователей. Каждая из этих цифр представляет собой сумму кодов разрешений r , w и x .

Например, команда вида chmod 444 filename означает, что все будут иметь право лишь на чтение файла ( r--r--r-- ), а команда вида chmod 700 filename указывает на то, что у владельца будет право чтения, записи и запуска файла ( rwx, 4+2+1 ), а никто другой не имеет права выполнять с файлом никаких действий ( rwx------ ).

Работа с Git

При работе с Git обычно используется следующая последовательность действий:

Модификация файла в локальной рабочей директории.
Индексирование файлов (команда git add ).
Сохранение слепка проиндексированных данных во внутренней базе данных ( git commit ).
Отправка изменений из локального репозитория в удалённый ( git push ).
Загрузка изменений из удалённого репозитория в локальный ( git pull ).

Типичная последовательность действий, используемая при работе с Git

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

Состояния файлов

Untracked (неотслеживаемый) — это файл, за изменениями которого Git не наблюдает. Этот файл может быть добавлен в индекс и оказаться в состоянии Staged.
Unmodified (немодифицированный) — файл, за которым организовано наблюдение, но содержимое которого не менялось. Если удалить этот файл, наблюдение за ним прекратится. Если его изменить — он перейдёт в состояние Modified.
Modified (изменённый) — файл, за которым организовано наблюдение, содержимое которого изменилось. Он может быть подвергнут индексированию и переведён в состояние Staged.
Staged (проиндексированный) — это файл, за которым осуществляется наблюдение, и который был включён в индекс. Соответствующие изменения могут быть включены в базу данных Git.

git init : эта команда создаёт в директории пустой Git-репозиторий. Это — первый шаг, выполняемый при создании нового репозитория. После выполнения этой команды можно пользоваться командами git add и git commit .

Команда git init

git add : данная команда добавляет файлы в индекс. Она поддерживает, в виде git add . , добавление в индекс всех непроиндексированных файлов, в виде git add filename — добавление в индекс конкретного файла, в виде git add dirname — добавление в индекс директории.

Команда git add

git commit : эта команда записывает изменения в локальный репозиторий. Эти изменения называют, по аналогии с именем команды, «коммитами». У каждого коммита имеется уникальный идентификатор, что облегчает работу с коммитами.

Команда git commit

git status : эта команда позволяет получить сведения о текущем состоянии репозитория.

Команда git status

git config : данная команда позволяет настраивать Git. Среди настроек Git можно отметить user.name и user.email . Они содержат имя пользователя и адрес его электронной почты, используемые в коммитах и указывающие на то, кто их сделал. Если при вызове команды git config используется флаг --global — настройки применяются ко всем локальным репозиториям. Без этого флага настройки применяются только к текущему репозиторию.

Команда git config

git checkout : эта команда применяется для переключения между ветками репозитория (в виде git checkout <branch_name> ). С её помощью можно создать новую ветку и переключиться на неё ( git checkout -b <new_branch> ).

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

git clone : данная команда используется для создания локальной рабочей копии удалённого репозитория. При её выполнении производится загрузка материалов удалённого репозитория на компьютер. Клонирование существующего репозитория сопоставимо с созданием нового репозитория командой git init . Но при клонировании в нашем распоряжении оказывается репозиторий, в котором уже что-то есть, а при выполнении команды git init — пустой репозиторий.

git pull : эта команда предназначена для загрузки свежих данных из удалённого репозитория.

Итоги

Я рассказала вам обо всём, что узнала во время моего путешествия в мир Linux и Git. Это было очень увлекательно. Надеюсь, вам захочется сделать нечто подобное и изучить что-то новое, что-то такое, что расширит ваши профессиональные горизонты.

Давайте рассмотрим простой пример рабочего процесса, который может быть полезен в вашем проекте. Ваша работа построена так:

Вы работаете над сайтом.

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

Вы работаете в этой ветке.

Переключиться на основную ветку.

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

После тестирования слить ветку содержащую исправление с основной веткой.

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

Основы ветвления

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

Это то же самое что и:

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

Но перед тем как сделать это — имейте в виду, что если рабочий каталог либо индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта. Есть способы обойти это (припрятать изменения (stash) или добавить их в последний коммит (amend)), но об этом мы поговорим позже в разделе Припрятывание и очистка главы 7. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на ветку master :

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

Вы можете прогнать тесты, чтобы убедиться, что ваше исправление делает именно то, что нужно. И если это так — выполнить слияние ветки hotfix с веткой master для включения изменений в продукт. Это делается командой git merge :

Заметили фразу «fast-forward» в этом слиянии? Git просто переместил указатель ветки вперед, потому что коммит C4 , на который указывает слитая ветка hotfix , был прямым потомком коммита C2 , на котором вы находились до этого. Другими словами, если коммит сливается с тем, до которого можно добраться двигаясь по истории прямо, Git упрощает слияние просто перенося указатель ветки вперед, так как нет расхождений в изменениях. Это называется «fast-forward».

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

После внедрения вашего архиважного исправления, вы готовы вернуться к работе над тем, что были вынуждены отложить. Но сначала нужно удалить ветку hotfix , потому что она больше не нужна — ветка master указывает на то же самое место. Для удаления ветки выполните команду git branch с параметром -d :

Стоит обратить внимание на то, что все изменения из ветки hotfix не включены в вашу ветку iss53 . Если их нужно включить, вы можете влить ветку master в вашу ветку iss53 командой git merge master , или же вы можете отложить слияние этих изменений до завершения работы, и затем влить ветку iss53 в master .

Основы слияния

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

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

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

Основные конфликты слияния

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

Это означает, что версия из HEAD (вашей ветки master , поскольку именно её вы извлекли перед запуском команды слияния) — это верхняя часть блока (всё, что над ======= ), а версия из вашей ветки iss53 представлена в нижней части. Чтобы разрешить конфликт, придётся выбрать один из вариантов, либо объединить содержимое по-своему. Например, вы можете разрешить конфликт, заменив весь блок следующим:

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

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

Если вы хотите использовать инструмент слияния не по умолчанию (в данном случае Git выбрал opendiff , поскольку команда запускалась на Mac), список всех поддерживаемых инструментов представлен вверху после фразы «one of the following tools». Просто введите название инструмента, который хотите использовать.

Мы рассмотрим более продвинутые инструменты для разрешения сложных конфликтов слияния в разделе Продвинутое слияние главы 7.

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

Если это вас устраивает и вы убедились, что все файлы, где были конфликты, добавлены в индекс — выполните команду git commit для создания коммита слияния. Комментарий к коммиту слияния по умолчанию выглядит примерно так:

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

Читайте также: