Как узнать количество новых коммитов (git) во время сборки TFS

Я следил за этим решение, чтобы получить файлы, которые были изменены в последней фиксации.

Решения будут похожи на

$files=$(git diff HEAD HEAD~ --name-only)
echo $files
$temp=$files -split ' '
$count=$temp.Length
echo "Total changed $count files"
New-Item -ItemType directory -Path $(Build.ArtifactStagingDirectory)\files
For ($i=0; $i -lt $temp.Length; $i++)
{
  $name=$temp[$i]
  echo "this is $name file"
  if (Test-Path "$(Build.SourcesDirectory)\$name")
    {
      Copy-Item $(Build.SourcesDirectory)\$name $(Build.ArtifactStagingDirectory)\files
    }
}

Благодаря этому я могу получить измененные файлы из последней фиксации, но в моем случае может быть N новых фиксаций.

Итак, я вижу способ добиться этого, изменив cmd, например

2 коммитов

$files=$(git diff HEAD HEAD~2 --name-only)

3 коммитов

$files=$(git diff HEAD HEAD~3 --name-only)

вроде так далее.,

Однако я не смог найти способ получить отсутствие новых коммитов в определении сборки.

Обновление 1

Мой TFS Get Sources всегда проверяет соответствующую ветку с последним идентификатором фиксации

2018-09-08T06:05:35.8623084Z ##[command]git checkout --progress --force e88c5a4bf29a539c515ca0e5fea104799426026e
2018-09-08T06:05:36.3681977Z Previous HEAD position was 40ac471... Updated xxxxxxx

Что также затрудняет поиск старых идентификаторов фиксации

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
0
539
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Я думаю, вы ищете git rev-list

Допустим, вы выполняете следующие шаги:

  • Вы на хозяине
  • Вы создаете ветку исправления: git checkout -b hotfix_1
  • Вы изменяете и фиксируете некоторые файлы, его хеш - f3de9ae73e1fb06c23506c.
  • Вы изменяете и снова фиксируете. последний хеш - 4985ead3183df8388cf8e4

На данный момент вы на два коммита впереди мастера, поэтому

git rev-list HEAD ^master

Означает: «перечислить те коммиты, которые находятся в моей истории, а не в истории мастера».

Что в этом случае печатает

4985ead3183df8388cf8e4
f3de9ae73e1fb06c23506c

(потому что имеет смысл перечислить их в обратном хронологическом порядке).

тем не мение этот метод имеет смысл только при сравнении ветвей, которые не расходятся. В противном случае вы получите только количество коммитов между вашим HEAD и последним общим предком, что не означает, что в ветви master не было никаких новых коммитов с тех пор, как ваш текущий HEAD разошелся.

спасибо за ваш ответ, ваше решение может работать, если я использую только коммиты, которые находятся в моей истории, а не в основной истории. Пожалуйста, посмотрите мой обновление 1 Моя TFS будет проверкой по умолчанию для ветки с последним идентификатором фиксации, так как в таком случае получить предыдущий идентификатор фиксации?

Jayendran 08.09.2018 11:49

Итак, ваша TFS заранее знает коммит, который она развернет, не так ли? В этом случае вы можете добавить строку в свой сценарий развертывания для захвата хэша предыдущего развертывания (git rev-parse --abbrev-ref HEAD), а затем выполнить мое предложение между этими двумя. Пока вы продолжаете развертывать основную ветку, что и должно быть, два развертывания не должны расходиться.

ffflabs 08.09.2018 11:58

Вместо этого попробуйте git rev-parse HEAD. Я привык работать с ветками или тегами, поэтому --abbrev-ref не подходил для вашего варианта использования. Обратите внимание, вы передаете последний коммит в качестве первого параметра, а предыдущий (записанный с помощью abbrev-ref) в качестве второго с префиксом ^. В противном случае в старом развертывании нет никаких коммитов, которых нет в новом.

ffflabs 08.09.2018 12:22

Другие вопросы по теме