Игнорирование файлов.
В каталоге проекта могут находится файлы временные, создаваемые во время компиляции или во время работы текстового редактора в ходе работы с файлами проекта, логи и прочее. Их, разумеется коммитить не нужно, их не нужно даже отслеживать!А еще лучше, чтобы gitих даже не видел!!
Есть возможность их проигнорировать, создав специальный файл.gitignore, в котором можно перечислить все «лишние» для git’а файлы. Этот файл воспринимает регулярные выражения (regularexpressions), то есть шаблоны.
* - любая строка
? - любой символ
anydir/ – игнорировать каталога anydir и его содержимое.
[a-zA-Z0-9] – алфавит и цифры с любым регистром вместо 1 символа.
test[0-2].js – будут проигнорированы файлы test0.js, test1.js, test2.js
! – знак отрицания.
В файл. gitignore можно вносить комментарии #
Нужно создать этот файл, внести в него «маску» и добавить в индекс, после чего файл начнет «работать», то есть GIT будет игнорировать все, что мы перечислили в этом файле.
Файл.gitignore - это musthave в любом серьезном проекте.
Журнал изменений
$ gitlog
Отсюда видно, кто, когда и что коммитил. Что – в смысле у нас есть уникальный хэш, по которому можно найти изменения, внесенные тем или иным разработчиком.
Можно посмотреть что конкретно было изменено в каждом файле через ключ -p:
$ gitlog –p -3
-3 -означает посмотреть последние 3 коммита, и подробности в правках
Вывод истории можно форматировать очень гибко. Тема достаточно велика. В целом того, что есть здесь, достаточно для рутинной работы.
Понятие ветки. Создание ветки
Ветки (branch)
|
|
Ветка – это работа над проектом с его независимой «копией». На самом деле ничего не копируется. Хорошее представление о ветках вот в этой статье:
https://git-scm.com/book/ru/v1/%D0%92%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2-Git-%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-%D0%B2%D0%B5%D1%82%D0%BA%D0%B0%3F
Сразу после создания репа, вы находитесь в основной ветке разработки master.
$ git branch testing - cоздатьновуюветку
Переключиться на другую существующую ветку:
$ gitcheckouttesting вернуться к последнему коммиту в ветке testingМожно объединить 2 предыдущие команды одной:
$ gitcheckout –b<newbranchname> - создается новая ветка и тут же в нее переключаемся.
… внесли изменения, проверили, закоммитили в новую ветку. Если все хорошо теперь содержимое ветки testing можно влить в основную ветку master.
$ gitcheckoutmaster - перешли в основную ветку
$ gitmergetesting – влили в нее изменения из ветки testing
Еслиновая ветка больше не нужна, ее можно удалить. Удалить новую ветку:
$ gitbranch -dtesting
Иногда слияние невозможно, поскольку файл в последнем коммите в ветке master отличается от файла в последнем коммите в ветке testing. После команды gitmerge GITне сольет ветки и остановится, пока не будет решен конфликт слияния.
На помощь придет gitstatus. Она покажет где исправить. Править можно вручную или при помощи графического инструмента
gitmergetool
Подробно о конфликтах при слиянии – самостоятельно.
Переключиться на определенный коммит и продолжить работу с него
$ gitcheckout -b new-branch 5589877 создать ветку new-branch, начинающуюся с коммитас хэшем 5589877
$gitlog -- graph--all – посмотреть все ветки в виде графа.
Псевдонимы
Сократить ввод команды, обозвав их новыми алиасами.
|
|
$ gitconfig --global alias.co checkout
$ gitconfig --global alias.br branch
$ gitconfig --global alias.ci commit
$ gitconfig --global alias.st status
Модуль 3 (1 пара)
Github
- Регистрация. Обзор интерфейса веб-сервиса.
// зарегистрироваться, пробежаться по пунктам веб-интерфейса.
- Создание удалённого репозитория. Клонирование
- Использование консоли Git в контексте Github
- Установка и использование клиента Github
- Доставка изменений в удалённый репозиторий
Удаленные репозитории.
Это те же централизованные/распределенные системы VCS, находящиеся не локально на машине пользователя, а где-то в сети (закрытой или локальной).Github–один из примеров, самый популярный репозиторий, но правда публичный. Можно поднять свой репозиторий на базе GIT.
Для чего нужен удаленный репозиторий? Чтобы делиться коммитами с другими разработчиками или попросту вести работу совместно над каким-то проектом.
Зарегистрируемся, создадим репозиторий, добавим README
Создадим удаленный репозиторий testrep, дадим ему description, отредактируем ему README.Клонируем его себе на наш клиент, предварительно создав для него каталог (можно не создавать, во время клонирования создастся папка с именем репозитория):
$ git clone https://github.com/almaunicef/testrep.git
Cloning into 'testrep'...
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpackingobjects: 100% (3/3), done.
Действительно создалась такая папка:
$ ls -l | greptestrep
drwxr-xr-x 1 root 197121 0 фев 9 13:42 testrep/
Перейдем в нее и посмотрим на содержимое:
$ cdtestrep/
root@mailsrvMINGW64 ~/testrep (master)
$ ls -l
total 1
-rw-r--r-- 1 root 197121 73 фев 9 13:42 README.md
root@mailsrvMINGW64 ~/testrep (master)
|
|
$ cat README.md
# testrep
my 1st student rep
Hello guys!
And "hello world!" too =)
Добавим в веб-интерфейсе файл.gitignore и подтянем его из репозитория себе на клиент. Как подтянуть? Есть такое понятие как pull. Pull «тянет» что-тооткуда-то.
$ git pull origin
Updating fc04038..6c7b1ba
Fast-forward
.gitignore | 2 ++
1 file changed, 2 insertions(+)
createmode 100644.gitignore
Как видно, к нам подтянулось обновление из репа. Проверим:
$ ls -al
total 14
drwxr-xr-x 1 root 197121 0 фев 9 13:54./
drwxr-xr-x 1 root 197121 0 фев 9 13:42../
drwxr-xr-x 1 root 197121 0 фев 9 13:54.git/
-rw-r--r-- 1 root 197121 11 фев 9 13:54.gitignore
-rw-r--r-- 1 root 197121 73 фев 9 13:42 README.md
root@mailsrvMINGW64 ~/testrep (master)
$ cat.gitignore
*.log
*~
При этом, если в вашем репозитории были файлы с такими же именами, к их содержимому добавиться merge содержимое удаленного репозитория.
Существует еще один метод доставки данных из удаленного репа, fetch. Нужна если вы хотитеполучить все ветки удаленного репозитория, но не сливать с нашими ветками.
А теперь мы экспортируем наш готовый репозиторий в обратном направлении, то есть на сервер, но уже в другой реп, к примеру это другой наш проект. Для начала вернемся в нашу директорию с репозиторием:
$ cd../testdir/
root@mailsrvMINGW64 ~/testdir (master)
$
Теперь нам нужно добавить удаленный репозиторий.
$ git remote add origin https://github.com/almaunicef/testrepv2.git
Эта команда делает следующее: она добавляет URL в качестве удаленного репозитория и дает ему название origin
Посмотрим список удаленныхрепов:
$ gitremote -v
origin https://github.com/almaunicef/testrepv2.git (fetch)
origin https://github.com/almaunicef/testrepv2.git (push)
А теперь отправим в него весь наш проект:
$ gitpush -u originmaster
…при это «вывалится окно с аутентификацией», мы должны подтвердить, что мы являемся владельцем данного удаленного репозитория, чтобы туда что-то отправить
Counting objects: 31, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (23/23), done.
Writing objects: 100% (31/31), 2.57 KiB | 0 bytes/s, done.
Total 31 (delta 9), reused 0 (delta 0)
remote: Resolving deltas: 100% (9/9), done.
Branch master set up to track remote branch master from origin.
To https://github.com/almaunicef/testrepv2.git
* [newbranch] master ->master
Теперь в веб-интерфейсе можно увидеть все наши файлы. И просмотреть детальные изменения для каждого коммита.
Для подробного изучения git:
https://git-scm.com/book/ru/v1
https://github.com/nicothin/web-development/tree/master/git