如何设置本地Git存储库和本地备份目录？
更新
我按照下面答案之一的指示设置了两个 Git 存储库，但备份目录没有工作目录中的文件副本。这是我在备份目录中看到的...
$ ls
total 0
drwxr-xr-x 10 Hristo staff 340 Feb 25 21:40 Kamma.git
...但我期待类似以下内容...
$ ls
total 16
drwxr-xr-x 6 Hristo staff 204 Dec 19 19:51 css
drwxr-xr-x 3 Hristo staff 102 Nov 13 18:00 images
-rw-r--r--@ 1 Hristo staff 4440 Feb 26 03:20 index.html
drwxr-xr-x 15 Hristo staff 510 Feb 24 14:19 js
再次，我想要我的主工作目录，/Users/Hristo/Sites/Kamma，作为我进行更改、提交和恢复等的地方。
我希望 /Users/Hristo/Sites/Kamma_bak 成为我定期推送重要更改的地方，例如我的项目的新版本，其中所有内容都是我的工作目录的副本，只是不是最重要的最新的副本。
我希望这是有道理的。
原始帖子
我想建立一个本地 Git 存储库。例如，我希望我的主要位置是 /Users/Hristo/Sites/Kamma ，这是我完成所有工作的地方。
我希望能够提交更改并恢复到以前的版本等...，颠覆的工作方式。但我还希望有一个备份目录，/Users/Hristo/Sites/Kamma_bak，作为故障保险，我会每隔一段时间“推送”版本。
在此备份目录 /Users/Hristo/Sites/Kamma_bak 中，我希望所有文件等都作为工作目录 / 的重复副本、备份副本存在Users/Hristo/Sites/Kamma
我如何使用 Git 来做到这一点？我已经将它安装在我的机器上，运行 Snow Leopard。
UPDATE
I set up the two Git repositories following the directions from one of the answers below, but the back-up directory doesn't have copies of the files in the working directory. This is what I see in the back-up directory...
$ ls
total 0
drwxr-xr-x 10 Hristo staff 340 Feb 25 21:40 Kamma.git
... but I was expecting something like the following...
$ ls
total 16
drwxr-xr-x 6 Hristo staff 204 Dec 19 19:51 css
drwxr-xr-x 3 Hristo staff 102 Nov 13 18:00 images
-rw-r--r--@ 1 Hristo staff 4440 Feb 26 03:20 index.html
drwxr-xr-x 15 Hristo staff 510 Feb 24 14:19 js
Again, I want my main working directory, /Users/Hristo/Sites/Kamma, to be the place where I make changes and do commits and reverts and such.
I want /Users/Hristo/Sites/Kamma_bak to be the place where I periodically push important changes, like a new version of my project, where everything is a copy of my working directory, just not the most up to date copy.
I hope this makes sense.
Original Post
I would like to set up a local Git repository. So for example, I would like my main location to be /Users/Hristo/Sites/Kamma which is where I would do all of my work.
I'm looking to be able to commit changes and revert back to previous versions, etc..., the way subversion works. But I would also like to have a back-up directory, /Users/Hristo/Sites/Kamma_bak, as a fail safe, where I would "push" versions every once in a while.
In this back-up directory /Users/Hristo/Sites/Kamma_bak, I would like all the files and such to exist as duplicate copies, as back-up copies, of the working directory /Users/Hristo/Sites/Kamma
How would I do this with Git? I have it already installed on my machine, running Snow Leopard.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，你绝对可以做到。尽管我建议您的备份文件夹位于另一台计算机上。
请阅读此主题，有效地一起使用 Git 和 Dropbox？
我认为这些说明完全提供了您想要的内容正在寻找； “dropbox”部分当然是可选的（它只是一个文件夹）。
编辑：忘记保管箱位。 Dropbox 只是一个本地文件夹+一个异地复制它的服务。这些说明对于本地文件夹也适用。
重要的是创建一个（本地）裸存储库，将其设置为“git 远程”并将更改推送到其中。
让我从引用的线程中复制并粘贴，并为您进行更改。
像这样的东西应该有效：
Yes you can absolutely do that. Although I would recommend that your backup folder is on another computer.
Please read this thread, Using Git and Dropbox together effectively?
I think the instructions provide exactly what you are looking for; the "dropbox" part is of course optional (it's just a folder).
EDIT: Forget about the dropbox bit. Dropbox is just a local folder + a service that replicates it offsite. These instructions will work for you too WITH A LOCAL FOLDER.
The important bit it to create a (local) bare repo which you setup as a 'git remote' and push your changes to.
Let me copy and paste from quoted thread, and make the changes for you.
Something like this should work:
注意：同一台计算机上的“备份”副本并不算是备份（尤其是在同一磁盘上时）。为了可靠，您确实需要将数据复制到一台（或多台！）不同的机器/介质，最好是在不同的位置。
听起来你的“备份”是一个裸存储库，但希望它成为一个非裸存储库（即您希望它签出自己的工作树）。
问题是推送到非裸存储库通常不是一个好主意。实际上，此类推送可能会更新 HEAD 指向的分支，而不更新索引或工作树。这可能会导致接收存储库中出现非常混乱的情况（例如，添加的文件显示为已删除状态等）。因此，Git 版本 1.7.0 及更高版本默认拒绝接受对当前签出的非裸存储库分支的推送。
注意：当您出于备份目的推送到裸存储库时，推送的提交中包含的所有文件都在那里，只是没有签出（它们被压缩并作为“松散对象”和“打包文件”保存在 Git 对象存储中”）。推送的数据代表您提交和推送的内容的历史记录的完整副本。您只是无法直接访问内容。相反，您必须将其克隆到非裸存储库（从而签出提交）或使用 git archive 提取一组文件，而无需额外的存储库或完全签出。
我不太相信您需要像您所描述的那样的东西。
如果您需要检查存储库的旧快照（并且您不想在正常工作存储库中执行此操作），那么您应该克隆一个临时副本并签出所需的旧提交。本地克隆很便宜，因为它们可以硬链接对象存储文件而不是复制它们。历史提交图通常就是您“回到过去”所需的一切。虽然 Git 允许您随意重写历史图，但您实际上并不会面临进行不可恢复的更改的太大危险，因为它通常需要
-f/--force开关和/或者提供恢复机制（reflogs、refs/original/、收集未引用对象之前的最低年龄要求等）。拥有另一个存储库（尤其是在另一个位置的另一台机器上）是一个好主意，您可以在其中推送您的提交以用于备份（以便您可以从（例如）
rm -rf 中恢复） working_repo），但是一个裸存储库通常就完全足够了。当您需要恢复时，您只需创建一个克隆即可。当您想在不影响正常工作存储库的情况下检查某些旧快照时，您可以在某处进行临时克隆。具有良好的提交卫生、git diff、git log（尤其是-p和-S选项）以及git show 通常可以提供您可能想要从旧提交中获得的任何“考古”信息，而无需检查任何内容（它们甚至可以在裸存储库中工作）。然而，如果你愿意接受风险，你完全可以做你想做的事。
Git 与任何其他“锋利”工具一样，会让您冒“搬起石头砸自己脚”的风险（请原谅这个混合的比喻）。
创建并配置您的备份存储库，并将其添加为工作存储库中的远程存储库。
在备份存储库中，设置一个
post-receive或post-update挂钩来执行git reset --hard。这将使索引和工作树与当前签出的分支保持同步。Git 常见问题解答 “为什么在“git Push”之后我看不到远程存储库中的更改？” 指向一个示例 <一个 href="http://utsl.gen.nz/git/post-update" rel="nofollow">
post-update脚本 可以相对安全地执行此操作（它节省了如果工作树或索引脏的话，则存储 - 如果推送具有相同路径名的新添加的文件，仍然可能会丢失未跟踪的文件）。当您想要更新时推送到备份存储库。
如果您使用这样的设置，您绝对应该避免在备份工作树中工作。您在那里所做的任何提交、您留在此处的任何分阶段更改以及您留在此处的任何未跟踪文件都可能会丢失。
Note: A “backup” copy on the same machine is not much of a backup (especially if it is on the same disk). To be reliable you really need to copy your data to one (or more!) different machines/media, preferably in different locations.
It sounds like your “backup” is a bare repository, but want it to be a non-bare repository (i.e. you want it to have its own working tree checked out).
The problem is that pushing to a non-bare repository is usually not a good idea. Effectively, such pushes are likely to update the branch that HEAD points to without updating the index or working tree. This can lead to very confusing situations in the receiving repository (e.g. added files shown with a deleted status, etc.). For this reason, Git versions 1.7.0 and later default to refusing to accept pushes to the currently checked out branch of non-bare repositories.
Note: When you push to a bare repository for backup purposes, all the files contained in the pushed commits are there, they are just not checked out (they are compressed and kept in Git the object store as “loose objects” and “pack files”). The pushed data represents a full copy of history of the content that you committed and pushed. You just can not access the content directly. Instead, you must clone it to a non-bare repository repository (and thus checkout a commit) or use
git archiveto extract a set of files without an additional repository or full checkout.I am not really convinced that you need something like what you describe.
If you need to examine an old snapshot of your repository (and you do not feel like doing it in your normal working repository), then you should just clone a temporary copy and checkout the desired, old commit. Local clones are cheap since they can hardlink the object store files instead of copying them. The historical commit graph is generally all you need to “go back in time”. While Git will let you rewrite the history graph at will, you are not really in much danger of making unrecoverable changes since it usually requires
-f/--forceswitches and/or provides recovery mechanisms (reflogs, refs/original/, minimum age requirements before collecting unreferenced objects, etc.).It is a good idea to have another repository (especially on another machine in another location) where you can push your commits for backup purposes (so that you can recover from (e.g.)
rm -rf working_repo), but a bare repository is usually entirely sufficient. When you need to recover, you just make a clone. When you want to examine some old snapshot without disturbing your normal working repository, you make a temporary clone somewhere. With good commit hygiene,git diff,git log(especially the-pand-Soptions), andgit showcan often provide whatever “archeological” information you might want from old commits without needing to checkout anything at all (they even work in bare repositories).However, if you are willing to accept the risk, you can do exactly what you want.
Git, like any other “sharp” tool, will let you risk “shooting yourself in the foot” (pardon the mixed metaphor).
Create and configure your backup repository and add it as a remote in the working repository.
In the backup repository, setup a
post-receiveorpost-updatehook that does agit reset --hard. This will keep the index and working tree up to date with the currently checked out branch.The Git FAQ “Why won't I see changes in the remote repo after "git push"?” points to an example
post-updatescript that can do this relatively safely (it saves a stash if the working tree or the index are dirty—this can still lose untracked files if newly added files with the same pathnames are pushed).Push to the backup repository when you want to update it.
If you use a setup like this, you should absolutely avoid working in the backup working tree. Any commits you make there, any staged changes you leave there, and any untracked files you leave there are liable to be lost.
git init将创建一个 git 存储库。要进行备份，请在原始存储库上执行 git clone --no-hardlinks 来复制它。从那里您可以从一个存储库推送到另一个存储库。git initwill create a git repo. To make the backup, do agit clone --no-hardlinkson the original repo to copy it. From there you can do a push from one repo to the other.