Странное поведение Git
Итак имеется: Git сервер с доступом по "ssh://...", комп1, комп2.
Перед работой "develop" (локальная копия) и "origin/develop"(серверная копия) вместе.
Работаю на компе 1 в ветке develop, после локальных коммитов "develop" и "origin/develop" расходятся, "develop" идет раньше "origin/develop" на отображаемом дереве.
После заброса на сервер опять всё "сходится".
Если забираю на компе 1 изменения, то "origin/develop" показывается после "develop" и нужно мержить две ветки. Всё как и ожидается.
Но!, теперь приходим на комп 2, забираем изменения. "develop" и "origin/develop" не расходятся, мержить ничего не нужно. Все изменения берутся правильно. Так получается каждый раз, на компе 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, а имелся в виду именно он, сдается мне. Поэтому можно коммитить что угодно и как угодно, ведь перед пушем все это можно (и нужно!) привести в божеский вид.
Лично я стараюсь придерживаться схемы "один коммит на тикет".
Я этим тоже пользуюсь активно, даже алиас сделал:
[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 из командной строки не намного труднее, чем из гуишки, особенно если печатаешь вслепую. Об автоматизации и превосходстве гуишки в определенных моментах писал ранее.