Показаны сообщения с ярлыком Git: система управления версиями для всех. Показать все сообщения
Показаны сообщения с ярлыком Git: система управления версиями для всех. Показать все сообщения

Git: система управления версиями для всех. Меньше теории, больше практики

1. Что такое система контроля версий?
2. Типы систем контроля версий
3. Чем отличается Git от других VCS?
4. Установка Git на Windows/Linux/Mac
5. Создание репозитория
6. Конфигурация Git
7. Как добавить файл в репозиторий Git?
8. Как исключить файлы из репозитория Git?
9. Как откатить изменения?
10. Встроенная система помощи
11. Внос (push) и забор (pull) изменений для удаленного источника (remote source) 
12. Git хостинг Bitbucket 
13. Связывание репозитория с удаленным хранилищем (remote origin)
14. Возобновление работы 
15. Работа в локальной сети 
16. git shortlog
17. git log
18. git clean
19. Теги 
20. Как делать слияние (merge) и разрешать возникающие конфликты 
21. Варианты использования ветвления 
22. Создание, добавление контента, и слияние ветвей
23. .config файл - алиасы
24. Git: система управления версиями для всех. За кулисами - основы основ

24. Git: система управления версиями для всех. За кулисами - основы основ

git init

Данная команда создает папку .git, вот ее содержимое:
  • hooks/ - это настраиваемые скрипты, которые могут встраиваться в различные Git команды и операции. Можно написать собственный hook и он попадет в эту папку. По умолчанию после git init создаются несколько hook-ов с именами файлов hook_name.sample, они остаются не активированными пока не будут переименованы hook_name. git help hooks выдаст больше информации по этой теме.
  • info/ - доп. информация о репозитории. Единственный файл внутри exclude содержит master список файлов, которые исключаются из мониторинга Git-ом. Отличается от .gitignore тем что любой шаблон исключений записанный в exclude отражается только на локальный репозиторий и не влияет на последующие клоны. А .gitignore является частью истории и может быть подвергнут другим командам: add, commit, merge, clone, pull, push.
  • config - project/repository-specific configuration file
  • description - user-defined описание репозитория, которое используется программой gitweb для отображения клиентам листинга репозитория. Пакет gitweb поставляется вместе со стандартной инсталляцией и нужен для предоставления веб-интерфейса к репозиториям.
  • objects/ - все что попадает под Git, рассматривается как объекты. Объекты бывают 4 типов: blobs (binary large object), trees (служат для внутреннего представление папок и структуры контента проекта, Git tree objects могут ссылаться на Git blobs и/или другие Git tree objects), commits (метаданные внесенных изменений: автор изменения, committer изменения, e-mail адреса, дата, время), и tags ("человеческие" имена для других объектов, обычно для commit-ов чтобы их было легче искать).
  • HEAD - указатель на активную ветвь. Например, для master branch: ref: refs/heads/master, а для test_release branch: ref: refs/heads/test_release
  • refs/ - SHA-1 IDs важных точек в репозитории, таких как tags (refs/tags) и branches (refs/heads). Каждый branch name это файл в refs/heads и этот файл содержит SHA-1 ID для commit-а конкретно из которого (parent по другому) создался данный branch. То же самое для tags - каждый tag это файл в папке refs/tags который имеет единственный SHA-1 ID на который он ссылается. Если папки heads и tags будут устроены иерархически то это просто означает что использовалось hierarchically structured name для branch или tag (например, git branch kamia/kashin приводит к heads/kamia/kashin).
  • index - содержимое этого файла станет следующим commit-ом. Это то место где Git хранит staging area information. Или другими словами это то место где хранятся файлы которые пользователь хочет за-commit-ить в репозиторий.

23. Git: система управления версиями для всех. Меньше теории, больше практики. .config файл - алиасы

CLI

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

Пример:
git config --local alias.ad add
git config --local alias.st status


Теперь если открыть файл .config
[alias]
ad = add
st = status


Мы только что создали алиасы для команд add (git ad) и status (git st).

Еще пример, изменяем файл .config:
[alias]
ad = add
st = status
ast = !git add . && git st
bco = "!f(){ git branch ${1} && git checkout ${1}; };f"
ct = "!f(){ git commit -m \"${1}\";};f"


