Eclipse gitlab

Eclipse gitlab DEFAULT

Eclipse & Gitlab Tutorial

This tutorial shows how to use source control software (GIT) from within Eclipse. There are several hosts that can provide GIT services, and Gitlab appears to be a great one! In this tutorial, I will show you how to CLONE my LPC project for the SJ-One board, and you can use the knowledge to work on your own GIT projects.

Setup Gitlab Profile

  • Create yourself a Gitlab profile.
    Verify it by clicking on the URL sent by Gitlab.
  • At the Gitlab homepage, click on "New Project"
  • Choose a good project name, such as "lpc1758_teamX"
  • If you want to clone my latest LPC project:
    Click on Import existing repository and copy/paste this:
    If you want to create a parent GIT folder and add one or more LPC projects inside, skip this step.
  • Use Private for the visibility level so only your team can access the code
    You will need to add other Gitlab users later (figure it out yourself!)
  • Click on Create Project
Tutorial gitlab newproject.PNG

Clone GIT Repository

In this section, we will bring-in the Gitlab project in your computer through Eclipse. Eclipse uses TEAM as a Git client.

  • Copy your Git Project HTTPS URL
    This is not my project's URL, but YOUR project's URL
  • In Eclipse, make sure that you have the "Git Repositories" view available
    Go to Window --> Show View --> Other
    Click on Git --> Git Repositories
  • Now in the Git window, click on Clone a Git repository
    Your copied Git repository will auto-fill
  • Type your username and password
    Choose "Store in Secure Store"
    Click Next, and then Next again
  • At this window, you will see Finish, but before you click, use correct destination directory
    Choose your "workspace" directory, such as SJSU_Dev/projects
    Choose the same project folder, "lpc1758_teamx"
  • Click Finish, and wait a few minutes for Eclipse to bring-in the Gitlab project
    Your project will show under "Git Repositories" section.
Tutorial gitlab eclipse clone.PNG

Import Gitlab project to Eclipse

If you cloned my LPC project, the final step is to IMPORT the project in Eclipse. As of now (June 2014), Eclipse has a bug where you cannot use "Import Project" while adding the Git project in the previous section, so we will do this manually.

Note that if you want to add multiple LPC projects at this GIT repository, just copy and paste the folders of your projects here, and then IMPORT individual projects. The next section shows you how to COMMIT and PUSH your changes if you have added subfolders of multiple projects at this directory.

  • In the Project Explorer section, right click and choose "Import Project"
  • Under General, pick Existing Projects into Workspace
  • Click Next and browse the root directory of your project and click Finish

Check-in code to Gitlab

After you have a project in Eclipse that is connected to Gitlab, you can now perform changes, and check-in the source code. Making changes is as easy as editing a file. Eclipse will inform you which files have changed by using icons next to the files or folders.

  • Make any changes
  • Right click on your project and click on Team --> Commit
    Type in your Gitlab username and password if needed.
    First line should be the heading or title of your commit, ie: "Fix bugxyz"
    Next lines can contain details of your changes
  • You can either "Commit" only, or "Commit and Push"
    "Commit" will not push your changes, it is like a local commit.
    "Commit and push" will push changes to the Gitlab repository.
  • Go to Gitlab and you will see your pushed changes.
Tutorial gitlab team eclipse.PNG

Other helpful hints:

  • If others' have checked-in source code, you can go to Team and Pull to pull-in their changes
    Do this often to continuously integrate other people's code in yours.
  • By browsing to Team --> Synchronize Workspace, you can see your changes.

9.4.1. Purpose of the history view

The History view allows you to analyze the history of your Git repository and to see to which commits the branches and tags points. This view displays author, date, commit message and the modified files of a commits.

This view is depicted in the following screenshot.

History view of changes

You can open this view via . Alternatively you can open it via the repository node in the Git Repositories view. For this click on the entry. Some views, e.g., in the Java EE-Perspective, do not have this shortcut, in this case use .

To see the history of a resource, select your project, a file or a folder, right-click on it and select the Show in> History context menu entry. Alternative you can use the ++ shortcut and select the History entry.

You can also configure the History view to display the history of the current selection. Select the highlighted button in the following screenshot for that.

Tracking active selection

If you select a commit you see the commit message and the involved files.

History View

Via right-click on an individual file you can compare this file with its ancestor (the commit before that) or with the current version in the workspace.

If the "compare mode" toggle is selected from the view menu of the History view you can also double click a file to compare it to the previous version.
Compare mode

9.4.2. The History view filters

