Команды git bash: cyberspacedk/Git-commands: Шпаргалка по консольным командам Git

Работа с Git через консоль — Блог HTML Academy

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

Когда получил непонятное задание.

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

Система контроля версий 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, используйте yum install git.
• Для 22 и последующих версий Fedora вводите dnf install git.
• Для дистрибутивов, основанных на Debian, например, Ubuntu, используйте apt-get: sudo apt-get install git.

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

Установка на 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 --version, должна появиться текущая версия программы на вашей машине. Эта проверка подходит для всех операционных систем.

Настройка Git

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

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

git config --global user.name "ваше имя"

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

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

Git — всему голова

А всё остальное — на интерактивных курсах по HTML, CSS и JavaScript. 11 глав сейчас и бесплатно.

Регистрация

Нажатие на кнопку — согласие на обработку персональных данных

Регистрация на GitHub

Что такое GitHub?

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

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

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

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

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

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

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

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

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

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

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

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

1. Открываем консоль.
2. Вводим cd ~/.ssh, чтобы перейти в нужный каталог.
   
   Переходим в нужную директорию.
3. Используем ls, чтобы увидеть список всех файлов в каталоге.
   Открываем список файлов в директории.
   
   Ищем пару файлов с названиями вида имя и имя.pub. Обычно имя — id_rsa, id_dsa, id_ecdsa или id_ed25519. Файл с расширением .pub — ваш публичный ключ, а второй — ваш приватный, секретный ключ.
   Если таких файлов или даже каталога .ssh у вас нет, вы можете их сгенерировать. Для этого делаем следующее.
4. Добавляем ключ в ssh-agent (сгенерированный или уже существующий). Проверяем доступность ключа командой eval "$(ssh-agent -s)" и добавляем с помощью ssh-add ~/.ssh/your_key_name, где указываем верный путь до файла с ключом и его имя.
   Добавляем ключ в shh-agent. Несколько важных примечаний:
   • Если вы захотите переименовать ключ, могут возникнуть проблемы. Их можно решить, добавив в ~/.ssh/config связь ключа с доменом.
   • Если у вас Windows и вы пользуетесь программой Cmder, возможны проблемы с командой eval "$(ssh-agent -s)". Может появиться такое сообщение об ошибке:
     «eval не является внутренней или внешней командой, исполняемой программой или пакетным файлом».

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

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

   • Если у вас macOS Sierra версии 10.12.2 и выше, нужно изменить ваш ~/.ssh/config файл, чтобы автоматически загрузить ключи в ssh-agent и хранить пароли.

     Host *
      AddKeysToAgent yes
      UseKeychain yes
      IdentityFile ~/.ssh/id_rsa

     Вы можете добавить свой приватный ключ в ssh-agent и сохранить пароль к нему с помощью команды ssh-add -K ~/.ssh/id_rsa. Если у вашего ключа другое имя, не забудьте заменить id_rsa в команде на правильное название.

   • Если у вас Linux, может понадобится переназначить для ~/.ssh права доступа командой chmod 700 ~/.ssh/
5. После того как создан ключ, его нужно добавить на GitHub. Для этого копируем его содержимое с помощью одной из следующих команд:
   • Если вы на Windows clip .

   • Для пользователей macOS pbcopy .

   • На Linux используйте sudo apt-get install xclip, чтобы установить необходимый для копирования пакет xclip, а затем введите xclip -sel clip . Или введите команду cat ~/.ssh/id_rsa.pub, контент документа появится прямо в консоли и вы сможете скопировать ключ оттуда.


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

6. Переходим на страницу для работы с ключами в вашем профиле на GitHub.
   
   Страница с настройками ключей в вашем профиле.

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

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

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

   Успешно добавленный ключ.

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

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

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

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

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

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

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

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

git clone [email protected]:your-nickname/your-project.git

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

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

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

git clone [email protected]:_your-nickname_/_your-project_.git folder_name

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

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

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

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

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

Новая ветка.

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

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

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

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

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

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

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

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

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

Теперь мы можем сделать коммит, то есть зафиксировать все сохранённые изменения и дать им название. Это делается с помощью команды git commit -m "ваше сообщение". Текст сообщения должен быть лаконичным и в то же время сообщать о том, что делает коммит (внесённые изменения). Например, «добавляет имя наставника в Readme», «вводит функцию сортировки изображений», «правит ошибку в поиске городов на карте».

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

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

Чтобы отправить свои изменения (коммиты) в репозиторий на GitHub, введите команду git push origin название-текущей-ветки, где origin означает репозиторий, который был склонирован на компьютер, то есть ваш форк.

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

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

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

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

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

   git remote add academy [email protected]:your-repo.git

   
   Вместо academy указывайте своё название и оно закрепится за этим репозиторием.

3. Теперь отправьте изменения уже из своей ветки master в ваш форк на GitHub с помощью команды git push origin master.
   Отправляем изменения в форк.

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

Шпаргалка по Git, в которой представлены основные команды

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

git add

Команда git add добавляет содержимое рабочей директории в индекс (staging area) для последующего коммита. По умолчанию git commit использует лишь этот индекс, так что вы можете использовать git add для сборки слепка вашего следующего коммита.

git status

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

git diff

Команда git diff используется для вычисления разницы между любыми двумя Git деревьями. Это может быть разница между вашей рабочей директорией и индексом (собственно git diff), разница между индексом и последним коммитом (git diff --staged), или между любыми двумя коммитами (git diff master branchB).

git difftool

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

git commit

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

git reset

Команда git reset, как можно догадаться из названия, используется в основном для отмены изменений. Она изменяет указатель HEAD и, опционально, состояние индекса. Также эта команда может изменить файлы в рабочей директории при использовании параметра --hard, что может привести к потере наработок при неправильном использовании, так что убедитесь в серьёзности своих намерений прежде чем использовать его.

git rm

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

git mv

Команда git mv — это всего лишь удобный способ переместить файл, а затем выполнить git addдля нового файла и git rm для старого.

git clean

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

git branch

Команда git branch — это своего рода “менеджер веток”. Она умеет перечислять ваши ветки, создавать новые, удалять и переименовывать их.

git checkout

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

git merge

Команда git merge используется для слияния одной или нескольких веток в текущую. Затем она устанавливает указатель текущей ветки на результирующий коммит.