Надо обратить внимание что эти изменения применяются только к текущему репозиторию. Чтобы сделать их глобальными надо вносить изменения в .gitconfig по пути C:\Users\your_username (или ~/ если ОС Mac или Linux).

Любую shell команду надо предварять символом !
${1} - значение параметра от пользователя (check_branch)

Далее, создаем ветку: Git bco check_branch
Создадим файл testfile.txt
Добавим все изменения и проверим статус: Git astИ делаем commit: Git ct "Created test branch, file to practice alias functionality"

GUI

Заходим в Tools | Add
В поле Name вводим Add and status
В поле Command вводим git add . && git status
После нажатия на Add в меню Tools появится пункт Add and status

22. Git: система управления версиями для всех. Меньше теории, больше практики. Создание, добавление контента, и слияние ветвей

CLI

1)
mkdir BCT
cd BCT

participants.txt
Finance team
 Charles
 Lisa
 John
 Stacy
 Alexander

2)
git init
git add .
git commit -m 'Initial list for finance team'

3)
Создадим новую ветвь marketing
git checkout -b marketing
или так
git branch marketing
git checkout marketing

participants.txt
Marketing team
 Collins
 Linda
 Patricia
 Morgan

4)
git add .
git commit -m 'Unfinished list of marketing team'
git checkout master

5)
participants.txt
Finance team
 Charles
 Lisa
 John
 
git add .
git commit -m "Final list from Finance team"
git checkout marketing

6)
participants.txt
Marketing team
 Collins
 Linda
 Patricia
 Morgan
 Amanda

git add .
git commit -m "Initial list of marketing team"

7)
git merge master

git merge branch_name сливает current/active ветвь с указанной ветвью. Даже после слияния ветвь продолжает существовать пока не будет удалена git branch -d branch_name (в случае если ветвь создавалась без умысла дальнейшего слияния с другой ветвью и нужно просто удалить всю ветвь то используется -D вместо -d).

Получим merge конфликт, который надо разрешить (20. Как делать слияние (merge) и разрешать возникающие конфликты).


8) Список ветвей можно просмотреть командой git branch


master является ветвью по умолчанию.
Ветвь со звездочкой является активной в данный момент ветвью.
Git показывает активную ветвь в скобках (branch_name).

9) gitk


GUI

1)
Branch | Create (Ctrl + N)


В поле Name надо ввести имя ветви и нажать кнопку Create, произойдет автоматическое переключение на созданную ветвь.

2)
Repository | Visualize All Branch History

21. Git: система управления версиями для всех. Меньше теории, больше практики. Варианты использования ветвления

Имя ветви не может содержать следующие символы:
  • space
  • white space character
    colon (:)
  • question mark (?)
  • tilde (~)
  • caret (^)
  • asterisk (*)
  • open bracket ([)
  • не может заканчиваться на forward slash (/), например можно my/name, но нельзя myname/, my/.name тоже нельзя потому что после / есть точка
  • имена не могут содержать две подряд идущие точки (..)
Причины для ветвления могут быть разными:

1. Исправление ошибок. Например, работа идет над P2, и вдруг найдена ошибка в P1. Возникает необходимость не сбрасывая работу над P2 переключиться на P1, исправить ошибку и потом переключиться на P2 чтобы продолжить работу.


2. Ветвление при каждом продвижении к следующей фазе. Например P1 от разработчиков посылается команде тестирования, а найденные ими ошибки исправляются в ветке development (v1.1 и v1.2) и сливаются потом с веткой testing, от которой потом ответвляется ветка production или release, к которой имеют доступ целевые пользователи.


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




20. Git: система управления версиями для всех. Меньше теории, больше практики. Как делать слияние (merge) и разрешать возникающие конфликты

[1] Создание репозитория и потом из него bare репозитория

1) Создадим новую папку collab_source
2) Создадим в этой папке текстовый файл mycontent.txt с содержимым:
Unchanged first line from source
Second line
Third line

3) Сделаем из папки collab_source репозиторий Git и сделаем commit файла mycontent.txt с описанием "Base commit from source".
4) Создадим bare репозиторий:
git clone --bare /your/path/to/collab_source /your/path/to/bare_collab


[2] Как участникам команды присоединится к работе

git clone /path/to/repository/bare_collab /path/of/local/copy/Bob_collab
git clone /path/to/repository/bare_collab /path/of/local/copy/Lisa_collab


