如何确保我的git回购代码安全？ [英] How to make sure my git repo code is safe?
问题描述
如果我们的组织要从一个像Subversion这样的中央服务器VCS切换到像git这样的分布式VCS，我该如何确保我所有的代码都可以避免硬件故障？
使用中央服务器VCS，我只需每天备份存储库。如果我们使用的是DVCS，那么在所有开发人员机器上都会有大量代码分支，并且如果该硬件出现故障（或者开发人员会丢失笔记本电脑或者它被盗），那么我们就不会有任何备份。
请注意，我不认为它是让开发人员将分支机构推送到服务器的好选择 - 这就是单调乏味，开发者最终不会这样做。
是否有解决此问题的常用方法？
一些说明：
使用本地中央服务器VCS，除开发人员最近的更改外， 必须位于中央服务器上。因此，例如，如果开发人员决定分支执行bug修复，那么该分支位于中央服务器上，并可立即备份。
如果我们使用DVCS然后开发者可以做一个本地分支（事实上许多本地分支）。这些分支都不在中央服务器上，只有开发人员认为哦，是的，我应该把它推送到中央服务器。
我看到了（如果我错了，请纠正我的错误！）：如果我们使用的是DVCS，但是使用的是正常的VCS，则半实施的功能和错误修正可能无法在中央服务器上备份。如何保持代码安全？我认为你会发现在实践中开发者更喜欢使用中央仓库比在彼此的本地存储库之间推拉。一旦你克隆了一个中央仓库，在处理任何跟踪分支时，获取和推送都是简单的命令。向所有同事的本地存储库添加六张远程控制台是一件痛苦的事情，这些存储库可能并不总是可以访问的（关掉电脑，在家里拿着笔记本电脑等）。
在某个时候，如果你们都在研究同一个项目，那么所有的工作都需要进行整合。这意味着您需要一个集成分支，将所有更改集中在一起。这自然需要在所有开发人员都可以访问的地方，例如，它不属于主要开发人员的笔记本电脑。
一旦你设置了一个中央您可以使用cvs / svn样式工作流来检入和更新。如果你有局部更改，cvs update会变成git fetch和rebase，或者如果你没有git pull， cvs commit成为git commit和git push。
通过这个设置，您与完全集中的VCS系统处于类似的位置。一旦开发人员提交他们需要做的更改（git push），他们需要做的工作才能被其他团队看到，他们会在中央服务器上进行备份。
<在这两种情况下需要遵守的规则是阻止开发人员长时间在中央存储库中进行更改。我们大多数人可能在一个开发人员正在研究特性x的情况下工作，这需要对某些核心代码进行根本性改变。这一变化将导致其他人需要完全重建，但功能还没有准备好主流，所以他只是保持检查，直到适当的时间点。
<这两种情况的情况非常相似，尽管存在一些实际的差异。使用git，因为您可以执行本地提交并可以管理本地历史记录，所以个人开发人员可能不会像使用cvs那样感受到推送到中央存储库的必要性。
另一方面，可以使用本地提交作为优势。将所有本地提交推送到中央存储库上的安全位置应该不是很困难。本地分支可以存储在特定于开发人员的标记名称空间中。
例如，对于Joe Bloggs，可以在其本地存储库中创建一个别名，以执行类似于以下内容的操作（例如） git mybackup 。 git push origin + refs / heads / *：refs / jbloggs / *
这是一个可用于任何点（如一天结束时），以确保他的所有本地更改都安全地备份。
这有助于各种灾难。乔的机器爆炸了，他可以使用另一台机器取回已保存的提交并继续从他离开的地方继续。乔生病了？弗雷德可以让乔的分支抓住他昨天做出的必须修复，但没有机会与主人进行测试。
要回到原始文件题。 dVCS和集中式VCS之间是否需要有所区别？你说半实现的功能和bug修复不会在dVCS案例中的中央存储库上结束，但我会认为不需要任何区别。
我见过许多情况下，使用集中式VCS时，半实施功能停留在一个开发人员工作箱上。它要么采取一项政策，允许将一半书面功能签入主流或做出决定以创建中央分支。
在dVCS中，同样的事情可能会发生，但应该做出同样的决定。如果有重要但不完整的工作，则需要集中保存。 git的优点是创建这个中央分支几乎是微不足道的。
If our organisation were to switch from a central-server VCS like subversion to a distributed VCS like git, how do I make sure that all my code is safe from hardware failure?
With a central-server VCS I just need to backup the repository every day. If we were using a DVCS then there'd be loads of code branches on all the developer machines, and if that hardware were to fail (or a dev were to lose his laptop or have it stolen) then we wouldn't have any backups.
Note that I don't consider it a good option to "make the developers push branches to a server" -- that's tedious and the developers will end up not doing it.
Is there a common way around this problem?
Some clarification:
With a natively-central-server VCS then everything has to be on the central server except the developer's most recent changes. So, for example, if a developer decides to branch to do a bugfix, that branch is on the central server and available for backup immediately.
If we're using a DVCS then the developer can do a local branch (and in fact many local branches). None of those branches are on the central server and available for backup until the developer thinks, "oh yeah, I should push that to the central server".
So the difference I'm seeing (correct me if I'm wrong!): Half-implemented features and bugfixes will probably not available for backup on the central server if we're using a DVCS, but are with a normal VCS. How do I keep that code safe?
I think that you will find that in practice developers will prefer to use a central repository than pushing and pulling between each other's local repositories. Once you've cloned a central repository, while working on any tracking branches, fetching and pushing are trivial commands. Adding half a dozen remotes to all your colleagues' local repositories is a pain and these repositories may not always be accessible (switched off, on a laptop taken home, etc.).
At some point, if you are all working on the same project, all the work needs to be integrated. This means that you need an integration branch where all the changes come together. This naturally needs to be somewhere accessible by all the developers, it doesn't belong, for example, on the lead developer's laptop.
Once you've set up a central repository you can use a cvs/svn style workflow to check in and update. cvs update becomes git fetch and rebase if you have local changes or just git pull if you don't. cvs commit becomes git commit and git push.
With this setup you are in a similar position with your fully centralized VCS system. Once developers submit their changes (git push), which they need to do to be visible to the rest of the team, they are on the central server and will be backed up.
What takes discipline in both cases is preventing developers keeping long running changes out of the central repository. Most of us have probably worked in a situation where one developer is working on feature 'x' which needs a fundamental change in some core code. The change will cause everyone else to need to completely rebuild but the feature isn't ready for the main stream yet so he just keeps it checked out until a suitable point in time.
The situation is very similar in both situations although there are some practical differences. Using git, because you get to perform local commits and can manage local history, the need to push to the central repository may not be felt as much by the individual developer as with something like cvs.
On the other hand, the use of local commits can be used as an advantage. Pushing all local commits to a safe place on the central repository should not be very difficult. Local branches can be stored in a developer specific tag namespace.
For example, for Joe Bloggs, An alias could be made in his local repository to perform something like the following in response to (e.g.) git mybackup.
git push origin +refs/heads/*:refs/jbloggs/*
This is a single command that can be used at any point (such as the end of the day) to make sure that all his local changes are safely backed up.
This helps with all sorts of disasters. Joe's machine blows up and he can use another machine and fetch is saved commits and carry on from where he left off. Joe's ill? Fred can fetch Joe's branches to grab that 'must have' fix that he made yesterday but didn't have a chance to test against master.
To go back to the original question. Does there need to be a difference between dVCS and centralized VCS? You say that half-implemented features and bugfixes will not end up on the central repository in the dVCS case but I would contend that there need be no difference.
I have seen many cases where a half-implemented feature stays on one developers working box when using centralized VCS. It either takes a policy that allows half written features to be checked in to the main stream or a decision has to be made to create a central branch.
In the dVCS the same thing can happen, but the same decision should be made. If there is important but incomplete work, it needs to be saved centrally. The advantage of git is that creating this central branch is almost trivial.
这篇关于如何确保我的git回购代码安全？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
