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

Предположим, у нас в репозитории есть файл firstFile.txt и репозиторий актуален у первого и второго пользователей:

 

Второй пользователь вносит свои изменения и делает commit:

 

.. А затем push:

 

Убедимся что в “основном репозитории” содержится актуальная (с изменениями от второго пользователя) версия файла:

 

Первый пользователь не сделал pull, поэтому в его локальном репозитории содержится старая (без учета изменений от второго пользователя) версия файла:

 

Теперь первый пользователь вносит свои изменения в файл и делает commit:

 

После этого, первый пользователь будет делать git push чтобы синхронизировать свои изменения с “основным репозиторием”.

 

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

 

Но изменения вносимые первым и вторым пользователем могут быть взаимоисключающими, например первый пользователь может в скрипте указать Stop-Service а второй Stop-Service. А это как раз и есть потенциальный конфликт.

Поэтому логика такова, что перед внесением изменений первый пользователь должен ознакомится с тем, что сделал второй с момента их последней синхронизации через “общий репозиторий”.

Поэтому первый пользователь при попытке git push получит уведомление:

 

Решений этой ситуации, очевидно два: первый пользователь либо сохранит свою версию файла, либо удалит ее:

 

В итоге нам доступно несколько коммитов:

 

Изменения от второго пользователя не потеряны, но остались в истории:

 

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