Asaf wrote:
Hello, I'm creating many branches, checkout code, make changes, etc.. At the end, I always merge these branches to the master branch and delete them when I finish, At the point where my local master repo seems to be stable, I push the changes to an origin repo that is public. I guess this is a standard cycle, right?
There are many standard cycles. This is one of them :)
What I'm confused about is how to tag correctly versions that are stable, Should I locally just add a tag and push the tag to the public repo?
Yes.
Is it enough to use a lightweight tagging for tagging a certain commit as a release?
That's up to you. I'd recommend against it, because the default update hooks disallow lightweight tags from being pushed. We use signed tags for all releases, so we know and can verify who tagged what. I guess it's a corporate thing to desire the capability of saying "It was *HIS* fault, not mine!", and signing a tag means you sign the tree as it is at sign-time with all the history leading up to it.
Is it possible later on to checkout a tag, make a change and push the change into the tagged version?
No. Consider published tags immutable in git, please. Imagine the confusion and headache you'd get from bug-reports if version 4.6.3 is not the same code everywhere. What you can and should do is to: * create a branch at the location of the old tag * make whatever changes are necessary * test as necessary * cut a new release with your changes At $dayjob, we have an update hook preventing tags without the "-beta$X" suffix from being pushed unless it points to an already tagged commit, so our workflow goes like this: 1 hack hack hack 2 beta-tag 3 buildbot builds beta package and sends it off to qa 4 qa responds with "ok to release" 5 we stable-tag the exact same version we shipped to qa 6 buildbot builds stable tag and copies it to "to-be-released" directory 7 release-manager pushes the release-button once changelogs and stuff are in place If qa says "hey, it's broken", we repeat steps 1-4 until we get "ok". If we accidentally tag something as stable while it's broken, we *can* go back and re-create the tag before step 7 is done. We've found out that it's usually more trouble than it's worth though, because there's always a small uncertainty that qa gets the new code on all his machines, and the bug we nearly released may not always show up on all platforms. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html