Изменение детализации после Git pull - PullRequest
110 голосов
/ 01 сентября 2009

После получения Git его вывод дает сводку по сумме изменений.

Как просмотреть подробные изменения каждого или нескольких файлов?

Хорошо, вот мой вопрос Джефроми:

  1. Как мне узнать, тянул ли я к мастеру? Все, что я сделал, это "git pull".

  2. На что указывает master и в чем разница между master и HEAD, двумя головками Git по умолчанию?

  3. Как просмотреть подробные изменения в определенном файле?

  4. Как мне снова увидеть изменение итогового результата за последний git pull?

  5. В чем разница между git diff и git whatchanged?

Ответы [ 4 ]

171 голосов
/ 01 сентября 2009

Предположим, вы тянете к мастеру. Вы можете ссылаться на предыдущую позицию master с помощью master@{1} (или даже master@{10.minutes.ago}; см. Раздел с указанием ревизий страницы справочного руководства git-rev-parse *), чтобы вы могли что-то делать как

  • Просмотреть все изменения: git diff master@{1} master

  • См. Изменения в данном файле: git diff master@{1} master <file>

  • Просмотреть все изменения в данном каталоге: git diff master@{1} master <dir>

  • См. Сводку изменений еще раз: git diff --stat master@{1} master

Что касается вашего вопроса «как узнать, нахожусь ли я на мастере» ... ну, использование веток является важной частью рабочего процесса Git. Вы всегда должны знать, в какой ветке вы находитесь - если вы вытягивали изменения, вы хотите перетянуть их в нужную ветку! Вы можете увидеть список всех веток, отмеченных звездочкой, на которые вы в данный момент выехали, с помощью команды git branch. Текущее имя ветви также выводится вместе с выводом git status. Я настоятельно рекомендую просмотреть справочные страницы команд для использования - это отличный способ медленно получить некоторые знания.

И ваш последний вопрос: HEAD - это название текущей проверенной ветки. Вы действительно можете использовать HEAD и HEAD@{1} и в этом контексте, но использовать ветки немного надежнее, так как если вы пойдете и посмотрите другую ветку. HEAD теперь вторая ветвь, а HEAD@{1} теперь master - не то, что вы хотите!

Чтобы избежать необходимости задавать много маленьких вопросов, подобных этому, вам, вероятно, стоит взглянуть на учебник по Git. В Интернете есть миллион, например:

  • Книга Pro Git
  • Git Magic
  • и 4,5 миллиона просмотров в Google для "Git tutorial"
41 голосов
/ 01 сентября 2009

Скажем, вы делаете git pull вот так:

$ git pull
remote: Counting objects: 10, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 6 (delta 4), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
From git@dev.example.com:reponame
   a407564..9f52bed  branchname   -> origin/branchname
Updating a407564..9f52bed
Fast forward
 .../folder/filename          |  209 ++++++++-----
 .../folder2/filename2        |  120 +++++++++++---------
 2 files changed, 210 insertions(+), 119 deletions(-)

Вы можете увидеть разницу того, что изменилось, используя номера ревизий:

$ git diff a407564..9f52bed
6 голосов
/ 19 сентября 2014

1. Как узнать, тянул ли я к мастеру? Все, что я сделал, это "git pull".

Сама команда работает так:

git pull [options] [<repository> [<refspec>…]]

и по умолчанию относится к текущей ветви. Вы можете проверить свои филиалы, используя

git branch -a

В этом списке будут перечислены ваши локальные и удаленные ветви, например, так (добавлен --- как разделитель между локальным и удаленным, чтобы сделать его более понятным)

*master
foo
bar
baz
---
origin/HEAD -> origin/master
origin/deploy
origin/foo
origin/master
origin/bar
remote2/foo
remote2/baz

Когда вы посмотрите на одно удаленное репо, вы увидите, на что вы ссылаетесь:

git remote show origin

выдаст список как следующий:

* remote origin
  Fetch URL: ssh://git@git.example.com:12345/username/somerepo.git
  Push  URL: ssh://git@git.example.com:12345/username/somerepo.git
  HEAD branch: master
  Remote branches:
    foo    tracked
    master tracked
  Local refs configured for 'git push':
    foo    pushes to foo    (up to date)
    master pushes to master (fast-forwardable)

Так что довольно легко быть уверенным, куда вытащить и толкнуть.

3. как увидеть изменение детализации в определенном файле?

4. как увидеть изменение итогового вывода при последнем git pull?

Самый простой и самый элегантный способ (IMO) это:

git diff --stat master@{1}..master --dirstat=cumulative,files

Это даст вам два блока информации об изменениях между вашей последней работой и текущим состоянием работы. Пример вывода (я добавил --- в качестве делителя между --stat и --dirstat, чтобы сделать его более понятным):

 mu-plugins/media_att_count.php                     |  0
 mu-plugins/phpinfo.php                             |  0
 mu-plugins/template_debug.php                      |  0
 themes/dev/archive.php                             |  0
 themes/dev/category.php                            | 42 ++++++++++++++++++
 .../page_templates/foo_template.php                |  0
 themes/dev/style.css                               |  0
 themes/dev/tag.php                                 | 44 +++++++++++++++++++
 themes/dev/taxonomy-post_format.php                | 41 +++++++++++++++++
 themes/dev/template_parts/bar_template.php         |  0
 themes/someproject/template_wrappers/loop_foo.php  | 51 ++++++++++++++++++++++
---
 11 files changed, 178 insertions(+)
  71.3% themes/dev/
  28.6% themes/someproject/template_wrappers/
 100.0% themes/
  27.2% mu-plugins/
   9.0% themes/dev/page_templates/
   9.0% themes/dev/template_parts/
  63.6% themes/dev/
   9.0% themes/someproject/template_wrappers/
  72.7% themes/
2 голосов
/ 06 марта 2014

Этот способ довольно хакерский, но он позволит вам использовать графические инструменты, такие как gitk или gitg или git-gui:

git pull
git reset HEAD@{1}
gitg (or gitk or whatever tool you like)

Ответ с наибольшим количеством голосов дает лучший способ использования инструмента git, но я использую этот метод, потому что затем я могу использовать инструменты с графическим интерфейсом для просмотра изменений: P

Тогда у меня был бы дополнительный шаг: сделать git checkout ., а затем снова сделать git pull, чтобы я правильно вытащил и слил, но я ценю способность исследовать различия в графическом интерфейсе, достаточные для того, чтобы справиться с дополнительными двумя шаги.

...