Tutorial: Git with Eclipse

There are things which are game changer in the world of software development: one such event was when I started using a VCS (Version Control System): it changed for me how I keep and store my projects and settings. It even changed the way how I deal with non-software related items like documents or other valuable things: I started storing them in to a VCS too.

EGit with Eclipse

EGit with Eclipse

VCS in a nutshell

In a nutshell: a VCS is a data base or a system which allows me to store and retrieve files. It keeps a history and I can go back in time to retrieve an earlier state or compare different states. It ‘versions’ items or files in a kind of data base. In most cases such a data base is used by multiple users or developers, and with this the system is able to ‘merge’ changes of different developers: it keeps an audit track and backup of all the changes. Not using a VCS for any medium or larger scale project especially with multiple developers collaborating sounds like suicide to me. If you never have used a version control system, you probably want to start using one. I have used different VCS (cvs, svn, git), and while I still keep projects for historical reasons in vcs and svn, I’m using git for all my new stuff.

If a VCS or git is new to you, I recommend you have a look at this tutorial video: https://git-scm.com/video/what-is-version-control

Git – Quick Start

The git project has been started by the famous Linus Torvalds. It is a modern and distributed version control system. To install git, follow the links and tutorial on https://git-scm.com/downloads

With git there are several basic actions:

  • add: adding files to the list of changes
  • commit: enter the change into the (local) repository
  • push: transfer the changes in the local repository to the remote one
  • pull: get the changes from the remote repository

By default, there is always a local repository. A remote repository is needed to share something, e.g. on GitHub.

In the Git Bash shell, configure first your user name and default email address:

git config --global user.name "John Doe"
git config --global user.email "john.doe@company.com"
Git configuration

Git configuration

That all what we need for configuration.

To create a new git repository I use

git init myGitRepo

which creates the repository with that name after the ‘init’.

Next I create a readme.txt in that folder created (I’m using nano below, you can use any text editor):

cd myGitRepo
nano readme.txt

To add that file to the repository I use:

git add readme.txt

and then commit it to the repository with:

git commit -m"initial version of readme"
added file to repository

added file to repository

Instead doing things on the command line, you are free to use graphical clients, see https://git-scm.com/downloads/guis

EGit Client for Eclipse

I’m always having a GUI client installed beside of the command line version and the Eclipse plugin. Each client has its pros and cons, and I’m using SourceTree which is free-of-charge. My model is:

  1. Using a GUI client like SourceTree for normal working with git
  2. Using the command line version for more advanced things or for automation
  3. Using the Eclipse plugin for working with Eclipse projects

My preference for an Eclipse plugin is ‘EGit‘, for which I wrote an article how to install it into CodeWarrior. Many Eclipse distributions already come with a git client pre-installed, and the NXP MCUXpresso IDE comes with EGit too.

Otherwise use (or update) from the following Eclipse Update site (Help > Install New Software):

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

Going forward, I will show how to use Eclipse (NXP MCUXpresso IDE 10.2) with EGit.

Git Perspective and Repository Setup in Eclipse

In Eclipse I switch to the Git perspective:

Open Git Perspective

Open Git Perspective

From the git perspective, I can add an existing repository (e.g. the one I have created above with the shell):

Add existing repository

Add existing repository

Then browse to the repository folder and add it:

Adding existing repo

Adding existing repo

Instead using the shell, I can use it to create a new repository too:

Create new repository

Create new repository

Then it asks me for the repository folder name:

new eclipse git repository

new eclipse git repository

and it adds it to the available repositories:

List of repos

List of repos

Or I can clone from an existing repository, e.g. from GitHub. For this I use ‘clone’:

Clone a Repository

Clone a Repository

For example I can clone and use the McuOnEclipse repository on GitHub:

https://github.com/ErichStyger/mcuoneclipse.git

💡 You won’t have access rights to push to that repository on GitHub. If you want to make changes to a GitHub repository: Clone it on GitHub to your own list of repository and use your repository URL.

Cloning McuOnEclipse

Cloning McuOnEclipse

Press next and select the desired branch (if any).

Select branch

Select branch

Then specify the (new/empty) directory name where to clone the repository:

Local Destination

Local Destination

Press Finish and it will download repository content which might take a while depending on the data in the repository.

Adding Projects to Repository

With the repository configured, I can add an existing project to a repository. Right-Click on the project and select Team > Share Project…

Sharing Project

Sharing Project

Select the VCS to use:

Select VCS

