Questions tagged «git»

目前，我正在一个项目上，我们将源代码保存在Github上的私有存储库中，我们每个人都作为合作者。 我们尚不清楚如何将我们的每项工作分开。 我认为我们需要做的是： 我们每个人都需要分叉存储库 当我们准备推送代码时，我们会向项目负责人的仓库提交拉取请求，而后者可以同时以此为契机进行代码审查 对于私有存储库，这是应该用于分叉的，还是我使情况变得过于复杂？

15 project-management  git  workflows  forking 

这听起来可能有点奇怪，但是我想知道一种以某种方式联网的多台机器在Git中工作的好方法。在我看来，我有两个选择，并且我可以看到双方的好处： 使用git本身进行共享，每台机器都有自己的存储库，您必须在它们之间进行获取。 即使另一台计算机处于脱机状态，您也可以在其中任何一台计算机上工作。我认为这本身就很大。 使用在计算机之间通过网络共享的一个存储库。 每次切换机器时都不需要执行git pull，因为您的代码始终是最新的。 不必担心您忘记了从其他非托管计算机中推送代码的机会，因为您正在该计算机上处​​理文件共享，因此现在无法访问该代码。 我的直觉是，每个人通常都选择第一种选择。但是我看到的缺点是，您可能无法始终能够从其他计算机访问代码，而且我当然也不想每天结束时将所有WIP分支都推送到github。我也不想一直把计算机留在原处，这样我就可以直接从它们中获取信息。最后一点是，所有使多个分支保持最新状态的git命令都可能很乏味。 在这种情况下是否有第三个处理方法？也许有一些第三方工具可以帮助简化此过程？如果您定期处理这种情况，您有何建议？

15 git  workflows  dvcs 

我只是更改了GitHub存储库上的分支设置，所以我的[下一个]分支需要通过pull请求传递一个CI构建。 随后与许多团队成员进行了关于测试失败的讨论。 为了上下文... 该仓库有一个[大师]分支，只有PR'd成时，有一个释放，使[大师]包含代码为的最后一个版本，无论它是否是一个重大的，未成年人，修补程序，β，α-/预发行版本。 [next]分支是“默认”分支，我们打算保留“发布就绪”代码；从技术上讲，可以随时将该分支公诸于[master]并发布。 每个fork都有自己的dev分支，并为[next]贡献者PR。 当我审阅不重要的PR时，我会将贡献者的dev分支合并到我的“ review”分支中，如果我发现可以快速修复的问题，则将提交/推送更改以及新的（有时会失败）测试和PR返回贡献者的dev分支；当他们合并我的更改时，使新的失败测试通过，然后推送，它们的PR进行同步，然后将PR合并到[next]中。 但是这个问题不是关于通过测试，而是关于失败的测试。 测试失败记录了需要解决的问题。 已知的bug应该编写测试，以便我们知道什么不起作用。 从技术上讲，GitHub 问题列表（针对错误和/或关键 标签进行了过滤）也可以做到这一点。它是一个很好的做法，也有一堆失败的测试文档的bug？ 在[next]上失败的构建意味着我们还没有准备好发布……但是，“准备发布”有点像“准备好”要孩子了-您从没有为此做好充分的准备，并且某些地方（重要性不一）将不可避免地出问题。 因此，我们只是将通过测试推向[next]。那么，将失败的测试推向何处呢？我的意思是，在PR /审查流程之外？ 例如，一个用户在问题列表中报告了一个新错误，我想为其编写一个失败的测试套件-以便指定需要执行的操作以及在何处进行操作，这使新贡献者更容易上手最终PR修复。 我应该在哪里推动这些失败的测试？还是将失败的测试推送到任何地方甚至是个好主意？

14 unit-testing  git  teamwork  continuous-integration 

我计划使用另一个框架等完全重写我的项目。保留旧代码（包括历史记录）作为参考会很好。避免风险，混乱和意外的最佳方法是什么？ 我的想法是创建一个新分支，在那里替换所有内容并在那里运行基本的“新”版本，标记最后一个“旧”母版，然后将该分支合并到母版中。听起来合理吗？

14 git  github 

我的团队目前使用相当简单的分支/部署过程，如下所示： ┌────────┐ ┌────┐ ┌──────┐ Environments: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ Builds: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ Branches: │ …

14 version-control  git  development-process  deployment  development-environment 

在由约5名开发人员组成的小型团队中，用一台服务器运行实时应用程序，正确使用git的最简单方法是什么？

14 version-control  git 

