Файл gitignore - примеры и документация

Дальнейшие коммиты

Давайте изменим несколько файлов после того, как мы их закоммитили. После того, как мы их изменили, сообщит о том, что у нас есть измененные файлы.

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

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

git add -u

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

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

git commit

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

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

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

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

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

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

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

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

По умолчанию включены:

ищет пробелы в конце строки;
ищет пробелы в конце файла;
ищет пробелы перед символом табуляции в начале строки.

По умолчанию выключены:

ищет строки с пробелами вначале вместо символа табуляции (и контролируется настройкой );
ищет символы табуляции в отступах в начале строки;
указывает Git на валидность наличия CR в конце строки.

Указав через запятую значения для настройки , можно сказать Git, какие из этих опций должны быть включены. Чтобы отключить ненужные проверки, достаточно удалить их из строки значений или поставить знак перед каждой из них. Например, чтобы включить все проверки, кроме , выполните команду (при этом является сокращением и охватывает как , так и ):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ищем пару файлов с названиями вида и . Обычно имя — , , или . Файл с расширением — ваш публичный ключ, а второй — ваш приватный, секретный ключ.
Если таких файлов или даже каталога у вас нет, вы можете их сгенерировать. Для этого делаем следующее.
- Открываем консоль и вводим команду:
```
ssh-keygen -t rsa -b 4096 -C "[email protected]"
```
  Указываем тот адрес электронной почты, который вводили при регистрации на GitHub.
  
  Генерируем ключ.
- Далее нужно указать расположение файла для сохранения ключа. Если вы не введёте путь до файла и просто нажмёте Enter, ключ сохранится в файле, указанном в скобках.
- Теперь нужно установить пароль к вашему ключу и дважды ввести его. Если вы не хотите вводить пароль каждый раз, когда используете ключ, пропустите этот шаг, нажав «Enter», и ничего не вводите.
  
  Указываем расположение ключа и вводим пароль.
Добавляем ключ в (сгенерированный или уже существующий). Проверяем доступность ключа командой и добавляем с помощью , где указываем верный путь до файла с ключом и его имя.

Добавляем ключ в shh-agent. Несколько важных примечаний:
- Если вы захотите переименовать ключ, могут возникнуть проблемы. Их можно решить, добавив в связь ключа с доменом.
- Если у вас Windows и вы пользуетесь программой Cmder, возможны проблемы с командой . Может появиться такое сообщение об ошибке:
  «eval не является внутренней или внешней командой, исполняемой программой или пакетным файлом».
  В Сmder для запуска можно использовать команду .
  
  Если проблема осталась, рекомендуем работать в Git Bash.
- Если у вас macOS Sierra версии 10.12.2 и выше, нужно изменить ваш файл, чтобы автоматически загрузить ключи в и хранить пароли.
```
Host *
 AddKeysToAgent yes
 UseKeychain yes
 IdentityFile ~/.ssh/id_rsa
```
  Вы можете добавить свой приватный ключ в и сохранить пароль к нему с помощью команды . Если у вашего ключа другое имя, не забудьте заменить в команде на правильное название.
- Если у вас Linux, может понадобится переназначить для ~/.ssh права доступа командой
После того как создан ключ, его нужно добавить на GitHub. Для этого копируем его содержимое с помощью одной из следующих команд:
- Если вы на Windows
- Для пользователей macOS
- На Linux используйте , чтобы установить необходимый для копирования пакет , а затем введите
Можно пойти другим путём, открыть файл прямо в папке и просто скопировать содержимое оттуда.
Переходим на страницу для работы с ключами в вашем профиле на GitHub.

Страница с настройками ключей в вашем профиле.

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

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

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

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

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

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

Теперь после настройки Git мы можем создать наш первый Git-репозиторий. Перейдите в каталог ваших проектов:

$ cd path/to/project

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

$ git init

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

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

$ git status

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

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

$ git add index.html style.css

Если вы предпочитаете отслеживать все ваши файлы в рабочем каталоге, просто введите:

$ git add .

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

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

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

$ git commit -m "Initial Commit"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

git merge username-project/master

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

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

git pull

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

git pull username-project --tags

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

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

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

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

* платные уроки

список обновляется…

Коммиты

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

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

Советы для эффективного введения в Git:

