版本控制方案

Question

我依靠Github / Bitbucket /版本控制大师。

场景是我有一个DEV服务器和一个LIVE服务器。我已经建立了一个存储库，以便我可以集中控制版本控制。在下面的图片中（暂时忘记用例..），我已经将LIVE和DEV服务器的两个副本复制到我的存储库中，所以我几乎可以从主服务器上创建一个主服务器，其中主服务器是LIVE服务器和分支机构将是开发服务器。因此，我在DEV服务器中感到满意的任何更改，然后我将合并到主服务器（LIVE服务器）。这就是我的想法。在这种情况下你会建议什么？

Answer 1

您似乎在文件夹与分支，repos与服务器和基本工作流之间存在混淆。没有本地仓库与远程仓库。 您描述的方案只有一个回购。您可以在localhost中拥有本地工作副本，在生产服务器中拥有克隆，当然还可以在github中或您想要的任何位置使用远程。但是工作副本仍然是同一个仓库的镜像。

我认为最简单的布局可以提供与你相同的目的

• 开发服务器（对于此示例，它将是您的本地主机）
  • 保留项目的一个工作副本。例如，在/home/user/project
  中
  • 除合并之外，您将此工作副本保留在develop分支中。
  • 您提交然后推送到您的原始远程，即git://github.com/Arty/project.git
• Web服务器
  • 它运行一个网络服务器（apache，nginx等）
  • 网络服务器有两个虚拟主机
  • Vhost1具有server_name dev.project.com，文档根目录为/var/www/dev_project
  • Vhost2具有server_name www.project.com，文档根目录为/var/www/project
  • 两个文档根目录都是git://github.com/Arty/project.git的工作副本，但第一个位于develop分支，而第二个位于master分支。
• Github Remote a.k.a. Origin
  • 这个不需要解释

添加新功能的工作流程将是

1. 您站在/ home / user / project（cd /home/user/project）
2. 您位于develop分支（git checkout develop）
3. 您破解了您的更改，然后提交它们（git commit -a -m "my new feature"）
4. 你推到原点（git push origin develop）
5. 您登录到您的网络服务器（ssh dev.project.com）
6. 您站在/ var / www / dev_project（cd /var/www/dev_project）
7. 您从原点（git pull origin develop）
中提取最近的更改
8. 您从网络服务器退出并在/home/user/project本地
上退回
9. 您验证您的更改是否正常工作 预计在dev.project.com
10. 如果他们不这样做，请重复第3至8阶段
11. 如果是，则切换到主分支（git checkout master）
12. 您从develop（git merge develop）
合并
13. 如果有冲突，您可以解决冲突，并推送到原点（git push origin master）
14. 您再次登录Web服务器
15. 您站在/ var / www / project（cd /var/www/project）
16. 你从原点（git pull origin master）
拉出来
17. 您确认您的制作网站www.project.com正在按预期运行
18. 您要完成直到您想要启动其他功能。

还有更详细的方案，但只要你不了解Git的内部运作方式，他们只会让你更加困惑。

对于分支方案，过去两年我在一个由8名开发人员组成的团队中使用gitflow，并且它完美无瑕。再说一次，如果你单独工作并且这是你使用Git的第一步，你可能要等到拥抱gitflow之前。