thanks Konstantin & Dale for your detail reply, much appreciated. I had to re-read the post several times as git is new to me and not familiar with the commands. But it's now clear the direction that I will take.
Specifically, I will setup a main codebase branch and individual branches which represent each customer. This way, I can quickly tell who is up to date etc And the codebranch will reset the customer branch once it's up to date. many thanks for your input Andrew On Monday, 25 April 2016 21:22:35 UTC+10, Konstantin Khomoutov wrote: > On Sun, 24 Apr 2016 17:00:55 -0700 (PDT) > Andrew Acevedo <office...@gmail.com <javascript:>> 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? > > No. > 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 > after: > > * 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, > > > > http://nvie.com/files/Git-branching-model.pdf > > > > 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 > repository: > > * 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 > merge. > 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