Дерево commit-ов выглядит на данном этапе следующим образом:


[3] Bob делает изменения

1) Он меняет первую строку и содержимое становится таким:
First line from source - Changed by Bob
Second line
Third line


2) Далее он добавляет изменения и фиксирует их:
git status
git add .
git commit -m 'Bobs first commit after changing the first line'
git log

3) Далее ему надо передать (push) свои изменения в общий bare репозиторий, но по хорошему сначала надо извлечь (pull) изменения, которые успели передать (push) члены команды до вас:
git pull
git push


[4] Lisa делает собственные изменения

1) Ее изменения выглядят так:
Unchanged first line from source = Not any more ;) - Lisa
Second line
Third line
Fourth line by Lisa


2) Далее она добавляет изменения и фиксирует их:
git status
git add .
git commit -m 'Lisa's first commit after changing the first line and adding a new fourth line'
git log

3) Далее перед тем как передать (push) свои изменения в общий bare репозиторий, она делает извлечение (pull) изменений, которые успели передать (push) другие члены команды:

Возник merge конфликт

[5] Разрешение merge конфликта

1) Если Lisa откроет файл то увидит следующее:
<<<<<<< HEAD
Unchanged first line from source = Not any more ;) - Lisa
=======

First line from source - Changed by Bob
>>>>>>> 9bab0336e6c9ab984b538f1f7724bf8a9703f55e

Second line
Third line
Fourth line by Lisa


2) Есть следующие варианты:
  • Указать порядок и применить оба изменения (т.е. и Боба и Лизы);
  • Удалить имеющиеся изменения и наложить ваши изменения;
  • Удалить ваши изменения и применить извлеченные;
  • Удалить оба.
3) Рассмотрим первый вариант. Лиза чувствует что изменения Боба более важные и придает им высший порядок. Поэтому она открывает файл и делает следующие изменения:
First line from source - Changed by Bob
Unchanged first line from source = Not any more ;) - Lisa
Second line
Third line
Fourth line by Lisa


Чтобы не делать изменения вручную можно использовать интерактивный инструмент meld. В нем есть три вида (local, base, и remote).  Local - это текущая модифицированная версия, base - это прежняя версия без вашей модификации, и remote - это модифицированная удаленная версия. Используя доступные стрелки и индикаторы можно упорядочить изменения.

git add .
git commit -m "Merge - Posted Bob's change to the top followed by mine"
git status
git log

git push


C3 - локальный commit от Лизы
C2 - commit от Боба
С4 - новый commit представляющий собой объединенние C3 и C2

4) Чтобы посмотреть граф истории через Git Gui надо зайти в Repository | Visualize all branch history:


В CLI режиме можно воспользоваться командой git log --graph

git log --graph

[6] Синхронизация остальных членов команды с bare репозиторием

1) Боб может обновиться следующим образом:
git pull
git log

2) Материнский репозиторий можно обновить следующим образом:
git remote add origin /path/to/bare_collab
git pull –u origin master

Добавление remote это одноразовая операция, т.е. добавив однажды можно потом добавлять не нужно.


19. Git: система управления версиями для всех. Меньше теории, больше практики. Теги

Теги прицепляются к commit-ам чтобы можно было обращаться к ним по имени тега, а не по SHA1 ID:
  • git checkout 2e361b44
  • git checkout edge_v1.1

Есть два типа тегов:
  • простые - только имя
  • аннотированные - имя, автор, время

Простые теги

git tag
Показывает все имеющиеся теги

git tag edge_v1.1
Создание тега с именем edge_v1.1

Также можно просмотреть теги в gitk

Чтобы посмотреть изменения для commit-a с тегами надо выполнить команду git show <tagname> например, git show edge_v1.1

Аннотированные теги

git tag –a ann_v1.1 –m 'Annotated tag v1.1'

Удаление тегов

git tag –d edge_v1.1
git tag –d Ann_v1.1

18. Git: система управления версиями для всех. Меньше теории, больше практики. git clean

git status

Неудачная распаковка архива readme_package.zip привела к тому что в папке появились "левые" файлы
git clean –f –e*.txt
  • force (–f) означает удалять файлы которые не были под мониторингом (чтобы не указывать каждый раз этот параметр можно поставить в конфигурации clean.requireForce = false)
  • –e задает шаблон для исключения файлов попадающих под критерий

