GitHub + Eclipse工作流程

Question

我确信这是一个RTFM的事情，但经过几天的研究后，我仍然无法确定正确的（或最佳）工作流程。

• 我有一个Eclipse Workspace，其中包含许多Java项目和许多C ++ / Arduino项目。
• 我想开始使用GitHub作为我的项目的在线存储库（可以从我的私有LAN开发环境外部轻松访问）
• 我在想我想要一个单独的C ++ / Arduino和Java GitHub repos。 Python，PowerShell等可能会出现更多问题（但我很乐意接受其他有关回购结构的建议）。

除了使用Egit的实际机制之外，我无法找到最合适的工作流程/文件夹结构来实现这一点。我应该创建本地Git存储库并推送到GitHub作为远程？我应该使用GitHub的Web界面导入整个Eclipse Workspace吗？我应该直接使用Eclipse Workspace还是拥有单独的Git文件夹？

我想我的问题的症结在于，在阅读了这个网站上的一些相关帖子之后，我得到了关于从Eclipse工作区创建本地repo而不是单独的本地repo的相互矛盾的建议。我认为在最终确定最佳整体工作流程之前，我需要首先理解这种区别。

我为这个问题的广泛性质道歉，但我希望社区可以帮助我缩小工作流程设计（或问题本身）。

Answer 1

Two things up front:

1. 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.

2. 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.

3. 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:

1. 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.

2. 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.

3. 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.