git mergetool

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

git log

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

git stash

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

git tag

Команда git tag используется для задания постоянной метки на какой-либо момент в истории проекта. Обычно она используется для релизов.

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

git fetch

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

git pull

Команда git pull работает как комбинация команд git fetch и git merge, т.е. Git вначале забирает изменения из указанного удалённого репозитория, а затем пытается слить их с текущей веткой.

git push

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

git remote

Команда git remote служит для управления списком удалённых репозиториев. Она позволяет сохранять длинные URL репозиториев в виде понятных коротких строк, например «origin», так что вам не придётся забивать голову всякой ерундой и набирать её каждый раз для связи с сервером. Вы можете использовать несколько удалённых репозиториев для работы и git remote поможет добавлять, изменять и удалять их.

git archive

Команда git archive используется для упаковки в архив указанных коммитов или всего репозитория.

git submodule

Команда git submodule используется для управления вложенными репозиториями. Например, это могут быть библиотеки или другие, используемые не только в этом проекте ресурсы. У команды submodule есть несколько под-команд — add, update, sync и др. — для управления такими репозиториями.

git show

Команда git show отображает объект в простом и человекопонятном виде. Обычно она используется для просмотра информации о метке или коммите.

git shortlog

Команда git shortlog служит для подведения итогов команды git log. Она принимает практически те же параметры, что и git log, но вместо простого листинга всех коммитов, они будут сгруппированы по автору.

git describe

Команда git describe принимает на вход что угодно, что можно трактовать как коммит (ветку, тег) и выводит более-менее человекочитаемую строку, которая не изменится в будущем для данного коммита. Это может быть использовано как более удобная, но по-прежнему уникальная, замена SHA-1.

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

git bisect

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

git blame

Команда git blame выводит перед каждой строкой файла SHA-1 коммита, последний раз менявшего эту строку и автора этого коммита. Это помогает в поисках человека, которому нужно задавать вопросы о проблемном куске кода.

git grep

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

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

Другие материалы по теме:

https://proglib.io/p/git-github-gitflow/

https://proglib.io/p/system-git/

Книга по Git

Официальные видео уроки по Git

Моя шпаргалка по работе с Git

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

В чем состоит отличие Git от Subversion?

Главное отличие Git от Subversion заключается в том, что Git — распределенная система контроля версий. Звучит ужасающе, но на практике это означает очень простую вещь. Каждый разработчик держит у себя на диске отдельный репозиторий. Обратите внимание — не копию репозитория, не некоторые бранчи, а тупо отдельный и при этом абсолютно полноценный репозиторий.

Пока мы работаем в рамках своего репозитория, все происходит в точности, как в Subversion. Мы коммитим и откатываем изменения, создаем, мержим и удаляем бранчи, разрешаем конфликты и тд. Помимо этого, предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает мерж локальных изменений в удаленный репозиторий, а «git pull» — наоборот, мерж изменений из удаленного репозитория в локальный. Обмен данными по сети обычно происходит с использованием протокола SSH.

В результате имеем:

• Git присущи все те же преимущества от использования VCS, что мы получаем в Subversion.
• Git дает нам нормальное шифрование «из коробки», безо всяких танцев с бубнами, как в случае с Subversion.
• Если сервер с «главным» репозиторием, куда пушат свои изменения все разработчики (хотя формально в Git нет никакого «главного» репозитория), вдруг прилег — ничего страшного. Делаем коммиты в локальный репозиторий и ждем, когда сервер вернется.
• Даже если сервер доступен, все равно удобнее сделать пяток локальных коммитов, а затем отправить их на сервер одним пушем.
• Сервер вообще не нужен. Вы можете использовать Git только локально. И не обязательно для работы с исходниками. Например, можно использовать Git для того, чтобы иметь возможность откатиться к предыдущим версиям файлов (каких-нибудь электронных таблиц) или вернуть случайно удаленные.
• Git не раскидывает по каталогам служебную информацию (помните «.svn»?), вместо этого она хранится только в корне репозитория.
• Git нынче очень моден (хотя это далеко не единственная распределенная система контроля версий, например, есть Mercurial и Darcs), в связи с чем растет число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме или собрать команду разработчиков, знакомых с этой VCS.
• Существует множество полезных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
• Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, …) — есть из чего выбрать.
• Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего open source проекта.

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

Я использовал Git при написании программы из заметки Генерация почти осмысленных текстов на Haskell, сидя под своей любимой FreeBSD. Вот как примерно выглядела моя работа с Git.

В первую очередь необходимо поставить Git:

Затем создаем пару ssh ключей, если не создавали ее ранее:

ssh-keygen
cat ~/.ssh/id_rsa.pub

Заходим на БитБакет, создаем git-репозиторий под новый проект, а в свойствах аккаунта прописываем свой открытый ssh-ключ. Затем клонируем репозиторий:

cd ~/projects/haskell
git clone [email protected]:afiskon/hs-textgen.git
cd hs-textgen

Делаем какие-то изменения:

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

git add TODO.TXT
git commit -a

Поскольку я не указал описание коммита, запускается редактор VIM, с помощью которого я и ввожу описание. Затем я отправляю все сделанные мною изменения на БитБакет:

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

git branch new_feature
git checkout new_feature

Работаем с этой веткой. Если ничего хорошего не вышло, возвращаемся к основной ветке (она же «trunk» или «ствол»):

Если вышло что-то хорошее, мержим ветку в master (о разрешении конфликтов рассказано в следующем параграфе):

git commit -a # делаем коммит всех изменений в new_feature
git checkout master # переключаемся на master
git merge new_feature # мержим ветку new_feature

Не забываем время от времени отправлять наш код на BitBucket:

Если мы правим код с нескольких компьютеров, то перед началом работы не забываем «накатить» в локальный репозиторий последнюю версию кода:

Работа в команде мало чем отличается от описанного выше. Только каждый программист должен работать со своей веткой, чтобы не мешать другим программистам. Одна из классических ошибок при начале работы с Git заключается в push’е всех веток, а не только той, с которой вы работали. Вообще я бы советовал первое время перед выполнением каждого push делать паузу с тем, чтобы подумать, что и куда сейчас уйдет. Для большей безопасности советую при генерации ssh-ключей указать пароль. Тогда каждый запрос пароля со стороны Git будет для вас сигналом «Эй, ты делаешь что-то, что затронет других».

