Изменение детали после git pull

После git pull, его вывод дает сводную информацию об изменении суммы.

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

Update:

Спасибо. Я не уверен, почему я не могу добавить комментарий или проголосовать за ваши ответы. Хорошо, вот мой вопрос к Джероми:

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

  • Что указывает мастер и какова разница между master и HEAD, двумя главами по умолчанию git

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

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

  • какая разница между git diff и git whatchanged?

Ответ 1

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

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

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

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

  • См. сводку изменений снова: git diff --stat [email protected]{1} master

[Отредактировано для четкого описания того, что делает каждая команда]

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

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

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

Ответ 2

Скажите, что вы делаете git, как это:

$ 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 [email protected]: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

Ответ 3

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://[email protected]:12345/username/somerepo.git
  Push  URL: ssh://[email protected]: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 [email protected]{1}..master --dirstat=cumulative,files

Это даст вам два блока информации об изменениях между вашим последним притяжением и текущим состоянием работы. Пример вывода (я добавил a --- как разделитель между выводами --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/

Ответ 4

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

git pull
git reset [email protected]{1}
gitg (or gitk or whatever tool you like)

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

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