与 jitpack 使用的分支相关的 github 版本

Question

Looking at:

https://help.github.com/articles/about-releases/

it looks like this is specific to github, and not a general git feature. My usage is, from my perspective, no different than branching. That is, branch x is just a marker. Maybe bug fixes, maybe feature added, whatever, maybe experimental. Granted, I'm a very light user of git, and don't use branching, nor merging, to their full potential.

This feature seems totally useless in relation to jitpack. And, yet, seems crucial to how jitpack operates. Why?

As I understand jitpack, a release is created on a repo, and then, automagically, a JAR is compiled by jitpack and made available for download through the maven plugin.

Why use the release feature? At first I was uploading JAR files to a release, but that's not actually required. How is using github release as a marker better than using a branch as a marker? In fact, it seems to serve the same function, and, in that sense, duplicates the functionality of a branch.

Presumably, there's a rationale.

Answer 1

it looks like this is specific to github, and not a general git feature.

Yes it is.

My usage is, from my perspective, no different than branching. That is, branch x is just a marker

No, it is not: a GitHub release is associated to a tag (a fixed marker), not a branch (a shifting marker whose HEAD changes at each new commit)

This feature seems totally useless in relation to jitpack. And, yet, seems crucial to how jitpack operates. Why?

Because that is how the delivery built is stored on GitHub, with a relation to a precise version of the sources which were used to build said delivery (through the tag)

Why use the release feature?

Because binaries are not stored in the git repo itself (which is there to version sources, not binaries). Hence the release, tied to a tag referencing the version of the sources for that binary.

How is using github release as a marker better than using a branch as a marker?

Because a branch is not a marker (and is used to record the evolution of sources).
A tag is a marker (and can be associated to the deliveries built from the sources marked by said tag)

---

The notion of "release branch" described in " Atlasian gitflow " is not the same as the GitHub release.

• One is for recording the versions of sources for a given release 11.1.0, 11.1.1, 11.1.2, and so on.
• The other is for associating binaries to a tag on the GitHub site in order to allow user of the repo to not have to compile the source (and to avoid to store that same binary in the repo itself, making it too big to be easily cloned)