奇怪的标题，是的，但是我认为我有足够的基础要掩饰。 我们在github上有一个带有专用存储库的组织帐户。我们要使用github的本机问题/拉动请求功能（就代码审查和功能讨论而言，拉动请求基本上正是我们想要的）。我们通过defunkt找到了工具中心，它具有一个很酷的小功能，它能够将现有问题转换为请求请求，并自动将当前分支与其关联。 我想知道是否最好的办法是让组织中的每个开发人员都分叉组织的存储库来完成其功能工作/错误修复等。这似乎是一个相当可靠的工作流程（基本上，这是github上每个开源项目所做的工作），但是我们希望确保我们可以跟踪问题并从组织存储库ONE来源提取请求。 所以我有几个问题： 在这种情况下，按开发人员分叉的方法是否合适？看来这可能有点过大。我不确定我们是否需要为每个开发人员准备一个分支，除非我们介绍没有直接推送访问权限并且需要审查其所有代码的开发人员。在这种情况下，我们只想针对那些开发人员制定这样的政策。那么，哪个更好？所有开发人员都在一个存储库中，还是每个人的叉子？ 是否有人对集线器工具（特别是拉动请求功能）有经验？如果我们按开发人员分叉（甚至针对特权较低的开发人员），那么集线器的请求请求功能将对上游主存储库（组织的存储库？）的拉取请求进行操作，还是有不同的行为？ 编辑 我对问题，分支和请求请求进行了一些测试，发现了这一点。如果在组织的存储库上创建问题，则将存储库从组织存储到您自己的github帐户，进行一些更改，并合并到存储库的master分支。尝试运行hub -i <issue #>时，出现错误User is not authorized to modify the issue。因此，显然，工作流程将行不通。

14 version-control  git  teamwork  github  workflows 

我是.NET开发人员，并且多次使用TFS（团队基础服务器）作为源代码控制软件。TFS的良好功能是： 与Visual Studio的良好集成（因此我几乎可以直观地完成所有操作；没有控制台命令） 便捷的退房，入住流程 易于合并和解决冲突 简单的自动化构建 分枝 现在，我想将Git用作我的开源项目的骨干，资源库和源代码控制。我的项目使用C＃，JavaScript或PHP语言，并使用MySQL或SQL Server数据库作为存储机制。 为此，我只是使用了github.com的帮助，并在那里创建了配置文件，并下载了Git的GUI。到这部分是如此简单。 但是我几乎坚持不下去了。我只想做一些简单（真的很简单）的操作，包括： 在Git上创建项目并将其映射到笔记本电脑上的文件夹 检出/检入文件和文件夹 解决冲突 那就是我现在要做的。但是，似乎GUI并不那么用户友好。我希望GUI具有一个Connect To...或类似的名称，然后希望显示一个项目列表，当我选择一个项目时，希望看到该项目的文件和文件夹列表，就像浏览TFS项目一样在Visual Studio中。然后，我希望能够右键单击文件，然后选择check-in...或之类的check-out东西。 我期望很多吗？我应该怎么做才能像TFS一样轻松使用Git？我在这里想念什么？

14 version-control  git  github  team-foundation-server 

我已经在该框架之上编写了一个PHP框架和一个CMS。CMS依赖于框架，但是框架作为CMS文件中的自包含文件夹存在。我想将它们作为单独的项目维护在GitHub上，但是我不想在每次更新框架时都有更新CMS项目的麻烦。理想情况下，我希望CMS以某种方式将框架文件包含在预定义的子目录中，而不是物理地提交这些文件。 Git / GitHub有可能吗？如果是这样，我需要知道什么才能使其正常工作？请记住，我对Git有非常非常基础的经验-我可以使用Eclipse的Git插件制作存储库并提交，连接到GitHub，就这样。我目前正独自从事这些项目，因此到目前为止，我还不需要了解更多有关Git的信息，但是我希望将来向其他人开放它，我想确保自己做对了。 另外，对于具有依赖性的项目，理想的工作流程应该是什么？任何有关该主题的技巧也将不胜感激。如果您需要有关我的设置的更多信息，请在评论中提问。

14 php  git  github  dependencies 

假设我有一个包含多个组件的项目：服务器组件，Web应用程序组件，iOS组件，Android组件等。这些组件都是单独的代码库，但也松散耦合（例如，对服务器的更改）代码也可能需要更改所有其他组件） 在Git中组织此项目的最有效方法是什么？如果将所有内容放在一个存储库中，则始终会拥有最新版本，但是当您开始更改一个组件而不是其他组件时，事情变得很混乱。 另一方面，如果将每个组件都作为一个单独的存储库，则如何“链接”这些存储库，以使您知道该应用程序的2.0版要求服务器组件的1.5版等？ 除了保持最新的自述文件（或者我看不到的更好的解决方案）之外，git中是否还有功能可以更有效地管理多个相关的存储库？

14 git 

在通常称为Git-flow模型的修补程序中，修补程序进入其特定hotfix-*分支，而在发布之前的小型集成修补程序也进入该release-*分支。以前版本中的常规错误修正似乎没有位置。 它们应该出现在哪里？它们是否应该在自己的bug-*分支中分支develop（就像feature分支一样）？

14 git  gitflow 

