Open source software configuration management process (1)--git

The software configuration management process is an important process throughout the software development cycle, and for this reason, there are many well-known enterprise tools, open source CVS, SVN, Enterprise-Class ClearCase, PVCS.
Because of the limited financial resources, unable to research large enterprise-level software, but CVs and SVN for the current software development, has become less convenient. In the field of open source software, open source collaborative development process, the adoption of a variety of mature development model, but it is worth our thinking, so I decided to investigate the open source software project development in the configuration management tools.

Thank you for the reference text of this article:
"Git-A Concise guide"
"A successful Git branching model"
"Contributing to Open Source on GitHub"

One, git--distributed version management tools

Git itself is not called a complete configuration management tool, but in the field of open source, it is currently the best version management tool.
The great thing about git is that it's a version model, and it's simple and straightforward to take snapshots directly. Git versioning is similar to a file system that changes over time, and each version of the content is saved as part of the snapshot, and the benefit is that any two versions can be quickly compared to each other to understand the direct difference between the code.

In order to reduce the resource consumption, if the file has not changed, then it will not be saved, and its changes in the file evaluation is based on the fingerprint information of the file, not the normal system time stamp, so does not produce inconsistent content information and other errors.

In addition, I prefer to use git, most of the operations are performed locally, very efficient, and you are not connected to the situation, still can be version management, if you want to revert to a previous version, it can immediately change your current file as a snapshot of the previous file, very convenient and fast. In many cases, it is easy to work.

A basic git tutorial

Open source software generally like to develop under Linux, I also use ubuntu14.04, then I will explain how Git uses this environment

First, Git is easy to install, just type it under the console:

sudo apt-get install git

If you need a GUI interface for Git, then you need to install:

sudo apt-get install git-gui

Git has a working path concept, and all of our git instructions are used in the workspace where the current path is located, and executing the following statement in a directory will initialize the directory as a Git workspace:

git init

At this point, our warehouse directory will automatically generate a ". Git" folder, which will keep git temporary files and local repositories, etc.
The Git workspace is probably a structure like this:

In Git, every repository is called a repository with local and remote repositories. After Git is initialized, a local repository is built for you, head points to the current development branch, and a buffer stage is created for you to temporarily add files to make a commit. Stash is a working state save stack that is used to save/restore temporary state in workspace.

Next, this instruction will add the file to the buffer:

git add <file name>

Of course, you can also use the following instructions to add a directory file to the buffer:

git add <path>

If you feel that the files in the cache are ready to be submitted to the local repository, called a new version, then you can submit the new version to the local repository, the current working local repository, which is the head point of the warehouse, if your branch is not correct, you may need to switch to branch:

git commit -m "commit message"

If you have a GitHub account, or have a remote repository, you can also sync this code to a remote repository, and we'll show you how to use Git to sync code on GitHub later.

git branches and warehouses

Branching is a very useful feature of git, there are a lot of software, after the main framework is written, there will be isolation development needs, in those classic cvs/subversion management tools in the world, merging/branching is considered to be somewhat scary, while using git, everything becomes simple, And git is encouraging you to do this, as much as possible by branching the settings, making the code development process clearer.

Branches are used to insulate the development of features. When you create a warehouse, Master is the "default" branch. Below we will create a branch called "feature_x" and Switch to the past:

git checkout -b feature_x

Switch back to the main branch:

git checkout master

To merge other branches into your current branch (for example, Master), execute:

git merge <branch>

Unfortunately, not all mergers do not conflict, and if two people modify a code at the same time, it often makes it difficult to merge, you need to manually modify the conflicting files and then add them back to ensure that the merge succeeds:

git add <conflicts file name>

A successful branching pattern is probably like this:

In many cases, we often do not care about the management of the branch, but this often brings problems to open source projects, and a reasonable design of open source projects, often can be very convenient multi-person collaboration.
And here's a look at the branching model, the process of each operation and its implications for the development process.

Main branch and Develop branch

We'll find out that the code that we've signed off on GitHub basically works perfectly directly, so how do you maintain the development version?
In general, we will build two branches like this:

• Master Branch
• Develop Branch

The master branch of origin is familiar to every git user. Another branch of parallelism is called the develop branch.
We think that each version of the code on the Master branch is available for publication. While developing the switch to the develop branch, on the key node, do the test, confirm the error, will be merged with the Master branch, and then hit the release number tag. For this operation, it should be strictly to ensure that the quality of each release version.

Feature Branch

Feature Branch (attribute branch) is a very useful auxiliary branch, the main goal is to help the players in parallel development, each person should be in different branches to develop their own auxiliary new features, so that everyone's work is in a very clear version of the.

If this is not the case, one of the serious consequences may be that someone's version contains untested code, and this code is directly submitted to the develop branch, then everyone's work after the code update, but all have problems, all employees are debugging, will seriously affect the progress of the project.

New branch, which is like putting the current version of the code into a secure implementation sandbox, even if the problem does not affect others, but we still do not recommend to publish their own feature branch to the public code base, of course, except for co-development. Attribute branches can be created from develop branches, and eventually must be merged to develop branches, as long as the feature is still in development, the branch should exist, but will eventually be merged into develop or discarded.

Release Branch and Hotfix branch

Release Branch is the new version is about to release, the core team should establish a corresponding release-* branch, this branch is used in the current identified software features, no longer add new features, full repair of existing bugs, debugging software and final testing, packaging and publishing work. The point at which the new release branch is pulled from the develop branch is when the development work has reached the expectations of the new version. At least at this point in time, all target attributes for the next release to be released must have been merged into the develop branch. The remaining unnecessary features can not be merged first, and so on, and then merge into the develop branch, so as not to increase the pre-release test and debugging difficulty.

Once the release branch is created, the next version number is determined, along with the new features supported by the release, where we can update the new feature list for the software, perform testing and minor repairs, build a release package and install packages, and more.

After all the work is done, we'll merge the release branch back into the master branch and tag the tag

$ git checkout master$ git merge --no-ff release-1.2$ 1.2

Below we also need to save the release branch of minor repairs, you need to merge it into the develop branch, but because some project development team is still working, may also update the code of the develop branch, this step merge may also introduce conflicts.

$ git checkout develop$ git merge --no-ff release-1.2

Hotfix branches are also temporary auxiliary branches that are used to temporarily fix existing problems, so we can temporarily create a new hotfix branch from a problematic release, which ends after a simple bug fix.

Once the work is done, the resolved bug code needs to be merged back into the master branch, but it also needs to be merged into the develop branch to ensure that the bug has been resolved in the next release. Of course, there may be some special cases, if a release branch exists, the hotfix branch needs to be merged into the release branch instead of the develop branch, because hotfix is urgent and should be released as soon as possible.

Upstream and downstream warehouses

There are some very large software, often in the way of component development, a component is often dependent on some other components, in their development process, upstream and downstream relationship is also very important.

Git can easily add its own upstream repository of interest:

git remote add pb git://github.com/reponame.git

You can also easily get the latest version

git fetch pb

Again, you need to sync to your remote repository to make others see your changes and use the command git push [remote-name] [branch-name] :

git push origin master

Of course, your update doesn't have to be successful, and if someone else pushes the update before you push the data, then your update will fail, you have to sync to the latest version and merge with your current version so you can update the version, as well, in the GitHub collaboration model, there are similar problems, when you send PR, If someone else updates first, then you have to sync, and your updates will be accepted.

In some production environments, even artists have their own remote warehouses, they will be their own design drawings uploaded to the Art warehouse, the front-end designers as long as the update, you can know whether they have new design patterns.

Open source software configuration management process (1)--git