Fun fact! Нравится статья? Поддержи автора, чтобы он мог писать больше полезных статей!

Для работы с Git под Windows можно воспользоваться клиентом TortoiseGit. Если память не подводит, для работы ему нужен Git for Windows. Для генерации ключей можно воспользоваться утилитой PuTTyGen. Только не забудьте экспортировать открытый ключ в правильном формате, «Conversions → Export OpenSSH key».

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

Шпаргалка по командам

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

Создать новый репозиторий:

Если вы планируете клонировать его по ssh с удаленной машины, также скажите:

git config —bool core.bare true

… иначе при git push вы будете получать странные ошибки вроде:

Refusing to update checked out branch: refs/heads/master
By default, updating the current branch in a non-bare repository
is denied, because it will make the index and work tree inconsistent
with what you pushed, and will require ‘git reset —hard’ to match
the work tree to HEAD.

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

git clone [email protected]:afiskon/hs-textgen.git

Если хотим пушить один код в несколько репозиториев:

git remote add remotename [email protected]:repo.git

Добавить файл в репозиторий:

Удалить файл:

Текущее состояние репозитория (изменения, неразрешенные конфликты и тп):

Сделать коммит:

git commit -a -m «Commit description»

Сделать коммит, введя его описание с помощью $EDITOR:

Замержить все ветки локального репозитория на удаленный репозиторий (аналогично вместо origin можно указать и remotename, см выше):

Аналогично предыдущему, но делается пуш только ветки master:

Запушить текущую ветку, не вводя целиком ее название:

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

Аналогично предыдущему, но накатывается только ветка master:

Накатить текущую ветку, не вводя ее длинное имя:

Скачать все ветки с origin, но не мержить их в локальный репозиторий:

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

Начать работать с веткой some_branch (уже существующей):

git checkout -b some_branch origin/some_branch

Создать новый бранч (ответвится от текущего):

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

Получаем список веток, с которыми работаем:

git branch # звездочкой отмечена текущая ветвь

Просмотреть все существующие ветви:

git branch -a # | grep something

Замержить some_branch в текущую ветку:

Удалить бранч (после мержа):

git branch -d some_branch

Просто удалить бранч (тупиковая ветвь):

git branch -D some_branch

История изменений:

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

История конкретного файла:

Аналогично предыдущему, но с просмотром сделанных изменений:

История с именами файлов и псевдографическим изображением бранчей:

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

git show d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

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

Удалить бранч из репозитория на сервере:

git push origin :branch-name

Откатиться к конкретному коммиту (хэш смотрим в «git log»):

git reset —hard d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

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

git reset —soft d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

Попытаться обратить заданный commit:

git revert d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

Просмотр изменений (суммарных, а не всех по очереди, как в «git log»):

git diff # подробности см в «git diff —help»

Используем vimdiff в качестве программы для разрешения конфликтов (mergetool) по умолчанию:

git config —global merge.tool vimdiff

Отключаем диалог «какой mergetool вы хотели бы использовать»:

git config —global mergetool.prompt false

Отображаем табы как 4 пробела, например, в «git diff»:

git config —global core.pager ‘less -x4’

Создание глобального файла .gitignore:

git config —global core.excludesfile ~/.gitignore_global

Разрешение конфликтов (когда оные возникают в результате мержа):

Создание тэга:

git tag some_tag # за тэгом можно указать хэш коммита

Удаление untracked files:

«Упаковка» репозитория для увеличения скорости работы с ним:

Иногда требуется создать копию репозитория или перенести его с одной машины на другую. Это делается примерно так:

mkdir -p /tmp/git-copy
cd /tmp/git-copy
git clone —bare [email protected]:afiskon/cpp-opengl-tutorial1.git
cd cpp-opengl-tutorial1.git
git push —mirror [email protected]:afiskon/cpp-opengl-tutorial2.git

Следует отметить, что Git позволяет использовать короткую запись хэшей. Вместо «d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4» можно писать «d8578edf» или даже «d857».

Дополнение: Также в 6-м пункте Мини-заметок номер 9 приводится пример объединения коммитов с помощью git rebase, а в 10-м пункте Мини-заметок номер 11 вы найдете пример объединения двух репозиториев в один без потери истории.

Работа с сабмодулями

Более подробно сабмодули и зачем они нужны объясняется в заметке Простой кроссплатформенный OpenGL-проект на C++. Здесь упомянем самое главное.

Добавить сабмодуль:

git submodule add https://github.com/glfw/glfw glfw

Инициализация сабмодулей:

Обновление сабмодулей, например, если после git pull поменялся коммит, на который смотрит сабмодуль:

Удаление сабмодуля производится так:

1. Скажите git rm --cached имя_сабмодуля;
2. Удалите соответствующие строчки из файла .gitmodules;
3. Также грохните соответствующую секцию в .git/config;
4. Сделайте коммит;
5. Удалите файлы сабмодуля;
6. Удалите каталог .git/modules/имя_сабмодуля;

Дополнительные материалы

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

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

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

Метки: Разработка.

Полезные команды для работы с Git — Блог HTML Academy

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

Первоначальная настройка Git

Работа с любой программой всегда начинается с её настройки. Git можно настроить один раз и менять что-то только по мере необходимости.

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

git config --global user.name "User Name"

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

git config --global user.email [email protected]

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

git config --global core.editor editor

С помощью команды git config --list можно посмотреть список всех установленных настроек.

Клонирование репозитория

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

Работа с изменениями

Любая работа с изменениями начинается с получения последней версии удалённого репозитория. Получить последнюю версию можно с помощью команды git pull. Будьте внимательны, вызов этой команды сотрёт все незафиксированные изменения.

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

Чтобы добавить отслеживание новых файлов, необходимо использовать команду git add <filename> <filename> для добавления нескольких файлов по имени.

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

Помимо добавления файлов, их также необходимо удалять. Для этого существует команда git rm <filename> <filename>, которая удаляет файлы по их имени.

После того как добавлены все новые и удалены старые файлы, можно делать фиксацию изменений. Фиксация изменений или коммит, очень важна, так как до выполнения этой команды ваши локальные изменения никуда не запишутся. Чтобы добавить коммит, необходимо ввести команду git commit -m "Комментарий к коммиту".

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

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