В данном случае т.к. все .txt файлы исключены, то удалится только readme_package.zip

Удалим остатки командой:
git clean –f




17. Git: система управления версиями для всех. Меньше теории, больше практики. git log

git log --skip=2
--skip=number  количество пропускаемых последних commit-ов.

git log --since=2008-09-08 --until=2008-09-09
--since=date - стартовая дата
–until - конечная дата
Также можно использовать относительные даты:
–since=2.days
--since=3.months

git log --grep="Merge"
Можно производить поиск по ключевым словам, за это отвечает параметр –grep
Чтобы выполнить поиск без учета регистра надо воспользоваться параметром -i




16. Git: система управления версиями для всех. Меньше теории, больше практики. git shortlog

git shortlog
Показывает commit-ы пользователей в упорядоченном виде по алфавиту. В скобках указано количество commit-ов.


git shortlog -n
Показывает commit-ы пользователей в упорядоченном виде по количеству commit-ов.

git shortlog -e
Показывает commit-ы пользователей и их (пользователей) метаданные.

git shortlog -s
Показывает количество commit-ов от каждого пользователя.


15. Git: система управления версиями для всех. Меньше теории, больше практики. Работа в локальной сети

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

Есть два способа решения этой проблемы:
  • Gitolite server;
  • общая папка с bare-репозиториями.

Удалённый репозиторий — это обычно голый (чистый, bare) репозиторий — Git-репозиторий, не имеющий рабочего каталога. Поскольку этот репозиторий используется только для обмена, нет причин создавать рабочую копию на диске, и он содержит только данные Git'а. Проще говоря, голый репозиторий содержит только каталог .git вашего проекта и ничего больше.

Рабочий каталог - это каталог в котором размещены наши исходные файлы. Например файл content.docx в Workbench.

Bare-репозиторий действует как посредник между всеми клонами и вашим исходным репозиторием, который содержит рабочий каталог. Нельзя просто так передавать (push) от клона к источнику клона, если источник содержит рабочий каталог.


CLI:
git clone --bare C:\Users\raviepic3\Desktop\Workbench C:\generic_share\
Bare_Workbench

Данная команда создает bare clone репозитория Workbench в общей папке generic_share.

GUI:

1) Скопировать .git каталог из существующего репозитория и вставить его с другим именем different_name.git вне репозитория.
Например копируем C:\Users\raviepic3\Desktop\Workbench\.git в C:\generic_share\Bare_Workbench.git

2) Открыть config файл внутри Bare_Workbench.git и установить в нем bare = true


14. Git: система управления версиями для всех. Меньше теории, больше практики. Возобновление работы

CLI:

1) Клонируйте Git репозиторий:
git clone https://raviepic3@bitbucket.org/raviepic3/online_
workbench.git /path/where/you/would/like/the/clone_to_be

2) Сделайте нужные вам изменения.
3) Подготовьте и зафиксируйте изменения:
git add *
git commit –m 'Your commit message'
git pull
git push

git add используется для подготовки изменений.
git commit для фиксации изменений.
git pull для проверки на не синхронизированные изменения с сервером.
git push для обновления файлов на сервере изменениями которые были зафиксированы в локальном репозитории.

Вместо git pull здесь можно было использовать:
git fetch
git merge @{u}

GUI:

1) Клонируем репозиторий через Git GUI | Clone Existing Repository
Вбиваем следующие данные:
Source location https://your_name@bitbucket.org/username/online_workbench.git
Target Directory /Path/where/you/want/to/have/the_cloned_repository_for_ease_of_work

2) Сделайте нужные вам изменения.
3) Подготовим и зафиксируем изменения.
4) Синхронизируем новые изменения файлов на сервере с локальным репозиторием через меню Remote | Fetch from | Origin
5) Теперь нужно сделать слияние этих двух рабочих пространств. Первое из них local master, которое вы используете для внесения изменений.  Второе remote master которое находится на сервере. Заходим в меню Merge | Local merge


Оставляем по умолчанию значение origin/master в списке и делаем Merge.
В случае успеха содержимое сервера будет синхронизировано (down-synced) с вашим.
6) Теперь нужно синхронизировать (up-sync) наше содержимое с сервером. Заходим в меню Remote | Push

