GIT plug-in EGIT manual on Eclipse

http://download.eclipse.org/egit/updates/
http://blog.csdn.net/luckarecs/article/details/7427605
Or use Eclipse Marketplace, search for EGit






II_Configuration before using EGIT

Configure personal information, the most The important thing is user.name and user.email

l Preferences > Team > Git > Configuration

l New Entry 3_New





GIT warehouse

New NC module project



l File > Team > Share Project After selecting GIT





to create a warehouse, under the $workspace\demo directory The .git folder is the repository address of git. Unlike CVS and SVN, GIT does not create a version control folder in each directory, but only creates a repository in the root directory.



At the same time, the project in eclipse also establishes git version control. At this time, no branch is created, and it is in the NO-HEAD state.



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

Four_Configuration.gitignore
At this point we try to make a commit

l Team -> Commit…



As shown in the figure above, Author and Committer will default to the user information configured by Git. You can see the files submitted this time in the Files window below. There are many files with NC_HOME. At this time, you can guess that the NC_HOME linked in our project is also defaulted to version control by GIT, as shown below. :



Obviously, NC_HOME and out do not need version control. We can exclude these two folders by configuring .gitignore.

Open the Navigator window, add a .gitignore file to the project root directory, and write the directory that needs to be excluded from control to .gitignore In the file, try to commit



again , and the files to be submitted have been filtered



. After the first submission, the master branch will be automatically generated



and then create a new file in public. You can see that the icon is still a question mark and is in an untracked state, that is, git does not monitor this file.



Through Team -> Add to index, you can add files to the git index and perform version monitoring.



You can see that the icon display has also changed (as long as Commit in EGIT, you can add untracked files to the index by default and then submit the update, no separate operation



is required). Files can be excluded from index control via Team -> Untrack.

Commit the newly added file to the warehouse, the file will be in the unmodified state, or in other words, this is a staged state



and then modify the content of the file, the file will be in the modified state 5_View



history
Team -> Show in history can View the version history and commit records,






you can choose the comparison mode








6_remote GIT warehouse
The premise of this summary is that the GIT server has been built and connected through the SSH protocol. Please refer to the documents "Building a GIT Server under RHEL", "Building a GIT Server under Windows XP" and "Basics of GIT Server Use". This article uses GIT-2012-01-11 under the RHEL5.5 system, the user root/password, and the GIT repository is uniformly stored in the /app/gitspace directory.
First, connect to the server through the shell tool, and create an empty warehouse gitdemo. The ssh access address at this time is as follows, which consists of protocol name, user name, IP, port, and git warehouse directory.

ssh://[email protected]:22/app/gitspace/gitdemo

Open the GIT repository window and select clone repository











Now that the remote GIT repository has been cloned to the local, the next step is to check out the repository as an NC module project.





Finally, the gitdemo module project is obtained. The branch is mirror



seven _ push the remote warehouse. After

cloning the server-side warehouse, an identical warehouse will be created locally, called the local warehouse. Performing the commit operation locally will submit the update to the local warehouse, then you can pull the server-side update to the local warehouse for merging, and finally push the merged local warehouse to the server side, thus making a remote submission.



Submit once to the local warehouse



and then push to the mirror branch on the server side. After Team -> remote -> Push



completes the push, you can view the record in the log of the mirror image on the server side.




Eight_Resolve push conflict

In the case of multi-person collaborative development, conflicts will inevitably arise when pushing updates to the server, so the conflict between the latest version on the server and the local repository needs to be resolved before pushing. The pull operation is to pull the server-side updates to the local warehouse for merging. After the merge conflict is resolved, the server branch can be pushed smoothly.

Assuming that the Mairo brothers are using GIT to develop the NewSuperMairoBro game, the current content of the mushroom.java file on the server side is as follows:



After MairoBro cloned the code, Mairo brother made the following



modifications



Use pull to merge the local warehouse and the remote warehouse, and the release files will conflict. At this time, GIT will automatically merge the conflicting files, as shown in the following figure:







Obviously, the automatically merged conflict files cannot be used directly. file, select Team -> Merge Tool



. The first item is to compare the file that GIT has automatically merged with the server-side file.

The second item is to use the latest version of the local file to compare with the server-side file. It is recommended to use this item.

Next is The familiar comparison interface



, Brother Mairo, modified the conflict file as follows,



then right-clicked the conflict file, and selected Team -> Add to index to add the file to the index control again. At this time, the file is no longer in conflict state, and can be submitted and pushed to the server



for resolution . After the merge conflict, Mairo's younger brother only needs to pull the merged version from the server to the local to complete a code merge for collaborative development. As can be seen from the history record, the history enters the branch from the mushroomroom, first is the record of mushroomA, then the record of mushroomB, and finally the history branch is merged.




Nine _Rebase and Merge difference
The final result of the Rebase and Merge operations is the same, but the implementation principles are different.

From the above MairoBro example, you can know how the pull merges the history records. In fact, the default pull operation is a branch merge operation, as shown in the figure below: Mairo brother

's submission record is as follows:



Mairo brother's submission record is as follows :