По умолчанию, эта команда удаляет только из индекса. А команда git reset --hard безвозвратно удаляет незафиксированные текущие изменения из локального репозитория и из индекса.

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

Работа с ветками

Работая с Git, приходится постоянно создавать и перемещаться по веткам.

Команда git checkout -b branch-name создаст ветку с указанным именем и автоматически переключится на неё.

После создания ветку можно отправить на сервер с помощью команды git push origin branch-name.

Аналогично можно забрать себе на компьютер ветку с удалённого репозитория командой git checkout origin/branch-name -b branch-name.

Чтобы не хранить названия веток в памяти или не искать названия веток, существуют две специальные команды, которые позволяют посмотреть все существующие ветки локального репозитория git branch или все существующие ветки удалённого репозитория git branch -r.

Переключиться на любую локальную ветку можно с помощью команды git checkout branch-name.

Прочее

После работы в репозитории могут оставаться различные ненужные, неотслеживаемые файлы и прочий мусор. Чтобы удалить всё лишнее, воспользуйтесь командой git clean -f -d.

Шпаргалка с основными командами для Git

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

git config --global user.name "[name]" — установить имя, которое будет прикрепляться к коммиту.

git config --global user.email "[email address]" — установить email, который будет прикрепляться к коммиту.

git config --global color.ui auto — включить полезную подсветку командной строки.

git config --global push.default current — обновлять удаленную ветку с таким же именем, что и локальная, при пуше изменений (если не указано иного).

git config --global core.editor [editor] — установить редактор для редактирования сообщений коммита.

git config --global diff.tool [tool] — установить программу для разрешения конфликтов при слиянии.

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

git init [project-name] — создать новый локальный репозиторий с заданным именем.

git clone [url] — загрузить проект и его полную историю изменений.

Работа с изменениями

git status — полный список изменений файлов, ожидающих коммита.

git status -s — краткий вид изменений.

git diff — показать изменения в файлах, которые еще не были добавлены в индекс коммита (staged).

git add [file] — сделать указанный файл готовым для коммита.

git add . — сделать все измененные файлы готовыми для коммита.

git add '*.txt' — добавить только файлы, соответствующие указанному выражению.

git add --patch filename — позволяет выбрать какие изменения из файла добавятся в коммит.

git diff --staged — показать что было добавленно в индекс с помощью git add, но еще не было закоммиченно.

git diff HEAD — показать что изменилось с последнего коммита.

git diff HEAD^ — показать что изменилось с предпоследнего коммита.

git diff [branch] — сравнить текущую ветку с заданной.

git difftool -d — то же самое, что и diff, но показывает изменения в заданной difftool.

git difftool -d master.. — показать изменения, сделанные в текущей ветке.

git diff --stat — показать статистику какие файлы были изменены и как.

git reset [file] — убрать файлы из индекса коммита (изменения не теряются).

git commit — записать изменения в репозиторий. для написания сообщения откроется назначенный редактор.

git commit -m "[descriptive message]" — записать изменения с заданным сообщением.

git commit --amend — добавить изменения к последнему коммиту.

Работа с ветками

git branch — список всех локальных веток в текущей директории.

git branch [branch-name] — создать новую ветку.

git checkout [branch-name] — переключиться на указанную ветку и обновить рабочую директорию.

git checkout -b <name> <remote>/<branch> — переключиться на удаленную ветку.

git checkout [filename] — вернуть файл в первоначальное состояние если он еще не был добавлен в индекс коммита.

git merge [branch] — соединить изменения в текущей ветке с изменениями из заданной.

git merge --no-ff [branch] — соединить ветки без режима “fast forwarding”.

git branch -a — посмотреть полный список локальных и удаленных веток.

git branch -d [branch] — удалить заданную ветку.

git branch -D [branch] — принудительно удалить заданную ветку, игнорируя ошибки.

git branch -m <oldname> <newname> — переименовать ветку.

Работа с файлами

git rm [file] — удалить файл из рабочей директории и добавить в индекс информацию об удалении.

git rm --cached [file] — удалить файл из репозитория, но сохранить его локально.

git mv [file-original] [file-renamed] — изменить имя файла и добавить в индекс коммита.

Отслеживание файлов

.gitignore — текстовый файл, в котором задаются правила для исключения файлов из репозитория. Например:

git ls-files --other --ignored --exclude-standard — список всех игнорируемых файлов.

Сохранение фрагментов

git stash — положить во временное хранилище все отслеживаемые файлы.

git stash pop — восстановить последние файлы, положенные во временное хранилище.

git stash list — список всех сохраненных изменений во временном хранилище.

git stash drop — удалить последние файлы, положенные во временное хранилище.

Просмотр истории

git log — список изменения текущей ветки.

git log --follow [file] — список изменения текущего файла, включая переименования.

git log --pretty=format:"%h %s" --graph — изменение вида отображения истории изменений.

git log --author='Name' --after={1.week.ago} --pretty=oneline --abbrev-commit — посмотреть над чем работал заданный пользователь последнюю неделю.

git log --no-merges master.. — посмотреть историю изменений только для текущей ветки.

git diff [file-branch]..[second-branch] — посмотреть различия между двумя заданными ветками.

git show [commit] — показать метадату и изменения в заданном коммите.

git show [branch]:[file] — посмотреть на файл в другой ветке, не переключаясь на неё.

Отмена коммитов

git reset — убрать изменения из индекса коммита, сами изменения останутся.

git reset [commit/tag] — отменить все коммиты после указанного коммита, изменения будут сохранены локально.

git reset --hard [commit] — принудительно вернутся к указанному коммиту, не сохраняя историю и изменения.

Синхронизация изменений

git fetch [bookmark] — загрузить всю историю с заданного удаленного репозитория.

git merge [bookmark]/[branch] — слить изменения локальной ветки и заданной удаленной.

git push — запушить текущую ветку в удаленную ветку.

git push [remote] [branch] — запушить ветку в указанный репозиторий и удаленную ветку.

git push [bookmark] :[branch] — в удаленном репозитории удалить заданную ветку.

git push -u origin master — если удаленная ветка не установлена как отслеживаемая, то сделать ее такой.

git pull — загрузить историю и изменения удаленной ветки и произвести слияние с текущей веткой.

