Talking about the principles of Maven and git and their use in the IDE

This article is reprinted blog, original address: http://www.blogjava.net/youxia/archive/2013/12/29/408182.html

Resources:
1.Maven Official Document Http://maven.apache.org/guides/index.html
2.Git Official Document Http://git-scm.com/documentation
3.SPRINGSIDE4 Official Document Https://github.com/springside/springside4/wiki

This blog post is different from articles such as the MAVEN use tutorial, git tutorial, and more everywhere on the web. I don't start with software installation and basic commands, but by exploring what design philosophies they contain and what kind of project management experience they can bring to us, so that you can get started with Maven and git in the shortest time possible with a blog post.
MAVEN is a great Java Project management tool. When doing a project in Java, the creation, compilation, testing, packaging, and installation of the project requires a lot of commands, and when compiling and running the Java program, you must be able to find the jar package that the project depends on in the Classpath, otherwise the compilation will not run smoothly and it is not likely to succeed. To solve these problems, Maven was born.

Features of Maven:
1. You can create a project from a template, or you can generate a template from an existing project, where the template, Maven terminology, is called archetype;
2. Automatic management of dependent jars;
3. The configuration file is very brief;
4. Can have a very rich plug-in, for most people, the use of plug-ins is very simple, do not need to know how to write plug-ins, and plug-in download and management are automatic.

MAVEN Keyword: convention; Phase archetype; GroupId; Artifactid; Plugin Task Dependency Repository

Here's what I understand about maven.
When Maven manages a project, a Pom.xml profile is placed in the project's directory, which is very brief. The reason to make the profile very brief is because Maven manages the project with a Convention (Convention), the directory structure of the MAVEN project is basically fixed, and the definition of the various phases of project management (phase) is also fixed, So even if you do not make any special definitions in the Pom.xml configuration file, you can use MAVEN's standard commands mvn compile, MVN test, MVN package, mvn install to automate project compilation, testing, packaging, and installation.
For complex tasks, it is done through plug-ins (plugin), which are defined as tasks (Task) in the plug-in, using the format mvn plugin:task. Creating a new project using MAVEN is done through the Archetype plugin's generate task, with the command format MVN archetype:generate. Similarly, the project file for the eclipse can be generated for MAVEN-managed projects, and the command is MVN eclipse:eclipse. Plug-ins and dependencies are automatically downloaded and managed, without the need for user intervention.
Automatically downloaded dependencies and plugins are stored in the local repository (repository), which is typically located under the. M2 Directory of the user directory. When our own project executes MVN install, it is also installed to the warehouse by default. Each project needs to be identified by GroupID, Artifactid, and version, including our own projects, dependencies, plugins, templates for creating new projects, and so on. You need to specify Archetypegroupid and Archetypeartifactid when you create a new project using MVN archetype:generate. GroupID represents the group in which the project is located, For example, Org.apache.maven, this is the Java World naming philosophy, here is not described in detail, artifactid only need to specify a project name can be packaged as a jar file, will generate a file named Artifactid-version.jar.
See below for a concrete example. If you want to create an empty project, use the following command:
MVN archetype:generate \
-darchetypegroupid=org.apache.maven.archetypes \
-darchetypeartifactid=maven-archetype-quickstart \
-dgroupid=com.xkland.maven-example \
-dartifactid=maven-example If you want to build a blank Web project, use the following command:
MVN archetype:generate \
-darchetypegroupid=org.apache.maven.archetypes \
-darchetypeartifactid=maven-archetype-webapp \
-dgroupid=com.xkland.maven-web-example \
-dartifactid=maven-web-example as you can see from the above command, to create different types of items, you only need to specify a different archetype. Let's look at the file structure of the project generated with the above command.

Then take SpringSide4 as an example. Clone SpringSide4 from GitHub first. (The git command later) is as follows:
git clone https://github.com/springside/springside4.git into the Springside4 directory, you can see there are three main directories, respectively, examples, modules, Supports Go to the Modules directory and run mvn install to mount the SPRINGSIDE4 to the local repository, which is simple. However, this operation takes a long time because you need to download a lot of dependent libraries.
After installing the SPRINGSIDE4, to create a Springside-based project, first go to Support/maven-archetype directory, run mvn install Springside archetype, Then just use the following command:
MVN archetype:generate \
-darchetypegroupid=org.springside.examples \
-darchetypeartifactid=quickstart-archetype \
-darchetypeversion=4.1.1-snapshot \
-dgroupid=com.xkland.springside-sample \
-dartifactid=springside-example the command involves no more knowledge than I have previously discussed. I'm not talking about the configuration syntax of the Pom.xml file, you can refer to the official documentation, and later, we will enter the IDE era.