13. Git: система управления версиями для всех. Меньше теории, больше практики. Связывание репозитория с удаленным хранилищем (remote origin)

CLI:

cd /path/to/your/Workbench/repo
git remote add origin https://your_bitbucket_repo_identity_here/online_workbench.git
git push -u origin master

origin - это псевдоним (alias) для пути к удаленному репозиторию
git remote add - команда для добавления Git репозитория точнее его пути в конфигурацию текущего репозитория для того чтобы изменения в одном репозитории отслеживались также и в другом.

С помощью команды push мы отсылаем данные в удаленный репозиторий. Данные из текущей ветки (в нашем случае это ветка master) отсылаются в ветку master удаленного репозитория origin. Флаг -u это по сути синоним флагу --set-upstream у команды git branch. Здесь мы сразу отправили данные на сервер и связали текущую ветку с той веткой, в которую мы отправляли эти данные.

Параметр -u origin master устанавливает remote branch по умолчанию, который используется в действиях push и pull над репозиторием. Если -u не использовался изначально, то для каждого pull и push запроса надо указывать вместе с запросом origin master.

GUI:

1) Открываем Git GUI окно для нашего Workbench репозитория

2) Переходим в меню Remote | Add... (Ctrl + A) и вводим:
Name: origin
Location: https://your_bitbucket_repo_identity_here/online_workbench.git
или

https://YOUR_LOGIN:YOUR_PASSRORD@bitbucket.org/YOUR_LOGIN/YOUR_PROJECT.git

Further Action: Do Nothing Else Now

3) Чтобы передать наш код в репозиторий online_workbench нужно зайти в меню Remote | Push, появится окно Push Branches


По умолчанию в списке Source Branches будет выбран master. А в списке Remote из группы Destination Repository по умолчанию будет выбран origin.

В случае успеха ветка master из локального репозитория Workbench будет синхронизирована с веткой master репозитория online_workbench.

12. Git: система управления версиями для всех. Меньше теории, больше практики. Git хостинг Bitbucket

У компании Atlassian есть продукт Bitbucket - один из множества Git хостингов (есть еще GitHub, Codaset и другие). Предлагаются безлимитные приватные и публичные репозитории. Единственное ограничение количество пользователей приватного репозитория - 5 человек, которые могут имеют права на запись и чтение.

В Bitbucket есть горячие клавиши, чтобы получить по ним справку нужно нажать Shift + ?

Создадим новый репозиторий через меню Repositories | Create repository (c + r) для импорта нашего репозитория Workbench на этот онлайн портал.

Далее предлагаются два варианта начала работы:
  • I'm starting from scratch - создайте у себя новую папку, инициализируйте ее как репозиторий, и привяжите ее к только что созданному удаленному Bitbucket репозиторию;
  • I have code I want to import - привяжите ваш существующий репозиторий к только что созданному удаленному Bitbucket репозиторию, и внесите ваш контент в него.
В случае выбора импорта существующего репозитория появятся инструкции для CLI режима:


11. Git: система управления версиями для всех. Меньше теории, больше практики. Внос (push) и забор (pull) изменений для удаленного источника (remote source)

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

git fetch
Используется для извлечения (fetch) изменений с источника (source) на получатель (destination).

git merge
Слияние используется для объединения двух рабочих пространств (branches) в одно. Часто используется для объединения текущего рабочего пространства с рабочим пространством от удаленного пользователя, после забора изменений с удаленного источника (remote source).

git pull
git pull == (git fetch + git merge)

git push
Используется для передачи (push) нашего контента с источника (source) на получатель (destination).

git remote
Используется для управления своим источником (source) и получателем (destination). Т.е. где и как вы можете поделиться своей работой с остальными. Любые операции связанные с обменом данных подразумевают удаленные подключения, которые обеспечиваются git remote. git fetch, git push, и git pull используют удаленные подключения.


10. Git: система управления версиями для всех. Меньше теории, больше практики. Встроенная система помощи

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

9. Git: система управления версиями для всех. Меньше теории, больше практики. Как откатить изменения?

Временный откат (checking out)

GUI

Checking out - это процесс переключения между всеми за-commit-енными изменениями.

Можно вернуться к предыдущему commit-у чтобы просмотреть содержимое какого-нибудь файла и потом снова вернуться к последней версии файла.

Меню Repository | Visualize All Branch History открывает gitk:


