EGit is a popular plugin to use when you would like to add support for git repositories in your project. It has a great number of features. It enables you to see changes compared to your last commit, view the history of a file, commit your changes, fetch new commits from a remote repository and so on.
It is definitely a really useful plugin, but you may not need it in every project (for example because you like using some other, external tool for managing you git repository). In STS (Spring Tool Suite) this plugin is installed by default. But disabling the git functionality can speed up the IDE.
How to disable git support
If you don’t want to use the functionality of this plugin for a project, you can disable it using the following:
- Right click on a project in the Package Explorer.
- Click on Team -> Disconnect
There is no way to commit an empty directory to a Git repository, you have to put a file in the directory to be able to commit it to your repo. Here is an explanation from the Git FAQ:
Currently the design of the Git index (staging area) only permits files to be listed, and nobody competent enough to make the change to allow empty directories has cared enough about this situation to remedy it.
Directories are added automatically when adding files inside them. That is, directories never have to be added to the repository, and are not tracked on their own.
So now we know that we have to put a file in the directory. But what file should it be?
If we are forced to put in a file we should make the best of it. Use a file that has at least some use, or could have a use in the future.
Use a README file
Some say, that the best idea is to use a
README file, and inside it, describe why did you leave this directory empty. This could be a good idea, but sometimes the reason for the directory being there is obvious (e.g. Controllers), you just don’t have any files in it, because you did not get to that point in the development.
Use a .gitignore file
Git uses the
.gitignore file to determine which files to exclude from tracking in the repository. Putting in an empty one leaves the possibility of adding exclusion rules later.
Use a .gitkeep file
In some people’s opinion the filename should be descriptive about the purpose of it. They use a file named
.gitkeep, that just means “Keep this folder in revision control, although it’s empty”.
As you probably know, the
git init command is used to create a new Git repository. It initializes a new repository by creating an initial file and folder structure that is required for a Git repository to work and track changes in your project.
When running the
git init command you can use the
Without the bare option
If you are not using the
bare option, then these files will be placed in a
.git named directory in the root of your project directory. In this case, your project directory will contain the current working files of your project alongside with the
.git that contains all of the version tracking information. Most commonly this is the way you want to set up your repository because it allows you to work on your project and then commit your changes in your local repository.
With the bare option
git init --bare
If you use the bare option you will have all the files that would live in the
.git folder directly placed under the root of your project directory. So in this case there will be no working files, only the repository files that contain all the version history of your project. This means that you cannot directly commit to this repository, you can only push changes to this repo or pull changes from it. This is the purpose of a bare repository: to have a centralized server (even though git is a decentralized version control system), where you can share your changes with your teammates or with the world.
When you want to work on your project, make changes to it, you need to have all the working files at your disposal…because you want to work with them. So in this case you have to use a non-bare repository.
When you want to create a central repository where people working on the same project can share their changes with each other then you need to create a bare repository.