Я следил за этим решение, чтобы получить файлы, которые были изменены в последней фиксации.
Решения будут похожи на
$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)
вроде так далее.,
Однако я не смог найти способ получить отсутствие новых коммитов в определении сборки.
Мой 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
Что также затрудняет поиск старых идентификаторов фиксации
Я думаю, вы ищете git rev-list
Допустим, вы выполняете следующие шаги:
git checkout -b hotfix_1
f3de9ae73e1fb06c23506c
.4985ead3183df8388cf8e4
На данный момент вы на два коммита впереди мастера, поэтому
git rev-list HEAD ^master
Означает: «перечислить те коммиты, которые находятся в моей истории, а не в истории мастера».
Что в этом случае печатает
4985ead3183df8388cf8e4
f3de9ae73e1fb06c23506c
(потому что имеет смысл перечислить их в обратном хронологическом порядке).
тем не мение этот метод имеет смысл только при сравнении ветвей, которые не расходятся. В противном случае вы получите только количество коммитов между вашим HEAD и последним общим предком, что не означает, что в ветви master
не было никаких новых коммитов с тех пор, как ваш текущий HEAD разошелся.
Итак, ваша TFS заранее знает коммит, который она развернет, не так ли? В этом случае вы можете добавить строку в свой сценарий развертывания для захвата хэша предыдущего развертывания (git rev-parse --abbrev-ref HEAD
), а затем выполнить мое предложение между этими двумя. Пока вы продолжаете развертывать основную ветку, что и должно быть, два развертывания не должны расходиться.
Вместо этого попробуйте git rev-parse HEAD
. Я привык работать с ветками или тегами, поэтому --abbrev-ref
не подходил для вашего варианта использования. Обратите внимание, вы передаете последний коммит в качестве первого параметра, а предыдущий (записанный с помощью abbrev-ref) в качестве второго с префиксом ^
. В противном случае в старом развертывании нет никаких коммитов, которых нет в новом.
спасибо за ваш ответ, ваше решение может работать, если я использую только коммиты, которые находятся в моей истории, а не в основной истории. Пожалуйста, посмотрите мой обновление 1 Моя TFS будет проверкой по умолчанию для ветки с последним идентификатором фиксации, так как в таком случае получить предыдущий идентификатор фиксации?