Коммитьте как можно чаще.
Одно изменение — один коммит: не помещайте все не связанные между собой изменения в один коммит, разделите их, чтобы было проще откатиться.
Формат сообщений: заголовок должен быть в повелительном наклонении, меньше 50 символов в длину и должен логически дополнять фразу (this commit will fix bugs — этот коммит исправит баги). Сообщение должно пояснять, почему был сделан коммит, а сам коммит показывает, что изменилось.
Если у вас много незначительных изменений, хорошим тоном считается делать небольшие коммиты при разработке, а при добавлении в большой репозиторий объединять их в один коммит.

История коммитов в Git

Коммиты хранят состояние файловой системы в определённый момент времени и указатели на предыдущие коммиты. Каждый коммит содержит уникальную контрольную сумму — идентификатор, который Git использует, чтобы ссылаться на коммит. Чтобы отслеживать историю, Git хранит указатель HEAD, который указывает на первый коммит (мы следуем по цепочке коммитов в обратном порядке, чтобы попасть к предыдущим коммитам).

Мы можем ссылаться на коммит либо через его контрольную сумму, либо через его позицию относительно HEAD, например ссылается на коммит, который находится 4 коммитами ранее HEAD.

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

На этом основное введение в Git заканчивается, и начинается более глубокое изучение.

Интерактивная подготовка

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

— показывает для каждого файла краткое описание того, что (не)подготовлено;
— подготавливает отслеживаемые файлы;
— убрать один или несколько файлов из подготовленной области;
— подготавливает неотслеживаемый файл;
— подготавливает только часть файла (полезно, когда вы, например, изменили несколько функций, но хотите разбить изменения на несколько коммитов). После выбора файла вам будут показаны его фрагменты и представлены возможные команды: . Можно ввести , чтобы узнать, что делает каждая команда;
— показывает список подготовленных файлов и позволяет посмотреть изменения для каждого из них;
— выходит из интерактивной консоли;
— показывает краткое описание каждой команды.

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

Правка истории

Для большего контроля над историей коммитов локальной ветки можно использовать команду , которая откроет интерактивную консоль для перемещения набора последних n коммитов, перечисленных в порядке от старых к новым (то есть в том порядке, в котором они будут перемещены). Таким образом вы можете «редактировать историю», однако помните, что оригинальные коммиты нельзя изменить, только переместить.

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

Изменение сообщения/разбивка коммитов

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

После завершения редактирования введите .

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

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

Объединение нескольких коммитов

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

Перенос отдельного коммита

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

Обратите внимание, что таким образом создаётся новый коммит, который только повторяет diff выбранного коммита (то есть разницу между этим коммитом и предыдущим), но не его состояние. Закрепите введение в Git информацией о типичных ошибках в данной VCS и способах их решения

Закрепите введение в Git информацией о типичных ошибках в данной VCS и способах их решения.

Перевод статьи «The Ultimate Beginner Git Cheatsheet»

Ветви в GIT

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

Исправная, стабильная версия кода не будет повреждена;
Люди могут безопасно разрабатывать собственные версии отдельно друг от друга;
Разработчики могут работать на своей ветви без опасения, что кто-то изменит их код;
Когда разработчики не уверены, как сделать лучше, они могут работать над своими версиями в отдельных ветвях, а затем сравнить результаты между собой.

1. Создание новых ветвей – git branch

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

Тем самым вы создаёте новую ветвь, на данном этапе одинаковую с master.

2. Смена ветвей – git checkout

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

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

3. Объединение ветвей – git merge

Наша «новая версия» будет просто другим текстовым файлом под названием feature.txt. Мы создадим его, добавим и зафиксируем.

Далее мы вернемся в ветвь master.

Теперь, если мы откроем наш проект в файловом менеджере, мы заметим, что feature.txt исчез. Это потому, что мы вернулись в master-ветвь, и здесь feature.txt так и не был создан. Чтобы перенести его сюда, нам нужно объединить две ветви вместе командой , применив изменения, сделанные в amazing_new_feature, к основной версии проекта.

Ветвь master обновлена, а ветвь awesome_new_feature branch больше не нужна и мы можем её удалить.

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

С этого момента мы будем проходить уроки на примере тестового сайта site-git.
Проект содержит три файла: index.html, css/main.css и .gitignore. По мере прохождения уроков будем понемногу расширять сайт, вносить изменения и добавлять новые файлы.

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

