rc-XYZW 형식의 버전 문자열 순서로 git 태그를 정렬하는 방법은 무엇입니까?

rc-XYZW 형식의 버전 문자열 순서로 git 태그를 정렬하는 방법은 무엇입니까?

---

명령을 입력 할 때 :

git tag -l

나는 그런 결과를 얻습니다.

rc-0.9.0.0
rc-0.9.0.1
rc-0.9.0.10
rc-0.9.0.11
rc-0.9.0.12
rc-0.9.0.2
rc-0.9.0.3
rc-0.9.0.4
rc-0.9.0.5
rc-0.9.0.6
rc-0.9.0.7
rc-0.9.0.8
rc-0.9.0.9

이것 대신에 나는 원한다 :

rc-0.9.0.0
rc-0.9.0.1
rc-0.9.0.2
rc-0.9.0.3
rc-0.9.0.4
rc-0.9.0.5
rc-0.9.0.6
rc-0.9.0.7
rc-0.9.0.8
rc-0.9.0.9
rc-0.9.0.10
rc-0.9.0.11
rc-0.9.0.12

그러한 결과를 얻기 위해 현재 목록을 정렬하는 것이 어떻게 가능합니까?

---

버전 정렬 사용

git tag -l | sort -V

또는 git 버전> = 2.0

git tag -l --sort=v:refname
git tag -l --sort=-v:refname # reverse

---

Git 2.0 (2014 년 6 월)을 사용하면 정렬 순서를 지정할 수 있습니다!

참조 b6de0c6 커밋 에서 9ef176b 커밋 에 의해 저술 (응웬 타이 응옥 두이 pclouds) :

 --sort=<type>

특정 순서로 정렬합니다 .
지원되는 유형은 다음과 같습니다.

• " refname"(사전 순서),
• " version:refname"또는 " v:refname"(태그 이름은 버전으로 처리됨).

-정렬 순서를 반대로하려면 앞에 " "을 추가하십시오 .

---

따라서 다음이있는 경우 :

git tag foo1.3 &&
git tag foo1.6 &&
git tag foo1.10

다음과 같은 결과를 얻을 수 있습니다.

# lexical sort
git tag -l --sort=refname "foo*"
foo1.10
foo1.3
foo1.6

# version sort
git tag -l --sort=version:refname "foo*"
foo1.3
foo1.6
foo1.10

# reverse version sort
git tag -l --sort=-version:refname "foo*"
foo1.10
foo1.6
foo1.3

# reverse lexical sort
git tag -l --sort=-refname "foo*"
foo1.6
foo1.3
foo1.10

---

Since commit b150794 (by Jacob Keller, git 2.1.0, August 2014), you can specific that default order:

tag.sort

This variable controls the sort ordering of tags when displayed by git-tag.
Without the "--sort=<value>" option provided, the value of this variable will be used as the default.

robinst comments:

the version sort order can now (Git 2.1+) be configured as default:

git config --global tag.sort version:refname

---

With Git 2.4 (Q2 2015), the versionsort.prerelease configuration variable can be used to specify that v1.0-pre1 comes before v1.0.

See commit f57610a by Junio C Hamano (gitster).

^{Note (see below) versionsort.prereleaseSuffix is now (2017) a deprecated alias for versionsort.suffix.}

---

git 2.7.1 (February 2016) will improve the output of git tag itself.

See commit 0571979 (26 Jan 2016), and commit 1d094db (24 Jan 2016) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 8bad3de, 01 Feb 2016)}

tag: do not show ambiguous tag names as "tags/foo"

Since b7cc53e (tag.c: use 'ref-filter' APIs, 2015-07-11), git tag has started showing tags with ambiguous names (i.e., when both "heads/foo" and "tags/foo" exists) as "tags/foo" instead of just "foo".
This is both:

• pointless; the output of "git tag" includes only refs/tags, so we know that "foo" means the one in "refs/tags".
• and ambiguous; in the original output, we know that the line "foo" means that "refs/tags/foo" exists. In the new output, it is unclear whether we mean "refs/tags/foo" or "refs/tags/tags/foo".

The reason this happens is that commit b7cc53e switched git tag to use ref-filter's "%(refname:short)" output formatting, which was adapted from for-each-ref. This more general code does not know that we care only about tags, and uses shorten_unambiguous_ref to get the short-name.
We need to tell it that we care only about "refs/tags/", and it should shorten with respect to that value.

let's add a new modifier to the formatting language, "strip", to remove a specific set of prefix components.
This fixes "git tag", and lets users invoke the same behavior from their own custom formats (for "tag" or "for-each-ref") while leaving ":short" with its same consistent meaning in all places.

If strip=<N> is appended, strips <N> slash-separated path components from the front of the refname (e.g., %(refname:strip=2) turns refs/tags/foo into foo.
<N> must be a positive integer.
If a displayed ref has fewer components than <N>, the command aborts with an error.

For git tag, when unspecified, defaults to %(refname:strip=2).

---

Update Git 2.12 (Q1 2017)

See commit c026557, commit b178464, commit 51acfa9, commit b823166, commit 109064a, commit 0c1b487, commit 9ffda48, commit eba286e (08 Dec 2016) by SZEDER Gábor (szeder).
^{(Merged by Junio C Hamano -- gitster -- in commit 1ac244d, 23 Jan 2017)}

versionsort.prereleaseSuffix is a deprecated alias for versionsort.suffix.

The prereleaseSuffix feature of version comparison that is used in "git tag -l" did not correctly when two or more prereleases for the same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2 are there and the code needs to compare 2.0-beta1 and 2.0-beta2).

---

According to this answer, on platforms which don't support sort -V like Windows and OSX, you can use

git tag -l | sort -n -t. -k1,1 -k2,2 -k3,3 -k4,4

---

Combining the answers already here:

Local repository

git -c 'versionsort.suffix=-' tag --list --sort=-v:refname

• suffix=- will prevent 2.0-rc coming "after" 2.0
• --sort=- will put the highest version number at the top.

Remote repository

git -c 'versionsort.suffix=-' ls-remote -t --exit-code --refs --sort=-v:refname "$repo_url" \
    | sed -E 's/^[[:xdigit:]]+[[:space:]]+refs\/tags\/(.+)/\1/g'

The advantage of this is that no objects are downloaded from the remote.

For more info see this answer.

---

To get a reverse sorting with the sort -V approach:

git tag -l | sort -V --reverse

---

Adapt this perl script, which sorts tags that look like client_release/7.2/7.2.25, to your specific tagging scheme.

---

I ended up writing a simple shell script to simplify this task.

#!/usr/bin/env bash

TAGS=$(git tag)
CODE=$?

if [ $CODE = 0 ]; then
    echo "$TAGS" | sort -V
fi

exit $CODE

I saved that as git-tags in my $PATH and run git tags whenever I need to list tags.

참고URL : https://stackoverflow.com/questions/14273531/how-to-sort-git-tags-by-version-string-order-of-form-rc-x-y-z-w