Select VCS

Select the repository to use and press Finish:

Selected Repository

Selected Repository

Ignore File

Git uses the file .gitignore to filter (hide) files or folders which should not end up in the repository.

Git stores the list of files and folders to be ignored into a file named .gitignore. By default the Project Explorer view hides all files starting with a dot. To show them, use the ‘Filters and Customization’ menu:

Filters and Customization

Filters and Customization

And then uncheck the *.resources setting:

Filters

Filters

With this I can edit the .gitignore file inside Eclipse:

Default .gitignore file

Default .gitignore file

The file is processed from the top to the bottom, with # used to start a comment line.

As a general rule: ignore everything which is derived or generated as it would easily create conflicts in the repository.

💡 For a list of things to be ignored for CodeWarrior and Processor Expert see https://mcuoneclipse.com/2013/03/29/version-control-with-processor-expert-projects/.

Update: It is recommended to ignore the .settings folder of the project (see discussions in the comments section of this article). The .settings folder contains XML files with local plugin settings and are specific to the user. So do not put that folder into the version control system.

For MCUXpresso IDE and SDK projects it is very simple: only the output folder with the generated make and object files needs to be ignored which is usually named ‘Debug‘ and/or ‘Release‘. As seen from the above .gitignore, Eclipse already added this to the list, so we are fine :-).

Commit

In the previous step I have added the project to the list of changes. But it is not yet stored in the repository. For this I need to do a commit. With the project added I have now many more actions available in the Team menu:

Extendd Team Menu

Extendd Team Menu

With the ‘Commit…’ menu item I get a Git Staging view:

Git Staging

Git Staging

The left upper area shows all the changes. I have to stage them into the lower left area using drag&drop or using the ‘+’ and ‘++’ icons in that toolbar and add a commit message:

Ready to commit

Ready to commit

Then I can commit (make the change in the local repository and push later) or do a commit with a push to the remote repository.

💡 I prefer to make smaller commits and then push them later. With a local (not shared) repository a push is not needed/possible as the push is to the remote repository.

Push, Pull and Compare

The push action is available in the Team menu:

Push

Push

In the same menu I find the pull actions (to get the changes from the repository.

To compare the changes, double-click on the file and it opens the Eclipse diff view:

Compare Changes

Compare Changes

Import from Git

Another cool thing is that I can import projects from git into my workspace. I use the Import item from the File menu:

Import

Import

Then select import from Git:

Import Projects from Git

Import Projects from Git

Select the repository source:

Select Repository Source

Select Repository Source

If you have cloned the McuOnEclipse repository, you can select that one or any of your repositories:

Select git Repository

Select git Repository

Then select the folder with the project(s) to import:

Select Project to Import

Select Project to Import

That way I can easily import projects from any repository :-).

As always with Eclipse, there are many ways to do one thing. Another way to import projects is from the Git Repositories view:

Importing Git Projects

Importing Git Projects

More Features

Be free to explore more of the EGit features in Eclipse. I recommend to go trough the Git perspective default views. For example the History view

Git History View

Git History View

Git History

Git History

Summary

Eclipse with the EGit plugin makes it easy to work with the git version control system. It takes a bit practice if not familiar with version control systems, but things are easy to learn and the internet is full of more tutorials and videos. Keep learning 🙂

Happy Gitting:-)

Links

Advertisements

