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

↑

▷ Содержание

⇐ ПредыдущаяСтр 9 из 13Следующая ⇒

Чтобы создать локальный репозиторий, нужно написать:

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

Мы находимся в master ветке, и пока мы не перейдем в другую, так все и останется. Таким образом видно, какие файлы изменены, но еще не добавлены в состояние staged. Чтобы добавить их в состояние staged, нужно написать git add. Здесь может быть несколько вариантов, например:

· git add -A — добавить все файлы из состояния в staged;

· git add. — добавить все файлы из этой папки и все внутренних. По сути тоже самое, что и предыдущее;

· git add <имя файла> — добавляет только конкретный файл. Здесь можно пользоваться регулярными выражениями, чтобы добавлять по какому-то шаблону. Например, git add *.java: это значит, что нужно добавить только файлы с расширением java.

Ясно, что первые два варианта простые, а вот с добавлением будет интереснее, поэтому пишем:

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

Отсюда видно, что регулярное выражение отработало верно, и теперь test_resource.txt находится в staged состоянии. И, наконец, последний этап — закоммитить и создать новый коммит:

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

Здесь уже видно, что появился наш первый коммит с текстом, который мы передали. Очень важно понять, что текст, который мы передаем, должен максимально точно определять то, что было проделано за этот коммит. А что случилось с файлом GitTest.java? Сейчас узнаем, используем для этого:

Как видим, он так и остался в состоянии untracked и ждет своего часа. А может мы вовсе не хотим его добавлять в проект? Бывает и такое. Далее, чтобы стало интереснее, попробуем изменить наш текстовый файл test_resource.txt. Добавим туда какой-то текст и проверим состояние:

Здесь хорошо видна разница между двумя состояниями — untracked и modified. GitTest.java находится в состоянии untracked, а test_resource.txt находится в modified. Теперь, когда уже есть файлы в состоянии modified, мы можем посмотреть на изменения, которые были произведены над ними. Сделать это можно при помощи команды:

То есть здесь хорошо видно, что я добавил в наш текстовый файл hello world! Добавляем изменения в текстовом файле и коммитим:

Чтобы посмотреть на все коммиты, пишем:

Как видим, уже есть два коммита. Таким же образом добавляем и GitTest.java. Теперь без комментариев, просто команды:

Работа с.gitignore

Ясно, что мы хотим хранить только исходный код и ничего другого в репозитории. А что может быть еще? Как минимум, скомпилированные классы и/или файлы, которые создают среды разработки. Чтобы гит их игнорировал, есть специальный файл, который нужно создать. Делаем это: создаем файл в корне проекта с названием.gitignore, и в этом файле каждая строка будет шаблоном для игнорирования. В этом примере гит игнор будет выглядеть так:

Смотрим теперь:

· первая строка — это игнорирование всех файлов с расширением.class;

· вторая строка — это игнорирование папки target и всего, что она содержит;

· третья строка — это игнорирование всех файлов с расширением.iml;

· четвертая строка — это игнорирование папки.idea.

Попробуем на примере. Чтобы посмотреть как это работает, добавим скомпилированный класс GitTest.class в проект и посмотрим статус проекта:

Ясно, что мы не хотим как-то случайно (если использовать git add -A) добавить скомпилированный класс в проект. Для этого создаем.gitignore файл и добавляем все, что описывалось ранее:

Теперь добавим новым коммитом гит игнор в проект:

И теперь момент истины: у нас есть в untracked состоянии скомпилированный класс GitTest.class, который мы не хотели добавлять в гит репозиторий. Вот здесь-то и должен заработать гит игнор:

Все чисто.

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

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

Видно, что у нас только одна ветка master, и звездочка перед ней говорит, что мы находимся на ней. К слову, чтобы узнать, на какой ветке мы находимся, можно воспользоваться и проверкой статуса (git status). Далее есть несколько вариантов создания веток:

· создать новую ветку на основе той, на которой находимся (99% случаев);

· создать ветку на основе конкретного коммита (1%).

Познавательные статьи:



Формы дистанционного обучения

Передача мяча двумя руками снизу

Значение правильной осанки для жизнедеятельности человека

Основные ошибки при выполнении передач мяча на месте