The History view has quite some options to configure which commits are displayed. Its toolbar allows you to customize which commits are displayed. By default, the History view filters the history based on the current selection and shows only the active branch.

If you work with several branches, e.g., because you are using Gerrit for code reviews, you typically want to see all branch information and remove the filter based on the resource.

The History view allows you to filter based on resources. See the tooltips of the toolbar for the meaning of the different filter options. In order to see all commits click the highlighted buttons with the Show all changes in this repository and Show all branches and tags tooltips.

Toolbar settings in history view

The following listing gives an overview of the purpose of the different buttons.

History View Buttons

Depending on your use case you may want to select the following option:

  1. show only those commits which are reachable from the current branch. Hide all commits on other topic branches.

  2. see only those commits which changed the selected resource (file, project, subfolder) or it’s children. E.g. display only those commits which touched the selected java file. The current selection is shown in the top right corner of the History view.

  3. see only those commits which changed anything in the parent folder of the selected resource (file, project, subfolder) or it’s children. E.g. display only those commits which changed the same package as the selected java source.

  4. see only those commits which changed anything in the same project as the selected resource or it’s children. Used when you are working in a repository which contains multiple projects.

  5. don’t filter at all. Show all commits of the current repository

The options b., c. and d. are tied to the currently selected resource. Button g. allows that the history view automatically updates when you change the selection.

If you got lost with the different filters and the history doesn’t show what you expect, set it back to show everything. Therefore make sure that Show all branches and tags (a) is turned on and Show all changes in repository (e) is selected.

9.4.3. Using search

You can also search for commits based on committer, author, ID or comment. For this turn on the Show Find toolbar (f) and type in a search string in the Find field. The commits fitting to your search are highlighted. You can combine this search with the filters explained above.

Search in the Git history view

The Git Search available in the menu is much more powerful and consumes less memory since it doesn’t need to also display the history.

Git search
  1. Crabbing season
  2. Brass polish walmart
  3. 2008 chevy suburban tail lights
  4. Restoration hardware fairy lights

GitLab instance:

GitLab has a similar functionality set compared to GitHub. A GitHub Pull Request is analogous to a a GitLab Merge Request. Below is a quick cheat sheet for getting productive with GitLab. The official GitLab User guide is here:

From Bugzilla cheat sheet


  • Global notification settings are in your profile:
  • Group notificaton settings are also in your profile
  • To "watch" a project, go to that project page. The notification bell at the top left can be changed to watch.


Quick actions


Bug blocks .. depends on functionality

GitLab supports Linked issues (related, is blocked by, depends on) - either in the same project, or across projects. See Linked Issues, or this example:

From Gerrit cheat sheet

Contributing code

While project committers can commit to the repositories directly, contributors must use Merge Requests (MR). In fact, project committers can (should?) also use the Merge Request model to trigger code review.

There are many methods to trigger a Merge Request. They are all described here:

Migrating from Gerrit and Bugzilla

Migrating Gerrit and Bugzilla to Gitlab is straightforward, but not complete. Items that are not migrated:

  • Gerrit changes. Although the complete Git repository, with history, is migrated, Gerrit changes are not imported.
  • Bug and comment attributions. All bugs are migrated as issues, but due to tool limitations, all bugs and comments are attributed to Eclipse Webmaster. The original submitter's name, and each commenter's name is preserved. Attachments are imported, and links to the original bug are preserved. Please see this example of a migrated bug:

To migrate your Git + Bugzilla to Gitlab: Please file an issue in Eclipse Foundation > Gitlab

Migration FAQ

Q: Big picture - what is involved in migrating a repository from github to gitlab?

A: First step is to cordinate the move with your community. Then, filing a Gitlab issue at

Q:What is the learning curve for contributors?

A: As far as I can tell, it is close in functionality to Github.

Q: Are there contribution procedures in place for contributors to Eclipse projects?

A: The same ones as found at Github.

Q: Does ECA check work the same?

A: Yes!

Q: Can we use GitLab runners and the CI?

A: No, not at this time. Jiro is the only CI supported.


Overview of project member permissions:

Default permissions

  • Project leads get "Maintainer" permissions.
  • Committers of a project get "Developer" permissions.
  • Contributors can get "Reporter" permissions.

Maintainer permissions include a few actions that project leads should not use:

  • "Add new team members" => Project leads are not allowed to simply add team members. Committers must be elected as defined in the Eclipse development process.
  • "Edit comments (posted by any user)" => Projects leads are not allowed to edit comments by any other user than themselves.

If any other permission or action is abused or violates the rules of the Eclipse development process, we retain the right to remove the permissions.