17 thoughts on “Tutorial: Git with Eclipse

  1. I know that this is a blog about Eclipse, but anway… I gave up using the Eclipse Git plug-ins long time ago, in favour of the separate Git client SourceTree (https://www.sourcetreeapp.com). The Mac version is probably the best Git GUI client available.

    My main complaint about the Eclipse Git plug-ins was that they tried (at least in the beginning, when I evaluated them) to behave somehow similar to the SVN plug-ins, which is confusing, Git is really different from SVN.

    Like

    • Hi Liviu,
      yes, me too: I’m using SourceTree for all the general Git work. Still the EGit plugin is handy to work within the Eclipse flow, but is not a replacement for a GUI client like SourceTree. I have used SVN a lot in the past, and I agree that early version of EGit had inherited some of that, but the current plugin is reasonable in my view.

      Like

    • Yes, but this means deleting it from your local copy, which means you won’t have it available any more e.g. to edit/build. The files remain in the remote repository, and if you do a pull the files will be restored on your local copy/disk.

      Like

  2. Good article!
    A confusing thing for me is still which files to check-in. Ideally you want _all_ project settings to be part of the git archive, for other developers to re-use, or to have them available when making multiple clones when working on different branches/features/bugs in parallel.
    There’s the Eclipse .project and .cproject files (using relative paths?), and the .gitignore. And the include path/indexer settings that appear to be in the workspace (discovered just recently):
    /home//workspace-eclipse/.metadata/.plugins/org.eclipse.cdt.core/.language.settings.xml
    But I have seen SDK Eclipse example projects that have a .settings directory as part of the project structure; not sure yet if this gets copied to the Eclipse workspace when importing.
    Perhaps there are more relevant files like this to be reused between developers (editor settings, highlighting settings, perspectives, cached index when large, …)?
    In most case I’ve seen external make file projects (for automation purposes), in git, developing using Eclipse. How do other people do this (efficiently)? Custom wrapper scripts that create/modify the whole Eclipse workspace structure and start-up sequence does not seem the way to go. Ideally you want the features of Eclipse (debugger, assembly, etc.), with the speed and efficiency of a small editor/mini IDE like geany (www.geany.org).

    Like

    • Thanks!
      You absolutely want the .project and .cproject files in the repository. The .gitgnore as well as it describes what to ignore.
      This has nothing to do with the Indexer thing: the indexer data is stored in the .metadata folder of the workspace, and that folder *never* should be in a version control system.
      The .settings directory in the project is debatable in my view: Usually I don’t store it as currently there is nothing of value and if I have a project imported without that .settings folder, things get recreated.
      But if you want to put it into the repository, why not.
      You can use external make files for the build, but this is rather a pain in my view. It is much easier to use the IDE in command line mode to build things, at least in a smaller scale. For larger scale systems it makes sense to use make files.

      Like

      • > The .settings directory … in the repository

        It depends on the plug-ins, but the files in this folder store the per-project user preferences, and sometimes include paths to local files.

        Putting these files in the repository makes life miserable to other team members, especially if they use different platforms (Windows/Mac/Linux).

        And even if these files do not include paths, being user preferences, might not match other users preferences.

        Like

        • Ok, good information! It seems I was right with ignoring the .settings directory in the past. I’ll add a note to the article.
          Multumesc mult!

          Like

        • Ok. Just that the files are not XMLs, but Java preferences (simple name=value lines).

          Like

      • > The .settings directory in the project is debatable in my view:
        > Usually I don’t store it as currently there is nothing of value

        The Indexer settings, like include paths and macros, can be a long list. They did not seem to get stored as part of the project settings. I found them in my workspace, but apparently you can also store them as part of the .settings. In that case it would be useful to reuse those settings between developers/clones, and put it in git. I haven’t fully figured this out yet though. I was surprised this didn’t work as expected out of the box.

        Like

        • > The Indexer in Eclipse is something completely different

          Not entirely it seems. For the Indexer to work, I needed to set the project settings -> C/C++ General -> “Preprocessor Include Paths and Macros etc”. These did not end up in the project settings but in the workspace .metadata. So a second clone, or other developer, did not have this long list of required settings. This was/is still the unexpected part.
          [Eclipse Photon Release (4.8.0)]

          Like

        • In Eclipse [Photon Release (4.8.0)] there appear to be _two_ configuration items for include paths,etc (?).
          – project settings -> C/C++ General -> “Paths and Symbols” (also has include paths, macros, etc.)
          – project settings -> C/C++ General -> “Preprocessor Include Paths and Macros etc”
          Not clear what the difference is, and the impact on the Indexer. I’ll see if I can play around with it a bit. Perhaps they end up in different config files.

          Like

        • These two configuration settings are typically populated by the CDT build plugin (project settings > C/C++ Build > Settings) and do not need to be configured, at least to my knowledge.
          Or in other words: the include path settings and the preprocessor macros shown there are coming from the build tool settings (compiler, assembler).

          Like

  3. Another great git GUI that I’ve recently found and like is Git Extensions: https://github.com/gitextensions/gitextensions. It’s very much no-frills, function over form, and gets the job done.

    I didn’t like the idea of having to register and “integrate” with Atlassian just to manage projects which have no interaction whatsoever with Bitbucket in the case of Sourcetree (assuming I didn’t mess up during the install and bring that on myself). Git Extensions is the best standalone, free license alternative I’ve found.

    Like

    • Thank your for that link, this is indeed an interesting alteratnive. I did not like that Atlassion registration too, and the constant updates which seem to cause some problems on my end too.

      Like

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.