我试图理解 subversion / git
我正在尝试理解和学习如何使用 subversion 或 git。你推荐哪一个？
看起来如此复杂和令人困惑。
我做了很多 PHP Web 开发项目。我有备份项目文件夹的习惯，例如project_name_version_date
对于初学者来说，最好的学习方法是什么？
如何将更新的项目从本地计算机上传到实时网站到不同的服务器，如何从 subversion / git 完成？并再次重新上传到新版本？
可以 2 到 3 个人同时从事同一个项目吗？他们从服务器加载代码文件吗？它不会互相冲突吗...就像他们删除了类对象、函数等一样。
I am trying to understand and learn how to use subversion or git. Which do you recommend?
It seem so complicated and confusing.
I do a lot of PHP web development projects. I have a habit backing up project folders like project_name_version_date
What is the best way to learn for beginner?
How do you upload updated project from local machine to live website to a different server, how that be done from subversion / git? and reupload to new version again?
Can 2 or 3 people work on the same project at the same time? do they load the code files from the server? wouldn't it conflict each other... like they had removed the class objects, functions, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
通过版本控制，您将拥有一个中央存储库和一个或多个工作副本（git 在每个工作副本中添加本地存储库以允许分布式存储/管理）。
就您而言，您的实时网站和开发副本都是工作副本 - 您从中央存储库检出到每个位置。然后，您可以处理开发副本，并将这些更改提交到中央存储库。准备好发布后，您只需对实时工作副本执行更新即可从中央存储库中提取所有更改。
是的 - 每个人都有一个可以更改的工作副本。
冲突是有可能的，并且会时不时地发生——但是 SVN 和 Git 可以很容易地处理很多事情。例如，对同一文件中不同位置的代码的更改只需合并即可。对同一文件中同一位置的代码的更改通常需要手动干预。
也许可能发生的最严重的冲突就是 SVN 所说的“树冲突”——文件夹结构的更改。这可能是一个真正需要解决的 PITA - 但你必须真正不遗余力地引起它们。
也就是说，在非版本控制环境中发生冲突的可能性（以及解决冲突的难度）要大得多。
有一些做法有助于防止发生重大冲突：
我认为如果您还没有使用其他任何东西，那么从 Git 开始可能会更好 - 分布式系统意味着您更能够在推送到中央存储库之前在本地级别解决冲突。我的所有项目都使用 SVN（在办公室和家里），但我开始通过 Drupal 项目使用 Git，就像我到目前为止所看到的那样。
With version control, you have a central repository and one or more working copies (git adds in a local repository at every working copy to allow distributed storage/management).
In your case, your live website and your development copy are both working copies - you checkout from the central repository to each of these locations. You then work on the development copy, and commit those changes to the central repository. Once you are ready to release, you simply perform an update on the live working copy which pulls all the changes from the central repository.
Yes - each person has a working copy which they make changes to.
Conflicts are likely, and will happen from time to time - but SVN and Git can deal with a lot very easily. For example, changes to code in different places of the same file are simply merged in. Changes to code at the same place in the same file will typically require manual intervention.
Perhaps the worst conflicts that can occur are what SVN calls 'tree conflicts' - changes in the folder structure. This can be a real PITA to fix - but you have to really go out of your way to cause them.
That said, the potential for conflicts (and difficulty in resolving them) in non-version controlled environments is far, far greater.
There are some practices which help prevent major conflicts from occurring:
I think Git is probably better to start with if you don't use anything else already - the distributed system means that you are more able to resolve conflicts at the local level before pushing up to the central repository. All of my projects are use SVN (at the office and at home), but I'm starting to use Git through the Drupal project, and like what I've seen so far.
GIT 是版本控制的较新范例。 SVN 已经存在了一段时间，但 GIT 和 Mercurial 正在获得关注，因为它们允许“分布式版本控制”。这意味着您的代码没有中央服务器。每个人都拥有完整的历史记录，并且可以互相发送“补丁”以共享代码。然而，git 和 Mercurial 确实支持与中央存储库非常相似的工作流程。集成 git 和“gerrit”对于与多人合作的项目确实非常有用。
我建议跳过 svn，因为 svn 是一项较旧的技术，实际上会阻碍您对 git / Mercurial 的理解，因为它是不同的范例并使用不同的流程。 GIT / Mercurial 在本地（没有服务器，你是唯一使用的）以及大型团队中都表现出色。
GIT 更强大，但更难使用，而 Mercurial 则以更可用的形式提供了基础知识。
GIT is the newer paradigm for version control. SVN has been around for a while but GIT and Mercurial are gaining traction as they allow for "distributed version control." This means that there is no central server for your code. Everyone has the entire history and can send "patches" to each other to share code. However, git and mercurial do support a workflow very similar to having a central repository. Integrating git and "gerrit" is really great for working on a project with multiple people.
I suggest skipping svn because svn is an older technology that will actually hinder your understanding of git / mercurial because it is a different paradigm and uses different processes. GIT / mercurial works awesome just locally (no server and you are the only one using) and also for large teams.
GIT is more powerful but harder to use while mercurial has the basics in a more usable form factor.
我建议，使用 git，你也可以在网络上访问你的存储库。至于颠覆，据我所知，没有这样的规定。但这不应该是唯一的原因。两个我都用过，git 很好用。 Git 的主要优点是您不必始终连接到主存储库。您可以在这个问题中阅读更多内容，该问题已得到很好的解释 为什么 Git 比 Subversion 更好？
I will suggest , go for git , you can access your repository on web also. With subversion, as far my knowledge goes, there is no such provision. But this should not be only reason. I have used both, git is very useful. Git's main advantage is that you don't have to be connected to master repository always. You can read more in this question which has been explained in nice way Why is Git better than Subversion?
因为您对整个版本/源代码控制概念还很陌生。我建议你阅读一些有关 VC 的一般知识。
最好的学习方法是在日常项目中实际使用 VCS。是的，很多人可以同时做同样的事情。然后就会发生“冲突”。但现代的 VCS 允许您执行称为合并的操作。
我建议你从学习git开始。由于您对整个事情都很陌生，所以这对您来说应该不会很难。但恕我直言，学习 SVN（这是一个“集中式版本控制系统”）然后转向 git（这是一个分布式版本控制系统）往往会让事情变得复杂。很多人认为分布式 VCS 是未来。所以我建议你开始学习 git 或 Hg，两者都是很好的 VCS。
祝你好运！
As you are new to the whole Version/Source Control concept. I suggest you read a bit about VC in general.
The best way to learn would be to actually use a VCS for your day to day projects. Yes many people can work on the same things at once. And then 'conflicts' can happen. But the modern VCS lets you do something called merging.
I suggest you start with learning about git. As you are new to the whole thing it shouldn't be very hard for you. But IMHO learning SVN(which is a 'centralized version control system) and then moving in to git (which is a distributed version control system) tends to complicate things. A lot of people feel distributed VCS are the future. So i suggest you start learning either git or Hg, both are good VCSs.
Good Luck!
您应该阅读 Subversion 教程，并远离 Git，直到您对 SVN 有一定的经验。
最好的学习方法是遵循实践教程，然后在正常的开发工作流程中亲自尝试相同的事情。
当然，很多人可以在同一个项目上工作，这是我们使用版本控制的主要原因之一。
You should read a tutorial on Subversion and stay very far away from Git until you are reasonably experienced in SVN.
The best way to learn is follow a hands-on tutorial and then try the same things out yourself during your normal development workflow.
And certainly many people can work on the same project, that is one of the main reasons we use version control.
我强烈建议您查看 http://hginit.com/ 它使用与 Git 非常相似的 Mercurial，但是从 hginit 中获得的重要一点是分布式版本控制（以及一般的版本控制）如何独立工作和作为团队的一部分工作。一旦您理解了 hginit 中的概念，您选择哪种分布式源代码控制工具就不再那么重要了。
I would strongly recommend checking out http://hginit.com/ It uses Mercurial which is very similar to Git, but the important thing to gain from hginit is how distributed version control (and version control in general) work both independently and as part of a team. Once you understand the concepts in hginit, which distributed source control tool tool you pick is not nearly as important.
Subversion 和 git 处理代码的方式非常不同，但目标是相同的。
Subversion 是源代码控制的集中式解决方案。 Git 是一种分布式源代码控制解决方案。在这两种情况下，您只能自己使用它们，或者任意大的团队都可以使用它们。
Subversion 是集中式的，这意味着只有一台服务器。所有代码都驻留在该机器上。从概念上讲，处理这个问题要简单一些。
Git 是分布式的，这意味着有很多服务器（每个人都是服务器和客户端）。这使得了解哪一个是“正确的”服务器变得有点复杂。
现在，您正在创建要保留在磁盘上其他位置的文件的副本，并将其用作备份。当您执行此操作时，您一次执行几个步骤（在概念层面上）：
决定要备份哪些文件
大多数源代码管理需要您的帮助来告诉它要跟踪哪些文件。这在 git 和 subversion 中都称为
add命令。备份这些文件，以便将来的更改不会影响它们
这是通过
提交对源代码管理正在跟踪的文件的更改来完成的。在 Subversion 中，这是通过commit完成的。在 git 中，add使 git 知道您对文件所做的更改，而commit使更改以永久方式保存。以对您有意义的方式标记文件副本
这是通过不同的源代码控制技术以多种方式完成的。两者都有提交的历史记录、分支/标签的概念和不同的存储库（尽管 subversion 中的存储库之间的代码通常不会更改）。
在 Subversion 中，代码位于单个服务器上。每个人都从那里获取它（最初使用
checkout，后来使用update）。在 git 中，您可以从另一个存储库获取远程更改。与 subversion 相比，Git 的冲突解决方案（两个人同时更改同一内容）稍显优越，但如果不小心，您仍然可能会遇到大量合并问题。 Git rebase 可能很有帮助，尽管我只是以个人方式使用它，所以我还没有进行太多冲突解决实践。
Git 有一些一些人非常信赖的工具（bisect 和 grep），我发现它们很有用。您的里程可能会有所不同:)
Subversion and git are very different in the way they deal with code, but the goal is the same.
Subversion is a centralized solution to source control. Git is a distributed solution to source control. In both cases, you can use them by yourself only or an arbitrarily large team can use them.
Subversion is centralized, meaning there is only one server. All the code lives on that machine. It's a little simpler conceptually to deal with this.
Git is distributed, meaning there are a lot of servers (everyone is a server and a client). This makes it a little more complicated to understand which one is the "right" server.
Right now, you are creating a copy of the files you want to keep somewhere else on the disk and using that as a backup. When you do this, you are doing several steps at a time (at a conceptual level):
Deciding which files you want to backup
Most source control needs your help to tell it which files to track. This is known as the
addcommand in both git and subversion.Backing up those files so that future changes do not impact them
This is done by
commiting the changes to the files your source control is tracking for you. In subversion this is done withcommit. In git,addmakes git aware of the changes you make to the files andcommitmakes the changes saved in a permanent manner.Labeling the copy of the files in a manner that makes sense to you
This is done in multiple manners in the different source control technologies. Both have a history of the commits, the concept of branches/tags and different repositories (though code doesn't normally change between repositories in subversion).
In Subversion, the code is on a single server. Everyone gets it from there (originally with
checkout, afterward withupdate). In git, youfetchremote changes from another repository.Git has somewhat superior conflict resolution (two people changing the same thing at the same time) to subversion, but you can still get into plenty of merge headaches if you are not careful. Git rebase can be helpful, though I've only used it in an individual manner so I have not had much conflict resolution practice yet.
Git has some tools that some people swear by (bisect and grep) that I have found to be somewhat useful. Your mileage may vary :)
这很大程度上是一个舒适度的问题，但由于您是初学者（并且可能愿意花一些时间学习新技能），所以我会推荐 git。作为一个使用过 svn 和 git 的人，我认为你的工作流程看起来会得到 git 的帮助。
在考虑 svn 与 git 时，您需要自己回答以下一些问题：
您所在的公司是否因政策而禁止您使用 git？ （如果是，请使用 svn）。
您是否有一个工作流程，您喜欢创建一个“主题分支”来开发功能，然后在您认为该功能运行良好时将其合并到主干中？ （如果是的话，git 更好，因为它实际上鼓励你创建分支，并很容易地将它们合并回来，而 svn 就创建分支并将它们合并到 main 而言完全是地狱）。
您是否更喜欢经常以小块的形式提交，以便拥有清晰的更改记录并可以有选择地展开？ （我认为 git 可以更好地支持这种开发风格）。
看看这个命令：http:// /www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html 。我无法告诉你有多少次我不得不进行自定义发布，其中我提取特定功能并“组成”图像/网站/应用程序以进行快速演示。如果你认为你会经常这样做，想想你会如何在颠覆中做到这一点。我可以提前预测这不会会是一次野餐:)
还有很多其他原因，但如果您的工作流程看起来像我所描述的那样，那么您应该使用 git。
您可以从这个很棒的资源中学习 git： http://progit.org/book
请记住，如果您遇到困难使用 svn 并且仍然想使用 git，这也很容易！
http://progit.org/book/ch8-1.html
It's largely a matter of comfort, but since you are a beginner (and presumably willing to spend some time learning a new skill), I will recommend git. As someone who has used svn and git, I think your workflow looks like it would be helped by git.
Here's some questions you need to answer for yourself when thinking svn vs. git:
Are you in a company where policy prevents you from using git? (If yes, use svn).
Do you have a workflow wherein you like to create a 'topic branch' to develop a feature, and then merge it into main when you believe that feature works well? (If yes, git is better, because it actually encourages you to create branches, and merge them back very easily, whereas svn is total hell as far as creating branches and merging them into main is concerned).
Do you prefer to commit often in small chunks so that you have a nice clean record of changes that you can selectively unroll? (I would argue that this style of development is supported better by git).
Look at this command: http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html . I cannot tell you how many times I have had to do a custom release wherein I pull specific features and 'compose' an image / website / app for a quick demo. If you think you will be doing this often, think how you would do it in subversion. I can predict in advance that it's not going to be a picnic :)
There are tons of other reasons, but if your workflows look like what I have described, then you should go with git.
You can learn git from this great resource: http://progit.org/book
And remember, if you are stuck with svn and would still like to use git, that is easy too!
http://progit.org/book/ch8-1.html