Egit usage Manual for Git plugin on eclipse

One _ Install Egit plugin

http://download.eclipse.org/egit/updates/

Or use Eclipse Marketplace to search Egit

Two _ Use the Egit before the configuration

Configure personal information, most importantly User.Name and User.email

L Preferences > Team > Git > Configuration

L New Entry

three _ New git warehouse

New NC Module Project

L File > Team > Share Project Select git

After the warehouse is created, the. git folder under the $workspace\demo directory is the repository address of git. Unlike CVS and SVN, Git does not create a version control folder in each directory, only the root directory to build a warehouse

Also, project in eclipse builds Git version control, and no branching is created at this time, in a no-head state

The symbol "?" in the folder Indicates that the folder is in the untracked state, so the Git warehouse is created successfully. Four _ configuration. Gitignore

At this time we try to do a commit

L Team-> Commit ...

As shown in the figure above, author and Committer will default to the user information that git configures. You can see this file in the Files window below, which contains a lot of nc_home files, and you can guess that the links in our project nc_home are also being git by default to version control, as shown in the following figure:

Obviously nc_home and out are not required for versioning, we can exclude these two folders by configuring. Gitignore.

Open the Navigator window, add the. gitignore file in the project root, and write the directory you want to exclude control to the. gitignore file

Try a commit again, the file that needs to be submitted has been filtered

The master branch is automatically generated after the first commit

Then create a new file in public to see that the icon is still a question mark, in a untracked state, that git has not monitored the file

You can add files to the Git index via Team-> add to index for version monitoring

You can see the icon display has also changed (in Egit as long as a commit can default to add untracked files to the index and then submit updates, do not need to separate operation)

You can also exclude files from the index control through the team-> Untrack.

Commit this new file to the warehouse, the file will be in unmodified state, or, this is a staged state

Then modify the contents of the file and the file will be in modified state

Five _ View historical records Team-> Show in history can view version history submission records

You can choose the contrast mode

Six _ remote git warehouse This summary is based on the premise that you have built a git server, and through the SSH protocol connection, see the document "Build git server under Rhel" "Windows XP Build git server" "Git Server usage basics." This paper uses the git-2012-01-11 of the RHEL5.5 system, the user Root/password,git warehouse is stored in the/app/gitspace directory uniformly.

First through the shell tool to connect to the server, set up an empty warehouse Gitdemo, the SSH access address is as follows, respectively, by the protocol name, user name, IP, port, git warehouse directory composition.

Ssh://root@192.168.1.101:22/app/gitspace/gitdemo

Open git repository window, select Clone repository

Now that you have cloned the remote Git repository locally, you need to check out the warehouse for the NC module project.

Finally get Gitdemo Module project, branch is mirror

Seven _ Push remote warehouse

After the server-side repository is cloned, a local repository is built locally, called the Local warehouse. A local commit will commit the update to the local warehouse, then the server-side update pull to the local warehouse for consolidation, and the merged local warehouse will be pushed to the server side, so that a remote commit is made.

Submit to the local warehouse first

Then push to the server-side mirror branch, Team-> remote-> Push

After the push is complete, you can view this record in the server-side mirror mirrored log

Eight _ Resolve push conflict

Multi-person collaborative development, in the case of push updates to the server will inevitably conflict, so push before you need to resolve the server side of the latest version and the local warehouse conflict. Pull operation is to the server-side updates to the local warehouse to merge, resolve the merge conflict, you can successfully push to the server branch.

Assuming now that the Mairo brothers are working with git to develop the Newsupermairobro game, the server-side Mushroom.java file currently reads as follows:

Mairobro cloned the code, Mairo brother did the following modifications

Mairo's brother did the following modifications

Then Mairo brother first push code, Mairo brother. Use pull to merge local warehouses and remote warehouses, and the release file conflicts, when git automatically merges conflicting files, as shown in the following illustration:

Obviously automatically merged conflict files cannot be used directly, we can manually adjust, right button conflict files, select team-> merge Tool

The first is to compare the files that git automatically merged with the server-side files

The second is to use the local latest version of the file and server-side files for comparison, recommended this

The next step is the familiar contrast interface.

Mairo Brother changed the conflict file as follows

Then right click on this conflict file, select Team-> Add to index again to add the file to the index control, the file is not a conflict state, and can be committed and pushed to the server side

After resolving the merge conflict, Mairo brother only needs to pull the merged version of the server to the local, completing a collaborative development of the code merge. As you can see from the history, the history of mushroom begins with the branch, first the Mushrooma record, then the Mushroomb record, and the last History branch merges.

Nine differences between the _rebase and the merge

The results of the rebase and merge operations are the same, but the implementation principle is different.

From the above Mairobro example can know how pull probably on the history of the merging operations, in fact, the default pull operation is a branch of the merge operation, the following figure to reproduce:

Mairo's younger brother's submission record is as follows:

Mairo's elder brother's submission record is as follows:

First, Mairo younger brother to push the update to the server, so that the server-side records and Mairo brother Local records are the same, and then Mairo brother to perform pull operations, now analysis under the pull is how to operate.