git pull [remote][branch] — указать конкретную удаленную ветку для слияния.

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

git remote -v — посмотреть детальный список доступных удаленных репозиториев.

git remote add [remote][url] — добавить новый удаленный репозиторий.

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

ЭННЕРА — Компьютерная энциклопедия. — GIT BASH Команды|Шпаргалка по GIT

GIT BASH Команды|Шпаргалка по GIT

В этой статье — напоминалке приведена небольшая шпаргалка по командам Git.

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

Поехали!

Инициализировать новый репозиторий:

Клонировать репозиторий с удаленного сервера:

Добавить в репозиторий файл:

Удалить файл из репозитория:

Проверить текущее состояние репозитория:

Сделать коммит (заиндексировать состояние репозитория):

Сделать коммит, введя его описание:

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

Аналогично предыдущему, но делается пуш только ветки master:

Запушить текущую ветку, не вводя целиком ее название:

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

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

Закачать текущую ветку, не вводя ее длинное имя:

Начать работать с веткой some_branch (-b создает новую):

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

Переключиться на другую ветку (на уже существующую):

Список доступных веток:

Список всех существующих веток:

Слить some_branch с текущей веткой:

Удалить ветку (после мерджа):

Посмотреть лог:

Лог конкретного файла:

Как и предыдущий запрос, но с просмотром сделанных изменений:

Лог с именами файлов и с графиками веток и слияний:

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

Посмотреть, кто менял строчку файла:

Откатиться к коммиту (хэш смотрим в «git log» — последние 7 символов):

Создание тэга (для быстрой навигации по коммитам):

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

Введение¶

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

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

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

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

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

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

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

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

git clone http://user@somehost:port/~user/repository/project.git

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

git clone /home/username/project myrepo

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

git clone ssh://user@somehost:port/~user/repository

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

git clone git://user@somehost:port/~user/repository/project.git/

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

git svn clone -s http://repo/location

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

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

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

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

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

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

git remote add username-project /home/username/project

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

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

git merge username-project/master

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

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

git pull

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

git pull username-project --tags

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

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

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

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

git push

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

git push ssh://yourserver.com/~you/proj.git master:experimental

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

git push origin :experimental

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

git push origin master:master

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

git push origin master --tags

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

git push origin origin/develop:master

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

git push origin origin/develop:refs/heads/test

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

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

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

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

mkdir project-dir
cd project-dir
git init

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

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

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

git add EDITEDFILE

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

git add .

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

отдельные файлы:

git rm FILE1 FILE2

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

git rm Documentation/\*.txt

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

git rm -r --cached .

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

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

git reset

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

git reset — EDITEDFILE

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

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

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

git status

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

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

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

git commit

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

Есть несколько ключей, упрощающих работу с git commit:

git commit -a

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

git commit -m «commit comment»

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

git commit FILENAME

внесет в индекс и создаст коммит на основе изменений единственного файла.

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

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

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

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

   git commit -C ORIG_HEAD

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

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

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

git add .
git commit -m «destined to death»
git reset --hard HEAD~1 — больше никто и никогда не увидит этот позорный коммит...
git reset --hard HEAD~3 — ...вернее, три последних коммита. Никто. Никогда!

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

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

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

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

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

git revert config-modify-tag

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

git revert cgsjd2h

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

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

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

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

git log

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

git log -p

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

git log --stat

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

git log --summary

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

git log README

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

git log — README

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

git log --since=«1 day 2 hours» README
git log --since=«2 hours» README

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

git log --since=«2 hours» dir/

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

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

git log v1...

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

git log v1... README

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

git log v1..v2 README

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

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

git log --pretty=oneline

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

git log --pretty=short

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

git log --pretty=full/fuller

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

git log --pretty=format:'FORMAT'

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

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

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

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

git diff

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

git diff --cached

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

git diff HEAD

Предпоследним коммитом:

git diff HEAD^

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

git diff master..experimental

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

git diff experimental

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

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

git show COMMIT_TAG

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

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

git blame README

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

git blame -L 2,+3 README — выведет информацию по трем строкам, начиная со второй.

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

git annotate README

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

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

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

git grep tst

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

git grep -с tst

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

git grep tst v1

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

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

git grep -e 'first' --and -e 'another'

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

git grep --all-match -e 'first' -e 'second'

Ветвление¶

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

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

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

git branch

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

git branch new-branch

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

git branch -d new-branch

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

git branch -D new-branch

Переименовать ветку:

git branch -m new-name-branch

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

git branch --contains v1.2

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

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

checkout some-other-branch

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

checkout -b some-other-new-branch

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

checkout -f some-other-branch

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

checkout -m some-other-branch

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

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

git checkout somefile

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

git checkout HEAD~2 somefile

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

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

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

git merge new-feature

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

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

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

git merge experiment

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

git status

Разрешаем проблемы:

edit TROUBLE

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

git add .

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

git commit

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

git reset --hard HEAD

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

git reset --hard ORIG_HEAD

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

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

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

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

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

git-rebase master topic

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

git-rebase master

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

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

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

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

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

git cherry-pick BUG_FIX_TAG

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

git cherry-pick BUG_FIX_TAG -n

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

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

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

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

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

git diff f292ef5d2b2f6312bc45ae49c2dc14588eef8da2

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

git diff f292ef5

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

git diff f292

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

git log febc32...f292

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

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

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

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

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

git tag stable-1

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

git tag stable-2 f292ef5

Удалить тег:

git tag -d stable-2

Перечислить тэги:

git tag -l

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

git tag -f stable-1.1

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

git diff stable-1.1...stable-1

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

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

git tag -a stable

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

git tag -a stable -m "production version" 

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

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

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

git diff master^

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

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

git diff HEAD^2

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

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

git diff master^^

То же самое:

git diff master~2

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

git diff master~3^~2
git diff master~6

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

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

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

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

#комментарий к файлу .gitignore
#игнорируем сам .gitignore
.gitignore
#все html-файлы...
*.html
#...кроме определенного
!special.html
#не нужны объектники и архивы
*.[ao]

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

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

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

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

Рецепты¶

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

repo="repo.git" 
mkdir $repo
cd $repo
git init --bare
chown git. -R ./
cd ../

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

repo="repo.svn" 
svnserver="http://svn.calculate.ru" 
git svn clone -s $svnserver/$repo $repo
mv $repo/.git/refs/remotes/tags $repo/.git/refs/tags
rm -rf $repo/.git/refs/remotes
rm -rf $repo/.git/svn
mv $repo/.git $repo.git
rm -rf $repo
cd $repo.git
chown git. -R ./
cd ../

Ссылки¶

Git bash: определение, команды и начало работы

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

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

Что такое Git Bash?

Git Bash — это приложение для сред Microsoft Windows, которое обеспечивает уровень эмуляции для работы с командной строкой Git.Баш — это аббревиатура от Bourne Again Shell. Оболочка — это терминальное приложение, используемое для взаимодействия с операционной системой с помощью письменных команд. Bash — популярная оболочка по умолчанию в Linux и macOS. Git Bash — это пакет, который устанавливает Bash, некоторые распространенные утилиты bash и Git в операционной системе Windows.

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

Git Bash входит в состав пакета Git для Windows. Загрузите и установите Git для Windows, как и другие приложения для Windows. После загрузки найдите прилагаемый .exe и откройте его для выполнения Git Bash.

Как использовать Git Bash

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

Как перемещаться по папкам

Команда Bash pwd используется для печати текущего рабочего каталога. pwd эквивалентно выполнению cd на терминале DOS (хост консоли Windows).Это папка или путь, в котором находится текущий сеанс Bash.

Команда Bash ls используется для «перечисления» содержимого текущего рабочего каталога. ls эквивалентно DIR на хост-терминале консоли Windows.

И Bash, и консольный хост Windows имеют команду cd. cd — это аббревиатура от «Change Directory». cd вызывается с добавленным именем каталога. Выполнение cd изменит текущий рабочий каталог сеансов терминала на переданный аргумент каталога.

Команды Git Bash

Git Bash содержит дополнительные команды, которые можно найти в каталоге / usr / bin эмуляции Git Bash. Git Bash действительно может обеспечить довольно надежную оболочку в Windows. Git Bash поставляется со следующими командами оболочки, которые выходят за рамки этого документа: Ssh , scp , cat , find .

В дополнение к ранее описанному набору команд Bash, Git Bash включает полный набор основных команд Git, обсуждаемых на этом сайте.Узнайте больше на соответствующих страницах документации для git clone , git commit , git checkout , git push , и других.

.

20 лучших команд Git с примерами

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

Вот описываемые команды Git:

• git config
• git init
• git clone
• git добавить
• git commit
• git diff
• git сброс
• git статус
• гит рм
• журнал git
• git показать
• тег git
• ветка git
• git checkout
• git слияние
• git удаленный
• git push
• git pull
• git stash

Итак, приступим!

Команды Git

git config

Использование: git config –global user.имя «[имя]»

Использование: git config –global user.email «[адрес электронной почты]»

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

git init

Использование: git init [имя репозитория]

Эта команда используется для запуска нового репозитория.

git clone

Использование: git clone [url]

Эта команда используется для получения репозитория по существующему URL-адресу.

git добавить

Использование: git add [файл]

Эта команда добавляет файл в область подготовки.

Использование: git add *

Эта команда добавляет один или несколько элементов в область подготовки.

git совершить

Использование: git commit -m «[Введите сообщение фиксации]»

Эта команда постоянно записывает или делает моментальные снимки файла в истории версий.

Использование: git commit -a

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

git diff

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

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

Использование: git diff –staged

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

Использование: git diff [первая ветвь] [вторая ветвь]

Эта команда показывает различия между двумя упомянутыми ветвями.

git сброс

Использование: git reset [файл]

Эта команда деактивирует файл, но сохраняет его содержимое.

Использование: git reset [commit]

Эта команда отменяет все фиксации после указанной фиксации и сохраняет изменения локально.

Использование: git reset –hard [commit] Эта команда отбрасывает всю историю и возвращается к указанной фиксации.

git статус

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

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

гит RM

Использование: git rm [файл]

Эта команда удаляет файл из вашего рабочего каталога и выполняет этап удаления.

git журнал

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

Эта команда используется для вывода журнала версий для текущей ветви.

Использование: git log – следовать [файл]

Эта команда выводит список версий файла, включая также переименование файлов.

git показать

Использование: git show [commit]

Эта команда показывает изменения метаданных и содержимого указанной фиксации.

тег git

Использование: git tag [commitID]

Эта команда используется для присвоения тегов указанной фиксации.

ветка git

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

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

Использование: ветка git [название ветки]

Эта команда создает новую ветку.

Использование: git branch -d [имя ветки]

Эта команда удаляет ветвь компонента.

git проверка

Использование: git checkout [название ветки]

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

Использование: git checkout -b [название ветки]

Эта команда создает новую ветку и также переключается на нее.

git слияние

Использование: git merge [название ветки]

Эта команда объединяет историю указанной ветки с текущей веткой.

git удаленный

Использование: git remote add [имя переменной] [Ссылка на удаленный сервер]

Эта команда используется для подключения вашего локального репозитория к удаленному серверу.

git push

Использование: git push [имя переменной] master

Эта команда отправляет зафиксированные изменения главной ветки в ваш удаленный репозиторий.

Использование: git push [имя переменной] [ветка]

Эта команда отправляет фиксации ветки в ваш удаленный репозиторий.

Использование: git push –all [имя переменной]

Эта команда помещает все ветки в ваш удаленный репозиторий.

Использование: git push [имя переменной]: [имя ветки]

Эта команда удаляет ветку в вашем удаленном репозитории.

git pull

Использование: git pull [ссылка на репозиторий]

Эта команда извлекает и объединяет изменения на удаленном сервере в ваш рабочий каталог.

git stash

Использование: git stash save

Эта команда временно сохраняет все измененные отслеживаемые файлы.

Использование: git stash pop

Эта команда восстанавливает последние сохраненные файлы.

Использование: git stash list

Эта команда выводит список всех сохраненных ревизий.

Использование: git stash drop

Эта команда отменяет последний сохраненный набор изменений.

Хотите узнать больше о командах git? Вот руководство по Git, чтобы вы начали. В качестве альтернативы вы можете воспользоваться подходом сверху вниз и начать с этого учебника DevOps.

.

Начать использовать Git в командной строке

GitLab Документы

• Версия

  GitLab.com (13.5-до)

  • GitLab.com (13.5-до)
    

  • 13,4

  • 13,3

  • 13,2

  • 12.10

  • 11.11

  • Архивы

• GitLab

• Омнибус

• Бегун

• Диаграммы

Документы GitLab

Установить

Требования

Омнибусные пакеты

Kubernetes

Докер

Из источника

Лазурь

Облачная платформа Google (GCP)

Amazon Web Services (AWS)

Аналитика

Уровень экземпляра

Групповой уровень

Уровень проекта

Инфраструктура

Добавление и удаление кластеров

Добавить кластеры EKS

Добавить кластеры GKE

Кластеры на уровне группы

Кластеры на уровне экземпляра

Канарские развертывания

Кластерные среды

Развернуть доски

Управляемые приложения GitLab

Настройка Crossplane

Инфраструктура как код

Агент Kubernetes

Управленческий проект

Журналы капсул

Runbooks

Бессерверный

Развертывание функций AWS Lambda

Защита ваших развернутых приложений

Группы

Аналитика вклада

Пользовательские шаблоны проектов на уровне группы

Эпос

Управляйте эпосами

Прокси-сервер зависимости

Групповой импорт / экспорт

Insights

Аналитика проблем

Итерации

Публичный доступ

SAML SSO для GitLab.com группы

Обеспечение SCIM

Подгруппы

Дорожные карты

Проекты

Безопасность приложений

Конфигурация безопасности

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

Мониторинг угроз

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

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

Статическое тестирование безопасности приложений

Секретное обнаружение

Динамическое тестирование безопасности приложений

API-фаззинг

Анализ покрытия

Панель безопасности

Автономные среды

Страницы уязвимостей

Интеграция сканера безопасности

Терминология Secure and Defend

Значки

Массовое редактирование

Владельцы кода

Соблюдение

Соответствие лицензии

Панель соответствия

Создать проект

Шаблоны описания

Развернуть ключи

Развернуть токены

Поиск файлов

GitLab Pages

Начиная

Домены по умолчанию, URL-адреса и базовые адреса

CI / CD для GitLab Pages

Пользовательские домены и сертификаты SSL / TLS

Интеграция Let’s Encrypt

Контроль доступа

Перенаправления

Изучение страниц GitLab

Интеграции

Обзор

Бамбук CI

Bugzilla

Пользовательский трекер проблем

Раздор

Электронные письма при нажатии

GitHub

Hangouts Chat

HipChat

Иркер

Jira

Панель разработки Jira

Mattermost уведомления

Команды с косой чертой Mattermost

Команды Microsoft

Макет CI

Прометей

Redmine

Уведомления Slack

Slack команды с косой чертой

Slack приложение

Вебхуки

YouTrack

Insights

Запросы на слияние

Разрешить сотрудничество

Утверждения

Тестирование производительности браузера

Создание запросов на слияние

Изменения кирки вишни

Качество кода

Нагрузочное тестирование производительности

Зависимости мерж-реквестов

Перемотка вперед

Слияние при успешном завершении конвейера

Разрешить конфликты

Отмена изменений

Просмотр и управление мерж-реквестами

Сквош и слияние

Версии

Рабочие процессы

Работа в процессе

Члены

Перенос проектов

Bitbucket Cloud

Сервер Bitbucket

ClearCase

CVS

FogBugz

Гемназия

GitHub

GitLab.com

Гитеа

Jira

Perforce Helix

Фабрикатор

Репо по файлу манифеста

Репо по URL

SVN

TFVC

Параметры push

Релизы

Репозитории

ветви

Атрибуты Git

Git LFS

Заблокированные файлы

Имя файла

История файлов

Зеркальное отображение

Защищенные филиалы

Защищенные теги

Правила push

Уменьшить размер репозитория

Подписанные коммиты

Подсветка синтаксиса

Веб-редактор

Веб-IDE

Требования

Настройки

Импорт / экспорт проекта

Токены доступа к проекту

Делитесь проектами

Фрагменты

Статический редактор сайта

Вики

вопросы

Конфиденциальные вопросы

Проблемы с перекрестными ссылками

CSV экспорт

CSV импорт

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

Сроки выполнения

Доски выпуска

Данные о выпуске и действия

Этикетки

Управление проблемами

Вехи

Графики выгорания

Несколько правопреемников

Связанные вопросы

Служба поддержки

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

Вес

Увеличить масштаб встреч по вопросам

Операции

Панель показателей

Настроить оповещения для показателей

Встраивание показателей в Markdown

Встраивание метрик в Grafana

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

Свойства YAML панели инструментов

Настройки приборной панели

Типы панелей для дашбордов

Использование переменных

Шаблоны переменных для дашбордов

Библиотека метрик

Мониторинг ресурсов AWS

HAProxy

Kubernetes

NGINX

NGINX Ingress

NGINX Ingress VTS

Отслеживание ошибок

Отслеживание

Управление происшествиями

Конечная точка общих предупреждений

Создание предупреждений и управление ими

Подробности оповещения

Создание инцидентов и управление ими

Страница статуса GitLab

Флаги функций

CI / CD

Вступление

Начиная

Включить или отключить

Использование ключей SSH

Переход с CircleCI

Переход с Jenkins

.gitlab-ci.yml Ссылка

Включает примеры

Авто DevOps

Начиная

Требования

Настроить

Этапы

Обновление PostgreSQL

Кеширование

Чат

Развертывание в облаке

Интеграция с докером

Сборка докера

Образы докеров

Канико

Переменные среды

Предопределенные переменные

Где можно использовать переменные

Устаревшие переменные

Среды

Защищенная среда

Примеры

Тестирование производительности браузера

Clojure

Развертывание с Dpl

Эликсир

Сквозное тестирование

Разработка игр

Java с загрузкой Spring

Java с Maven

PHP с PHPunit и atoum

PHP с NPM и SCP

PHP с Laravel и Envoy

Python на Heroku

Рубин на Heroku

Scala на Heroku

Внешние репозитории

Bitbucket Cloud

GitHub

Дополнительные развертывания

Интерактивные веб-терминалы

Большие репозитории

Отчеты по метрикам

Трубопроводы

Архитектура

Эффективность трубопровода

Направленный ациклический граф

Многопроектные трубопроводы

Родительско-дочерние конвейеры

Конвейеры для запросов на слияние

