Git эквивалент статуса svn -u

Что эквивалентно git svn status -u или более подробному svn status --show-updates. Команда svn status --show-updates показывает обновления, которые команда svn update будет выводить с сервера.

Спасибо!

Ответ 1

Я не могу придумать способ сделать это, не выбирая обновления (может быть, кто-то другой). Предполагая, что вы находитесь в ветке "master" по умолчанию, а вверх по течению, из которого будут появляться эти гипотетические обновления, является удаленное "происхождение" по умолчанию, попробуйте...

git fetch
git log --name-only ..origin/master

Обратите внимание на двойные точки.. не одна точка или не elipsis 1.

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

NB в git "выборка" этих обновлений - это не то же самое, что применять их к локальной ветке. Вы, несомненно, уже знаете, как это сделать с помощью git pull.


1 Что касается того, откуда берутся двойные точки, name1..name2 указывает диапазон. Если name1 опущено, на его месте используется HEAD. Этот синтаксис относится ко всем коммитам, достижимым с name2 назад, но не включая, HEAD. [Git снизу вверх

Ответ 2

Оба Martinho Fernandes и tialaramex правильно отвечают, что вам нужно делать. Позвольте мне описать , почему так оно и есть.


Subversion

Subversion - это система управления версиями централизованная. Это означает, что он работает в режиме клиент-сервер: сервер хранит все данные о версии (репозитории), клиент имеет только рабочий каталог (файлы) плюс некоторые административные и вспомогательные данные. Это означает, что для большинства команд клиент должен связаться с сервером. Это также означает, что есть много команд, запрашивающих состояние репозитория на сервере или конфигурацию сервера, например "svn status --show-updates".

(Sidenote: одна вспомогательная информация, которую Subversion хранит на клиенте, является "первозданной" версией файлов, а это означает, что проверка внесенных изменений не требует подключения к серверу (что медленно)... но это также означает, что проверка SVN может быть больше репозитория Git).

"svn update" (требуется до фиксации, если репозиторий имеет какие-либо изменения в данной ветке) загружает последнюю версию из удаленной и объединяет (пытается слить) изменения, которые вы сделали с изменениями с удаленного. IMHO этот рабочий процесс с обновлением до фиксации не очень проводен.


Git

Git - это система управления версиями распределенная. Это означает, что он работает по принципу "одноранговый": каждый "клиент" имеет все данные о версиях (полный репозиторий). Центральный репозиторий является центральным только из-за социальной конвенции, а не технических ограничений. Это означает, что при обращении в другой удаленный репозиторий количество команд, "выполненных удаленно", очень мало. Вы можете запросить ссылки (заголовки aka. Branch и tags) с помощью "git ls-remote" (и "git show update" ), вы можете вытащить (получить) или нажать (опубликовать) данные с помощью "git fetch" (или "git удаленное обновление" )/ "git push", и если сервер настроен на его разрешение, вы можете получить моментальный снимок состояния удаленного репозитория с помощью "git archive --remote".

Итак, чтобы проверить коммиты, находящиеся в удаленном репозитории, но не присутствующие в вашем репозитории, вам необходимо загрузить данные на свой компьютер. Но "git pull" на самом деле не что иное, как "git fetch", который загружает данные и "git merge", который объединяет его (с небольшим количеством сахара, чтобы подготовить сообщения фиксации и выбрать, к какой ветки нужно объединить). Затем вы можете использовать "git fetch" (или "git удаленное обновление" ), изучить вновь полученные коммиты с "git log" и "gitk" (не ограничиваясь фиксированным выходом), а затем, если все все правые слияния с "git merge".

Это не относится к Git, но ко всем системам управления распределенными версиями, хотя способ отображения SCM, но не связанные с ним, может отличаться (Git использует ветки удаленного отслеживания в 'remote/<remotename> /* 'namespace, Mercurial из того, что я понимаю, использует неназванные главы).


НТН

Ответ 3

Если вы выбрали:

git fetch <remote>

вместо вытягивания:

git pull <remote>

на пульте дистанционного управления, вы можете проверить, что изменилось с помощью git log. Чтобы применить изменения:

git merge <remote>/<remote-branch>

Ответ 4

Вы можете использовать git ls-remote для отображения SHA ссылок в удаленном репозитории; поэтому вы можете увидеть, есть ли какие-либо изменения, сравнивая вывод:

$ git show-ref origin/master     # <-- Where this repo thinks "origin/master" is
5bad423ae8d9055d989a66598d3c4473dbe97f8f refs/remotes/origin/master
$ git ls-remote origin master    # <-- Where "origin" thinks "master" is
060bbe2125ec5e236a6c6eaed2e715b0328a9106    refs/heads/master

Если они отличаются, то есть изменения в выборке:

$ git remote update
Fetching origin
...
From github.com:xxxx/yyyy
5bad423..060bbe2  master     -> origin/master

Ответ 5

Для меня просто для отображения файлов, которые будут изменены, это:

git fetch (1)
git diff --name-only ..origin/master (2)
  • Выбирает изменения в базе данных Git "(только в каталоге .git) и не меняет файлы.
  • Показывает имена файлов, которые будут изменены после слияния

Для обновления файлов (не только Git "database" ) выполните Git merge

Ответ 6

Gits дает нам больше инструментов для проверки "обновления". Сначала вам нужно "загрузить" обновленное состояние репозитория:

git fetch

Теперь вы можете получить список измененных файлов:

git log --name-status ..origin/master

Дополнительно, вы можете увидеть полный список изменений с помощью diff:

git diff ..origin/master

Значение стартовых букв: Добавлены (A), Скопированные (C), Удаленные (D), Модифицированные (M), Переименованные (R), изменены (T), Unmerged (U), Неизвестны (X ) или имели сопряжение Broken (B)

Ответ 7

git fetch && git log --name-status ..origin/master действительно показывает журналы, которые будут объединены. Однако он также переносит изменения. Технически невозможно сделать то же самое, что и svn status -u, но git fetch работает так быстро, что обычно не имеет значения

Если вам абсолютно нужен журнал перед извлечением, единственный способ - подключить (SSH или эквивалент) к удаленному компьютеру и выпустить git log там.