Цветные кружки показывают сделанные commit-ы, а справа от них комментарии.
SHA1 ID это commit ID, который используется для отката/наката изменений.
Если теперь в Git Gui зайти в Branch | Checkout (Ctrl + O), вставить в поле Revision Expression какой-нибудь SHA1 ID и нажать Checkout то произойдет переход на эту ревизию.

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

Чтобы вернуться к последним изменениям надо сделать в Git Gui:
1) Branch | Checkout
2) Выбрать Localbranch и затем master
3) Нажать кнопку Checkout

CLI

Используются команды:
git log
git checkout ___commit_id___

git log показывает историю репозитория предоставляя следующую информацию: commit ID, автор, дата, и комментарий.

При указании commit ID достаточно указывать первый 5 символов вместо всех 40.


Чтобы вернуться к последним изменниям достаточно дать команду:
git checkout master

Примечание: когда вы возвращаетесь на предыдущий commit вы "парите в воздухе" потому что все изменения которые вы сделаете исчезнут при возврате к master.

Перманентный откат (reset)

Есть три типа resetting-а:

  • Soft
  • ‹‹Hard - игнорировать все изменения сделанные после commit-а
  • ‹Mixed

GUI

1) В Git Gui переходим в меню Repository | Visualize All Branch History, откроется Gitk.
2) Нажимаем правой кнопкой мыши на commit-e и выбираем Reset master branch to here.
3) В появившемся окне выбираем тип resetting-а.
4) File | Reload (Ctrl + F5) чтобы перезагрузить Gitk.

CLI

git log
git reset --hard 8b4fe


8. Git: система управления версиями для всех. Меньше теории, больше практики. Как исключить файлы из репозитория Git?

Для того чтобы исключить какие-то файл из по мониторинга Git надо создать в корне репозитория файл .gitignore и добавить в него правило:


В данном случае исключаться будут файл подходящие под маску ~*.*
Т.е. все файлы начинающиеся с символа ~ и с любым расширением.

Реальный пример применения. Вы работаете с файлом content.docx, а Word создает временный файл ~$ontent.docx, который нет необходимости добавлять в репозиторий, т.к. он существует только пока открыт Word, а после закрытия удаляется. Такие файлы можно добавлять в список игнорируемых.

7. Git: система управления версиями для всех. Меньше теории, больше практики. Как добавить файл в репозиторий Git?

[1] Подготовка

Термины:
Unstaged Changes - изменено (не будет сохранено)
Staged Changes - подготовлено (будет сохранено)

GUI:
1) Добавить файл в репозиторий
2) В Git GUI нажать Rescan или F5
3) Для того чтобы перевести файл из Unstaged Changes в Staged Changes надо на панели Unstaged Changes нажать на иконку страницы слева от файла.

Для массового добавления файлов можно использовать горячую клавишу Ctrl + I

Чтобы отменить добавление файла можно аналогично на панели Staged Changes нажать на иконку страницы слева от файла.

CLI:
1) Добавить файл в репозиторий
2) Воспользоваться командами:
git status
git add content.docx

git status является аналогом Rescan (F5)

Для массового добавления файлов можно использовать команды:
git add .
git add *.docx

git add . является аналогом Ctrl + I


Чтобы отменить добавление файла надо дать команду:
git reset filename.extension

[2] Фиксация изменений (Committing)

Мы подготовили изменения (Staged Changes) для фиксации. Теперь их нужно зафиксировать для закрепления нового этапа измененных файлов.

К каждому commit-у можно делать пометку.

GUI:


Каждый commit имеет свой идентификатор.

CLI:
git commit –m "your comments for the commit"


6. Git: система управления версиями для всех. Меньше теории, больше практики. Конфигурация Git

Пункт Options из меню Edit открывает окно конфигурации:

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

Для начала указания имени и e-mail будет достаточно.

Как всегда то что можно сделать через GUI можно сделать и через CLI:

git config --global user.name "your full name"
git config --local user.name "your full name"
git config --global user.email "your email id"
git config --local user.email "your email id"
git config -l


Если вы закрыли и снова хотите открыть Git GUI для своего репозитория то это можно сделать как минимум двумя способами:
  • выбрать его в списке Open Recent Repository;
  • зайти в папку репозитория и в контекстном меню выбрать Git GUI here.