L pull default is to first update the server-side records to the corresponding mirror branch in the local remote tracking

L then merge the mirror branches of the local mirror branch and the remote tracking

The result of the merge operation is that a new merge record node will be added, as follows:

As you can see from the figure above, the Mushrooma is before Mushroomb, and this time relationship does not depend on who executes the push first, but on who commits the commit in the local repository first. So the merge will record each commit in strict chronological order.

Next look at rebase, in fact, Rebase is also the operation of the merger of two branches, when Mairo brother push update, server-side mirror branch of the history of the following:

The local history of Mairo's brother is as follows:

Now Mairo brother is not performing the merge operation, but performing the rebase operation, the final result is as follows:

The obvious difference is that there is no branch record, and note that mushrooma*, please note that this record and mushrooma are not the same record, we first analyzed under rebase operation, Mairo Brother's history has made changes:

L Saves the update portion of the current branch to the staging area first, and the current branch resets to the previous pull record

L then add server-side updates to the current branch, at which time the current branch and server-side branch are the same

L finally commit the update part of the original branch to the mushrooma of the current branch to add the Mushrooma update after Mushroomb, of course, the update record is not the previous mushrooma, and if there is a conflict, use the contrast tool to resolve the conflict. The last record becomes mushrooma*.

If Mairo's brother submits mushroomA1, mushroomA2, mushroomA3, then the rebase, MushroomA1, MushroomA2 will perform the merge as shown in the previous image, respectively, in the mushroomA3. The final record is mushrooma1*, mushrooma2*, mushrooma3*. Obviously the rebase operation is more complex, the probability of conflict is higher, and is not recorded in chronological order.

10 Simple analysis of how to choose _rebase and merge

This summary why say is simple analytic, because rebase and merge choice question discussion is more intense, the author also did not have a conclusion, and Git also is in the research development stage, many theories have not completely skillful.

For a multiple-person development team to submit updates frequently, if the use of the merge will make the history map very complex, and merge once will add a record point, if the use of rebase is full linear development.

The image above shows two results of the merge and rebase, and obviously you don't want the confusing results of the merge, can you tell me if the line in the merge is the master branch?

So given the following suggestions, if the same file repeatedly modified or submitted more times, expect to appear a lot of conflict, then you can use merge merging, only need to resolve a conflict can (however, a wide range of theme-style changes, should be a new branch in advance.) If the scope of the modification is small and the expected conflict is low, rebase is recommended.

The default pull operation in Egit is Fetch+merge, and if you want to use rebase, you can separate operation. Perform the fetch update remote tracking before performing the rebase merge (the next section describes the rebase operation). or modify the default action for the pull, configured in the. git/config file:

The above configuration is only valid for the mirror branch, or it can be configured globally and configured in $home/.gitconfig, the Windows system defaults to the $documents and Settings/user directory if it does not configure the home variable:

11 _fetch and Rebase

Mairobro to do the fetch and rebase test, first Mairo brother in the client to add files Opq submitted separately, and push to the server, as shown:

At this point, the history of the server side has been updated, but Mairo brother's remote tracking mirror branch has not been updated to the latest records, as shown:

So you need to update the branch in the remote tracking so that it synchronizes with the branch on the server side, right click on the resource pool to select Fetch

This updates the branch in the local remote tracking, which synchronizes it with the server-side branch.

Then Mairo brother adds the file ABC to the local private, and submits it to the local warehouse separately.

Then rebase the local mirror branch and the Mirror branch in the remote tracking, checkout the local mirror branch, and then right click on the Select Rebase

As you can see in the previous picture, the Order of history is OPQABC, has been rebase successfully, and then pushed to the server.

12 _ Reset function

GIT has three reset functions, namely soft, mixed, hard, and the difference is as follows:

L Soft- The current branch is reset to the specified commit record location, the index and the working tree are unchanged;

L Mixed- The current branch resets to the specified commit record location, the index is updated, and the working tree is unchanged;

L Hard- The current branch is reset to the specified commit record location, and both the index and the work tree are updated.

It seems difficult to understand, first of all to understand git three areas (work tree, index area, warehouse), you can refer to the document "Git introduction."

First do soft test, new Soft.java file, you can see this file is not added to the index control

Make a commit first, and then reset the commit in the History window, as shown in figure:

View the working tree after resetting, as shown

As you can see from the image above, the soft file also exists, indicating that the reset did not change the working tree, and that the soft file is not a "question mark" icon, indicating that it has been added to the index, indicating that the index has not changed. The only reset is the history record.

The new Mixed.java file is then created and Mixed.java is not added to the index control and then submitted.

Resetting in the History window

View the work tree after resetting the results are as follows:

As you can see from the illustration above, the Mixed.java file still exists, indicating that the working tree has not changed, but the file status is untracked, the index is updated, and the file does not have index control added.

Finally look at the hard reset, new Hard.java file, the file is not indexed, and then submitted.

Reset this submission in the history interface, as shown in figure:

After you reset, look at the working tree, and the results are as follows:

You can see that the Hard.java file no longer exists, indicating that both the index and the work tree are updated.