I moved to GitLab

How to add GitLab repository in Eclipse?

Make sure you have eGit in Eclipse:

  1. Help -> Installation details
  2. See that "Eclipse Git Team provider" is in the list.

If it is not installed, follow the indications in the answer from @VonC

Make sure you have the URL to the repository in GitLab. Something like You get it from when you are at the overview page for the project:

  • Menu (the hamburger icon ≡, 3 horizontal lines),-> projects, then click in the one you want to work with from eclipse. Now you are in the overview page. Right beneath the name of the project and its description there are a few buttons to allow you to perform some actions. One of those buttons is a selector for SSH/HTTPS protocols. For now, select HTTPS and copy the URL that follows it: that is the URL to the project.

These steps have been tested in Eclipse Kepler and Eclipse Luna. Rumor has it that they are outdated and might not work as indicated. If you use a newer Eclipse, take care and post back the new steps :-)

  1. Window -> Open Perspective -> Other
  2. Search for "Git", select it, and click "OK"
  3. Click the button with an arrow and the tool tip "Clone a Git repository and add the clone to this view"
  4. In the "Source Git Repository" wizard:
    • URI: the URL from the repository in GitLab, like
    • eGit has filled in the host and repository path for you.
    • Leave the connection as it is (https and no port) and fill in the details for the authentication: user and password you use to log in
    • If you tick the "Store in Secure Store," Eclipse will handle user/password for you from now on; I do it, but it is not advisable if you share Eclipse installation with someone else, or you do not trust your PC to hold your passwords.
    • Click next
  5. Branch selection wizard.
    • If there are more than one branch in the repository, you may now choose which one you want to clone locally, the one with which you want to interact. You may also choose to clone all branches to have them available.
    • Once you are done, click Next
  6. Local destination wizard.
    • You may now choose where you want to place your local Git repository. eGit defaults to a subdirectory under you user, unrelated to eclipse, it works well. If you do not like it, change to your liking.
    • As with other Git installations, it will name the repository as "origin". You may also change that if you really want.
    • In the projects box check the "Import all projects" and, if you work with "Working Sets", you may choose now in which one to place it.
    • Click Finish.

eGit now works for a bit and shows you the newly cloned repository in the view. You have a cloned repository with which you will be able to interact from Eclipse.

  1. File -> Import...
  2. Git -> Projects from Git -> Next
  3. Existing local repository -> Next
  4. Select the newly cloned repository -> Next
  5. Import using the New Project Wizard -> Finish
  6. Choose the project type that is hosted in In my case is "Java Project;" in other occasions it has been "Maven -> Maven Project". Then click Next
  7. Name the project and change the settings you want. As destination, do not use the default location, but navigate to the location of the cloned repository (as used in step 6 in the previous section cloning the repository) -> Next
  8. Verify that the import looks like you want it and click Finish.

You may now work within Eclipse and use the Team menus to sync and commit and push.


Gitlab eclipse

CSE 373, Autumn 2018: Eclipse load from git

Note: this box contains optional background information: you do not need to know any of the information presented here.

When working on larger projects, programmers tend to face a few different problems:

  1. How do you keep track of what 3rd party libraries the project needs installed?
  2. Each IDE stores its project config in a slightly different way. How can you make sure your project can run on all kinds of different IDEs, including ones you've never heard of, with minimal fuss?
  3. Sometimes, building our project and producing a final JAR we can give to our users can require running multiple instructions/performing several complex steps. Instead of having to do that manually, can we just write a script that does this all automatically for us?

It turns out that we can use the same tool to answer all of these questions: we can use a build manager. Basically, what happens is that we record all of the libraries we need, all project configuration, and all build instructions inside of a special file our build manager understands.

Conveniently, it also turns out that all (modern) IDEs have great support for a wide variety of popular build managers: they can read the special file and automatically convert all of those instructions into their IDE-specific configuration.

In our case, we're using a build manager called "gradle". Try opening up inside of your project. If you skim through it, you can see that the file configures a variety of things and specifies a handful of 3rd party libraries we want to install and use. (We've commented this file fairly heavily in case you're curious).

Gradle isn't the only build manager – other popular build managers for Java include Ant, Maven, and Ivy.

If you start working with other programming languages, you'll learn that they all also have their own build managers and conventions for managing large projects. However, at a high level, they all work in the same way: you specify the libraries you need and your build instructions in some file(s), and run some sort of build tool to manage everything for you.

Cloning Java Project from Github into Eclipse IDE


You will also be interested:


451 452 453 454 455