In the software development process, there is another problem to be solved, that is the source code version control and multi-person collaboration. Now the most popular version control software is git, and more and more open source software is migrating from subversion to Git.
Features of Git:
1.Git is a distributed version control system that does not have the concept of a central server (although a central server can be built in real-world development), with a complete history on each development machine, but it has the concept of local code warehouses and remote code warehouses (or how many people collaborate.) ), and can track multiple remote repositories;
The 2.Git is able to set up branch and merge branches very quickly and has the ability to track branches and switch branches.
The above two features determine the process of working with Git. I'll elaborate on the use and workflow of Git later. Let's take a look at what keywords git needs to understand.
Key words of git: working directory; Repository Stage Commit Remote Branch Merge
Here's what I understand.
Each project should have a working directory (working directory), we can build a directory ourselves (this is not nonsense.) Don't worry, there's more. ), and then use Git to manage the code in this directory (using the git init command and git add command, as detailed later), or you can clone a project from somewhere else with the git clone command to automatically generate a working directory. The files in the working directory are the files that are currently being edited and modified, and if it is a newly created directory or a new clone directory, the files in the working directory are the latest state of the project. Git has all the history and branch records stored locally, which are in the. git directory of the working directory, called the Local repository (locally repository). When switching branches or viewing previous versions of history, the files in the working directory change automatically (this is the focus, the work does not need to switch directories, the files in the directory will automatically switch). There are three types of files in the working directory: modified, staged, committed. The modified file can be added to the staging area and submitted together at the end of the work.
Git is distributed, without the concept of a central server, but the actual work can still put the code warehouse on a server that everyone can access, do the actual central server use (this workflow is used only in small teams, the reason is detailed later). After working on the local machine, use the git push command to push the repository to the server, and replace it with a different machine, just git clone, and get all the code (including all the history and branches) to continue working. Server failure is not a problem, because every working machine has a complete code repository, so never worry about code loss. There is no network, it can be committed on the local machine (git commit), because the entire warehouse on its own machine, when there is a network, push a bit.
Git has a remote repository concept, and can manage many remote repositories, a remote repository can be a server, or someone else's personal computer (but generally no one uses it), and each remote repository has a short name and an address, repository. The remote repository alias at the beginning of the clone code is often default to origin, and the remote repository you add can optionally specify an alias, and all remote repositories can modify the alias at will. You can get the code (git fetch command or git pull command) from the remote repository, or you can push your code to the remote repository (the git push command requires write permission).
Now that git can get code from a remote repository and push its own code to a remote repository, wouldn't it be a mess when people collaborate? The solution to this problem is Git's must-kill technique-creating branches and branching merges. Let's use the chart to illustrate the problem. The following series of images comes from the e-book Pro git on the official Git website.
First, as you commit again and again, form a main branch in your local code base, as shown in the following diagram:

Sometimes in order to develop new features, you can open a new branch at any time, as shown below:



The new branch and the main branch can be switched at will, as the branching progresses, as in the following diagram:



The main branch can also move forward, as follows:



Finally, when the new branch code is stable, you can merge it into the main branch, as shown in the following diagram:



The key to being able to prevent confusion when collaborating with multiple people is that when you go from a remote repository clone code library to a local or fetch code library locally, the markup for the remote branch is not equal to the local branch's markup. After a code base from remote clone to local, its master branch has two tokens, one marked origin/master represents the master branch in the remote library, and one marked Master, which represents the local master branch. The following figure:


As you can imagine, the master branch in the remote repository will certainly move forward because of someone else's work, but the origin/master tag will not move until the next time the network is connected. While the local master tag continues to move forward.

Until the next Internet connection, using the git fetch command to retrieve the contents of the remote repository locally, the origin/master tag will change location, then it looks like two branches, as shown below:

Finally, merging the Origin/master branch into the master branch (using the Get Merge command), the local code base once again becomes a single master branch, continues to develop, and can push it to the remote repository for others to use.
Git conflicts are handled entirely by human. (Logically, machines cannot handle conflicts perfectly.) such as a small team to work with, they can set up a server to save a remote git repository, then everyone to work before working from the remote repository fetch code, then work, after the work is completed, the first submitted locally, and finally push to the remote repository. But when a person push, there are already people pushing before him, if they work in the same branch, there will be conflict. The solution to the conflict is to first fetch the content of others ' push, merge the branches, and push again.
Through the previous understanding of Git principles, you can analyze the following workflows when using Git:
1. A person does not need to consider the conflict, can open branches, merge branches and switch branches at any time, can be submitted locally at any time. If you want to prevent the code from being lost, you can open a server and push it to the server each time the work is done;
2. Small team cooperation, as mentioned earlier, open a server to save the Code warehouse, and then all the people take the server as a remote warehouse, before work to fetch, work and then push. If there is a conflict, the first fetch, the Merge branch resolves the conflict, and then push. If there are too many teams, everyone will push to the server, and that's how many conflicts. It is possible for a developer to push the server for the first time, someone has already push before him, he had to fetch, manually merge to resolve the conflict, but when he again push again, found that someone else he had already push, so he had to do a conflict resolution process, But if he's working, there's another push. This is why the workflow is only suitable for small development teams.
The above process has been appropriately modified can also be used by large teams, that is, groups of teams, each member of the group shared a server when the remote warehouse, the team leader merged the work of the group, and then push to another server when the total remote warehouse, so that can greatly reduce the number of conflicts and reduce workload.
3. Cooperation in open source projects, in which case everyone exposes their own warehouses to the Internet. The organizer or owner of an open source project sets the owner's warehouse as a remote repository, merges meaningful work into the main branch, and then publishes the official Git repository. Each developer completes his work by taking the code from the official warehouse and then pushing it to its own warehouse on the internet, waiting for the project owner to integrate his work into the official warehouse. If the project leader does not work, change people, as long as people continue to develop, the project can continue. It can also be grouped if the team is in a larger situation.
The construction of the server is also quite simple, because git supports the SSH, HTTP and other protocols to transmit data, if you need to write permissions to the server, you can open the SSH service bar, set up an account for everyone to access the Git repository. If you only need read-only permissions, use any one of the HTTP servers. For the construction of a git server, please refer to the official documentation yourself. If it is a personal, open source project, you can use the services provided on the GitHub website to store it directly on the Internet. (GitHub's private warehouse is for cash.) ）

It's not easy to make git clear, with so much space. Here's a look at Git commands:
git config configuration git, general use does not need special configuration, but at least to set the developer's name and mailbox
Git init and git add create a new repository and track files in the working directory
git clone clones a project from remote, including working directory and warehouse
Git add puts the modified file into the cache area (staging areas), or this indicates that the conflict has been resolved
Git status Displays the status of the file, whether it has been modified or has been cached or committed
Git commit commits the project
GIT Remote repository Management
git fetch and GIT pull fetch data from remote repositories
git push pushes data to remote repository
Git branch and git merge to create branches and merge branches
git Checkout switch branches

Git also has a visualizer gitk, which allows you to graphically view information such as the history, branching, and merging branches of a commit. The following figure is a screenshot of the gitk I executed in the SPRINGSIDE4 directory:

You can see that there is a complicated record of branching and branching.

The installation of Maven, Git, and Eclipse is not written in this post because it takes only one sudo apt-get install maven Git Eclipse in my system, and OPENJDK is automatically installed as a dependency. Yes, you're right, I'm using Ubuntu. OS version ubuntu 13.10,maven 3.0.4, git 1.8.3.2, Eclipse 3.8. Install the M2E and Egit plugins for Eclipse as well.
If I just write about maven and git in general, it's not my style anymore, and here's the show picture, of course. Friends who don't have a widescreen display are not up to it. However, you can zoom out and view the Web page by Ctrl + the mouse wheel.
Below is the image of my Ubuntu desktop:

The following figure, using the simple and powerful ancient artifact vim editor in the Virtual Console (gnome-terminal), with a translucent background, is cool:

The following figure, my work interface, while using the console and Eclipse, is convenient and efficient:


When choosing a new project in Eclipse, you can choose to create a MAV