I am sure this is a RTFM thing, but after a few days of research I still cannot determine the correct (or best) workflow for this.
I have an Eclipse Workspace with a number of Java Projects in it and a number of C++/Arduino projects.
I want to start using GitHub as an online repository (easily reachable from outside my private LAN dev environment) for my projects
I was thinking I would like a separate C++/Arduino and Java GitHub repos. More could come for Python, PowerShell, etc. (But I will happily entertain other recommendations for repo structures).
Outside of the actual mechanics of using Egit, I cannot figure out the most appropriate workflow/folder structure for accomplishing this. Should I create local Git repos and push to GitHub as a remote? Should I use GitHub's web interface to import the entire Eclipse Workspace? Should I work directly with the Eclipse Workspace or have separate Git folders?
I guess the crux of my problem is that after reading a few related posts on this site I get conflicting advice about creating a local repo from the Eclipse workspace vs. a separate local repo. I think I need to understand this distinction first before I ultimately determine the best overall workflow.
I apologize for the broad nature of this question, but I hope that the community can help me narrow the workflow process design (or the question itself).
Two things up front:
Never put your entire workspace in source control; projects: yes, workspace: no. The .metadata folder contains data specific to that location and your machine, and that's ignoring any potential security risks with making it public.
eGit works with your git clones' own metadata, so if you're more comfortable doing certain things from the command line, go for it. I know I am, but I still appreciate the UI and decorations that eGit provides. Just make sure any automatic refresh/update preferences on the Workspace or Git preference pages are turned on.
You probably want the repository to contain multiple projects, rather than having a separate repository for each one. That way histories and changes that belong together are together. Nest the layout however you like, but remember that you're not constrained to a single repository for everything, either.
I don't know that there's a best practice for this, especially with projects that already exist, but projects should themselves be relocatable. My recommendation, after backing it all up:
Make the Github projects, clone their repos locally. I do it this way, from the command line, to save me any headaches with the history, remotes, and refs. I don't think you can modify the repository metadata in this method, though.
Move the workspace projects into the local clone. You can delete them from the workspace (be sure not to delete the underlying files), physically move the directories while outside of Eclipse, and then import them as projects back in from the Git Repositories View--unless they're Maven projects, in which case it's better to use M2E's import wizard.
Stage, commit, and push the projects up to the remote origin. For Java projects, don't forget to set the JRE System Library in the Java Build Path to use an Execution Environment. It's a simple bit of indirection that makes them more portable across machines.
Related
Should we remove the .che folder from Git when we use Web IDE Full-Stack?
The rule of thumb is to never include IDE-specific files into a Git repository. There are several articles and blogs on this and I would point you to this one: IDE Project Files In Version Control - Yes or No? Of Course, Not!
The main drawbacks of having IDE specific files checked-in are the following:
Each IDE would add its own files. E.g. if some of your developers would decide to use VSCode, then you would also have a .vscode folder in there.
The file structure may be different depending on the IDE version (if you use the SAP Web IDE Cloud, this should not be an issue, but it might be if one developer is using the local WebIDE).
The files change very frequently and lead to merge conflicts. E.g. if you do a deploy and also one of your colleagues does a deploy, then you will have a conflict when you want to merge your branch with his (assuming that you work on parallel branches).
The files may contain environment-specific settings. E.g. the name of the project folder, which may actually be different for each developer.
The only clear advantage is that setting up the project after a clone operation might be faster marginally (i.e. the developer which is doing the clone might have to do some settings locally on his copy).
We're using the Groovy/Grails tool suite from Spring (similar to STS), version 3.1, and have an eGit remote repository on a shared network drive. That network drive is going away and we need to move it somewhere else. I have found instructions on how to move local repos, but not remote repos. Is there an easy way to accomplish this? I've also seen warnings against disconnecting the repository when searching for ways to do this as apparently re-importing became troublesome. I did try copying the repository to another location, deleting my project, and re-importing but the wizard still contained references to the old location (I think they were just default repository settings set within the tool suite) and I wasn't sure that this would be the best practice.
Being relatively new to git, and quite frankly not a huge fan yet, I'm unsure as to how to proceed. I see documentation on cloning and adding repos, but not how to move one. I've also put forth an argument for using gitHub but that won't happen before I need to do this. Thanks!
[Update: See comments]
So lets say I have a structure like this:
/trunk/src
/trunk/platform/linux/[eclipse project]
/trunk/platform/windows/[eclipse project]
I want both project to be able to see /trunk/src, open its files and use the automatic error highlighting on those files. I've tried creating Linked Resources to the directory. This works great with nasty limitations. It never updates unless you re-import and you can't create/delete files. I tried storing a symbolic link in the git repo which apparently as of git 1.6.1 no longer works. I tried anyway and upon cloning the symbolic link comes our broken.
This is really just for ease of access to the main codebase for a multi platform project. The solution need not be elegant but it is important. So I figure I can instruct each dev to just make their own sym link to the main codebase as part of dev environment setup. Tried and these symbolic links created with ln -s do not seem to appear in Eclipse nor can they be imported.
Finally I figured I could create a General Project in /trunk/ within Eclipse. Seems Eclipse is "smart" enough to warn me that this is not possible because it detects other projects deeper in.
Any help appreciated.
First, a comment:
'/trunk/xxx/yyy' is a SVN approach, where all branches/tags are "emulated" as directory.
You don't need them with Git. Two branches (one 'linux', one 'windows') are enough; then you can clone your repo twice, once in a 'windows' directory, one in a 'linux' directory.
Regarding a possible solution:
If the only difference between the linux and the windows platform, regarding eclipse, are the .project and .classpath files, I would actually recommend having only one repo (for your sources), with aforementioned two branches, each one including the sources and the eclipse files (tailored for each platform).
That way, the solution is much easier to maintain: one repo, one structure. Two branches.
I have one Eclipse Workspace containing two projects.
- The first is my actual library.
- The second is example code for using the library.
When I push this code to GitHub, I don't want two separate projects, I want the example code to go into an "example" folder of the second library.
How and where would I do this? From Eclipse, GIT, or GitHub?
Or is there a better way of including sample code in GitHub projects? (the example code doesn't actually need any version control)
What if I decide to add more than one sample project?
You can apply source-control to projects in one wokspace, project by project is that pointng to different nodes
Please see Tutorials Git with Eclipse (EGit) and Git, Github and Egit Eclipse integration
Hopes that helps
After more experience with Git and GitHub over my belt, now days I usually place any example code in a separate orphaned branch.
This has several benefits over placing examples into a sub-folder. Primarily, any changes or additions to the examples (Which obviously aren't critical to the library) won't give unnecessary notices of the library code being "changed", or even "ahead" of code in any forks. Also, this setup works well with Eclipse, since both projects will then have their own separate local repositories.
It's also a good idea (and I often forget) to point out this "example" branch in the README.
I want to store a project in Mercurial that contains external code (which can be modified by me) coming from Git and SVN repositories. In SVN I would solve this with vendor branches and copy the code around, but I understood that in Mercurial it's better to have different repositories for different projects, and pull between them when needed.
The project layout will be like this:
- externalLibraryA [comes from a SVN repo]
- ...with some extra files from me
- externalLibraryB [comes from a SVN repo]
- ...with some extra files from me
- externalPluginForExternalLibraryB [comes from a Git repo]
In Subversion I would create vendor dir and a trunk dir, copy all external libraries first in vendor, and then in the right place in trunk. (I think) I can do this in Mercurial too, with subrepositories, but is this the best way to do this?
I tried setting up different repositories for the external libraries, but then it seems I can't pull the externalLibraryARepo into the externalLibraryA directory of my main repository? It goes in the main directory, which is not what I want. I can also create a Mercurial mirror repository and include it as a subrepo in my main repository, but then the changes in this subdirectory go to the mirror repository, while I want them to stay in the main repository.
I'd probably just store this in one repository - note that in the link you give they are using their build system in the end to bring together the binary output from the different repos. I'm not clear on their rationale there.
If the underlying problem you're trying to solve is how to update the externals in a clean way, I'd probably use anonymous branching for that.
I.e. add the external lib to your project, and your modifications. Make sure it works. Tag with ExternalA-v1.0. Hack away on your actual project. Now ExternalA, Inc. has a new version of their stuff. Update your repo to ExternalA-v1.0 tag. Import their new version and apply your modifications on top. Commit. Now you have two heads: one with the latest version of your code (that works with ExternalA-v1.0) and one with the latest version of ExternalA (that does not work with your code, maybe). So then you merge and reconcile the two. Tag again, now with ExternalA-v2.0. Repeat as needed.
You can still keep your externals in separate repositories, but I assume that the project that is using those does not need to be up to date with changes there all the time - looks like the whole point of vendor branches is to have some point of isolation between dependee and dependants. Of course, moving the changes from the externalA project to the project that is using that will then be a manual affair (well, a copy, much like in SVN really).
It depends on whether your vendor code is going to be customized by your team or not. Our teams have had a great deal of success maintaining a named "vendor" branch on repositories with our own customizations on branches named by project name. This vendor code is then easily included in a project as a subrepository.
A caveat to this approach: if active development is going on in the subrepository, best keep it to directly editing the subrepository as a separate clone, otherwise it becomes necessary to pay close attention to the top-level repository so you don't inadvertantly bump your .hgsubstate forward to the wrong revision and break your build.
Watch out for merges of the top-level repository (your project) between versions which point to different named branches of your subrepository, as this can result in a merge between the "vendor" and "project" branches in the subrepository as it recurses, which may not be desirable.
Note that this functionality may change in the future as well, as some "warm" discussions have been taking place in recent months on the mercurial-devel mailing lists about the future of subrepository recursion.
edit:
I just saw this discussion in the related links as well, which seems relevant: https://stackoverflow.com/a/3998791/1186771