It's a familiar scenario.

You have what you think is a great idea. Implementing it will require gutting your current code base. It may or may not work, it may work but be inefficient, etc.

If it works, you will continue from the new code. If it doesn't, you'll revert to the code prior to the experiment—but you'll keep the experiment around for reference.

You have several options:

You can commit the experimental code and then either undo that commit or revert to a previous commit.

You can branch, even after the fact, and then either merge the experimental code (knowing that you will not have conflicts) or just ignore the branch and continue on the trunk.

If the experiment turned out to have no lasting merit, another option is to simply discard the changes.

Let's leave collaboration and even a remote repository out. Consider the case of working on a solo project with only a local repository.

Are git branches exactly what you need? Is there another facility in git that more closely matches this need? Is branching an overkill and reverting to a prior commit sufficient? Here we assume that you will not continue development on the trunk during the experiment.

What is the workflow recommended in an R&D scenario such as the one described here?

---

Yes: 2.

Git branches are exactly what you need. Git is very good with everything regarding branches.

In git, branches are trivially lightweight. Branches are the main thing in git driving all the incredible power it has - compared to some other repository systems where branches are heavyweight, or afterthoughts, or not existant at all. Branches are never overkill.

Never hesitate even for a second to create a new branch in git. The creation is instantaneous and takes zero resources. Keeping a branch around forever after you merged it back into master als has zero cost, since it is impossible to delete the actual history anyways as it is now part of master , ie of a branch you are very unlikely to delete. You can delete them of course, it will only remove the name and nothing of the actual history - useful if you get confused by too many branch names in your (G)UI.

The only cost a branch ever incurs is to keep the commits leading up to it alive, before you merge it back into master (or into another permanent branch, for that matter). So if you really happen to have a branch with incredibly large space usage that you certainly will not need ever again, then sure, delete it after a while. But really, I don't see this as a concern; unless you happen to commit large images or other binary files to it.

链接地址: http://www.djcxy.com/p/49316.html

上一篇: 如何在多个分支上更改文件时正确合并git分支？

下一篇: 使用git作为研发工具