Итак имеется: Git сервер с доступом по "ssh://...", комп1, комп2.

Перед работой "develop" (локальная копия) и "origin/develop"(серверная копия) вместе.

Работаю на компе 1 в ветке develop, после локальных коммитов "develop" и "origin/develop" расходятся, "develop" идет раньше "origin/develop" на отображаемом дереве.

После заброса на сервер опять всё "сходится".

Если забираю на компе 1 изменения, то "origin/develop" показывается после "develop" и нужно мержить две ветки. Всё как и ожидается.

Но!, теперь приходим на комп 2, забираем изменения. "develop" и "origin/develop" не расходятся, мержить ничего не нужно. Все изменения берутся правильно. Так получается каждый раз, на компе 2.

Все работает, но непонятно почему.

А на втором компе перед pull-ом что-то в develop нового, того что не было на origin/develop, было закоммичено?

Ну и второй вариант - автоматический merge сработал без конфликтов. Дерево бы после pull-а на второй машине посмотреть.

Каждый день примерно одни и те же действия на компе 2

Открываю гит морду

Забираю изменения

Делаю чего то. "Записываю" локально.

Отправляю на сервер.

В логах авто мерже не видно.

Ну, эта.. А коммит от 24.05.18 08:14:58 чем не merge?

Он, похоже, происходит на 1-м компе. (Не понятно зачем, должен был быть fast-forward, локальных изменений нет, только на сервере от 2-го компа, и никакого merge-а. Может где настройка есть "при pull используй --no-ff ?)

Предположение: отличаются настройки гуевины, которую вы используете. На 1-м компе каждый pull создает merge commit, даже когда не надо, а на втором - нет. Искать в чекбоксиках по ключевым словам "pull" и "fast forward" (наверное).

P.S. Именно из-за такой ерунды - только консоль. Команда и конфигурация git-а и всё.

P.P.S. Да, а что это за гуевина? описание последнего коммита за именами веток прячет...

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

точно, дома забыл переключить. Делает мерге после гета.

На 1-м компе каждый pull создает merge commit, даже когда не надо

не совсем так. Я специально так сделал чтобы каждый мерге был виден.

Именно из-за такой ерунды - только консоль.

Если есть прога у которой только консоль я просто не пользуюсь этой прогой

Да, а что это за гуевина? описание последнего коммита за именами веток прячет...

Git Extensions

https://sourceforge.net/projects/gitextensions/

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

P.S. Именно из-за такой ерунды - только консоль. Команда и конфигурация git-а и всё.

Поддерживаю. Работа с гитом из командной строки способствует лучшему пониманию всего его функционала и его предсказуемости.

В принципе к системе контроля версий разработчик обращается не так часто, чтобы это стало очень уж утомительным. ИМХО

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

Гуишка же всегда будет иметь урезанный функционал, а также делать что-то за кулисами.

Но я от нее полностью не отказался конечно. В чем-то она удобна - например diff, merge...

В принципе к системе контроля версий разработчик обращается не так часто,

По несколько раз в день и к разным проектам бывает - это не часто?

Всегда коммичу небольшие логические куски.

к системе контроля версий разработчик обращается не так часто, чтобы это стало очень уж утомительным.

-----

Вообще-то, после каждого выполненного таска.

А если что-то не вполне понятно - то и много чаще.

Таск, обычно, минут 15-20... т.е мин. 30 раз в день...

...чтобы это стало утомительным (с) ;)

Вообще-то в гите commit - это не push, а имелся в виду именно он, сдается мне. Поэтому можно коммитить что угодно и как угодно, ведь перед пушем все это можно (и нужно!) привести в божеский вид.

Лично я стараюсь придерживаться схемы "один коммит на тикет".

ведь перед пушем все это можно (и нужно!) привести в божеский вид

А что Вы под этим подразумеваете?

git rebase -i

А еще есть такая удобная штука как --fixup

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

Я этим тоже пользуюсь активно, даже алиас сделал:

[alias]
    st = status
    ci = commit
    gl = log --graph
    glo = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative 
    co = checkout
    br = branch
    df = difftool --dir-diff
    fx = commit -a --fixup HEAD

Но в последнее время коммичу из IntelliJ из-за pre-commit ништяков типа форматирования и проверки SonarLint.

...чтобы это стало утомительным (с) ;) Вообще-то в гите commit - это не push, а имелся в виду именно он, сдается мне. Поэтому можно коммитить что угодно и как угодно, ведь перед пушем все это можно (и нужно!) привести в божеский вид.Лично я стараюсь придерживаться схемы "один коммит на тикет".

Если это было адресовано мне...

Я в курсе разницы между commit и push. Может я ранее не совсем правильно выразился, говоря о нечастом использовании системы контроля версий. Я хотел сказать, что эта активность (по крайней мере у меня) занимает малую долю всего рабочего процесса. В основном - написание кода, коммуникация. Сделать commit из командной строки не намного труднее, чем из гуишки, особенно если печатаешь вслепую. Об автоматизации и превосходстве гуишки в определенных моментах писал ранее.