Hi,
I'm currently developing some firmware for the MOD5234 using the NBEclipse environment. I'm using Git as my main source/version control.
The repository currently tracks all files since at the time of creation I was not sure what files were valid to be ignored. But this has become pretty cumbersome due to the amount of .metadata files along with occasionally bricking my environment setup once in a while after merging various branches.
I am wondering if the following folders/files can safely be left untracked:
/.metadata
/myProjectName/Release
/myProjectName/Debug
Does anyone have any recommendations? Thanks.
Recommended files to ignore in version control (gitIgnore)
Re: Recommended files to ignore in version control (gitIgnor
I ignore the Release and Debug folders in my repositories since the files in there get generated by the build. I'm not sure about the metadata folder since I don't use NBEclipse anymore, but my guess would be that it's okay to leave it untracked.
Re: Recommended files to ignore in version control (gitIgnor
You should ignore the metadata, and any other files that start with a '.', such as .project, .cproject
Re: Recommended files to ignore in version control (gitIgnor
Great! Thanks for the help guys
Recommended files to ignore in version control gitIgnore
What is the recommended SVN client to use? I have had good luck with SVNKit but have not tried the others.
Re: Recommended files to ignore in version control (gitIgnore)
My project has some linker options (i.e. -lFatFile) that are captured in .cproject file. Don't I need to include .cproject in my repo to capture this?
Re: Recommended files to ignore in version control (gitIgnore)
You can check in the eclipse project .xxxxxxx files, but they will also contain installation dependent information, which will cause major issues if someone with a different environment checks them out and tries to use them. An issue we have seen many times is that someone copies all the project files to a different computer with a different environment, and that causes the same problems and the project will not build.
The recommended method is to check in only source files so a developer's environment is not overwritten when they do a checkout. If you are using an IDE to manage a project, add a readme file to specify whatever needs to be done for a new user. For users with an existing project, they will be happy their configuration is not overwritten
All this applies to using an IDE. If you use the command line, either as a developer, or more commonly for automated build scripts and testing, then the makefile contains all the build options/configuration, and is portable to different environments. So the makefile should definitely be checked in.
The recommended method is to check in only source files so a developer's environment is not overwritten when they do a checkout. If you are using an IDE to manage a project, add a readme file to specify whatever needs to be done for a new user. For users with an existing project, they will be happy their configuration is not overwritten
All this applies to using an IDE. If you use the command line, either as a developer, or more commonly for automated build scripts and testing, then the makefile contains all the build options/configuration, and is portable to different environments. So the makefile should definitely be checked in.