使用 git 组织大量个人脚本的好方法是什么?
我有大量个人脚本,我想开始使用 Git 进行版本控制。我之前按如下方式组织了我的代码:
~/code/python/projects/ (for large stuff, each project contained in an individual folder)
~/code/python/scripts/ (single file scripts all contained in this directory)
~/code/python/sandbox/ (my testing area)
~/code/python/docs/ (downloaded documentation)
~/code/java/... (as above)
现在我将开始使用 git 对我的代码进行版本控制,以便我可以拥有历史记录并将所有代码备份到远程服务器。
我知道如果我使用 SVN,我只会将整个“~/code/
”目录保存在一个大型存储库中,但我知道这不是使用 Git 执行操作的好方法。
我在网上看到的大多数信息都建议将我的所有项目文件夹保存在一个地方(例如,没有单独的 python 或 java 目录),每个项目都包含它自己的 git 存储库,并且简单地有一个包含所有单-的“snippets”目录文件脚本/实验可以在以后转换成项目。
但我不确定将所有代码目录合并到一个区域有何感觉。有没有一种好方法可以保持我单独的代码目录完好无损,或者它不值得付出努力?也许我只是附加到单独的代码目录,因为我从来不知道其他任何东西......
另外(作为旁注),我希望能够快速查看我所有项目和脚本的时间历史记录。这样我就可以看到我最近创建的项目。我曾经通过在所有项目的开头保留一个数字来做到这一点,002project
、003project
。
是否有自动或简单的方法可以在 git 中执行此操作,而无需向所有项目名称添加数字?
我愿意接受您提出的任何实用或哲学的代码组织建议。谢谢!!!
I have a large collection of my personal scripts that I would like to start versioning using Git. I've previously organized my code as follows:
~/code/python/projects/ (for large stuff, each project contained in an individual folder)
~/code/python/scripts/ (single file scripts all contained in this directory)
~/code/python/sandbox/ (my testing area)
~/code/python/docs/ (downloaded documentation)
~/code/java/... (as above)
Now i'm going to start versioning my code using git, so that I can have history and backup all my code to a remote server.
I know if I were using SVN I would just keep my entire "~/code/
" directory in a large repository, but I understand this is not a good way to do things with Git.
Most info I've seen online suggests keeping all my project folders in a single place (as in, no separate directories for python or java) with each project containing it's own git repository, and simply having a "snippets" directory containing all single-file scripts/experiments that can be converted into projects at a later date.
But I'm not sure how I feel about consolidating all of my code directories into one area. Is there a good way to keep my separate code directories intact, or is it not worth the effort? Maybe I'm just attached to the separate code directories because I've never known anything else...
Also (as a side note), I'd like to quickly be able to see a chronological history of all my projects and scripts. So I can see which projects I created most recently. I used to do this by keeping a number at the beginning of all my projects, 002project
, 003project
.
Is there automatic or easy way to do this in git without having to add a number to all of the project names?
I'm open to any practical or philosophical code organizing advice you have. Thanks!!!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
git 阻止人们拥有单一的、整体的存储库的原因是你无法克隆存储库的子目录(就像使用 SVN 一样)
假设你有 git://blah/somecorp_code.git,其中有数百万个修订版,容量为 15GB。如果你只想要该代码的子目录,那就很难了——你要么得到全部 15GB,要么什么也得不到。
对于个人代码,这确实不是问题 - 我有一个“整体”git 存储库,大约 20MB,我可以很高兴地将它克隆到我希望使用它的所有机器上。
没有其他人使用它,没有其他人提交,而且我很少以分支的方式做太多事情。它实际上只是使用一个具有良好同步和远程备份功能的奇特撤消系统(私人 GitHub 项目),
我将其组织如下:
在存储库的根级别中,我有一个
code
文件夹(沿着带有sites
文件夹,用于 Web 开发内容 - 这就是存储库为 20MB 的原因)在代码文件夹中,我有各种语言的文件夹(
python
、ruby
、c
等)在每个语言目录中,我有两个文件夹,
snippets
和projects
。片段内部是一堆文件,项目内部是一系列文件夹。这些项目是我写的随机的东西,但并没有真正发挥作用(玩具项目,“我想知道我是否可以......” - 项目等)
如果它是一个单一的Python文件,它就在
code 中/python/snippets/
,如果它有多个文件,它会进入code/python/projects/{project name}
当我想公开发布一个项目时(通常在 Github 上) ,我创建一个新的存储库,将代码复制到此并将其与 Github 同步。
单独的“活动项目”存储库现在与整体存储库无关。我研究了子模块项目,但它不适用于这种用途 - 它旨在使克隆依赖项变得容易,而不是管理一系列不相关的存储库
我确实有一个脚本,它使用 Github API 在本地自动克隆我的所有项目,或者使用 git pull 更新它们 - 它只是 githubsync.py(我将 github.py 合并到同一个文件中)。它可以在 这里作为 gist/373731 找到
我使用 githubsync.py 将我的项目克隆到我的笔记本电脑和台式机最初,并且经常在 Dropbox 中运行它作为备份。
The reason git dissuade people from having single, monolithic repositories is you cannot clone sub directories of a repository (like you can with SVN)
Say you have
git://blah/somecorp_code.git
which has millions of revisions, and is 15GB. If you just want a subdirectory of that code, tough - you either get all 15GB or nothing.For personal code, this really isn't an issue - I have one "monolithic" git repository, which is about 20MB, and I can happily have it cloned on all the machines I wish to use it on.
No one else uses it, no one else commits, and I rarely do much in the way of branching. It's really just use it a fancy-undo-system with nice syncing and remote backup (private GitHub project)
I organised it as follows:
In the root level of the repository, I have a
code
folder (along with asites
folder, for web-dev stuff - this is why the repository is 20MB)In the code folder, I have folders for various languages (
python
,ruby
,c
etc)In each language directory, I have two folders,
snippets
andprojects
. Inside snippets is a bunch of files, inside projects is a series of folders.These projects are random things I've written, but don't really work on much (toy projects, "I wonder if I could..."-projects etc)
If it's a single Python file, it goes in
code/python/snippets/
, if it's more than one file it goes incode/python/projects/{project name}
When I want to publicly release a project (on Github, usually), I create a new repository, copy the code to this and sync it with Github.
The separate "active project" repository is now unrelated to the monolithic repo. I looked into the submodule project, but it is not intended for this usage - it's designed to make cloning dependencies easy, not manage a series of unrelated repositories
I do have a script that uses the Github API to automatically clone all my projects locally, or update them with
git pull
- it's just self-contained version of githubsync.py (I merged github.py into the same file). It can be found here as gist/373731I used githubsync.py to clone my projects to my laptop and desktop initially, and also routinely run it inside Dropbox, as a backup.
是的,确实如此。
但是,一旦您拥有了这个大型存储库,您就必须区分其中的各个部分,这些部分将随着自己的生命周期和自己的标签而发展。
正如您所说,这些将是 子模块 ,他们自己的 git 存储库。
所以你仍然得到:
注意:通过命名约定仍然可以更好地管理项目创建的时间顺序。
有了这么多子模块,您可以:
Yes it is.
But once you have that large repository, you have to distinguish the parts in it which will evolve with their own lifecycle and their own tag.
Those would be submodules that will be, as you said, a git repo of their own.
So you still get:
Note: the chronology of projects creation is still better managed with a naming convention.
With that many submodules, you can: