Часто используемые команды
Чтобы инициализировать Git в репозитории, вам просто нужно ввести следующую команду. Если вы не инициализируете Git, вы не сможете запускать другие команды Git в этом репозитории.
Если вы используете GitHub и отправляете код в репозиторий GitHub, который хранится в Сети, вы используете удаленный репозиторий. Имя, установленное по умолчанию для этого удаленного репозитория, называется origin (источник), он же alias (псевдоним). Если вы скопировали проект из GitHub, у него уже есть источник. Вы можете просмотреть этот источник с помощью команды git remote -v. Она выдаст вам URL-адрес удаленного репозитория.
Если вы инициализировали свой репозиторий Git и хотите связать его с репозиторием на GitHub, вам придется создать его на GitHub, скопировать предоставленный URL-адрес и использовать команду git remote add origin <URL>, где <URL> — ссылка на репозиторий GitHub. Оттуда вы можете добавлять, коммитить и пушить в удаленный репозиторий.
Допустим, вы скопировали чей-то удаленный репозиторий и хотите изменить его владельца на свою учетку GitHub. Схема такая же, как с git remote add origin, с одним дополнением: используйте set-url, чтобы изменить удаленный репозиторий.
Самый распространенный способ скопировать репозиторий — через git clone с указанием URL.
Имейте в виду, что удаленный репозиторий будет связан с учетной записью, из которой вы его клонировали. Поэтому если вы скопировали чей-то репозиторий, вы не сможете отправить его на GitHub, пока не измените источник, используя приведенные выше команды.
Вы быстро поймете, что ветки — это удобно. Если вы не знаете, что это такое, поищите руководство по этой теме. Это понадобится в дальнейшем.
Команда git branch перечислит все ветки на вашем компьютере. Если вы хотите создать новую ветку, можете использовать команду git branch <name>, где <name> — имя ветки (например, master).
Команда git checkout <name> переключит на существующую ветку. Поэтому чтобы создать новую ветку и сразу же переключиться на нее, можете использовать команду git checkout -b <name>. Обычно эту команду используют, чтобы не писать отдельно git branch, а отдельно git checkout.
Если вы внесли кучу изменений в ветку и хотите смержить ее в основную ветку (назовем ее develop), используйте команду git merge <branch>. Если захочется при этом сначала провести checkout основной ветки, тогда запустите git merge develop, чтобы смержить develop в основную ветку.
Если вы работаете еще с кем-то, может случиться так, что репозиторий обновили на GitHub, но у вас изменения не появились. В этом случае используйте git pull origin <branch>, чтобы получить последние изменения указанной удаленной ветки.
Если вам интересно узнать, какие файлы изменили, можете использовать git status. Если вы хотите увидеть, насколько сильно был изменен файл, используйте git diff, чтобы увидеть количество измененных строк.
Windows
2. Лицензионное соглашение
На первом экране вам предложат согласиться с условиями лицензии GNU GPL. Внимательно их прочитайте, после чего нажмите кнопку (как показано на скриншоте):
Выберите путь для установки Git (лучше его оставить по умолчанию) и нажмите кнопку (как показано на скриншоте):
4. Компоненты для установки
Удостоверьтесь, что выбранные опции (флажки) соответствуют приведённым на скриншоте (они выбраны по умолчанию) и нажмите кнопку (как показано на скриншоте):
Оставьте значение по умолчанию и нажмите кнопку (как показано на скриншоте):
6. Редактор по умолчанию
Выбранный по умолчанию редактор (Vim) достаточно тяжёл для новичков, поэтому выберите из выпадающего списка опцию и нажмите кнопку (как показано на скриншоте):
Чуть позже в рамках нашего курса настроим Git на использование другого редактора.
7. Переменная окружения PATH
На данном этапе необходимо выбрать, добавлять ли Git в переменную окружения . Это набор путей файловой системы, в которой ищутся запускаемые файлы. Если для вас это звучит не понятно — не расстраивайтесь, эта информация нам не особо нужна. Выберите опцию и нажмите кнопку (как показано на скриншоте):
️ Внешний вид этого пункта может отличаться в новых версиях. Выбирайте пункт с подписью Recommended
8. HTTPS
Необходимо выбрать библиотеку, которая будет использована для HTTPS-соединений. Оставьте выбранной опцию и нажмите кнопку (как показано на скриншоте):
9. Символы окончания строки
Символы, обозначающие окончание строки различаются в Windows и Unix-подобных ОС (Mac OS, Linux, FreeBSD), поэтому выберите опцию и нажмите кнопку (как показано на скриншоте):
10. Терминал
На данном экране вам предлагают выбрать какой терминал (командную строку) вы будете использовать с Git. Оставьте выбранной по умолчанию опцию и нажмите кнопку (как показано на скриншоте):
11. git pull
Поведение по умолчанию для . Оставьте выбранной опцию Default (fast-forward or merge) и нажмите кнопку (как показано на скриншоте):
12. Credential Manager
Выберите значение None и нажмите кнопку (как показано на скриншоте):
Убедитесь, что установлен флажок только на и нажмите кнопку (как показано на скриншоте):
Убедитесь, что все экспериментальные опции отключены и нажмите кнопку (как показано на скриншоте):
Дождитесь завершения установки и нажмите кнопку (как показано на скриншоте):
Проверка установки
Кликните правой кнопкой мыши на любой папке в Windows, в открывшемся контекстном меню должны появиться две новых опции (как показано на скриншоте):
Выберите опцию . Вы должны увидеть окошко, похожее на то, что показано на скриншоте:
Где — имя вашего пользователя, — имя вашего компьютера.
Вы можете настроить фон, шрифты, цвета и остальные параметры кликнув на заголовке окна правой кнопкой мыши и выбрав из выпадающего меню пункт (как показано на скриншоте):
Если что-то пошло не так
Вы можете удалить Git через Панель Управления и установить его заново. В любом случае, обязательно сделайте скриншот ошибки и пришлите его и номер шага (на котором произошла ошибка) нашим ассистентам — они вам обязательно помогут.
Коммиты
Коммит в git репозитории хранит снимок всех файлов в репозитории. Почти как огромная копия, только эффективнее.
Git пытается быть лёгким и быстрым, так что он не просто слепо копирует весь проект каждый раз, а ужимает коммит в набор изменений или «дельту» между текущей версией и предыдущей. Это позволяет занимать меньше места.
Также Git хранит всю историю о том, когда какой коммит был сделан и кем
Это очень важно, можно посмотреть из-за кого упал прод и навалять ему. Файлы в репозитории могут находиться в 3 различных “областях”
Файлы в репозитории могут находиться в 3 различных “областях”.
- HEAD
- Индекс
- Рабочий каталог
Наш проект сейчас пуст. Давайте создадим первый файл:
На данном этапе только область “Рабочий каталог” содержит данные.
Рабочий проект это ваша папка с файлами, в данном случае это . Две другие области сохраняют свое содержимое внутри каталога в понятном и удобном для git формате, но не понятном для человека. Рабочий Каталог распаковывает их в файлы, что упрощает для нас их редактирование.
Считайте Рабочий Каталог песочницей, где вы можете опробовать изменения перед коммитом. На данном этапе вы можете в любой момент очистить все изменения и вернуться к последнему коммиту.
Сделаем снимок текущего состояния проекта, то есть сделаем коммит. Для этого необходимо сначала добавить содержимое “Рабочего Каталога” в Индекс. Индекс — это черновик коммита. Только файлы из индекса попадают в коммит.
Без добавления файла в Индекс у нас не получится создать коммит, проверьте это сами:
Для добавления в Индекс используется следующая команда:
Когда у вас много файлов, вы можете добавить их все разом .
Теперь сделаем наш первый коммит, выполнив команду . Тем самым мы сохраним содержимое Индекса как неизменяемый снимок в области . Хорошей практикой считается коротко описать, что было изменено, для этого используется флаг :
Все, коммит готов. И файл попал в область . будет родителем следующего созданного коммита. Как правило, самое простое считать снимком вашего последнего коммита. Возможно пока не совсем понятно что такое , но о нем мы еще поговорим.
Если сейчас выполнить , то мы не увидим никаких изменений, так как все три области одинаковые.
Теперь мы хотим внести изменения в файл и закоммитить его. Мы пройдём через всё ту же процедуру; сначала мы отредактируем файл в нашем рабочем каталоге. Давайте называть эту версию файла v2 и обозначать красным цветом.
Теперь посмотрим, какие изменения произошли в git:
Нам подсказывают, что изменения не попадут в коммит, пока мы не сделаем . Выполним эту комманду чуть позже, пока добавим новый файл:
Еще раз проверяем статус репозитория:
Новый файл появился в списке не отслеживаемых, то есть в Рабочем Каталоге. Давайте добавим в отслеживание этот файл, а так же измененный ранее.
Теперь у нас есть изменения, которые будут включены в коммит. Значит можно сделать второй коммит:
Я уже упоминал, что у коммитов есть родитель, который указывает на предыдущий коммит. Из таких цепочек складывается “ветка”. О ветках мы поговорим в следующей статье. Пока достаточно знать, что по умолчанию у нас уже есть ветка .
Для удобства восприятия визуализируем наши коммиты. Кружочки это коммиты, а стрелочки между ними указывают на родителей.
Доступ к GitLab по ssh
Перейдите в домашнюю директорию и сгенерируйте ключ с помощью
ssh keygen
cd
ssh-keygen -t rsa -b 2048
Ключ проще всего назвать
gitlab_com_rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/Andrei/.ssh/id_rsa): gitlab_com_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in gitlab_com_rsa
Your public key has been saved in gitlab_com_rsa.pub
The key fingerprint is:
SHA256:wAhrNr63vvUrQvhP6dbekTHlk6wtP7Y+fIJWnpLyCQN Andrei@DESKTOP-OP43ER5
The key&339;s randomart image is:
+——-+
| . . |
| 2 = + . |
|E * = = |
| . + . B . |
| … =+ S |
| .. .. =. |
| .o..*=+ |
| ..=J=*+o. |
| +PP=+*= |
+———+
Создайте файл
config
touch ~/.ssh/config
vi ~/.ssh/config
Копируем содержимое ключа в буфер.
В
Windows
GitBash
cat ~/.ssh/gitlab_com_rsa.pub | clip
В
Linux
если стоит
xclip
xclip -sel clip < ~/.ssh/gitlab_com_rsa.pub
GitLab.com
Пример
Теперь можно клонировать из GitLab по SSH
mkdir test
cd test
git init
touch .gitignore
git clone [email protected]:ВАШ_АККАУНТ/ИМЯ_ПРОЕКТА.git
Как изменить имя пользователя и почтовый ящик глобальной инициализации git?
http-equiv=»Content-Type» content=»text/html;charset=UTF-8″>yle=»margin-bottom:5px;»>Теги: git Git изменить имя пользователя электронной почты
запись
1. Если вы не инициализированы. Так прямо:
Это может быть инициализировано.
Поэтому вам нужно использовать следующий метод:
Тогда проверьте это
Установлено, что модификация прошла успешно.
Интеллектуальная рекомендация
1. Для реальных сигналов (для понимания): A (ω) является соотношением амплитуды выходного сигнала и амплитуды входного сигнала, называемого частотой амплитуды. Φ (ω) — это разница межд…
Один. вести Многие люди задавали некоторые вопросы о создании проекта Flex + LCDS (FDS) в сообщениях и группах. Из-за операции ее трудно четко объяснить, поэтому я написал простой учебник (я обещал эт…
package com.example.phonehttp; import android.os.Bundle; import android.os.Handler; import android.app.Activity; import android.widget.ScrollView; import android.widget.TextView; public class MainActi…
Он предназначен для реализации подкласса того же родительского класса с родительским классом. Полиморфизм Один и тот же ссылочный тип использует разные экземпляры для выполнения разных операций; Идея …
тема: Объедините два упорядоченных слоя в новый заказанный список и возврат. Новый список состоит из всех узлов двух связанных списков, данных сплавным. Пример: Анализ: два связанных списка состоит в …
Вам также может понравиться
D. Самая ценная строка Пример ввода 2 2 aa aaa 2 b c Образец вывода aaa c На самом деле, будучи задетым этим вопросом, вы должны быть осторожны. После инвертирования строки, если две строки имеют один…
Given a 2D integer matrix M representing the gray scale of an image, you need to design a smoother to make the gray scale of each cell becomes the average gray scale (rounding down) of all the 8 surro…
calc () может быть очень незнакомым для всех, и трудно поверить, что calc () является частью CSS. Поскольку он выглядит как функция, почему он появляется в CSS, поскольку это функция? Этот момент такж…
Основываясь на дереве регрессии, сформированном CART, а также на предварительной и последующей обрезке дерева, код выглядит следующим образом:…
Откат Обновление в режиме онлайн с версии Centos (CentOS Linux версии 7.3.1611 (Core) до CentOS Linux версии 7.5.1804 (Core)) # ошибка соединения yum-ssh после обновления yexpected key exchange group …
¶ Как создавать репозиторий?
Шаг 1. Зайдите в свой аккаунт на GitLab и нажмите на иконку «Groups» в верхней панели.
Шаг 2. Затем перейдите во вкладку «Your group».
Шаг 3. Выберите команду с названием вашего учебного проекта.
Шаг 4. Вы перешли на страницу своей команды. Теперь нужно создать репозиторий. Для этого нажмите на кнопку «New project».
Если у вас уже есть нужный вам репозиторий, то перейдите к шагу 6.
Шаг 5. Напишите название вашего репозитория и добавьте нужные данные. Готово!
Шаг 6.
Перенос существующего репозитория
Если у вас уже есть репозиторий на MIEM GitLab, то его легко можно перенести:
- Для этого зайдите на страницу нужного вам проекта. Далее перейдите в настройки.
- Опуститесь до раздела «Advanced» и разверните его с помощью кнопки «Expand».
- Найдите внутри блок «Transfer project» и с помощью селектора выберите новое расположение.
Перенос существующего репозитория с другой платформы
Если проект был создан на другой платформе (Github, Bitbucket и т.д.), то при создании нового репозитория откройте вверху вкладку «Import project» вместо «Blank project», а затем выберите » Repo by URL».
Подробнее о миграции проектов.
При этом вся информация по коммитам будет перенесена. Однако, чтобы она корректно отображалась и учитывалась в статистике, необходимо, чтобы коммиты были сделаны с почты @miem.hse.ru. Если коммиты были сделаны с другой почты, то необходимо добавить ее адрес в личном кабинете в Git.miem.hse.ru (подробнее в блоке «Коммит»)
Прочие команды и необходимые возможности
Хэш — уникальная идентификация объектов
В git для идентификации любых объектов используется уникальный (то есть с
огромной вероятностью уникальный) хэш из 40 символов, который определяется
хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты,
файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла,
то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки
в сорок символов.
Больше всего нас интересует тот факт, что хэши идентифицируют коммиты. В этом
смысле хэш — продвинутый аналог ревизий Subversion. Несколько примеров
использования хэшей в качестве способа адресации.
Ищет разницу текущего состояния проекта и коммита за номером… сами видите,
каким:
То же самое, но оставляем только шесть первых символов. Git поймет, о каком
коммите идет речь, если не существует другого коммита с таким началом хэша:
Иногда хватает и четырех символов:
Читает лог с коммита по коммит:
Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно
поэтому были введены другие объекты — тэги.
git tag — тэги как способ пометить уникальный коммит
Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит,
имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик
может оставлять на таких тегах собственную цифровую подпись.
Кроме этого в git представленные так называемые «легковесные тэги» (lightweight
tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило,
используются для упрощения навигации по дереву истории; создать их очень легко.
Создаёт «легковесный» тэг, связанный с последним коммитом; если тэг уже есть,
то еще один создан не будет:
Помечает определенный коммит:
Удаляет тег:
Перечисляет тэги:
Создаёт тэг для последнего коммита, заменяет существующий, если таковой уже был:
После создания тэга его имя можно использовать вместо хэша в любых командах
вроде git diff, git log и так далее:
Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо
информации, вроде номера версии и комментария к нему. Иными словами, если в
комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по
имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».
Создаёт обычный тэг для последнего коммита; будет вызван текстовый редактор для
составления комментария:
Создаёт обычный тэг, сразу указав в качестве аргумента комментарий:
Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от
команд для «легковесных» тэгов.
Относительная адресация
Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один
механизм — относительную адресацию. Например, можно обратиться прямо к предку
последнего коммита ветки master:
Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам
коммитов слияния:
Ищет изменения по сравнению со вторым предком последнего коммита в master; HEAD
здесь — указатель на последний коммит активной ветки.
Аналогично, тильдой можно просто указывать, насколько глубоко в историю ветки
нужно погрузиться.
Что привнес «дедушка» нынешнего коммита:
То же самое:
Обозначения можно объединять, чтобы добраться до нужного коммита:
Файл .gitignore — объясняем git, какие файлы следует игнорировать
Иногда по директориям проекта встречаются файлы, которые не хочется постоянно
видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов,
временные файлы и прочий мусор.
Заставить git status игнорировать определенные файлы можно, создав в корне или
глубже по дереву (если ограничения должны быть только в определенных директория)
файл .gitignore. В этих файлах можно описывать шаблоны игнорируемых файлов
определенного формата.
Пример содержимого такого файла:
Существуют и другие способы указания игнорируемых файлов, о которых можно узнать
из справки git help gitignore.
Серверные команды репозитория
Команда создания вспомогательных файлов для dumb-сервера в $GIT_DIR/info и
$GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки
и пакеты есть на сервере:
Проверяет сколько объектов будет потеряно и объём освобождаемого места при
перепаковке репозитория:
Переупаковывает локальный репозиторий:
init
Начать отслеживать изменения — инициализаци или начало работы Git
$ git init
Initialized empty Git repository in C:/Users/aolegovich/Desktop/Sites/hello-world/.git/
По умолчанию репозиторий хранится в подкаталоге с названием «.git» в
корневом каталоге рабочей копии дерева файлов, хранящегося в репозитории.
Любое файловое дерево в системе можно превратить в репозиторий git, отдав команду создания репозитория
из корневого каталога этого дерева (или указав корневой каталог в параметрах программы)
Важно понимать, что инициализировать репозиторий нужно в директории с проектом.
На одном копьютере могут быть десятки проектов и каждый из них может иметь свой репозиторий,
который, в свою очередь может быть подлючён к github, gilab или куда-то ещё.
Перейдя из одной директории в другую вы перемещаетесь между этими репозиториями. Благодаря файлам
.gitinit git автоматически понимает, что вы уже в другом месте и работаете с
другим проектом.
Можно настроить ваш терминал
bash
или zsh так, чтобы он показывал вам
с каким именно репозиторием вы работаете и какая ветка активна.. Создать файл
Создать файл
$ touch index.html
push
Отправить новые данные на удалённый репозиторий
$ git push origin master
Enumerating objects: 83, done.
Counting objects: 100% (83/83), done.
Delta compression using up to 4 threads
Compressing objects: 100% (81/81), done.
Writing objects: 100% (83/83), 3.36 MiB | 3.19 MiB/s, done.
Total 83 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To https://github.com/andreiolegovichru/travel-site.git
* master -> master
Если нужно делать push из другой ветки — просто напишите её называние вместо master
git push origin some/other/branch_name
Enumerating objects: 30, done.
Counting objects: 100% (30/30), done.
Delta compression using up to 8 threads
Compressing objects: 100% (26/26), done.
Writing objects: 100% (26/26), 6.32 KiB | 6.32 MiB/s, done.
Total 26 (delta 7), reused 0 (delta 0)
remote:
remote: To create a merge request for some/other/branch_name, visit:
remote: https://gitlab.yourcompany.com/Project/Project/merge_requests/new?merge_request%5Bsource_branch%5D=some%2Fother%2Fbranch_name
remote:
To gitlab.ssh.com:IAM/IAM.git
abcdefdc8..abcdef000 topic/qa/init_perf_test_controller -> topic/qa/init_perf_test_controller
¶ Клонирование репозитория
Для получения копии существующего Git-репозитория необходимо ввести в терминале команду .
Клонирование репозитория осуществляется командой:
После вы должны ввести имя пользователя и пароль от своей учетной записи в GitLab.
Вы можете в любой момент перейти к папке с вашим репозиторием с помощью команды:
Следующая команда показывает, что файл «README.md» скачался и лежит в нашей папке:
Заполнение данных
Если указана опция , то эти настройки достаточно сделать только один раз, поскольку в этом случае Git будет использовать эти данные для всего, что вы делаете в этой системе. Если для каких-то отдельных проектов вы хотите указать другое имя или электронную почту, можно выполнить эту же команду без параметра в каталоге с нужным проектом.
Если вы хотите проверить используемую конфигурацию, можете использовать команду , чтобы показать все настройки, которые Git найдёт:
Добавление файлов в репозиторий
Одной из важнейших команд является . Система отслеживает изменения, и с помощью этой команды мы узнаем о состоянии системы. Если выполнить эту команду сразу после клонирования, то можно увидить что-то вроде этого:
Это означает, что у вас чистый рабочий каталог. Другими словами, в нем нет отслеживаемых измененных файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь.
Если у вас уже есть некоторые файлы, которые нужно перенести в репозиторий, вы можете скопировать их в рабочий каталог.
Как переключаться между коммитами и создавать ветви¶
Для того, чтобы переключиться к более старой версии кода необходимо найти хеш идентификатора коммита в истории проекта. Посмотреть его можно в комманде , как было описано выше. Для переключения на необходимый коммит используется команда:
$ git checkout commit
— первые 4 (или более) символа контрольной суммы SHA-1, увидеть можно с помощью команды . Постарайтесь ничего не изменять в проекте после переключения на более старый код, т.к. здесь требуется комбинация довольно хитрых шагов, без выполнения которых вы рискуете поломать репозиторий. Используйте такое переключение только для того, чтобы ознакомиться со старым кодом. Чтобы переключиться обратно на последний коммит, достаточно указать той же команде текущую ветку разработки:
$ git checkout master
В Git есть механизм, позволяющий создавать параллельную версию вашего кода, не затрагивая основной, и делать с ней всё, что душе угодно. Этот механизм основан на использовании ветвей. Для создания ветви используются команды:
$ git branch iss53 $ git checkout iss53
Первая команда создает ветвь, вторая переключает на нее. В параллельной ветви мы можем делать различные изменения, которые пока что не затронут нашу главную ветвь . Делается это для удобства программиста и для того, чтобы случайно не сломать что-нибудь в ветви .
Когда мы закончили изменения в новой ветви , то чтобы влить эти изменения обратно в необходимо сначала переключиться, а затем выполнить команду слияния ветвей:
$ git checkout master $ git merge iss53
Теперь изменения из попали в .
После настройки Git вы можете перейти к настройке удаленного репозитория, как описано в статье Управление репозиториями.
Что такое VCS?
Системы контроля версий (СКВ, VCS, Version Control Systems) позволяют откатить проект до старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.
Репозиторием называют хранилище вашего кода. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске. Также есть хостинги репозиториев, такие как GitHub и GitLab, которые позволяют хранить проект в интернете.
VCS позволяют нескольким разработчикам работать над одним проектом и сохранять внесённые изменения независимо друг от друга. При этом каждый участник команды видит, над чем работают коллеги.
