We use git to manage our code, and just create one tag when rel开发者_如何学运维ease new version. So if we
find bugs after we release and hava made some new changes, how to deal with case ?
BTW: we do not use mutil branch because we would like to make process easy
This situation is part of the reason branches exist, so I suspect that in the long run you're just making things harder for yourself by avoiding branches. I suppose you could do something like this, though:
Checkout the release tag.
Make your bugfix, commit, re-tag and release the fix.
Rebase master off of your new tag.
This will insert your fix in the timeline (by avoiding branches you've linearized your commit graph) immediately after the release.
Update
As @cdhowie points out in the comments, "this approach will not work seamlessly if more than one developer has the repo cloned, since it will alter history and require a forced push". See the section of the git-rebase
man page tilted "Recovering from Upstream Rebase" where it says:
Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.
So in other words, you could go with a rebasing strategy and keep your history linear, but you're probably actually creating more work for yourself that way. Having a separate branch for each release is the standard practice for good reason.
Use a per-release branch that you can commit fixes to. This is the easiest way to manage releases.
... And if you don't want to use the branching feature of Git, why aren't you using something with a GUI, like Subversion instead? If simplicity of your VCS is a concern, Git is the wrong choice. If awesome branching features are a concern, Git is the perfect choice.
精彩评论