First, the younger brother Mairo pushes the update to the server, so that the records on the server side are the same as the local records of the younger brother Mairo, and then the older brother Mairo performs the pull operation. Now analyze how the pull operates.

l By default, pull is to first update the latest record on the server side to the corresponding mirror branch in the local Remote Tracking.

l Then perform the merge operation on the mirror branch of the Local and the mirror branch of Remote Tracking.



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



As can be seen from the above figure, MushroomA is before MushroomB. This time relationship does not depend on who executes the push first, but depends on who executes the commit first in the local warehouse. So merge will strictly record each commit in chronological order.

Let’s take a look at rebase next. In fact, rebase is also an operation of merging two branches. When Mairo’s brother push is updated, the history of the mirror branch on the server side is as follows:



Mairo’s local history is as follows:



Now Mairo’s brother is not performing the merge operation, but Execute the rebase operation, and 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, let's first analyze what changes have been made to the historical records of brother Mairo under the rebase operation:

l first The updated part of the current branch is saved to the temporary area, and the current branch is reset to the record of the last pull.



Then the server-side update is added to the current branch. At this time, the current branch and the server-side branch are the same.



Finally, update the original branch. Part of the mushroomA is submitted to the back of the current branch, which is to add the update of mushroomA after the mushroomB. Of course, the update record is no longer the previous mushroomA. If there is a conflict, use the comparison tool to resolve the conflict, and finally the record becomes mushroomA*.



If brother Mairo has submitted mushroomA1, mushroomA2, and mushroomA3, then after rebase is executed, the merges shown in the figure above will be performed in sequence on mushroomA1, mushroomA2, and mushroomA3, and finally recorded as mushroomA1*, mushroomA2*, and mushroomA3*. Obviously the rebase operation is more complex, the probability of conflict is higher, and it is not recorded in chronological order.

Ten _A simple analysis of how to choose Rebase and Merge Why is

this summary a simple analysis, because the discussion on the choice of rebase and merge is relatively intense, and the author does not have a conclusion, and git is also in the research and development stage, and many theories have not been fully completed. Sophisticated.

For a multi-person development team that frequently submits updates, using merge will make the historical line graph very complicated, and merge will add a record point at a time. If rebase is used, it is completely linear development.



The above picture shows the two results of Merge and Rebase. Obviously you don't want the confusing result of merge. Can you tell me that the line in the merge diagram is the master branch?

Therefore, the following suggestions are given. If the same file is modified repeatedly or submitted many times, and many conflicts are expected, then merge can be used, and only one conflict needs to be resolved (however, large-scale thematic modification, should it be? How about opening a new branch in advance?); If the scope of modification is small and the expected conflict is small, it is recommended to use rebase.

The default pull operation in EGIT is Fetch+Merge. If you want to use rebase, you can operate it separately. First perform Fetch to update remote tracking, and then perform rebase to merge (the rebase operation will be introduced in the next section). Or modify the default operation of pull and configure it in the .git/config file:



the above configuration is only valid for the mirror branch, and it can also be configured globally. It can be configured in $HOME/.gitconfig. If the HOME variable is not configured in the Windows system, it will default to $documents and settings/ USER directory:



Eleven _Fetch and Rebase

MairoBro to do fetch and rebase tests, first, Mairo brother adds the file OPQ to the client and submits it separately, and pushes it to the server, as shown in the figure:



At this time, the history of the server has been It has been updated, but the mirror branch in the remote tracking of brother Mairo has not been updated to the latest record, as shown in the figure:



Therefore, the branch in remote tracking needs to be updated to synchronize it with the branch on the server side. Right-click the resource library and select Fetch





to update it. The branch in local remote tracking, so that it is synchronized with the server-side branch.



Then brother Mairo adds the file ABC in the local private and submits it to the local warehouse respectively.



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









. As shown in the figure above, you can see that the order of the history records is OPQABC, the rebase has been successful, and then push to the server.

12_Reset function

There are three reset functions in GIT, which are soft, mixed, and hard. The differences are as follows:

l Soft - the current branch is reset to the specified commit record position, and the index and work tree remain unchanged;

l Mixed - the current branch Reset to the specified commit record position, the index is updated, and the work tree remains unchanged;

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

It seems difficult to understand. First of all, you must understand the three areas of GIT (work tree, index area, and warehouse). You can refer to the document "GIT Introduction".

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



first , and reset the submission in the History window after submission, as shown in the figure:



View the work tree after reset, such as Figure As can be seen



from the above figure, the soft file still exists, indicating that the reset did not change the working tree, and 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 thing reset is the history.

Then create a new Mixed.java file. At this time, Mixed.java is not added to the index control, and then submit. Reset



in the History window and view the working tree result after reset as follows:







As can be seen from the above figure, the Mixed.java file still exists, indicating that the working tree has not changed, but the file status is untracked, indicating that the index has been updated, and the file has not added index control at this time.

Finally, look at the hard reset, create a new Hard.java file, and then submit the file without adding an index.



Reset this commit on the History interface, as shown in the figure:



Check the work tree after reset, and the result is as follows:



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