Smartgit/hg

Graph view

The Graph displays the log graph («history») starting from the selected Branches anchors. Branches/tags and other refs will show up at the «appropriate» commits. In case of File (or Subtree) Logs or filtered Logs (see Filter input field, below), every ref will be mapped to the most recent commit of the graph which is still part of the ref’s history. In case of File (or Subtree) Logs, the file (or subtree) content of the mapped ref commit will be identical to the content of the actual commit to which the refs points. For filtered Logs, there is no such relation between the mapped commit and the actual commit, still you will be able to see which of your filtered commits are part of which ref’s history.

Как пользоваться Git?

Дальше я буду предполагать, что вы выполнили установку и базовую настройку git. Кроме установки, вам нужно указать правильный адрес электронной почты и имя пользователя для доступа к серверу Git, например, на GitHub. Если вы этого еще не сделали смотрите инструкцию установка Git в Ubuntu 16.04.

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

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

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

Эта команда создаст нужную структуру папок и переводит текущий каталог в только что созданный. Теперь создадим первый файл нашего проекта:

Проект готов, но система контроля версий git еще не знает об этом.

Настройка проекта в git

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

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

Если все прошло хорошо, то команда ничего не выведет.

Фиксация изменений

Изменения тоже автоматически не отслеживаются. Фиксация изменений выполняется с помощью команды commit. Вам нужно указать что было изменено с помощью небольшого комментария, буквально в несколько предложений. Хорошая практика выполнять фиксацию перед каждым серьезным изменением.

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

Команде необходимо передать два параметра, первый — это -m, ваш комментарий, второй -a, означает, что нужно применить действие ко всем измененным файлам. Для первого раза используется этот параметр, но обычно вам нужно указать измененные файлы или каталоги. Например, можно делать так:

Отправка изменений

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

Сначала нужно добавить удаленный репозиторий с помощью команды remote. Для этого нужно передать ей URL:

Затем можно посмотреть список удаленных репозиториев:

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

Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.

Управление ветвями

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

Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:

Переключаться между ветвями можно тоже с помощью той же команды:

Теперь создадим еще один файл:

И добавим его в нашу новую ветвь develop:

Сделаем коммит для внесенных изменений:

Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:

Затем переключаемся на ветку master и снова смотрим:

Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:

Перед тем как будет выполнено слияние вам нужно ввести комментарий, зачем это нужно. Затем если вы еще раз выполните ls, то увидите, что здесь уже есть нужный файл. Наши примеры git подошли к концу.

Исправление коммита

Если вы опечатались в комментарии или забыли добавить файл и заметили это сразу после того, как закоммитили изменения, вы легко можете это поправить при помощи commit —amend. Эта команда добавит все из последнего коммита в область подготовленных файлов и попытается сделать новый коммит. Это дает вам возможность поправить комментарий или добавить недостающие файлы в область подготовленных файлов. Для более сложных исправлений, например, не в последнем коммите или если вы успели отправить изменения на сервер, нужно использовать revert. Эта команда создаст коммит, отменяющий изменения, совершенные в коммите с заданным идентификатором. Самый последний коммит может быть доступен по алиасу HEAD:

Для остальных будем использовать идентификаторы:

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

Команда git

Уже по традиции, перед тем, как перейти к примерам и работе с командой давайте рассмотрим ее основные опции и параметры. Синтаксис git очень прост:

$ git опции команда аргументы

Сначала рассмотрим опции, они влияют на работу всей утилиты:

• -C — использовать указанную папку репозитория вместо текущей папки;
• -c параметр=значение — использовать указанное значение параметра конфигурации;
• -p — прокручивать весь вывод с помощью less;

Теперь рассмотрим команды git, их немного больше и именно с помощью них вы будете выполнять все основные действия:

• add — добавить файл или папку в репозиторий git;
• am — применить все патчи из email;
• archive — создать архив файлов;
• bisect — использовать бинарный поиск для поиска нужного коммита;
• branch — управление ветками проекта;
• bundle — перемещение объектов и ссылок в архиве;
• checkout — переключение между ветками;
• cherry-pick — внести изменения в уже существующие коммиты;
• clean — удалить все неотслеживаемые файлы и папки проекта;
• clone — создать копию удаленного репозитория в папку;
• commit — сохранить изменения в репозиторий;
• diff — посмотреть изменения между коммитами;
• fetch — скачать удаленный репозиторий;
• init — создать репозиторий;
• merge — объединить две ветви;
• pull — интегрировать удаленный репозиторий с локальным;
• push — отправить изменения в удаленный репозиторий;
• tag — управление тегами;
• worktree — управление деревями разработки.

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

