Что эквивалентно git svn status -u
или более подробному svn status --show-updates
.
Команда svn status --show-updates
показывает обновления, которые команда svn update
будет выводить с сервера.
Спасибо!
Что эквивалентно git svn status -u
или более подробному svn status --show-updates
.
Команда svn status --show-updates
показывает обновления, которые команда svn update
будет выводить с сервера.
Спасибо!
Я не могу придумать способ сделать это, не выбирая обновления (может быть, кто-то другой). Предполагая, что вы находитесь в ветке "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 снизу вверх
Оба Martinho Fernandes и tialaramex правильно отвечают, что вам нужно делать. Позвольте мне описать , почему так оно и есть.
Subversion - это система управления версиями централизованная. Это означает, что он работает в режиме клиент-сервер: сервер хранит все данные о версии (репозитории), клиент имеет только рабочий каталог (файлы) плюс некоторые административные и вспомогательные данные. Это означает, что для большинства команд клиент должен связаться с сервером. Это также означает, что есть много команд, запрашивающих состояние репозитория на сервере или конфигурацию сервера, например "svn status --show-updates
".
(Sidenote: одна вспомогательная информация, которую Subversion хранит на клиенте, является "первозданной" версией файлов, а это означает, что проверка внесенных изменений не требует подключения к серверу (что медленно)... но это также означает, что проверка SVN может быть больше репозитория Git).
"svn update" (требуется до фиксации, если репозиторий имеет какие-либо изменения в данной ветке) загружает последнюю версию из удаленной и объединяет (пытается слить) изменения, которые вы сделали с изменениями с удаленного. IMHO этот рабочий процесс с обновлением до фиксации не очень проводен.
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 из того, что я понимаю, использует неназванные главы).
НТН
Если вы выбрали:
git fetch <remote>
вместо вытягивания:
git pull <remote>
на пульте дистанционного управления, вы можете проверить, что изменилось с помощью git log
. Чтобы применить изменения:
git merge <remote>/<remote-branch>
Вы можете использовать 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
Для меня просто для отображения файлов, которые будут изменены, это:
git fetch (1)
git diff --name-only ..origin/master (2)
Для обновления файлов (не только Git "database" ) выполните Git merge
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)
git fetch && git log --name-status ..origin/master
действительно показывает журналы, которые будут объединены. Однако он также переносит изменения. Технически невозможно сделать то же самое, что и svn status -u
, но git fetch
работает так быстро, что обычно не имеет значения
Если вам абсолютно нужен журнал перед извлечением, единственный способ - подключить (SSH или эквивалент) к удаленному компьютеру и выпустить git log
там.