Создайте на github новый приватный репозиторий site-git.
Скачайте архив с файлами сайта и распакуйте содержимое в папку site-git

Обратите внимание на .gitignore

Кроме index.html и main.css в архиве лежит еще скрытый файл .gitignore.
Это файл, в котором прописаны папки и файлы, которые git не отслеживает.
Подробнее о .gitignore мы поговорим во второй части курса

После этого нужно инициализировать репозиторий, как мы делали в прошлом уроке.
Не забудьте поправить имя Webdevkin на свое.

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

Вводная

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

Git позволяет легко отслеживать все изменения, видеть добавленные и удаленные файлы в проекте, а также изменения в самих файлах.
Если мы изменим хоть один символ в коде, git заметит это изменение и уже не потеряет.
Команды git status и git diff (от слова difference — разница) позволяют отслеживать все изменения в проекте.

git status

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

Также git status выводит некоторую дополнительную информацию, которую мы изучим позже.

В PhpStorm — окно Version Control (Вызов окна — Alt+9)

git diff

Это команда для просмотра изменений в файлах. В терминале мы видим добавленные и удаленные строки.
То есть если в строке изменился хоть один символ, то git diff покажет 2 строки: одну удаленную, другую — добавленную.

Просмотр всех изменений

Просмотр изменений в отдельном файле

Изменения в PhpStorm

В онке Version Control мы сразу видим список измененных файлов. Чтобы посмотреть изменения в конкретном файле, нужно кликнуть на него и нажать Crtl+D (diff).
В окне difference видны не только добавленные и удаленные строки, но и изменения в отдельных строках.

Плюсы PhpStorm

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

PhpStorm отлично интегрируется с git. Конечно, не он один.
Некоторые продвинутые редакторы кода тоже могут работать с git.
Вы можете посмотреть, как реализована поддержка git, например, в sublime, но это далеко не так удобно, как в IDE от JetBrains.
Это не реклама, а просто совет использовать удобные инструменты.

PhpStorm платная программа (9 $/месяц на январь 2020 года), но это затраты, которые окупятся. Рекомендую.

Поддержка git в Sublime Text 3

В Sublime Text 3 ситуация несколько изменилась — поддержка git улучшилась.
Подробнее рассмотрим работу с git в sublime во второй части курса

На этом все. В конспекте информации мало, только основные команды, поэтому смотрите видеоурок. Там все нагляднее и понятнее.

В следующем уроке мы познакомимся с коммитами и научимся с ними работать.

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

Следующий урок ⇨
Урок 4. Коммиты и история коммитов

⇦ Предыдущий урок
Урок 2. Создание и клонирование репозитория

What’s The Point Of .gitignore?

In most projects, there’s a difference between code/config, and generated files from that code or config. The latter is usually not useful, and can generally be ignored.

Usually, you only want the code and config to be tracked through git. This is because the generated files are ephemeral, and if you delete them, you can just regenerate them again. There’s often no point to uploading them, as they will simply complicate things and cause unnecessary merge conflicts.

This is a broad definition, so lets look at an example. In Node JS projects, there is a folder called that contains all the external packages that your code needs to run. You can delete this directory and completely rebuild it by running , which uses the configuration to search for packages.

So what’s the point of having the folder in Git? There isn’t one really, as it’s more complicated, can cause issues, and can even drastically increase the size of the Git repo in many cases.

If you ignore the whole directory, all of your coworkers can still generate their own local copy from the file. So, instead, only should be tracked in Git. Most things that get added to follow this pattern. Build artifacts, like a folder, don’t get committed since they’re a direct result of the code itself.

Other things can also be added to for convenience. MacOS generates system files called , which you can always ignore. Perhaps you store API keys in that you don’t want being tracked in source control, you can add those too. Caches, logs, and other output can usually be ignored.

GITHUB

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

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

После того как у вас будет создан аккаунт в Github можно будет начать полноценно работать с ним.

Копирование репозитория Git в локальную папку

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

Копировать или клонировать репу c GitHub можно по HTTPS или SSH.

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

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

Смотрим статус:

Добавление данных в Git или коммит (commit)

Создаем файл с текстом:

Смотрим статус:

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

Снова смотрим статус, видим что у нас появился новый файл example.txt, добавляем данный файл в репозиторий используя git commit:

Отправка данных в онлайн Git репозиторий

Отправить данные в репу можно используя команду git push:

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

Добавляем удалённый репозиторий

