On Sun, 24 Apr 2016 17:00:55 -0700 (PDT)
Andrew Acevedo <officeanal...@gmail.com> wrote:
> I'm not familiar with git, but can the same tag be moved around on
> several branches and a history is kept which position on the branch
> it's been pinned too before?
The only place where movement of "refs" (which are heads (branches) and
tags)) is recorded is the so-called "reflog" (see `git help reflog`)
but it has some properties which make it unfit for what you're
* It only is there as a safety measure against occasional "oopsies"
where you, say, moved the head of a branch several commits back.
* The reflog is local to a particular repository, and its contents is
neither pushed nor fetched, and it's impossible to do this.
* Bare repositories (those usually used to serve as "shared" -- think
of repos hosted on Github etc) by default have their reflog disabled.
But what you think you should use tags for appears to be wrong.
I'll try to explain this commending your example situation inline.
> I have 4 customers on the same program but on different versions. e.g
> Customer A, Customer B etc.
> Customer A has version 10 of helloworld.cpp
> Customer B has version 4 of helloworld.cpp
> Customer B requires an urgent hot fix on top of version 4 for
> helloworld.cpp and can’t take the latest version 10.
> Using this setup in mind,
> Is it possible to setup git to show at a glance which version they
> are all up too?
Well, first thing first: in Git, branches and tags are mere ways to
reference particular commits. The only difference between them is that
you can "advance" a branch by recording a new commit on it but you
can't update a tag in any way. This difference is semantical: tags
are there to mark fixed points in the history while branches are there
to support distinct lines of development.
> and using tags to keep track of the earlier versions which was
> released to customers. So that I can determine quickly which version
> Customer B had before it had version 4, so that I can quickly roll
> back if necessary to their earliest version?
Well, if I understood your problem statement correctly, you basically
want to roll your development in a way that the repository contains
branches for abstract versions of your code base, like ver4 and ver10.
Am I right?
If yes, then the question of keeping the information about which
customer got which version is really orthogonal to the repository, and
I'm not sure why you'd want to keep it there (why not in some external
corporate resource like, say, a wiki?).
On the other hand, there are ways to keep this information in the
* Dedicate a special branch to store your release information
in a simple text file (or whatever else which would be more convenient
for you) or a set of files -- say, one file per customer.
Each time you deploy a new version to a customer, check out that
dedicated branch, update the information there, commit, push.
To create a dedicated branch (not connected to any other branch)
use the combo explained in `git help checkout`:
$ git checkout --orphan relinfo
$ git rm -rf .
$ git commit
To save time spent on checkouts when maintaining such a branch,
you might employ the `git-new-workdir` facility.
The matter of exploring the history of deploying releases then
becomes studying the output of `git log relinfo` etc.
* Have per-customer branches along with "pristine" branches for
different versions of your code base.
Then, when you're about to deploy a new version to a customer,
merge the branch containing that version of the codebase
to the customer's branch (you might force this merge to be "true"
even though it could have been resolved to a fast-forward case --
to record the time you switched the customer's code base, and maybe
add some notes on this in the merge commit message).
Instead of merging, you could just hard-reset the customer branch
to the tip of the branch containing the new version. Basically,
if you have no special customization for customers, this is the same
than plain merging explained above without forcing a non-fast-forward
Should you adopt this approach, each time you update the customer's
branch this way, you could decorate it with a tag -- possibly
annotated -- explaining which version was deployed.
Note that while branches and tags are not explicitly namespaced, it's
easy to emulate it by adopting a simple policy -- say, the names of
tags marking versions of software deployed to customers might have
the form <customer>/<version>, like in "acme-ltd/v4.1.1".
Git is fine with this (but don't use things which systems with non-POSIX
filesystems won't like -- so basically avoid having ":" and trailing
"."-s in your branch and tag names if you want them to be subject to
successful checkout on Windows.
> I have searched for tag examples for a commit but havent seen any
> setup which moves tags across branches etc or an organised way of
> doing it.
Hope the above explanations help.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.