For a Clojure project with Cursive IDE, what project files should be ignored by version control? Is there an example .gitignore for such projects?
The only ones I can see are:
*.iml
.idea
Put these in your global ignore file: ~/.gitignore on linux/mac
Related
Is it possible to create one project in GitHub, and two teams who are using different IDE like Eclipse and Intellij can configure project with github and can work simultaneously on same project?
I have searched it but not able to find proper solution for it.
Yes, you even can version:
your .project and .classpath (eclipse)
and your .idea folder (intellij)
And both set of IDE-specific files would ignore each others: one could use the Eclipse settings without realizing there is an IntelliJ IDEA project, and vice-versa.
Yes this is possible.
Most IDE's do create some specific project folders, where the IDE does store Data for your project. As example local build paths and so on.
Git provides the .gitignore file.
In this file you can specify which folders and files git will ignore. As example IDE Based files and folders. Due that every developer can his favourite IDE and no local IDE based files will be in the Git Porject itself.
Most IDE's will update or crate the .gitignore File automatic when they do find an git folder in the project.
What files you have to add to the .gitignore file is differs from IDE to IDE. It also depends on what Programm language your Project is written in.
Here you can find more about the gitignore file:
How do I ignore files in a directory in Git?
http://www.bmchild.com/2012/06/git-ignore-for-java-eclipse-project.html
Yes you can, there no limits on IDEs and number of team members, check this for Eclipse
and this for IntelliJ
Generating eclipse project file from a cmake based projects works really good. We no longer need to commit eclipse project files to the repository.
But what is with the project specific settings like 'code style'. In a fixed eclipse project I could save and commit this setting. Is it possible within a cmake based project with generated project files for eclipse?
I do not see a solution to this as cmake completely regenerates the project. That's the reason why I use Makefile projekts with eclipse. I don't see any drawback of this as eclipse can easily trigger the make command.
i'm working with eclipse c/c++ helios.
i'm using template projects with makefile with a multimedia framework. all dll dependencies are specified in makefile, so no nightmare.
i have an empty projects template, so each time i had to start a new project i have to make a new copy of that folder, import in eclipse as a makefile project.
despite of this simplicity i have to :
1) add project references
2)make a new launch configurations:
right-click on project > properties > run/debug settings > new..
and set somethings
i know that handle this with an eclipse plugin but i'm not interest in that.
i would like to make a little python script that copy emptyProject folder, edit .project or .cproject or whatever, and do the boring launch configuration for me. project references are in .project file,
but new launch configurations? where it is? where can i find that informations? in .project or .cproject i didn't find anything.
wherelse can i looking for?
i worked it out due to this post:
How do I save Eclipse launch profiles across workspaces?
i found the asnwer.
the place for launch configurations is:
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
I am the only developer on this project.
I would not add the complete workspace, but I would add the .classpath and .project files (as well as the source, of course) so that you can recreate the project if needbe.
I wouldn't commit the whole workspace. But it is worth exporting platform settings and checking them into source control (probably in a separate SCM project as they don't really belong to any individual project) if you've made several changes in case you need to import them into a new workspace.
Examples of these files are those settings for:
Java->Code Style->Formatter
Java->Code Style->Clean Up
Java->Code Style->Code Templates
General->Editors-Text Editors-Spelling-Dictionary
Any other preferences you've made extensive changes to that support import/export
You should check in the primary sources/resources for the project. As others have noted, for a typical project this includes the .project and .classpath files.
Depending on the type of project, I'd add the .settings folder from the project. This folder contains project-specific settings that override the platform preferences, and other project-specific settings. If those are essential to your project then I would add them.
No.
Files that are generated by the IDE or by a build process (binary files, documentation produced by a generator) should not be checked into source control. The only files that should be checked in are your source files and external libraries that your source files utilize.
You might also be interested in the answers to this question: What should NOT be under source control?
I would commit only the project(s) you are working on, as well as .classpath and .project files, and not the whole workspace itself.
Even if you are the only developer, avoid committing the .settings directory. You could switch to another version of Eclipse, or another installation with a different set of plugins, and when you checkout projects in the second installation the .settings directory will be different. Also the .metadata directory is bound to vary.
That said, attempt to use Maven so that the Eclipse .project and .classpath files can be generated without requiring them to be checked in.
I've played with the idea (with Subversion) of having a "MyProject_Eclipseproj" folder that only contains the the Eclipse project files and directories, with an svn:externals prop that pulls in all the "MyProject" files/directories.
So, the layout would be:
/repos/trunk/MyProject
/repos/trunk/MyProject/build.xml
/repos/trunk/MyProject/src
/repos/trunk/MyProject/src/com
/repos/trunk/MyProject/src/com/mypackage
/repos/trunk/MyProject/src/com/mypackage/MyClass.java
/repos/trunk/MyProject_Eclipse_34 <- external prop goes here
/repos/trunk/MyProject_Eclipse_34/.settings/
/repos/trunk/MyProject_Eclipse_34/.project
/repos/trunk/MyProject_Eclipse_34/.classpath
/repos/trunk/MyProject_Eclipse_35 <- external prop goes here
/repos/trunk/MyProject_Eclipse_35/.settings/
/repos/trunk/MyProject_Eclipse_35/.project
/repos/trunk/MyProject_Eclipse_35/.classpath
The MyProject folder would be pure code, no eclipse contaimination. The MyProject_Eclipse_Ver would contain Eclipse specific files, and pointers to pull in the code folders. You could also have specific folders for different Eclipse versions so each developer wouldn't be forced to upgrade if something changed in the .settings or .project file between versions.
We normally use Eclipse for a particular Java project, but recently I imported the project into NetBeans to use its dialog building features.
Since I'll probably come back to this, I wanted to store the NetBeans project files into version control. However, I don't want to commit files that are "mine" versus "project", i.e., files with my own settings that would conflict with another user's.
NetBeans created the following structure in the top-level project area:
nbbuild
nb-build.xml
nbproject
<various files>
configs
private
Clearly nbbuild is build output, so that won't go in. The nb-build.xml file seems likely, as does most of nbproject. However, nbproject/private suggests it's "mine". Peeking at "configs", it's not clear to me if that's mine or project...
Anyone have some guidelines?
The NetBeans knowledge base article on project files & version control discusses the NetBeans project files, with loose advice about which files are project specific (i.e. can be shared via version control), and which are user specific.
Here is the section on version control:
If the project is checked out of a version control system, the build (or nbbuild), dist (or nbdist), and the nbproject/private folders should not be checked into that version control system.
If the project is under the CVS, Subversion, or Mercurial version control systems, the appropriate "ignore" files are created or updated for these directories when the project is imported.
Though nbproject/private should be ignored, nbproject should be checked into the version control system. nbproject contains project metadata that enables other users to open the project in NetBeans without having to import the project first.
It turns out that both Thomas & Petercardona are correct, in a way. NetBeans recommends that you only import source code and/or documentation. Oh and the nbproject folder but not the *nbproject/private** folders.
From the NetBeans Knowledge Base article on importing Eclipse projects:
Version Control Considerations
If the project is checked out of a
version control system, the build (or
nbbuild), dist (or nbdist), and the
nbproject/private folders should not be checked into that version control
system.
If the project is under the CVS,
Subversion, or Mercurial version
control systems, the appropriate
"ignore" files are created or updated
for these directories when the project
is imported.
Though nbproject/private should be
ignored, nbproject should be checked
into the version control system.
nbproject contains project metadata that enables others users to open the
project in NetBeans without having to
import the project first.
None.
Only source files, build scripts, and documentation that is not automatically generated (e.g. - the output of tools such as JavaDoc and Doxygen) should be checked into a repository. Things like project files, binaries, and generated documentation should not be checked in.
The reason is two-fold. First, you don't want to overwrite another developer's project settings with your own. Second, other developers might not be using the same IDE as you (or even an IDE at all), so don't give them any more than they need to build (the project or its associated documentation) or run the project.
As tested with Netbeans 6.8, only the project.xml, configurations.xml and the main makefile (the customisable one in the parent dir of the 'nbproject' dir, with pre/post target definitions) must be distributed via the repository. All other files will be automatically (re)generated by Netbeans (Makefile-impl.ml, Makefile-variables.ml, all the Makefile-$CONF, Package-$CONF.bash). The 'private' dir should also be ignored, obviously.
You can check also
https://github.com/github/gitignore/blob/master/Global/NetBeans.gitignore
This open source project contains
A collection of useful .gitignore templates
Toptal has a useful tool for developers wanting to find out what should go on a .gitignore file.
https://www.toptal.com/developers/gitignore
For netbeans, just search Netbeans and it should return a template something like
**/nbproject/private/
**/nbproject/Makefile-*.mk
**/nbproject/Package-*.bash build/
nbbuild/
dist/
nbdist/
.nb-gradle/
Copying and pasting this into a .ignore file on your project's directory should solve your problem.