Possible Problems & Solutions

Authenticating with two or more accounts

If you want to authenticate to your GitHub repositories, using two or more accounts, open Preferences, section Hosting Providers, open the GitHub hosting provider there and deselect Use OAuth token for repository authentication. When pulling/pushing a GitHub repository for the next time, SmartGit will ask you for Username and Password. For the Username, just enter the appropriate GitHub account name, for the Password it’s recommended to generate a new Personal Access Token in your GitHub account settings (the repo scope needs to be selected).

Depending on your Git configuration, Git might request credentials only per-domain instead of per-repository. If so, try to reconfigure:

git config --global credential.github.com.useHttpPath true

Private repositories do not show up

If you are authenticating using OAuth and you can’t see private repositories of your GitHub organization or pushing to your organization’s repositories fails with HTTP error code 403, make sure that your organization allows Third-party access and SmartGit is Approved. Your organization settings might look like this:

Note that the screenshot above shows the interface of the organization’s manager. If you are not the manager, but just a member of the organization, you can request access for SmartGit to this organization from your Settings — Applications, tab Authorized OAuth Apps: select SmartGit here and check for which organizations you may request access. The screenshot below shows  for which access can be requested. Once done so, the organization manager will receive a notification and may confirm.

Git-Flow Pull Requests will be closed on Finish Feature

When using Git-Flow or Git-Flow Light in combination with pull requests, pull requests may be marked as Closed instead of Merged after invoking Finish Feature. This happens when you have Delete Feature Branch selected for the Finish Feature dialog: with this option selected, the local and remote feature branch will be deleted immediately, however the resulting merge/rebase has not yet been pushed. If a branch will be deleted before it has been merged, GitHub will mark the pull request as Closed. If it’s only deleted after the branch has been merged, it will be marked as Merged. If you don’t want your pull requests to become Closed, unselect Delete Feature Branch, push the resulting merge/rebase first and only then Delete the feature branch from GitHub (e.g. from the Branches view).

Основы

Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.

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

Основные операции для работы с git

Clone

Первое, чему стоит научиться – это снимать копию проекта из удалённого репозитория в локальный.
Делается это довольно просто:

Clone

Затем копируем ссылку репозитория, созданного на Гитхабе (шаг 2)

Ссылка на репозиторий

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

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

Commit

Репозиторий готов – пора приступать к работе.
Написанный код мы помещаем в локальный репозиторий  — папку .git (путь к которой мы указали в операции clone).

Добавление файла в локальный репозиторий

Если всё прошло успешно, в окошке SmartGit’а появится скопированный файл.

Новый файл в SmartGit

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

Commit

В открывшемся окне пишем пояснительный комментарий к сохраняемому файлу и снова нажимаем кнопку Commit

Пояснения к Commit’у

Файл сохранён, а изменения внесены в журнал.

Файл отправлен в локальный репозиторий

Push

Теперь заглянем на Github.com в наш удалённый репозиторий. Там до сих пор нет ни одного файла. Нужно срочно менять ситуацию.Чтобы перенести изменения, внесённые в локальный репозиторий, в удалённый репозиторий, необходимо нажать кнопку Push.

Push

К слову, отправить изменения в удалённый репозиторий, нам предлагают ещё в точке Commit’а

Commit & Push

Pull

Возникает резонный вопрос: как получат изменения остальные участники разработки, если они клонировали проект в самом начале?
Для этого существует команда Pull, передающая в локальный репозиторий все изменения, происходящие в удалённом.

Pull

К слову, для командной разработки на Гитхабе есть ещё несколько важных опций.

Перенос информации из сторонних репозиториев на Гитхаб  

Когда нужно собрать разрозненные кусочки кода в один проект, используйте кнопку Import repository и работайте с файлами в удобном репозитории Гитхаба.

