2 个非同一地点的开发人员可以使用什么 git 工作流程？
我有一份编写部分程序的合同。 写另一部分的人在另一个城市。 我想找到一种方便的方式来来回发送更改。 由于其他原因，我想学习使用 git 作为分布式版本控制系统和电子邮件来回更改。 （我以前使用过 SCCS、RCS 和 PVCS，总是使用锁定。我想督促自己学习如何更好地使用分支和合并，而不是依赖于中央服务器。）
我们需要执行以下两项任务（相当标准的列表）：
(a) 我们每个人都为需要对这两个部分进行更改的错误修复和新功能做出贡献。
(b) 为客户编译并打包二进制文件。
（我们还需要单独处理不依赖于其他功能的功能，但我认为任何适用于任务 (a) 的功能也适用于此。）
背景：另一个人以前从未使用过 VCS； 他对这个想法有点抵触。 他甚至不知道他们并不都还在使用锁定结帐。 我需要足够深入地了解我们所做的一切，这样我才能帮助他度过难关，而不会让他感到太多沮丧。 他还对将源代码存储在服务器上感到非常不舒服，这是更喜欢通过电子邮件进行更改的另一个原因。 我们可以轻松加密它们。
其他可能相关的上下文：我们使用 Windows 上的 Delphi 作为我们的开发环境。 我们极不可能再增加一名开发人员。 如果是的话，我们每年只需要打包客户版本几次。 顾客数量可能永远不会超过十个。
问题：
1）我应该使用这个项目来学习分布式开发技术吗？ 还是说这太过分了，我应该做一些更简单的事情？ 我不介意花一些额外的时间来学习，但不要超过几周。
2) 假设问题 1 为“是”，我们应该使用什么工作流程来完成上述每项任务？
3) 哪些 Windows GUI 程序可以完成所有必需的任务？ （我对命令行的东西很满意；他不是。）
感谢您的帮助。
我写了一篇关于“gitting start”的非常详细的教程，展示了我到目前为止所学到的关于使用 git 的知识。 如果您想阅读目前为止的内容，请访问 http://xorandor.com/GittingStarted。 我试图为一个对 VCS 了解一点但不是很多的 git 新手编写它。 随着我了解更多，我计划对此进行补充。
I've got a contract to write part of a program. The person writing the other part is in another city. I want to find a convenient way to send changes back and forth. For other reasons, I'd like to learn to use git as a distributed VCS and email changes back and forth. (I've worked with SCCS, RCS, and PVCS before, always with locking. I want to push myself to learn how to better use branching & merging and to not depend on a central server.)
We need to do the following two tasks (pretty standard list):
(a) Each of us contribute to bug fixes and new features that require changes to both parts.
(b) Compile and package binaries for customers.
(We also need to work separately on features that don't depend on the other, but I assume that anything that works for task (a) will work for this also.)
Background: The other guy has never used a VCS before; he's a little resistant to the idea. He didn't even know that they don't all still use locking checkouts. I'd need to understand everything we do in enough depth that I can help him over the rough spots with not much frustration on his part. He's also very uncomfortable with storing the source on a server, which is another reason to prefer emailing changes. We can easily encrypt them.
Other possibly relevant context: We're using Delphi on Windows as our development environment. It's extremely unlikely we'd ever add another developer. We only need to package customer versions a couple of times a year, if that. The number of customers will probably never exceed ten.
Questions:
1) Should I use this project to learn techniques for distributed development? Or is that so much overkill that I should just do something simpler? I don't mind spending some extra time on the learning, but no more than a couple of weeks.
2) Assuming "Yes" to question 1, what workflow should we use for each of the tasks above?
3) What Windows GUI programs will do all the required tasks? (I'm very comfortable with command line stuff; he's not.)
Thanks for your help.
I have written a pretty detailed tutorial on "gitting started" that shows what I've learned so far about using git. It's at http://xorandor.com/GittingStarted if you want to read it so far. I tried to write it for a git novice who knows a little bit but not a whole lot about VCSs in general. I plan to add to that as I learn more.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我参与了对被迫从源安全切换到颠覆的用户的培训和支持。 用户的抵制程度令人惊讶。 现在已经过去一年多了，当“颠覆破坏了我的东西”时，我仍然经常被叫去修复问题（当然从来没有这种情况）。
知道这一点后，我会非常犹豫是否要尝试帮助某人从根本没有 VCS 切换到 git（这可能不是最用户友好的 VCS）。 特别是如果他们讨厌 VCS 的想法。 如果你不能在他们的办公桌前帮助他们，那就更是如此。
所以想一想：有些原因只是失败的原因。 除非您要与此人长期合作，否则您最好为自己建立一个存储库。 您可以让他通过电子邮件将更改后的文件发送给您，反之亦然。 至少 git 可以让您轻松查看自上次集成点以来哪些文件发生了更改。
I have been in involved in training and supporting users which were forced to make the switch from source-safe to subversion. There has been a surprising amount of user resistance. It's been over a year now and I still regularly get called in to fix things when "subversion broke my stuff" (it's never the case of course).
Knowing this, I would be very hesitant to try and help someone make the switch from no VCS at all to git (which is probably not the most user-friendly VCS around). Especially if they hate the idea of a VCS. Doubly so if you can't be there helping them at their desk.
So consider: some causes are just lost causes. Unless you are going to work with this person for a long time, you may be better off setting up a repository just for yourself. You can let him email changed files to you and vice versa. At least git will make it easy for you to see which files changed since the last integration point.
你应该使用这个项目来学习 git 吗？ 我会说是的。
除了源代码控制的固有好处之外，我还使用 git其优点是在每个开发人员系统上都拥有存储库的完整副本。
除了每个人都有一个存储库之外，我要做的一件事是让你们每个人每天左右与中央服务器同步。
工作流程如下：
我知道分布式版本控制系统的重点是没有中央存储库，但我真的很喜欢在异地拥有额外的副本。 如果有的话，它会为您提供存储库的另一个副本以用于备份目的。
至于 Windows 上的 git，我会查看在 Windows 上运行 git 的图解指南。 内置的 git-gui 还有很多不足之处，但它功能齐全且可用。
另外，由于您的合作伙伴是源代码控制的新手，我会推荐 Eric Sink 的优秀 源代码控制 HOWTO。 它为您提供了大量有关源代码控制如何的重要信息。
Should you use this projet to learn git? I would say yes.
Besides the inherent benefits of source control, I using git has the advantage of having full copies of the repository on each developers system.
One thing I would do on top of each having a repository, is to have each of you sync with a central server every day or so.
The workflow would go like:
I know that the whole point of a distributed version control system is to not have a central repo, but I really like having that extra copy offsite. If anything it gives you yet another copy of the repository for backup purposes.
As far as git on windows, I would check out the illustrated guide to running git on windows. The built in git-gui leaves a lot to be desired, but it is functional and usable.
Also, since your partner is new to source control, I would recommend Eric Sink's excellent Source Control HOWTO. It gives you a lot of great information about the how of source control.
看起来 git 有内置 电子邮件补丁功能。 不过我没有使用过它，所以我不能评价它的实用性。
It looks like git has built-in emailed patches functionality. I've not used it though, so I can't speak for its usefullness.
根据我的经验，Git 在 Windows 上还没有得到很好的支持。
有关类似但恕我直言更用户友好的 DVCS，请参阅 Mercurial（又名 Hg）。 它还有一个 Tortoise 客户端和一个相当友好的命令行工具。
还有适用于 Mercurial 的 Visual Studio 和 Eclipse 插件（我想还有 NetBeans）。 它们工作得相当好，并且是其他工具的一个很好的附加功能。 （内容会自动添加/删除/重命名，基本同步任务（推/拉）工作正常。）
Im my experience, Git is not very well supported on Windows, yet.
For a similar, but IMHO more user-friendly DVCS, see Mercurial (a.k.a. Hg). It has a Tortoise-client and a rather friendly command-line tool too.
There's also Visual Studio and Eclipse plugins for Mercurial (I think NetBeans too). They work reasonably well and are a great add-on to the other tools. (Stuff get's added/deleted/renamed automatically and basic syncronization tasks (push/pull) work fine.)
我对 git 还很陌生，但也许最快的开始方法是这样的：
使用 git，您可以在计算机上创建两个存储库。
第一个用于您的工作，第二个用于他发送给您的工作。
有很好的入门教程（正如尼克提到的）
如果您在 TortoiseGit 之前使用过 windows/subversion，则此工具非常有用
我的观点是：除非你对 git 感觉非常好，否则不要开始教他，在你的计算机上创建一个存储库/分支。
I am pretty new in git, but maybe the fastest way to start is this:
With git you can create two repositories on your computer.
One for your work, and second for the work that he sends to you.
There nice tutorial to start (as mentioned by Nick)
This tool is good if you work with windows/subversion before TortoiseGit
My point : don't start to teach him until you feel very good in git, make a both repos/branches in your computer.
我只需在每个上配置 autosetuprebase，然后从一个非常简单的设置开始。
拥抱你所遇到的冲突——否则这些改变就会消失。
I'd just configure autosetuprebase on each and just start with a pretty simple setup.
Embrace the conflicts you get -- those are the changes that would've otherwise been lost.
由于其他开发人员不熟悉版本控制概念，我建议慢慢开始。
我建议的工作流程包括您这边的一个存储库，他可以“git克隆”。
向他展示如何从中获取更改并让他将更改邮寄给您。 向他展示 git 如何邮寄变更集。 这样，您将不得不担心编辑冲突，这对于以前从未使用过版本控制系统的人来说往往是一个很大的混乱来源。
Since the other developer isn't familiar with revision control concepts, I suggest starting slowly.
My suggested workflow consists of a repository on your side that he can "git clone".
Show him how he can fetch changes from that and have him mail his changes back to you. Show him how git can mail changesets around. This way, you are going to be the one who will have to worry about edit conflicts which tend to be a great source of confusion for people who have never used version control systems before.