Репозиторий — это файловое хранилище проектов. На бесплатном тарифе можно загружать до 500 МБ данных и создавать неограниченное количество репозиториев.

Чтобы создать репозиторий, нажмите на кнопку New repository, назовите проект и кликните Create repository. Можно добавить описание проекта, сделать его публичным или приватным и прикрепить технические файлы:

README file содержит подробное описание проекта — так другие разработчики узнают, какой репозиторий они смотрят и зачем он нужен.
Gitignore позволяет сэкономить место и не заливать на GitHub лишние файлы. Например, можно исключить скрытые файлы Mac OS.
License добавляет к коду ссылку на первоисточник и защищает права разработчика. Лицензия позволяет понять, как правильно использовать чужой код и можно ли его свободно внедрять в коммерческие проекты.

Мы создаём тестовый репозиторий, поэтому обойдёмся без лицензии — выберем только два дополнительных файла: README file и gitignore. Если вы пока не знаете, что писать в README file и что добавлять в gitignore, — оставьте эти файлы пустыми или посмотрите инструкцию в разделе Read the guide.

Мы создали публичный репозиторий и будем хранить файлы в папке test
Мы создали публичный репозиторий и будем хранить файлы в папке test

Переходим на сайт gitignore.io.
Добавляем macOS или другую операционку, с которой вы работаете.
Жмём Create и получаем нужный служебный файл.
Копируем данные и переносим их в файл gitignore на GitHub.

После редактирования gitignore делаем коммит — записываем в историю проекта факт того, что мы установили ограничение для файлов Mac OS.

Просмотр изменений в истории

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

показывает изменения в каждом коммите;

показывает сокращённую статистику для коммитов, например изменённые файлы и количество добавленных/удалённых строк в каждом их них;

показывает n последних коммитов;

и позволяет отфильтровать коммиты по промежутку времени, например покажет коммиты с 1 января 2019 года;

позволяет указать формат логов (например, ), также можно использовать для большей кастомизации, например ;

и фильтруют коммиты с сообщениями/изменениями кода, которые содержат указанную строку, например, позволяет посмотреть добавление/удаление функции;

пропускает коммиты со слиянием веток;

позволяет посмотреть, какие коммиты из ветки 2 не находятся в ветке 1 (полезно при слиянии веток)

Например, покажет, каких коммитов из ветки test нет в master (о ветках поговорим чуть позже).

показывает коммиты, которые есть либо в ветке 1, либо в ветке 2, но не в обеих; знак обозначает коммиты из , а — из .Обратите внимание: используется три точки, а не две;

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

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

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

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

Примечание Не путайте с ! Первый ищет по файлам среди коммитов, а последний смотрит на сообщения логов.

Шаг 1 — Знакомство с вкладкой Source Control

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

Откройте Visual Studio Code и запустите встроенный терминал. Вы можете открыть его, используя сочетание клавиш в Linux, macOS или Windows.

Используя терминал, создайте каталог для нового проекта и перейдите в этот каталог:

Затем создайте репозиторий Git:

Также вы можете сделать это в Visual Studio Code, открыв вкладку Source Control (иконка выглядит как развилка дороги) в левой панели:

Затем нажмите кнопку Open Folder:

При нажатии кнопки откроется проводник файлов, где будет открыт текущий каталог. Выберите предпочитаемый каталог проекта и нажмите Open.

Затем нажмите Initialize Repository:

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

Вы увидите созданный каталог :

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

После этого на панели Source Control вы увидите, что рядом с именем вашего нового файла отображается буква U. Обозначение U означает, что файл не отслеживается, то есть, что это новый или измененный файл, который еще не был добавлен в репозиторий:

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

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

Чтобы записать изменения, введите команду отправки в поле ввода в верхней части панели Source Control. Затем нажмите иконку отметки check для отправки файла в репозиторий.

После этого вы увидите, что несохраненных изменений нет.

Теперь добавьте немного содержания в файл .

Вы можете использовать ярлык Emmet для генерирования базовой структуры кода HTML5 в VS Code, нажав , а затем клавишу . Теперь добавьте что-нибудь в раздел , например, заголовок , и сохраните файл.

На панели исходного кода вы увидите, что ваш файл изменился. Рядом с именем файла появится буква M, означающая, что файл изменен:

Для практики давайте запишем это изменение в репозиторий.

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