我们是一家小型公司，拥有多个团队管理自己的git存储库。这是一个Web平台，每个团队的工件都在一天结束时部署以进行夜间测试。我们正在尝试使围绕版本控制和打包的过程正式化。 每个团队都有一个主分支，负责日常开发。每个团队的质量保证成员都希望将他们团队变更中的工件部署到测试台中，由厨师将所有组件组合在一起。工件是压缩包，但我想将其转换为RPM，以便我们可以正确思考和推理版本。 发布过程涉及从每个git存储库的开发分支（在大多数情况下为master）切断发布分支。然后将其提供给质量保证，由质量保证对一组工件进行测试和签核。 例如，这是一个典型的git存储库及其相关的发行分支： 0-0-0-0-0-0-0-0-0-0 (master) | | 0 0 (rel-1) | 0 (rel-2) 我一直在试图找出一种方案来执行来自开发分支的软件包的版本控制。我们不想过多地标记每个仓库的主分支，并限制标签仅释放分支。但是我们应该能够使用标准的yum / rpm语义查询测试机器中已部署的软件包。当master分支没有标签时，开发版本会是什么样？我知道这git describe可以为我提供构建版本的有用表示，但是当标记分支上的各个发行点时，它可以很好地工作。 编辑1：响应@ Urban48的答案 我认为我应该多解释一下发布过程。为了便于讨论，我们假设master在所有存储库中都有分支。该master分支被视为开发分支，并且已部署到支持CI-CD的自动化QA环境。这是每晚测试的子集，用于确保主服务器的稳定性。在削减发行分支之前，我们先看一下这一系列工作。我们的发行分支是短暂的。假设（从稳定的主服务器上）剪切了一个发布分支之后，将运行完全回归，进行修复并将其部署到生产中。这大约需要一周的时间。我们几乎每两周发布一次产品。 我们的功能分支总是从母版中剪切下来的，并在与母版合并之前经过一定量的开发人员测试，然后对它们进行CI-CD稳定性检查。 修补程序是在修补程序分支（从发行版分支切下的）上进行的，并以最小的影响测试将其部署到生产环境中。 以下是我们针对发行版和修补程序分支的版本控制策略。在质量检查周期中，发行分支会经历的版本v2.0.0-rc1，v2.0.0-rc2最后在质量检查批准后变为v2.0.0。 有时，我们会针对一些小功能进行点发布，这些小功能会合并到版本变为的版本分支（然后合并到母版）中v2.1.0。修补程序采用该v2.1.1模式。 但是，问题不在于对这些分支进行版本控制。我不希望完全更改此版本控制方案。唯一的变化来自开发部门。主。如何在CI-CD环境中可靠地指示在生产中的先前发行版中存在哪个版本。理想情况下，这可以通过智能git标记完成，但最好不要过度标记master分支。

13 git  continuous-integration  versioning  release-management  packages 

我对Git经验不足，但是我会尽力去适应它，到目前为止，我只是将它用于我自己从事的项目。 当我编写代码时，自然会有一些自上而下的方法（因为我不知道未来），并且有一个重复出现的主题： 我做一些工作。 我发现要使我的工作变得“值得承担”，我需要做其他工作。 其他工作值得自己承担。 所谓可承诺的东西，是指可以编译的东西，或者不是完全混乱的东西。 通过某种值得它自己提交的东西，我指的是我了解到提交应该只做一件事。 我解决它的方法很麻烦。如果其他工作在另一个文件中，则我创建一个新分支，在那里提交并合并。如果工作在同一文件中.. ugh ..我进行本地复制并将文件重置为HEAD中的状态，进行所需的提交，然后开始从该副本恢复我的工作。我实际上应该如何处理？我没有想到这是这样吗？我不这么认为，因为它一定会经常出现在每个人身上（至少他们也不知道未来）。还是似乎我的工作流程可能有缺陷？

13 git 

我有一些网站都在共享托管下托管在同一网络托管服务上。我的网络主机支持Git，并且可以通过SSH进行访问，并且我的笔记本电脑上也具有Git设置。 我想这样做，以便当我执行“ git push origin master”时，它将自动更新Web服务器上的文件，并且还保存以前提交的文件的备份，以便我可以轻松回滚。这可能吗？

13 git  web 

我的目标是检查不满足某些要求的提交数据，然后拒绝正在创建或推送到远程存储库的提交。 进行预提交挂钩的问题在于，很难将其部署给许多必须手动更新其预提交挂钩文件的人。同样，Git不允许您在.git文件夹中包含子模块，这对部署来说非常容易，可惜。 我看到的另一个选择是进行检查，我相信远程的更新挂钩，它将检查开发人员推送的每个提交，如果任何提交未通过测试，则拒绝该推送。 有人对此问题有见识吗？如果是这样，您能否提供或指出一个示例更新挂钩脚本？我对它的工作方式有些困惑。

13 git