Конвейеры для объединенных результатов

Объединить поезда

Артефакты работы

Расписания

Настройки

Запуск конвейеров

Обзор приложений

Бегунов

Примеры услуг

MySQL

PostgreSQL

Redis

Исправление проблем

CI Lint

Пакеты и реестры

Реестр пакетов

Реестр контейнеров

Прокси зависимости

Репозиторий композитора

Репозиторий Конана

Перейти прокси

Репозиторий Maven

Реестр НПМ

Репозиторий NuGet

Репозиторий PyPI

API

Ресурсы

.gitignore (шаблоны)

.gitlab-ci.yml (шаблоны)

Запросы доступа

Внешний вид (приложение)

Приложения

Аудит событий

Аватар

Наградные смайлы

Значки (проект)

Значки (группа)

ветви

Широковещательные сообщения

Кластеры (проект)

Кластеры (группа)

Кластеры (экземпляр)

Совершает

Реестр контейнеров

Настраиваемые атрибуты

Аннотации на панели инструментов

Зависимости

Прокси зависимости

Развернуть ключи

Развертывания

Обсуждения

Dockerfile (шаблоны)

Среды

Эпос

События

Особенности флаги

Списки пользователей с флагами функций

Периоды заморозки

Географические узлы

Аналитика групповой активности

Группы

импорт

Доски выпуска (проект)

Доски выпуска (группа)

вопросы

Проблемы (эпический)

Статистика проблем

Вакансии

Артефакты работы

Ключи

Этикетки (проект)

Ярлыки (группа)

Лицензия

Лицензии (шаблоны)

Ссылки (проблема)

Ссылки (эпические)

Управляемые лицензии

Markdown

Члены

Утверждение мерж-реквестов

Запросы на слияние

Объединить поезда

Вехи (проект)

Вехи (группа)

Пространства имён

Примечания (комментарии)

Настройки уведомлений

Пакеты

Страницы доменов

Токены личного доступа

Графики трубопроводов

Триггеры конвейера

Трубопроводы

Псевдонимы проекта

Импорт / экспорт проекта

Перемещение хранилища репозитория проекта

Статистика проекта

Шаблоны проектов

Проекты

Защищенные филиалы

Защищенные теги

Релизы

Ссылки на выпуск

Репозитории

Файлы репозитория

Подмодули репозитория

События итерации ресурсов

События ярлыка ресурса

Ключевые события ресурса

События состояния ресурса

События веса ресурса

Бегунов

SCIM

Поиск

Сервисы

Настройки (приложение)

Показатели Sidekiq

Sidekiq очереди

Фрагменты

Фрагменты (проект)

Статистика (приложение)

Предложения

Системные хуки

Теги

Списки дел

Пользователи

Переменные (проект)

Переменные (группа)

Версия

Уязвимости

Выводы уязвимости

Вики

GraphQL

Начиная

Справочник по GraphQL

Создать аудиторский отчет (пример)

Определите доски задач (пример)

от v3 до v4

Lint.gitlab-ci.yml

GitLab как провайдер OAuth3

Пользователь

Отчеты о нарушениях

Счет

Активные сессии

Удалить аккаунт

Разрешения

Токены личного доступа

Настройки профиля

Двухфакторная аутентификация

Обсуждения

Общее

Аутентификация

SSH

Интеграции

Git

Частичный клон

Устранение неполадок Git

Полезные команды

Настройки GitLab.com

Горячие клавиши

Markdown

AsciiDoc

Уведомления по электронной почте

Быстрые действия

Автозаполнение символов

Зарезервированные названия проектов и групп

Поиск

Расширенный глобальный поиск

Синтаксис расширенного поиска

Учет времени

Списки дел

Администратор

Эталонные архитектуры

До 1000 пользователей

До 2000 пользователей

До 3000 пользователей

До 5000 пользователей

До 10 000 пользователей

До 25000 пользователей

До 50 000 пользователей

Исправление проблем

Настроить

Внешность

CI / CD

Пользовательские шаблоны проектов на уровне экземпляра

Пределы различий

Эл. адрес

Флаги функций

Географические узлы

Администрирование Git LFS

Gitaly таймауты

GitLab Pages

Проверка здоровья

Журналы работ

Этикетки

Система журналов

Приложения OAuth

Интеграция с PlantUML

Управление интеграцией проекта

Проверки репозитория

Пути хранения репозитория

Типы хранилищ репозитория

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

Шаблоны услуг

Системные хуки

Часовой пояс

Загрузки

Отчеты о нарушениях

Активировать и деактивировать пользователей

Аналитика

Аудит событий

Блокировать и разблокировать пользователей

Широковещательные сообщения

Elasticsearch

Консул

PostgreSQL

PgBouncer

Репликация и отработка отказа

Служба внешней базы данных

Балансировщик нагрузки

NFS

Redis

Sidekiq

Гитали

Гитали Кластер

Ссылка Gitaly

Метрики

Прометей

Панель производительности

Статистика использования

Хранилище объектов

Операции

Очистить сеансы Redis

Быстрый SSH.

Добавление существующего проекта в GitHub с помощью командной строки

Документы GitHub

• Все продукты

• GitHub.com

• Начиная

  • Быстрый старт
    • Настроить Git
    • Создать репо
    • Форк репо
    • Быть социальным
  • Изучение GitHub
    • Продукты GitHub
    • Изучение выпусков раннего доступа с предварительным просмотром функций
    • Типы аккаунтов GitHub
    • Часто задаваемые вопросы об изменениях в планах GitHub
    • GitHub CLI
    • GitHub Desktop
    • GitHub для мобильных устройств
    • Разрешения на доступ на GitHub
    • Глоссарий GitHub
    • Шпаргалка по Git
    • Учебные ресурсы Git и GitHub
  • Регистрация на GitHub
    • Регистрация новой учетной записи GitHub
    • Подтверждение адреса электронной почты
    • Настройка пробной версии GitHub Enterprise Cloud
    • Настройка пробной версии GitHub Enterprise Server
  • Изучение проектов на GitHub
    • Поиск способов внести свой вклад в открытый исходный код на GitHub
    • Сохранение репозиториев со звездочками
    • Следуя за людьми
  • Использование GitHub
    • Поддерживаемые браузеры
    • Устранение проблем с подключением
    • Горячие клавиши

.