Импортировать репозиторий

Кнопка New gist на этой панели предназначена для мгновенного обмена информацией.

А кнопка New organization открывает массу возможностей для командной разработки.

Скрытие (stashing) изменений до коммита

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

При помощи команды можно временно отменить внесенные изменения, не удалив их окончательно:

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

Чтобы вернуть скрытую функциональность, достаточно ввести:

Если же скрытая функциональность больше не нужна, ее можно удалить с помощью:

Отправка изменений на сервер

Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории. Команда, предназначенная для этого — push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

В зависимости от сервиса, который вы используете, вам может потребоваться аутентифицироваться, чтобы изменения отправились. Если все сделано правильно, то когда вы посмотрите в удаленный репозиторий при помощи браузера, вы увидете файл hello.txt

Клиенты Git GUI для Windows:

1. GitHub Desktop

Рабочий стол GitHub в основном является расширением рабочего процесса GitHub. Вы можете войти в систему, используя свои учетные данные GitHub и начать работу с вашими репозиториями. Есть  возможность создавать новые репозитории, добавлять локальные репозитории и выполнять большинство операций Git из пользовательского интерфейса. GitHub Desktop является полностью открытым исходным кодом, и он доступен для MacOS и Windows. Нажмите здесь, чтобы загрузить GitHub Desktop.

2. GitKraken

GitKraken — это независимый разработчик Git для Windows. Он поддерживает GitHub, Bitbucket и Gitlab. GitKraken доступен в бесплатных, премиальных и корпоративных вариантах. Бесплатная версия подходит для небольших команд и стартапов, но вам может потребоваться обновиться после того, как ваша команда и работа будут расширяться.  Перед использованием этого инструмента вам необходимо зарегистрироваться на сайте. Нажмите здесь, чтобы скачать GitKraken.

3. SmartGit

SmartGit — отличный клиент Git профессионального уровня, который можно использовать для некоммерческих организаций. Вы можете свободно использовать его для разработки open-source и бесплатного программного обеспечения. Но вам может потребоваться приобрести лицензию, если вы собираетесь использовать этот инструмент для коммерческих целей. SmartGit охватывает все функции Git и поставляется со всеми функциями для совместной работы. Инструмент даже поддерживает создание pull-запросов на GitHub. Нажмите здесь, чтобы загрузить SmartGit.

4. SourceTree

SourceTree — бесплатный клиент Git, разработанный Atlassian, компанией, стоящей за Jira и Bitbucket. Этот бесплатный клиент Git показывает огромную поддержку репозиториев, размещенных Bitbucket и GitHub. Перед использованием SourceTree вам необходимо создать учетную запись Atlassian. Нажмите здесь, чтобы загрузить SourceTree.

Итог

Итак, это были некоторые из клиентов Git, которые я использовал и нашел полезными. Если вы просто новичок, я бы рекомендовал использовать такой инструмент, как GitHub Desktop или Source Tree. И если вы опытный разработчик, идите на GitKraken и Smart Git.

Спасибо, что читаете! Подписывайтесь на мои каналы в Telegram, и . Только там последние обновления блога и новости мира информационных технологий.

Почему git

1. Распределенность
   Создать репозиторий в локальной папке можно просто написав
2. Наличие стабильного клиента
   Процесс разработки без ветвлений выглядит примерно так: версия… разработка… версия… разработка…
   Видно, что в каждый момент времени наличие стабильной версии, на которой можно поправить баги и зарелизить, не гарантировано. А точнее, получается так, что исправить некий выловленный баг можно только закончив разработку текущей версии. Простые ветки в git позволяют в любое время достать версию любого предыдущего релиза и работать с ней не мешая идущей разработке. Исправить баги в отдельной ветке, смержить в предыдущий релиз и в текущую разработку.
3. Удобство использования
   git хранит все свои данные в одном каталоге, а не плодит повсюду папки .svn. Переключить проект с одной ветки на другую можно всего одной командой или парой кликов в клиенте. При этом содержимое папки проекта заменяется новым, которое соответствует выбранной ветке. Для разных веток не нужно создавать новые папки или проекты. В большинстве случаев, Flash Builder сам обновит все классы и перекомпилит зависимости.
