【问题标题】:How to work wit Git correctly?如何正确使用 Git?
【发布时间】:2017-04-15 00:28:01
【问题描述】:

我曾使用 Git 进行尝试,但我很确定我没有正确使用它。
我想知道如何使用 Git 变得更专业。
我想从头开始,所以从没有安装 Git 的情况开始。
当然,我已经阅读了手册并在 Google 上搜索了很多内容,但我只是不确定如何正确使用它。

现在我们有一个专门用于网站的 unix 服务器。
我在 Windows 上使用 PhpStorm 进行 Web 开发,我有一所大学在 .htaccess 中进行了小的 301 重定向更改。
也许将来我们会与另一位程序员一起扩展。
我也希望能够跟踪他所做的更改,或者只是将一些重定向添加到 .htaccess 中,Git 是否矫枉过正?

在这种情况下使用 git 的最佳方法是什么?
主人应该在哪里等
我对 Git 很陌生,所以请具体说明。
我还听说有可能我必须在我的大学提交的提交上线之前对其进行审核,我想这样工作。

我还需要用新代码更新 master 还是全部是单独的分支等。

【问题讨论】:

    标签: windows git unix version-control


    【解决方案1】:

    让我用简单和最少的语言来解释一下。

    1. Git 不一定只用于多用户环境,但对于个人开发人员来说,它是相同或更有用的独立版本。在开始时,我们应该首先以个人开发者的身份利用它的所有功能,而不是以协作的方式。

    2. 让我们在本地系统上创建 git 存储库(使用 git init),开发人员正在处理(master 或 branch,稍后会占用..),在开发周期中,他/她应该识别非常小但正在工作的完整工作单元,即添加了按钮并执行一些基本功能,并且应该分阶段( git add )和提交( git commit )并提供适当的详细信息。作为一名开发人员,我曾经每天在本地存储库中进行 5 到 10 次提交。

    3. 第 2 阶段的优势是,我们可以随时回到过去.. 如果在几秒钟内出现任何问题.. 将本地存储库设置为提交编号期间的状态。 3 或提交没有。 10 ( git checkout .. commit no. ) 它在调试过程中非常有用,并且有清晰的画面以供进一步规划。即使是在任何特定提交之后出现的任何问题也很容易发现(git diff 将显示任何 2 次提交之间的差异)。所以我们可以通过 git 很好地控制我们的文件..

    4. 现在我们可以选择在分支中工作,而不是在 master 中工作。比如在每一个新功能之前,可以创建一个分支(git branch branch_xyz, git checkout branch_xyz),我们可以制定一些规则(不是通过git)比如(代码审查完成,单元测试,组件测试)没有完成,代码不会合并到 master.. 审阅者、测试者或感兴趣的项目团队,可以拉他们系统中的特定分支.. 为他们的活动。无论是它的主节点还是分支,提交逻辑都保持不变,并且第 2 点中提到的所有内容都将保持不变。很少有我们想要识别为里程碑的提交可以被标记,即(git tag -a build_3.4 -m “build description)。全部验证后,代码可以合并到master(git checkout master, git merge branch_xyz)

    5. 以上所有内容都是可以在本地系统本身上使用的最低功能,无需任何服务器。现在在多用户环境中可以选择在我们自己的服务器上拥有存储库,或者我们可以使用 github 或 bitbucket 之类的存储库。我的代码使用 bitbucket。不需要只将最终更改推送到主存储库(不要等待)...我们可以继续将更改推送到主存储库( git push –all -u remotename ),就像我们在本地进行的那样,如果在本地它是分支的一部分,在 main 中它也将是同一分支的一部分,如果在本地它被合并到主服务器,那么它只会在服务器上被合并到主服务器..

    6. 其他想要工作的团队成员.. 他们可以使用 git clone 或 git pull 命令从主存储库获取副本.. 并发布他们可以按照第 2 点中提到的相同步骤进行操作..

    多用户环境中的 Git

    问 - 创建主服务器(使用 git)的最佳位置是在托管网站的专用服务器上还是在内部单独安装的服务器上?

    • 你不必称它为master,因为git server和git node都会有master(main code)和branchs(WIP Code),下面解释

    • 主 Git 服务器不必是专用服务器,也不必在托管网站的同一台机器上。只要你可以,它可以在任何地方 下载并准备用于部署的构建。但是 git Main server/repository 不应该用于开发目的,但不是必需的。

    Q - 创建 master 后,我需要将 master 克隆到我自己的计算机上并开始开发。之后我需要将更改提交到 git-server?

    • 让我们假设您的团队中有 3 名成员 1) Ron - 开发人员 2) Gerard- 开发人员 3) Sytse - Tester ,您当前的构建是 build_4_01 位于 master 分支的主 git 服务器上,截至今天您的团队成员的系统中有代码。

    • 首先这三个人都在他们的本地系统上安装了 git,并从主服务器克隆它。现在他们在 master 分支下的本地 git 存储库中有 build_4_01

    • 下一个 Ron 被要求处理下一个功能,该功能将被命名为 build_4_02

    • Ron 首先将在他的本地 git 存储库中创建一个分支,即 branch_build_4_02,并在 branch_build_4_02 下完成代码。

    • build_4_02 下共有 20 个小功能,Ron 在 10 天内完成。

    • 在完成每个小功能后,Ron 用于在本地存储库上执行提交

    • 在每次提交之后,或者在一天结束时,Ron 会将代码 (git push) 推送到主服务器(不用担心,主服务器不会与现有代码混淆。Ron 推送的是在分支内部branch_build_4_02 和主服务器有效地保持 master 和 branch 分离)

    • 在这 10 天的开发时间里,Ron 多次希望 Gerard 帮助他审查代码,或者在技术上帮助他

    • 因此 Gerard 需要 Ron 提供的所有最新代码。每天早上 Gerard 都会执行 git pull ( command ) ,它会将他的本地 git 存储库与 Ron 所做的所有最新更改同步,Gerard 可以在 branch_4_02 中看到它们

    • 编码完成后(build_4_02)Sytse(Tester)被告知,他也像Gerard一样在他的本地系统中执行了一个pull request,得到了最新的代码

    • Sytse 将 git branch 4_02 的代码部署到测试服务器上并完成测试

    • 在测试过程中,他提出了一些缺陷,但 Ron 已修复它们,并将代码推送到 git 服务器上,Sytse 将它们拉到本地 git 上重新测试

    • 在完成所有测试并收到测试签核后,继续进行生产部署。代码仍在分支 4_02 下

    • Ron 现在 10 天内第一次将他的本地 git 指向 master (git checkout master) 并将分支合并到 master (git merge branch_4_02),他还为最后一次提交指定了一个名为 build_4_02 的特定标签,这样每个人都可以按名称识别

    • 特定的提交看起来像 3003b9fe441dd6a2e3c1410880c3a86b496fcb27,但可以使用用户友好的名称进行标记,即 4_01_code_completed、test_completed、4_01_prod

    • Ron 又执行了一次推送 (git push ..),所以同样的更改也会反映在服务器上..

    • Gerard 负责 Prod 部署,他在本地系统上执行 git pull,在 Master 分支中使用最新代码,他为特定提交执行 prod 部署(Ron 已经完成)并将其命名为 tag build_4_02。

    • 团队中的每个人都在他们的本地 git 存储库上执行了一个 git pull 请求,以与 prod 同步。

    • Sytse 有时需要处理生产问题,因此想返回构建 401,他只需检查该特定提交并在他的系统中包含构建 4_01 代码

    Q - 之后我需要与 git-server 上的 master 合并吗?

    Sytse 会收到签名后在本地 git 上进行合并,但合并后会像上面 Ron 所做的那样再次推送到服务器

    问 - 我如何将更改从 git-server 推送到网站?

    这将与您当前的流程相同,唯一的区别是人将更改推送到网站,将在他的本地 PC 上安装 git,之前 将更改推送到网站,他将确保他获得最新的代码,并有正确的提交(标签 build_4_02),就像 Gerard 上面所做的一样

    问答

    Q - 所以要确保 git 主服务器仅用于接收和发送构建。我可以简单地使用单独的电脑作为 git 主服务器,只安装 git 和 centos 吗?

    是的,可以使用单独的服务器,但不是强制性的,但是与其调用它的作业来接收和发送构建,不如说它是集中的代码存储库,团队可以获得任何版本的代码。

    问 - Ron 什么时候 git merge branch_4_02 将更改与本地 git 和 git 主服务器合并?并且感谢这些合并 git 主服务器将始终是最新的?

    不,合并只发生在本地系统,从一个分支到另一个分支,或者从子分支到主分支,反之亦然。要将其发送到主服务器,应该在本地服务器上执行 git push 命令,它为开发人员提供了更多控制权,只有当开发人员要求时,才会将提交发送到服务器。进一步使用 push 命令,开发人员还必须提及远程服务器名称。

    Q - 最好的提交方式是开发者给它标记 4_02_prod,而部署更改的人拉取代码并给它一个标记 4_02_build?

    理想情况下,由开发人员 (Ron) 完成并标记为 4_02_prod 的代码应该原样用于 Prod 而无需更改,在这种情况下,部署人员不需要任何标记。 但在某些情况下,部署者 ( Gerard ) 在 Ron 更改之上进行更改,他必须用好的标题标记它,即 4_02_deployed。优点是在生产问题期间,一个简单的 diff (git diff) 将清楚地显示 2 次提交/标记之间的更改以缩小问题范围,并且测试人员可以进一步提取两个提交/标记以进行进一步调查。

    Q- 当一切都完成后,你应该删除分支还是保留所有内容?

    Ron 后立即将分支 4_02 合并到 master,并给它一个标签 4_02_prod,并将其推送到 Prod,branch_4_02 必须被删除。因为相同的内容会 在带有标签 4_02_prod 的 master 分支中可用。过了这个时间再让分支活着,没有任何好处,但是如果有人用错了,就会有很大的风险。

    要删除它,Ron 将能够看到 2 个分支 1) 一个在本地系统使用命令 git branch 2) 另一个在主服务器使用命令 git 分支 -r。两者都必须删除,然后git push,所以主服务器也是同步的。

    Q - 你提到我需要删除两个地方的分支。一个在本地,一个在主服务器上。但是当我在本地和主服务器上删除分支时,我仍然可以恢复到旧版本吗?

    是的,如果您从本地 git 和主服务器中删除分支,您仍然拥有所有版本的代码,因为在删除分支之前,该分支本身已合并到 master 并被标记为 4_02_prod。

    这就是 git 的美妙之处,只需使用一个命令 git checkout 开发人员就可以获得任何版本的代码,只要它被提交。

    在当前场景中,Ron 只需要执行一个命令git checkout tags/build_4_02_prod,他的系统中就会有旧代码。他可以有最新的 只需执行命令git checkout master

    Q - 你说首先删除构建然后进行推送(我猜是从你的主人那里),这一切都是在部署到网站/实时代码之前完成的?

    是的,删除分支后我再次推送,因此服务器处于同步状态。为了更安全,我做 2 push 1)在合并完成后到 master 2)在分支删除完成后。如果以某种方式在一个地方删除了分支但没有在其他地方删除,它将在后续推送期间不断出错..

    【讨论】:

    • 感谢您的解释,但我仍然对某些事情感到困惑。我想去多用户环境。创建主服务器(使用 git)的最佳位置是在托管网站的专用服务器上还是在内部单独安装的服务器上?创建 master 后,我需要将 master 克隆到我自己的计算机上并开始开发。之后我需要将更改提交到 git-server?之后我需要与 git-server 上的 master 合并吗?以及如何将更改从 git-server 推送到网站?
    • 我已经编辑了我之前的答案,并用一个现实生活中的简单场景回答了这些问题。你可以问是否还有任何疑问.. :)
    • 谢谢解释很清楚,但我还有一些问题,抱歉。所以要确保 git 主服务器仅用于接收和发送构建。我可以简单地使用单独的 pc 作为 git 主服务器,只安装 git 和 centos 吗?当 Ron 执行 git merge branch_4_02 时,更改会与本地 git 和 git 主服务器合并?并且感谢这些合并 git 主服务器将始终是最新的? .....
    • ...... 最好的提交方式是开发者给它标签 4_02_prod 并且部署更改的人拉取代码并给它一个标签 4_02_build?当一切都完成后,您应该删除分支还是保留所有内容?
    • 再次为您的问题更新了我的答案...对于任何人来说,了解全貌确实太多了。只需几分钟的阅读.. 因此,如果您仍有任何疑问,请随时询问..
    【解决方案2】:

    通常master branch 是默认分支,并且始终需要使用所有稳定的代码对其进行更新。工作流程看起来像 -

    • 一个/多个开发人员创建并从 master 切换到新分支。然后进行更改并测试代码。完成任务后(代码也稳定),创建pull requestmerge主分支代码。

    • 现在,master 有了一些新的变化,所有其他开发人员都将 master 的最新代码(提取)到他们正在开发的不同分支中。

    • 当需要发布产品的一个版本时,在 master 分支的提交上给一个tag (e.g. v1.0.0)。然后从该标签创建一个新分支(例如release-v1.0.0)并发布产品。

    【讨论】:

      猜你喜欢
      • 2017-07-17
      • 2016-07-26
      • 2011-02-06
      • 2012-04-18
      • 1970-01-01
      • 1970-01-01
      • 2016-03-21
      • 1970-01-01
      • 2017-04-13
      相关资源
      最近更新 更多