Git（Bitbucket）创建备份版本

Question

I am wondering what the standard procedure is to create an easy to find stable backup version of a git project. Ideally, it should not be necessary to go through the git logs, find a certain version and revert. Ideally, a version would be tagged. I saw git (I am using bitbucket) allows to create branches and some of those branches seem to have a tag release which In like because it indicates it is a stable version. Is branching out and switching back to the main branch for further a good way to manage this or are there better solutions available. I am not very familiar with git and its mechanics, so I would be happy to get some pointers towards good conventions.

Answer 1

Use Tags

You can use git-tag to create tags, with or without annotations. git tag --list will show you the available tags, and git-show can be used to view the annotation of a given tag. You then have to push the tags upstream, using git push --tags or similar. For most other purposes, you can treat a tag as a commitish for selecting commits. For example:

git tag --annotate --message="Release message 1" release01
git push --tags origin
# code ...
# code ...
git tag --annotate --message="Release message 2" release02
git push --tags origin
# code ...
# code ...
git tag --list
git show release02
# code ...
git reset --hard release01

Pragmatically, you can use the name of a tag almost anywhere you could use a commit ID. You can use it to reset your branch, as a branch point to create new branches, and so forth.

Download Archives from Tags

In online services like Bitbucket, GitHub, or GitLab, every tag you create triggers an archive build, which you can download as a zipfile or tarball from the tags/releases widgets. In Bitbucket, you can navigate to your available downloads at:

https://bitbucket.org/<username>/<repository>/downloads/?tab=tags

In Bitbucket, you will see a screen with archives in zip, gzip, and bzip2 format for each tag in the project. Just click the format you want to download it.

This archive feature is common to most of the popular online Git hosts, but features and navigation to the archives may vary. To create the archives locally, just use git-archive from the command line instead.

Answer 2

I'm sure there will be others with more complete answers, but here are some tips:

• Git != Bitbucket. Git is the version control system, Bitbucket is a git project hosting platform. You could just as easily work with a git repository hosted on bitbucket, github, a vps, or your local computer. Bitbucket adds a nice user interface for viewing 'releases' and such, but underneath it is all just git.
• Yes, tagging and branching are major things used:
  • tagging: any commit in git can be tagged. These tags can then be used as references. You could make tags like v1.1 , v1-stable , v1-beta to indicate stable or testing versions, etc. Usually used for marking particular revisions for various purposes (often releases).
  • branches: these are parallel sequences of commits - many projects use something like a stable master branch where commits are only merged to it when thoroughly tested, and a dev branch where main development happens on. Used for tracking development, especially when adding new features that require multiple commits, or trying out something different that you don't want in master .
• You can 'checkout' any commit, tag, branch, etc. on your computer, which sets all the tracked files to their state as they were at that point. This means that whatever system of branching/tagging you use, you can always revert back to any commit/tag/branch you want.
• Have a look at how other projects manage this. For example, the rust project on GitHub . They have multiple branches (eg. stable , master , beta ), and releases are tagged (eg. 1.0.0-beta , 1.5.0 ).
• Version control is a huge topic, and no single 'best' way to manage development. I'd suggest reading up on it (vcs in general, and the functions git gives), looking around at other projects, and most of all, jumping in and trying things yourself. Sooner or later you'll settle on a workflow that suits you or your projects' development style, whether it be tagging, branching, other features, or a combination of all.

Answer 3

You can add a tag and push it to the remote:

git tag <tagname>
git push origin --tags

This would tag the current commit and push that new tag to the remote you cloned from. Checking out a particular branch or commit would let you tag that using this same mechanism. As stated in other answers, deciding on your tagging strategy is a different matter altogether, but this is the mechanism you use to create the tag and distribute it.