Egit user manual for Git plugin on eclipse?

Egit user manual for Git plugin on eclipseOne _ Install Egit plug-in

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

Or, using Eclipse Marketplace, search for Egit

Two _ configuration before using Egit

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

L Preferences > Team > Git > Configuration

L New Entry

Three _ New git repository

New NC Module Project

L File > Team > Share Project Choose Git

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

At the same time, project in Eclipse builds git versioning, where no branch is created, in No-head state

The symbol in the folder "?" Indicates that the folder is in a untracked state so that the GIT repository is created successfully.

Four _ configuration. Gitignore

At this point we try to do a commit

L-Team--Commit ...

As shown, author and committer default to the user information that is configured for Git. In the Files window below you can see the submitted file, which has a lot of files with Nc_home, and you can guess that the nc_home linked in our project is also being defaulted to version control by git, like this:

Obviously nc_home and out are not required to be versioned, and we can exclude the two folders by configuring the. Gitignore.

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

Try commit again, files that need to be submitted have been filtered

The master branch is automatically generated after the first commit

Then create a new file in public, you can see the icon is still a question mark, in the untracked state, that is, git does not monitor this file

You can add a file to the GIT index for version monitoring by using team-, add to Index

You can see that the icon display has also changed (in Egit, you can add the untracked file to the index by default and commit the update without having to separate the operation)

You can also exclude files from index control by using team---untrack.

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

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

Five _ View history

Team-and show-history can view the version historical commit record

You can choose the contrast mode

Six _ remote git repository

This summary is based on the premise that the GIT server has been built, and through the SSH protocol connection, you can see the document "Set up git server under Rhel" "WindowsXP git Server" "Git servers use the foundation." This article uses the git-2012-01-11 under 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, the establishment of an empty warehouse Gitdemo, at this time the SSH access address is as follows, respectively, by the protocol name, user name, IP, port, git repository directory composition.

Ssh://[email Protected]:22/app/gitspace/gitdemo

Open the Git repository window and select Clone repository

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

Finally get Gitdemo Module project, branch is mirror

Seven _ Push remote repository

Once the server-side repository is cloned, a local repository is created locally, called the Local warehouse. Committing the commit locally commits the update to the local repository, which can then pull the server-side updates to the local repository for consolidation, and finally push the consolidated local repository to the server side, making a remote commit.

Submit to local warehouse first time

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

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

Eight _ Resolve push conflicts

In the case of collaborative development of multiple people, there is a conflict in the push of updates to the server, so the latest version of the server side and the local warehouse conflict need to be resolved before the push is taken. Pull is the server side of the update to the local warehouse to merge, resolve the merge conflict, you can successfully push to the server branch.

Assuming that the Mairo brothers are now collaborating with Git to develop Newsupermairobro games, the current server-side Mushroom.java file contains the following:

Mairobro cloned the code, Mairo brother made the following changes

Mairo Brother made the following changes

Then Mairo brother first push the code, Mairo brother use pull to merge the local warehouse and remote warehouse, the release file conflicts, Git will automatically merge the conflicting files, as shown in:

It is obvious that automatically merged conflict files cannot be used directly, we can manually adjust, right-click Conflicting files, select Team---merge Tool

The first is to compare git auto-merged files with server-side files

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

The next step is the familiar contrast interface.

Mairo Brother Change the conflict file as follows

Then right click on the conflicting file, select Team---add to index again to add the file to index control, when the file is not in conflict state, and can commit and push to the server side

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

Nine the difference between _rebase and merge

The final result of the rebase and merge operations is the same, but the implementation principle is different.

From the Mairobro example above, you can see how pull has probably merged the history record, but the default pull operation is a branch merge operation, such as reproducing:

Mairo Brother's submission record is as follows:

Mairo Brother's submission record is as follows:

First of all, Mairo brother put the update push 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 of how pulling is done.

L PULL the default is to update the server side of the latest records to the local remote tracking corresponding to the mirror branch

L then merge the local mirror branch with the Mirror branch of the remote tracking

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

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

Next look at rebase, in fact rebase is also the operation of merging two branches, when Mairo brother push update, the server side of the Mirror branch history as follows:

Mairo Brother's local history is as follows:

Now Mairo brother does not perform the merge operation, but instead performs the rebase operation, the final result is as follows:

The obvious difference is that there is no record of branching, and note that this record and mushrooma are not the same record, we first analyze what changes have been made to Mairo brother's history under Rebase operation: mushrooma*

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

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

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

If Mairo brother submits mushroomA1, mushroomA2, mushroomA3, then the rebase, MushroomA1, and MushroomA2 will perform the merge shown separately, The last record is mushrooma1*, mushrooma2*, mushrooma3*. It is clear that the rebase operation is more complex, the probability of conflict is higher, and it is not recorded in chronological order.

10 Simple parsing of how _rebase and merge are selected

This summary why is simple analysis, because the choice of rebase and merge more intense discussion, the author did not have a conclusion, and Git is also in the research and development stage, a lot of theories are not fully skilled.

For a multi-person development team to frequently submit updates, if using merge will make the history line graph very complex, and the merge will add a record point once, if the use of rebase is fully linear development.

As shown in the two results of merge and rebase, obviously you don't want the messy result of merge, can you tell me if the line in the merge diagram is the Master branch?

So give the following suggestions, if the same file is repeatedly modified or submitted more times, expect a lot of conflict, then you can use merge merging, only need to resolve a conflict (however, a large-scale theme-style modification, 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, which can be operated separately if you want to use rebase. Perform a fetch update of the remote tracking, and then perform the rebase merge (the rebase action is described in the next section). or modify the default action of Pull, which is configured in the. git/config file:

The above configuration is only valid for Mirror branch, can also do global configuration, configured in $home/.gitconfig, Windows system default in $documents and Settings/user directory if the HOME variable is not configured:

11 _fetch and Rebase

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

The server-side history has been updated, but the mirror branch of Mairo Brother's remote tracking has not been updated to the latest records.

So you need to update the branch in the remote tracking so that it synchronizes with the server-side branch and right-click on the repository to select Fetch

This updates the branch in the local remote tracking so that it synchronizes with the server-side branch.

And then Mairo brother adds the file ABC to the local private, and submits it to the local repository, respectively.

Then rebase the local mirror branch and the Mirror branch in the remote tracking, checkout the local mirror branch first, then right-click to select Rebase

If you can see the history of the order is OPQABC, has been rebase successful, and then push to the server.

12 _ Reset function

There are three reset functions in git, namely soft, mixed, hard, and the difference is as follows:

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

L Mixed- The current branch is reset 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 the index and work tree are updated.

Seemingly not good understanding, the first to understand git three areas (work tree, index area, warehouse), you can refer to the document "Git introduction."

Do soft test first, create a new Soft.java file, you can see this file is not added to the index control

Commit once, and then reset the submission in the History window.

View the work tree after resetting,

As you can see, the soft file also exists, stating that the reset does not change the working tree, and that the soft file is not a "question mark" icon, stating that it has been added to the index, indicating that the index has not changed. The only resets are historical records.

Then create a new Mixed.java file, at which point Mixed.java is not added to the index control and then commits.

Reset in the History window

To view the working tree after resetting the results are as follows:

As can be seen, the Mixed.java file also exists, indicating that the work tree has not changed, but the file status is untracked, indicating that the index is updated, the file does not add index control.

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

Reset this submission at the history interface,

Reset and then look at the working tree, the results are as follows:

You can see that the Hard.java file does not already exist, indicating that both the index and the work tree are updated.

url:http://blog.csdn.net/luckarecs/article/details/7427605

Egit user manual for Git plugin on eclipse?