4. Нет необходимости в постоянном конекте к центральному хранилищу
   Как я уже сказал, все комиты сохраняются локально и становятся частью общего репозитория только тогда, когда непосредственно пушатся в него. Это сложно вообразить, но порой получается так, что нет доступа в интернет, а работать нужно. Или вы как обычно забыли настроить VPN к рабочему репозиторию. Радует скорость комитов и ощущение полного контроля над локальной копией.
5. Удобные частичные комиты
   Непосредственно перед комитом помечаются файлы, которые в него войдут с помощью . При этом существует возможность в отдельный комит внести часть изменений в файле, а не файл целиком.
6. Возможность припрятать изменения.
   В git есть интересная возможность — припрятать (stash) незакомиченные файлы и потом достать их снова. Иногда бывает полезно таким образом переносить или временно откатывать изменения, например, я часто забываю переключать ветки.
7. Наличие графических клиентов.
   Для git не такой уж и большой выбор графических клиентов. Мне больше всего понравился GUI клиент SmartGit. Он кроссплатформенный и для некоммерческого использования доступен бесплатно. Обладает всеми нужными функцими, но все же иногда бывает нужно залезть в Terminal и выполнить пару команд git. Хорошо бы в них примерно разбираться. Для Винды есть TortoiseGit, на Маке я пользовался некоторое время GitX, но тогда он был уж сильно хуже, чем SmartGit. Для Eclipse (то есть для Flash Builder) есть плагин EGit, который давно мне чем-то не понравился. Надо будет вернуться к нему еще раз, тем более он только что обновился. Возможно, это не фишка клиента, а часть дистрибутива git, но тем не менее, хочется упомянуть еще классное отображение веток. В сложном проекте выглядит как карта метро Нью Йорка. Люблю я такие абстрактные картиночки.

Log

In the Log window of your repository, you can interact with GitHub in following ways.

Pull Requests

When initially loading the Log, SmartGit will also refresh information on related Pull Requests from the GitHub server:

• Incoming pull requests are those which other users are requesting to pull from their repositories. They are displayed in a separate category called Pull Requests in the Branches view.
• Outgoing pull requests are those which you have sent to other users/repositories, requesting them to pull your changes. They are display directly below the local (or if it does not exist), the remote branch in the Branches view.

Incoming pull requests, in first place, are just known on the server. To get the commits, which such a pull request includes, locally, use invoke Fetch Pull Request from the context menu of the pull request. This will fetch all commits from the foreign repository to a special branch in your local repository and will create an additional merge node between the base commit from which the pull request has been forked and the latest (foreign) pull request commit. When selecting this merge node in the Commits view, you can see the entire changes which a multi-commit pull request includes and you can on these changes, if necessary. After commenting changes, it’s probably a good idea to Reject the pull request to signal the initiator of the pull request, that modifications are required before you are willing to pull his changes. If you are fine with a pull request, you may Merge it. This will request the GitHub server to merge the pull request and then SmartGit will pull the corresponding branch, so you will have the merged changes locally available.

Outgoing pull requests can be Fetched as well, however this is usually not necessary, as the pull request belongs to you and it contains your own commits. If you decide that you want to take a pull request back, use Retract.

For a pull request which had been fetched once, there was a special ref created which will make it show up in the Pull Requests category, even if it is not present on the server anymore. In this case, you may use Drop Local Data on such a pull request to get rid of the corresponding ref, the local merge commit, all other commits of the pull request and the entry in Pull Requests as well. It’s safe to use Drop Local Data, as it will only affect the local repository and you can re-fetch a pull request anytime you like using Fetch again.

You can invoke Review|Sync to manually update the displayed information. Usually you will want to do that, if you know that server-side information has changed since the Log has been opened.

To create a pull request, use Create Pull Request from the context menu of the Branches view.

GitHub allows to comment on a commit itself or individual line changes (diffs). Comments can be applied to a commit or to a Pull Request. Pull Request Comments will be refreshed together with those pull requests which are locally available (see Fetch Pull Request above). Plain Commit Comments will by default not be refreshed for performance reasons. To tell SmartGit to fetch plain commit comments, too, configure in the Preferences, Low-Level Properties.

