We Keep Coding

What files should I git for my Spring boot project

I have done my first project using spring boot, I like it :)
But now, I have several files, that I don't know if I have to git it or ignore it
.classpath
.project
.gradle/5.6.2/*
.gradle/*
.settings/org.eclipse.buildship.core.prefs
bin/main/*
build/class/java/main/com/.../*.class
build/libs/snapshot.jar
build/reports/test/test/*
build/resources/main
Can you tell me which one should I include in my VCS ?

There is no clear answer to your question because it depends on whether you want them to be committed or not :) but...
.gradle is a folder that includes settings for building your project. Deleting it is safe, because Gradle will generate it again anyway
bin is usually where the compiled Java classes are copied to
build is where Gradle generates all build artifacts
.settings is where Eclipse stores its preferences files
.project if I'm not mistaken, this file is also related to Eclipse and describes the project somehow
.classpath maintains the project's source and target references for Java compilation
All the files above can be regenerated. For example, Gradle is probably generating the .classpath for you, while .project is generated by Eclipse.
Regarding build and bin, there's no good reason to commit them
I can't make the decision for you, but instead of you, I would ignore all of the files you've mentioned.

Ignore .classpath and .project from Git

I keep myself telling me and others not to commit .classpath and
.project files and use Maven.
Somehow, Junior developers always ignore certain rules and commits those files and it's much better to have such files for newbies who can jump and start using the code.
Now from myside, I would like to try/do something. When I clone the repo, I will get .classpath and .project files and certainly they get modified in my system.
But I want them not to be committed and should always be ignored while
synchronizing with Git. So that my changes in local system doesn't
mess up with Git and Git changes of those files doesn't mess up my
local files.
How do I achieve this? Anyway to mark those files to be ignored in such a way?

If the .project and .classpath are already committed, then they need to be removed from the index (but not the disk)
git rm --cached .project
git rm --cached .classpath
Then the .gitignore would work (and that file can be added and shared through clones).
For instance, this gitignore.io/api/eclipse file will then work, which does include:
# Eclipse Core
.project
# JDT-specific (Eclipse Java Development Tools)
.classpath
Note that you could use a "Template Directory" when cloning (make sure your users have an environment variable $GIT_TEMPLATE_DIR set to a shared folder accessible by all).
That template folder can contain an info/exclude file, with ignore rules that you want enforced for all repos, including the new ones (git init) that any user would use.
As commented by Abdollah
When you change the index, you need to commit the change and push it.
Then the file is removed from the repository. So the newbies cannot checkout the files .classpath and .project from the repo.

Add the below lines in .gitignore and place the file inside ur project folder
/target/
/.classpath
/*.project
/.settings
/*.springBeans

The git solution for such scenarios is setting SKIP-WORKTREE BIT. Run only the following command:
git update-index --skip-worktree .classpath .gitignore
It is used when you want git to ignore changes of files that are already managed by git and exist on the index. This is a common use case for config files.
Running git rm --cached doesn't work for the scenario mentioned in the question. If I simplify the question, it says:
How to have .classpath and .project on the repo while each one can
change it locally and git ignores this change?
As I commented under the accepted answer, the drawback of git rm --cached is that it causes a change in the index, so you need to commit the change and then push it to the remote repository. As a result, .classpath and .project won't be available on the repo while the PO wants them to be there so anyone that clones the repo for the first time, they can use it.
What is SKIP-WORKTREE BIT?
Based on git documentaion:
Skip-worktree bit can be defined in one (long) sentence: When reading an entry, if it is marked as skip-worktree, then Git pretends its working directory version is up to date and read the index version instead.
Although this bit looks similar to assume-unchanged bit, its goal is different from assume-unchanged bit’s. Skip-worktree also takes precedence over assume-unchanged bit when both are set.
More details is available here.

Use a .gitignore file. This allows you to ignore certain files. http://git-scm.com/docs/gitignore
Here's an example Eclipse one, which handles your classpath and project files: https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore

What's in an Eclipse .classpath/.project file?

We recently had an issue with an Eclipse project for one of our team members. Tomcat was not deploying JARs of the application.
We eventually noticed the .classpath Eclipse file was not the same as for the team members where the project was OK. We replaced the .classpath file with one from a project that was OK and the Tomcat deploy was complete.
Just out of curiosity and to know at what to look in the future if something is wrong, what is inside the .classpath and .project files. What can I add in there, what does it all mean?

Eclipse is a runtime environment for plugins. Virtually everything you see in Eclipse is the result of plugins installed on Eclipse, rather than Eclipse itself.
The .project file is maintained by the core Eclipse platform, and its goal is to describe the project from a generic, plugin-independent Eclipse view. What's the project's name? what other projects in the workspace does it refer to? What are the builders that are used in order to build the project? (remember, the concept of "build" doesn't pertain specifically to Java projects, but also to other types of projects)
The .classpath file is maintained by Eclipse's JDT feature (feature = set of plugins). JDT holds multiple such "meta" files in the project (see the .settings directory inside the project); the .classpath file is just one of them. Specifically, the .classpath file contains information that the JDT feature needs in order to properly compile the project: the project's source folders (that is, what to compile); the output folders (where to compile to); and classpath entries (such as other projects in the workspace, arbitrary JAR files on the file system, and so forth).
Blindly copying such files from one machine to another may be risky. For example, if arbitrary JAR files are placed on the classpath (that is, JAR files that are located outside the workspace and are referred-to by absolute path naming), the .classpath file is rendered non-portable and must be modified in order to be portable. There are certain best practices that can be followed to guarantee .classpath file portability.

.project
When a project is created in the workspace, a project description file is automatically generated that describes the project. The sole purpose of this file is to make the project self-describing, so that a project that is zipped up or released to a server can be correctly recreated in another workspace.
.classpath
Classpath specifies which Java source files and resource files in a project are considered by the Java builder and specifies how to find types outside of the project. The Java builder compiles the Java source files into the output folder and also copies the resources into it.

Complete reference is not available for the mentioned files, as they are extensible by various plug-ins.
Basically, .project files store project-settings, such as builder and project nature settings, while .classpath files define the classpath to use during running. The classpath files contains src and target entries that correspond with folders in the project; the con entries are used to describe some kind of "virtual" entries, such as the JVM libs or in case of eclipse plug-ins dependencies (normal Java project dependencies are displayed differently, using a special src entry).

This eclipse documentation has details on the markups in .project file: The project description file
It describes the .project file as:
When a project is created in the workspace, a project description file is automatically generated that describes the project. The purpose of this file is to make the project self-describing, so that a project that is zipped up or released to a server can be correctly recreated in another workspace. This file is always called ".project"

eclipse and SVN adding jar files

I'm trying to make modifications to the trunk found at https://wafle.svn.codeplex.com/svn SVN repository location. The way that I did this in Eclipse was that I used Subclipse, added a new repository location, then opened up the project and right clicked on the trunk. Then I clicked "checkout" and checked it out as a new Java project. Then I found the folder containing the source code that I want to change and recompile and I used Build Path->Make source folder. Next, I realized that I needed 190394994 jar files that were all in different places under the project's "Third Party" folder. So I used Build Path->Configure Build Path in Eclipse, then individually added each jar I needed through "Add External Jars".
My question is; did I do all of this right, and is there something I could have done more easily, such as import all the jars at once instead of individually clicking each?
Thanks.

I'm guessing that you are embellishing a little and didn't add 190 million jar files by hand. (Even at 1 jar click per second, you would be going nonstop for 2,200 days.) Incidentally, you can shift-click and choose many jars from the same directory.
The secret is in the .classpath file; that is where the build path is stored. Someone before you has probably created a fully-orbed .classpath file and stored it in SVN.
If you created this as a new Java project, it will begin with a very simple .classpath with the folder for your project's class files and the JRE. (Apparently, SVN does not overwrite it with the .classpath or you chose not to merge your local version with the one from SVN.)
Next time, you might want to overwrite your project's .classpath with that fully-orbed one on SVN. Refresh and look at the Build Path. They should be all there and in place.

First thing: rajah9 is exactly correct - there is a .classpath file already.
You just got a little hung up on a really odd svn repo layout. the java stuff is mixed in with the .net stuff. Check out the trunk and then do a file > import... then select general > existing projects into workspace. You'll want to select the Source/JNAWindowsAuthProvider/ folder.
There is already a .classpath that references the jars in the ThirdParty folder. (not quite 190 million)
Second thing: when you added the jars as external jars, it makes an absolute path to the jar file. you want to always avoid that, if you hit the add jars button it will be a relative path.

Checking in an Eclipse project into SVN

I want to checkin a Dynamic Web Project I created in eclipse into svn. Can someone tell me which files I have to check in and which one I should not? The idea is to be able to check out the project using the New Project Wizard so that I can create the Dynamic Web Project again. More specifically here are the files/directories I have in the project --
src
WebContent
build
dist
build.xml
.project
.classpath
.settings/
The build directory is not supposed to checked in obviously. What about the other ones?
I am guessing all the . files should not be checked in either. Can some one verify this?
What is this dist directory and the .settings directory?
Also where does eclipse store the Server information (tomcat)? I don't want to check it in either.
EDIT:
I initially checked in all of the above except the build directory of course. When I checked out the project from inside Eclipse it did not prompt me to create a new project since the .project is there but Eclipse was creating a JavaEE project or something instead of the Dynamic Web Project. Did anyone else run into this behavior?
** EDIT 2 **
Found it! Turns out I should not check in the following --
.project
.settings/
.classpath
Once these 3 are removed the New project Wizard works as expected and everything is fine.

If you check in .classpath/.project/.settings you make your project Eclipse-specific. What about developers who work with Netbeans or IntelliJ? IMO it is cleaner to keep your project IDE-independent and easy to set up.
I usually go for a Maven build. The pom.xml specifies all the required dependencies and mvn eclipse:eclipse generates the .classpath/.project files for you.
The .settings directory contains local settings (like which Java version you want to use). IMO it is not useful to check this in. You can enforce Java version compliance via the Maven2 pom.
Finally, for your next project, my protip is to svn-ignore the files or directories you don't want in SVN before your first commit. In a Maven2 setup that would be .settings .classpath .project target (the default output directory of Maven2) and any other generated stuff (log files, gfembed directories, etc). In your case you would ignore build and dist instead of target.
You can svn-ignore files or directories with RIGHT_MOUSE->Team->'Add to svn:ignore' (I use the Subclipse plugin). Ignore instructions are stored as svn-properties on the parent directory. The properties on a directory can be viewed by RIGHT_MOUSE->Team->Show properties. You can also edit the properties directly there by clicking on the value field. Make sure there is an end of line after each property.
Now that you have already committed and then removed these files, ignoring is not going to work anymore in my experience. Somehow I have never managed to successfully ignore generated files which have ever been checked into the SVN repository; they are like zombies, always coming back from the dead. Maybe by deleting their entries physically in the SVN repo this can be achieved, but I've never done it.

In our case, we have checked in all you mentioned in the list except, .settings/.
With .classpath and .project checked in, users can quickly check out the project and fire up Eclipse on a new computer and just start working on it; the alternative being to configure the project manually and adding in all the jar dependencies painstakingly (if you use ant). Many open source projects do this.
Read this, there are some really good points to ponder about.

Good Question... Many of us are in a dilemma on whether we want to check in IDE related files or not. I normally go for checking in .classpath for eclipse and I use eclipse variables to make sure that team needs to just change the variable value and it works. We also check in .project so that team need not to create new project in their workspace.

I would omit the .project, .settings/, dist, and build.
The .classpath can be left in if you use variables instead of hardcoded paths. This is useful so you don't have to rebuild your classpath every time you check out the project.