Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
student:eclipse:git [2019/12/11 16:49] – Added the section on non-fast-forward bernstdhstudent:eclipse:git [2025/03/28 14:12] (current) – bernstdh
Line 1: Line 1:
 ===== Using Git with Eclipse ===== ===== Using Git with Eclipse =====
  
-The Eclipse plugin that integrate Git with Eclipse is called EGit.+The Eclipse plugin that integrate Git with Eclipse is called EGit. For more information, see the [[ https://wiki.eclipse.org/EGit/User_Guide | Egit User Guide ]].
  
 ==== Installation ==== ==== Installation ====
Line 10: Line 10:
 ==== Configuration ==== ==== Configuration ====
  
-To configure Git, click on <key>Window+Preferences</key>. Then, expand <key>Git</key> and click on <key>Configuration</key>.+To configure Git, click on <key>Window+Preferences</key>. Then, expand <key>Version Control</key>, expand <key>Git</key>, and click on <key>Configuration</key>.
  
-Since many Git servers use your email address for authentication, it is important that the ''user.email'' value exists and is correct. +Since many Git servers use your email address for authentication, it is important that the ''user.email'' key exists and that the value is your email address. It's useful if the "user.name" key exists and that the value is your personal name (e.g., first name) followed by a space and your family name (e.g., last name).
  
 You can edit an existing entry by clicking on it. You can add an entry by clicking on <key>Add Entry...</key> and then entering a key and value. Keys are hierarchical, with levels delimited by a ''.'' character (e.g., ''user.email''). You can edit an existing entry by clicking on it. You can add an entry by clicking on <key>Add Entry...</key> and then entering a key and value. Keys are hierarchical, with levels delimited by a ''.'' character (e.g., ''user.email'').
Line 26: Line 26:
  
   - Open the [[ #opening_the_git_perspective | Git Perspective ]]   - Open the [[ #opening_the_git_perspective | Git Perspective ]]
-  - Click on "Create a new local Git repository"+  - Click on "Create a local Git repository"  (or the icon for creating a Git repository).
  
 Note that you should not put the repository under the directory containing the Eclipse workspace. Note that you should not put the repository under the directory containing the Eclipse workspace.
Line 32: Line 32:
 ==== Adding a Project to Version Control ==== ==== Adding a Project to Version Control ====
  
-A project should be added to version control only once. After that, files in the project can be added to version control individually (or in groups). It is best to create a local repository for the easiest to add a project to version control +A project should be added to version control only once. After that, files in the project can be added to version control individually (or in groups). To add a project to version control:
- +
-To add a project to version control:+
  
   - [[  #creating_a_local_repository | Create a local repository ]] (if you have not already done so)   - [[  #creating_a_local_repository | Create a local repository ]] (if you have not already done so)
Line 43: Line 41:
   - Click on <key>Finish</key>   - Click on <key>Finish</key>
  
-The name of the local repository you are using for this project will now appear next to the name of the project. In additions, the icons on any directories/files in the project will change to indicate that they have not yet been committed.+The name of the local repository you are using for this project will now appear next to the name of the project. In addition, the icons on any directories/files in the project will change to indicate that they have not yet been committed.
  
 If you look at the project directory (outside of Eclipse) you will see that it is now empty, and if you look at the If you look at the project directory (outside of Eclipse) you will see that it is now empty, and if you look at the
Line 64: Line 62:
 The easiest way to instruct Git to commit files to the local repository is: The easiest way to instruct Git to commit files to the local repository is:
  
-  - Open the [[ Git Perspective | opening_the_git_perspective ]]+  - Open the [[ #opening_the_git_perspective|Git Perspective ]]
   - Click on the "Git Staging" tab   - Click on the "Git Staging" tab
   - Select the appropriate files in the "Unstaged Changes" list   - Select the appropriate files in the "Unstaged Changes" list
Line 80: Line 78:
 The "URI", "Host", "Protocol", and "Port" will vary with the Git host. The "URI", "Host", "Protocol", and "Port" will vary with the Git host.
  
-You will also be asked to provide a "User" and "Password" for that host. If you select "Store in Secure Store", Eclipse will save this information for you locally, and you will not need to provide it each time you push. Otherwise, you will need to authenticate yourself each time you push.+You will also be asked to provide a "User" and "Password" for that host. Because of recent security enhancements, you must enter your "Personal Access Token" in the "Password" field, not your GitHub password. (If you select "Store in Secure Store", Eclipse will save this information for you locally, and you will not need to provide it each time you push. Otherwise, you will need to authenticate yourself each time you push.)
  
  
Line 87: Line 85:
 The easiest way to clone a remote repository is to: The easiest way to clone a remote repository is to:
  
-  - Open the [[ #opening_the_git_perspective | Git Perspective ]] +  - Open the [[ #opening_the_git_perspective | Git Perspective ]]. 
-  - Click on "Clone a Git repository" +  - Click on "Clone a Git repository". 
-  - Enter the "URI", "Host", "Repository path", and "Protocol" +  - Enter the "URI", "Host", "Repository path", and "Protocol". 
-  - Enter your authentication information for the Git server +  - Enter your authentication information for the Git server.  (Because of recent security enhancements, you must enter your "Personal Access Token" in the "Password" field, not your GitHub password.) 
-  - Select the appropriate branch (probably ''master'') and click on <key>Next</key>+  - Select the appropriate branch (probably the main branch, the name of which may vary but should be apparent from the context) and click on <key>Next</key>.
   - Enter the appropriate local directory for the "Destination", the appropriate "Remote name" (probably ''origin''), and click <key>Finish</key>.   - Enter the appropriate local directory for the "Destination", the appropriate "Remote name" (probably ''origin''), and click <key>Finish</key>.
  
 At this point, you will have cloned the repository but you will not have any Eclipse projects. To import a project from the repository, while still in the Git Perspective you should: At this point, you will have cloned the repository but you will not have any Eclipse projects. To import a project from the repository, while still in the Git Perspective you should:
  
-  - Expand the repository +  - Right-click on the repository 
-  - Expand the "Working Tree" +  - Select <key>Import Projects...</key> 
-  - Right-click on the project of interest +  - Select on the project(s) of interest
-  - Select <key>Import Projects</key>+
   - Click on <key>Finish</key>   - Click on <key>Finish</key>
  
 +Note: Some versions of Eclipse/Egit have a defect that require you to close Eclipse at this point and re-start it.
  
 ==== Responding to ''non-fast-forward'' Messages  ==== ==== Responding to ''non-fast-forward'' Messages  ====
  
-If you attempt to push changes that weren't made to the most recent revision (which the system considers the "official revision") the you will receive a ''non-fast-forward'' message. To remedy the situation, you must conduct retrieve the most recent central revision, resolve any conflicts that arise between it and your local revision, and then push the result (which will succeed because it only involves changes to the most recent revision). This can be accomplished in two different ways, using a merge or using a rebase. A merge is non-destructive (i.e., the existing branches are not changed in any way) whereas a rebase rewrites the project history.+If you attempt to push changes that weren't made to the most recent revision (which the system considers the "official revision") the you will receive a ''non-fast-forward'' message. To remedy the situation, you must retrieve the most recent central revision, resolve any conflicts that arise between it and your local revision, and then push the result (which will succeed because it only involves changes to the most recent revision). This can be accomplished in two different ways, using a merge or using a rebase. A merge is non-destructive (i.e., the existing branches are not changed in any way) whereas a rebase rewrites the project history. Both are started by right-clicking on the project, pulling down to <key>Team</key> and selecting <key>Pull...</key> (note the ..., there is a <key>Pull</key> option and a <key>Pull...</key> option, the former uses default settings).
  
-=== When Using a Centralized Workflow ===+You can then choose the option to use "When pulling", either <key>Merge</key>, <key>Rebase</key>, or <key>Rebase interactively</key>. If you choose to rebase interactively, the system will take you through the conflicts one at a time. Then, if you are uncomfortable with (or don't understand) the textual conflict markers that are inserted into the code, you can right-click on the name of the file containing the conflict and select <key>Team+Merge tool</key> to open a side-by-side editor.
  
-When you perform a pull with the rebase option, all of your commits are moved to the tip of the master branch. This eliminates the need for a merge commit every time someone needs to synchronize with the central repository. Hence, +When you perform a pull with the rebase option, all of your commits are moved to the tip of the main branch. This eliminates the need for a merge commit every time someone needs to synchronize with the central repository. Hence, 
-it is preferred by most organizations that use a centralized workflow.+it is often preferred by organizations that use a centralized workflow. When using an alternative workflow, the team should agree on when merges and rebases will be used. Opinions differ on which is better because rebasing keeps the history flat and clean whereas merging keeps everything.
  
- 
-=== When Using an Alternative Workflow === 
- 
-When using an alternative workflow, the team should agree on when merges and rebases will be used. Opinions differ on which is better because rebasing keeps the history flat and clean whereas merging keeps everything. 
  
  
  
 +==== Icons/Decorations ====
  
 +Egit uses a variety of different icons/decorations to illustrate the state of files. They are described in the 
 +[[ https://wiki.eclipse.org/EGit/User_Guide/State | Egit User's Guide ]]
  
  
Line 134: Line 131:
  
 To add an entry to the ''.gitignore'' file, right-click on the file and then <key>Team+Ignore</key>. To add an entry to the ''.gitignore'' file, right-click on the file and then <key>Team+Ignore</key>.
 +
 +For more information, see the [[ https://wiki.eclipse.org/EGit/User_Guide | Egit User's Guide ]]
 +
 +
 +==== Troubleshooting ====
 +
 +  - If you get an error related to your HttpConnection when you attempt to clone a repository, it may be because of the HTTP client you are using. To change it, open the Git Preferences dialog and change the HTTP client (e.g., from "Apache HTTP" to "Java Built-in HTTP"
 +