SVN trunk, branches and tags meaning

--A simple contrast

The working mechanism of SVN is like a growing tree in some way: a tree with a trunk and many branches A branch grows out of a trunk, and a thin branch grows from a relatively coarse trunk. a tree can have only a trunk without branches (but this will not last long, and as the tree grows, there will certainly be branches, ^^) a tree without a trunk but with many branches looks more like a bundle of sticks on the floor. If the trunk is diseased, eventually the branch will be affected, and the whole tree will die. If the branch is sick, you can cut it off, and then other branches will grow out of the OH. If the branch grows too fast, it can be very heavy for the trunk, and eventually the whole tree will collapse . When you feel your tree, trunk, or branch looks beautiful, you can take a picture of it, so you can remember how good it was at that time.

--trunk

trunks are the primary environment for placing stable code, like a car factory that assembles the finished car parts together.

The following will show you how to use the SVN trunk: unless you have to deal with bugs that are easy and quick to fix, or you have to add irrelevant logic files (such as media files: images, videos, CSS, and so on), you should never do development in the trunk directly . Do not make too much of a change to the previous version because of a particular need, how the relevant situation implies the need to create a branch (as described below) do not submit some content that might disrupt the trunk, such as merging from branch If at some point you accidentally break the trunk,bring some cake the next day ("With great responsibilities come ... huge cakes")

--branches

a branch is a regular copy from a subtree in an SVN repository. Normally it works like a symbolic link on a UNIX system, but once you've modified some files in an SVN branch, and the modified files evolve independently from the copied source files, you can't think of it that way. When a branch is completed, and it is considered stable enough, it must be merged back to its original copy, that is, if it was originally copied from the trunk, it should go back to the trunk, or merge back to its original copy of the parent branch.

The following will show you how to use SVN branches: If you need to modify your application, or develop a new feature for it, create a new branch from the trunk and develop it based on this new branch unless you have to create a new child branch from a branch, the new branch must be created from the trunk When you create a new branch, you should switch the past immediately. If you didn't, why did you create this branch in the first place?

--tags

on the surface, there is no difference between SVN branches and SVN tags, but conceptually, there are many differences. In fact, an SVN tags is described above, "take a photo of this tree": a trunk or a branch revision of the named snapshot.

The following will show you how to use SVN tags: as a developer, never switch to, remove, or submit anything to an SVN tag: a tag is like some kind of "photo", not a real thing, tags are only readable, not writable. in environments where special or special attention is required, such as: production environment (production),. (staging), test environment (testing), etc., only from a fixed (fixed) tag checkout and update, never commit to a tag. for the above mentioned environment, you can create the following tags: "production", "staging", "testing" and so on. You can also name the tag according to the software version, the maturity level of the project: "1.0.3", "stable", "latest" and so on. When the trunk is stable and can be released externally, it is necessary to recreate tags accordingly, and then update the relevant environment (production, staging, etc)

--workflow Example

Suppose you have to add a feature to a project, and the project is versioned, you almost need to complete the following steps: using SVN checkout or SVN Switch gets a new working copy (branch) from the trunk of this project use SVN to switch to the new branch to complete the development of the new feature (of course, to do enough testing, Include before starting encoding) Once this feature is complete and stable (committed), and after your colleagues confirm, switch to trunk to merge your branch to your working copy (trunk), and resolve a series of conflicts recheck the merged code if possible, trouble your colleague to review the code you wrote and changed (review) Submit a merged work copy to Trunk If some deployments require a special environment (build environment, and so on), update the relevant tag to the revision you just submitted to trunk using SVN Update deployment to the relevant environment