Both, Pull Request and Plain Commit Comments, can refer either to a commit itself or to a specific line in a file:

• Commit comments will show up in the Commits view.
• Comments on individual lines will show up in the Changes view and the affected files will be highlighted in the Files and Commits view, too. This works the same way for line-comments of Pull Requests, provided that the pull request has been Fetched and the local pull request merge commit has been selected.

Comments can be created, modified and removed using the corresponding actions from the Comments menu or context menu actions in the Commits and Changes view. If a pull request merge commit is selected, only line-comments of the pull request can be manipulated.

More behavior of the GitHub integration can be customized by Low-Level Properties.

Шаг 5. Выбираем Гит-клиент

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

Но вернёмся к git-клиентам.

Самыми популярными гит- клиентами на данный момент являются:

SmartGit

Удобное  приложение гармонично сочетает все необходимые функции и доступную интуитивно понятную систему управления. SmartGit – один из самых удобных графических интерфейсов для профессиональной разработки. Некоммерческая разработка и разработка open-sourse проектов не требуют платной лицензии.

GitHub Desktop

«Родной» графический интерфейс Гитхаба. GitHub Desktop работает под Windows и Mac и практически полностью копирует функционал основного сайта. Работает под той же учётной записью.
Правда, не всегда оперативно справляется с большими программами.

Зато отлично подходит для начала работы с git.

GitKraken

Поддерживает GitHub, Bitbucket и Gitlab.
Кракен очень любят программисты – фрилансеры, которым периодически приходится менять команды, а значит, и условия командной разработки. Возможность работы с разными git-хостингами через привычное приложение со знакомым интерфейсом в таких случаях играет важную роль.

SourceTree

SourceTree позволяет работать с Bitbucket и GitHub. В приложении довольно простой интерфейс, подходящий, как для опытных программистов, так и для новичков.

Why prefer SmartGit as Git Client?

One for All.

This powerful, multi-platform Git client has the same intuitive user interface on Windows, macOS and Linux:

• graphical merge and commit history
• drag and drop commit reordering, merging or rebase

Use your SmartGit license on as many machines and operating systems you like.

Everything Included.

No need to install and configure additional tools.

• command line Git client (Windows, macOS)
• Graphical Merge and Commit History
• Git-Flow
• SSH-client
• File Compare
• File Merge («Conflict Solver»)

Adopt to Your Needs and Workflows.

A commercial Git client should support your work-flows. You can customize SmartGit in various ways:

• Preferences for Merging, Rebasing
• Layout of certain views,
• External tools,
• External or built-in Compare or Conflict Solver tools,
• Keyboard shortcuts,
• Toolbars,
• Syntax coloring,
• Light and dark themes

Interacting with popular platforms.

SmartGit comes with special integrations for GitHub, BitBucket and BitBucket Server (former Atlassian Stash) to create and resolve Pull Requests and Review Comments.

источник

История версий

Версия 3

Версия 3 SmartGit была выпущена 2 марта 2012 и содержит большие изменения, наиболее заметные — миграция GUI с библиотеки Swing на SWT. В результате графический интерфейс SmartGit 3 содержит «родные», а не эмулированные элементы, что приводит к более привычному внешнему виду и поведению интерфейса. Другие заметные изменения в SmartGit 3 включают:

• Поддержка Mercurial
• Поддержка OpenJDK в Linux
• Более компактный экран истории

Версия 4

SmartGit/Hg 4 был выпущен 16 января 2013. Название программы было изменено, чтобы подчеркнуть поддержку Mercurial, которая была наиболее значимым улучшением со времен версии 3. Другие заметные изменения включают:

• Поддержка Git ‘blame’
• Плотно интергрированный интерфейс пользователя для работы с ветками, тэгами, удаленными ветками и stash-хранилищем
• Реорганизация и объединение коммитов в интерактивном режиме

Версия 4.5

SmartGit/Hg 4.5 был выпущен 26 апреля 2013. Наиболее заметные изменения:

• Выделение синтаксиса цветом
• Поддержка внешних инструментов
• Автоматическое обновление
• Необязательные Save Stash/Apply Stash в случае, если определенные команды, то есть Pull, завершатся неудачно из-за локальных изменений.