Git - это консольная утилита, для отслеживания и ведения истории изменения файлов, в вашем проекте. Чаще всего его используют для кода, но можно и для других файлов. Например, для картинок - полезно для дизайнеров.

С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.

Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.

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

Часто временные файлы содержат специфические суффиксы, по которым их легко обнаружить и в последствии удалить. Для поиска таких файлов можно воспользоваться командой find. В качестве примера посмотрим, как найти все файлы, которые генерируются компилятором Python и имеют расширение .pyc

Переходим в папку с проектом /home/user/project:

cd /home/user/project

И показываем список файлов с расширением .pyc:

find . -name *.pyc

Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:

find . -name *.pyc -delete

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

Создадим локальный репозиторий в папке с проектом:

После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.

Команды git add и git commit составляют основу рабочего процесса Git. Эти две команды должен изучить и понимать каждый пользователь Git, независимо от модели совместной работы, принятой в его команде. Эти команды используются для записи версий проекта в историю репозитория.

Работа над проектом ведется по стандартной схеме «редактирование — индексирование — коммит». Сначала вы редактируете файлы в рабочем каталоге. Когда вы будете готовы сохранить копию текущего состояния проекта, вы индексируете изменения командой git add. Затем вы вызываете команду git commit, которая добавляет проиндексированный снимок состояния в историю проекта. Для отмены коммита или проиндексированного снимка состояния используется команда git reset.

Если у вас уже есть ветка feature, то после коммита в нее сделайте git checkout master – это переключит текущую ветку на master.

Пока вы не вкоммитили изменения, вы не можете переключиться на другую ветку. Выхода два: вкоммитить изменения или отложить их. Второе можно сделать с помощью git stash – это добавит текущие незакоммиченные изменения в стек изменений и сбросит текущую рабочую копию до HEAD'а репозитория. Далее вы сможете:

git stash list: показать все изменения в стеке git stash show: показать последнее изменение в стеке (патч) git stash apply: применить последнее изменение из стека к текущей рабочей копии git stash drop: удалить последнее изменение в стеке git stash pop: применить последнее изменение из стека к текущей рабочей копии и удалить его из стека git stash clear: очистить стек изменений й# Журнал изменений

Ветка в Git — это простой перемещаемый указатель на один из таких коммитов. По умолчанию, имя основной ветки в Git — master. Как только вы начнёте создавать коммиты, ветка master будет всегда указывать на последний коммит. Каждый раз при создании коммита указатель ветки master будет передвигаться на следующий коммит автоматически.

Создание конфликтов Создает новую ветку с именем new_branch_to_merge_later и выполняет переход в нее. Перезаписывает содержимое файла merge.txt. Выполняет коммит нового содержимого. В этой новой ветке new_branch_to_merge_later мы создали коммит, который переопределил содержимое файла merge.txt. Системы контроля версий предназначены для управления дополнениями, вносимыми в проект множеством распределенных авторов (обычно разработчиков). Иногда один и тот же контент могут редактировать сразу несколько разработчиков. Если разработчик A попытается изменить код, который редактирует разработчик B, может произойти конфликт. Для предотвращения конфликтов разработчики работают в отдельных изолированных ветках. Основная задача команды git merge заключается в слиянии отдельных веток и разрешении любых конфликтующих правок.

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

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

Типы конфликтов слияния Конфликт во время слияния может произойти в двух отдельных точках — при запуске и во время процесса слияния. Далее рассмотрим, как разрешать каждый из этих конфликтных сценариев.

Git прерывает работу в самом начале слияния Выполнение команды слияния прерывается в самом начале, если Git обнаруживает изменения в рабочем каталоге или разделе проиндексированных файлов текущего проекта. Git не может выполнить слияние, поскольку иначе эти ожидающие изменения будут перезаписаны новыми коммитами. Такое случается из-за конфликтов не с другими разработчиками, а с ожидающими локальными изменениями. Локальное состояние необходимо стабилизировать с помощью команд git stash, git checkout, git commit или git reset. Если команда слияния прерывается в самом начале, выдается следующее сообщение об ошибке:

Git прерывает работу во время слияния Сбой В ПРОЦЕССЕ слияния говорит о наличии конфликта между текущей локальной веткой и веткой, с которой выполняется слияние. Это свидетельствует о конфликте с кодом другого разработчика. Git сделает все возможное, чтобы объединить файлы, но оставит конфл

Чтобы удалить ветку из локального Git-репозитория, выполните: git branch -d <имя_ветки> Удалить Удаленную Ветку. Чтобы удалить ветку из удаленного Git-репозитория, выполните: git push origin --delete <имя_ветки>. Для просмотра изменений одного файла, можно воспользоваться следующей командой: Изменения по коммитам git log -p FILE_NAME. Изменения до коммита git diff FILE_NAME Hard Reset. Самый жесткий вариант.

1. Создать аккаунт на GitHub. Если у вас этого нет, запишем полный адрес GitHub.com.

2. Создать локальный репозиторий. Это должны сделать вы. Для этого надо создать папку, внутри неё вызвать команду git init, совершить какие-то действия, создать файлы, чтобы появился хотя бы один коммит.

3. «Подружить» ваш локальный и удалённый репозитории. GitHub при создании нового репозитория подскажет, как это можно сделать.

4. Отправить (push) ваш локальный репозиторий в удалённый (на GitHub), при этом вам, возможно, потребуется авторизоваться на удалённом репозитории. Если сделаете это один раз, «подружите» ваш редактор VS Code с GitHub, в дальнейшем эту операцию проводить уже не понадобится.

5. Провести изменения «с другого компьютера». Естественно, не надо искать другой компьютер. Можете сделать это на GitHub.

6. Выкачать (pull) актуальное состояние из удалённого репозитория.

1. Делаем форк (fork) интересующего нас репозитория. Смотрим на понравившийся репозиторий, куда хотим внести свой вклад, и делаем fork. В это время на нашем аккаунте возникает полная копия этого репозитория. К ней у нас уже будет свой доступ.

2. Делаем git clone для нашей версии этого репозитория. Так появляется версия на нашем аккаунте, и именно эту версию мы клонируем.

3. Создаём ветку с предлагаемыми изменениями.

4. Производим все изменения только в этой ветке.

5. Отправляем эти изменения на свой аккаунт (push), так как на чужой доступа нет.

6. В окне на GitHub появляется возможность отправить pull request.