Questions tagged «workflows»

我已经思考了很长时间，却没有找到最佳答案。 首先，我是一位热爱编程的医生，但从未真正地学习过它，除了在家学习和在业余时间玩代码很多年之外。 目前，我正在尝试建立一个小型项目来管理我的诊所，为此，我首先创建了一个我希望能够做的选择列表。 例： 活跃的患者记录。 具有不同角色（例如，患者，护士，博士）的身份验证 预约时间表（包括日历，定期接种疫苗/手术等，并带有提醒） 允许医生创建自己的插件。 仪表板，供医生查看其统计信息 然后，我开始使用codeigniter / mysql / php / jquery并开始编码。 我在开发过程中的步骤：- 第一个数据库。 首先创建所有需要的表。 创建了我所有的模型来处理这些表（1个主模型，在处理基本读/写/更新/验证的同时还考虑了我的表关系 之后，我开始为视图和控制器编码。我首先创建了视图HTML，然后创建了将处理该视图的控制器，并开始编写函数以使视图交互有效。 编写约会视图时的示例（控制器booking.php）： 当用户单击时，创建此布局并使表td可单击：jquery get（booking / add_ Patient_form）并弹出它 用户保存时：发布到预订/保存-保存约会，然后重新加载index（）函数 等。我继续执行创建视图的相同步骤，然后创建其控制器-包含该视图所需的所有逻辑-完成整个项目。 最后，我所有的目标功能都运行良好，但是由于从一开始就没有PLAN，而且由于整个项目都是脑力激荡和调试，没有任何计划，所以在完成该项目后，我发现自我维护性和灵活性！并且无法将它们链接在一起。 我感觉到网站上的每个页面都是彼此完全隔离的，我什至不记得每个页面的加载方式和内部的功能，而不会偷看！ 无论如何，我可以恢复它并进行设计吗？

18 php  mysql  design-patterns  workflows 

我已经将我的几个项目迁移到git flow工作流程中，并且我很喜欢它。但是，我还没有找到一种最佳实践来使一个项目同时维护一个以上的主要版本，从而使事情顺利进行。 具体来说，我不是在维护“免费版本”和“付费版本”或任何其他并行模型，我是在谈论一个项目，其中发布了版本1，并且仍支持次要版本（1.1、1.2等） 。），直到发布了第3版为止，此时将维持第2和第3版，直到第4版发布为止。 您如何或将如何在gitflow工作流程中一次维护一个项目的两个或多个受支持版本？

18 git  workflows  gitflow 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 当您中断某些代码的工作时（是因为您必须进行其他工作或去度假，或者仅仅是因为一天结束），一旦关闭该Visual Studio项目，您记住的首选方式是当您再次开始处理该代码时，下一步要做什么。 您设置Visual Studio书签还是写下类似的内容// TODO: continue here next time？也许您有一个特殊的标签，例如// NEXT:？您在显示器上贴了便签吗？您使用我应该知道的很棒的工具还是Visual Studio插件？ 您是否有任何个人技巧可以帮助您在代码中找到上次使用代码的地方？

18 tools  workflows  visual-studio-2010 

我们的团队刚刚从FogBugz＆Kiln / Mercurial转到了Jira＆Stash / Git。我们使用Git Flow模型进行分支，从功能分支添加子任务分支（与Jira功能的Jira子任务有关）。当我们创建一个合并到父分支的拉取请求时，我们使用Stash来分配一个审阅者（通常是开发，但是对于子任务来说是返回到功能分支）。 我们发现的问题是，即使对功能用例进行了最佳的规划和分解，当多个开发人员一起使用同一个功能时，例如在前端和后端，如果他们正在使用相互依赖的代码，在一个单独的分支中，一个开发人员最终阻止了另一个。 随着我们的发展，我们尝试在彼此的分支机构之间拉动。我们还尝试了创建本地集成分支，每个开发人员可以从多个分支中提取它们以在开发时测试集成。最后，这似乎到目前为止对我们来说是最好的，尽管开销更大，我们尝试立即从功能分支创建一个集成分支。当子任务分支（不在功能分支中）准备好进行拉取请求和代码检查时，我们还将手动将这些更改集合并到此功能集成分支中。然后，所有感兴趣的开发人员都可以从该集成分支拉到其他依赖的子任务分支。这样可以防止任何人等待他们依赖的任何分支通过代码检查。 我知道这不一定是Git问题-它与在多个分支中处理相互依赖的代码有关，并与我们自己的工作流程和文化相结合。如果我们没有用于开发的严格代码审查策略（真正的集成分支），则开发人员1可以合并以进行开发，以供开发人员2退出。另一个复杂的问题是，在将功能交付给QA之前，我们还需要在代码审查过程中进行一些初步测试，这意味着即使前端开发人员1正从后端开发人员2的分支直接拉出如果后端开发人员2完成并且他/她的拉取请求在代码审查中待了一周，那么前端开发人员2从技术上讲就无法创建他的拉取请求/代码审查，因为他/她的代码审查者无法测试，因为后端开发人员2' 最重要的是，在这种情况下，我们发现自己采用的是串行方式而不是并行方式，这取决于我们走的路线，并希望找到一种避免这种情况的过程。 我要提到的最后一件事是，我们通过在尚未经过代码审查和定稿的分支之间共享代码来实现，但实际上我们是在使用其他Beta代码。在某种程度上，我认为我们无法避免，并且愿意在一定程度上接受这一点。

17 git  workflows  branching  jira  gitflow 

前提条件 团队使用DVCS IDE支持注释解析（例如TODO等） 诸如CodeCollaborator之类的工具预算昂贵 诸如gerrit之类​​的工具过于复杂，无法安装或无法使用 工作流程 作者在中央回购功能分支上的某个位置发布 审阅者获取它并开始审阅 如果有任何问题/评论，请创建带有特殊标签的评论，例如“ REV”。此类标签不得在生产代码中-仅在审核阶段： $somevar = 123; // REV Why do echo this here? echo $somevar; 当审阅者完成评论后，它只会发送愚蠢的消息“ comments”并向后推送 作者将功能分支拉回并以类似方式回答评论或改进代码并将其推回 当“ REV”评论消失时，我们可以认为，该评论已成功完成。 作者以交互方式为功能分支重新设置基础，挤压功能分支以删除那些“注释”提交，现在可以合并功能以开发或进行任何成功的内部检查后通常可以采取的操作 IDE支持 我知道，自定义注释标签可以在Eclipse和Netbeans中使用。当然，它也应该属于blablaStorm家族。 问题 您认为这种方法可行吗？ 你知道类似的东西吗？ 有什么可以改进的吗？

16 teamwork  code-reviews  workflows  dvcs 

我正在研究一种方法，以更好地理解采用scrum方法的持续集成工作流程如何更好地适合于软件开发公司。 我在想这样的事情： 那将是一个不错的工作流程吗？

16 testing  development-process  scrum  continuous-integration  workflows 

我目前正在与一个使用git工作流程的团队一起进行项目。这非常简单，master应该处于可部署状态，并且分支用于创建功能和修补程序。每当我们完成并测试了功能或错误修正后，我们就会尽快将其移交给母版。想法是分支应该尽可能小，以使其更易于合并回主节点。我们有一个政策，即任何推送到master分支的代码都应处于可部署状态并通过测试。 我们遇到这样的情况，其中一个开发人员在一个分支上做了很多工作（几个月的价值），而这个分支还没有被合并回master。现在，该分支上有一些单独的功能和大量提交，实际上，该分支确实应该已经合并了几次，但到目前为止还没有合并。大多数代码处于良好的状态，可以将单元测试合并回到主测试中，但是最近的更改肯定不应该如此，因为它们尚未完成且未经测试。 处理这样一个分支实际上与另一个分支相距甚远的情况的最佳方法是什么？将来，我们可以通过哪些方式避免分支从master获得大量提交？

15 git  workflows 

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

15 project-management  git  workflows  forking 

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

15 git  workflows  dvcs 

奇怪的标题，是的，但是我认为我有足够的基础要掩饰。 我们在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 

我编写了许多（主要是c ++和javascript）代码，涉及计算几何和图形以及此类主题，因此我发现视觉图表已成为解决问题过程中不可或缺的一部分。 我现在已经确定，“哦，如果我能以某种方式将手绘图附加到一段代码上作为注释，那岂不是太棒了”，这将使我回到自己从事的工作上，数天，数周，数月之前，并且可以更快地重新获得我的算法。 作为一个视觉学习者，我觉得这几乎可以通过每种类型的编程来提高生产率，因为简单的图表可以帮助您理解和推理任何类型的非平凡数据结构。例如图表。在大学的图形理论课上，我只能真正理解我可以实际绘制的图形表示形式的图形关系。 所以... 据我所知，没有IDE可让您将图片保存为代码注释。 我的想法是，我或其他人可以提出一些合理易用的工具，该工具可以将图像转换为base64二进制字符串，然后将其插入代码中。 如果转换/插入过程可以简化，这将使图表与实际代码之间的连接更好，因此，我不再需要按时间顺序搜索笔记本。更棒的是：IDE的插件可以自动解析并显示图像。从理论的角度来看，这绝对没有困难。 我的猜测是，我将需要花费一些额外的时间才能真正弄清楚如何扩展我最喜欢的IDE并维护这些插件，因此，我对一种可以进行相同解析和解析的代码后处理器感到非常满意。渲染图像并在浏览器或其他内容中与代码并排显示。由于我是一名JavaScript程序员。 人们怎么看？有人愿意为此付费吗？我会。但是我也许还会指出，无论我本人还是同龄人中的很多人愿意为这种事情付出代价，这种事情可能成功的唯一途径就是通过开源发行。

14 productivity  code-reviews  comments  workflows  image-manipulation 

通常，当我编程时，我要完成一个明确的任务，但是会发现我想继续进行的烦人的事情要清理。 在这里，我看到三个选项： 以后再做（可能会忘记/不得不花费时间添加票证） 现在就做，并将其与我当前的工作一起提交（不清楚） 现在执行并分别提交（必须找到它，可能会犯一个错误，无意中选择了选项2） 这可能是相当基本的，但是有什么方法可以使用svn / git / other来规避呢？

12 version-control  git  svn  workflows 

我是开源世界的新手。我正在从事的项目位于Github上。（仅供参考）我正在处理的项目是Plex Media Server的插件。我计划将插件提交给Plex，以便将其包含在他们的“应用程序商店”中。现在我的问题。 刚开始时，我发现了一个较旧的半废弃插件，可以满足我的要求，但效果不佳。我首先为该回购做贡献。我立即被选为拥有该回购协议全部权利的协作者，因为当前所有者说他太忙了，无法再使用它了。但是，当我开始更深入地研究代码时，我意识到它是徒劳的。现有的代码库很糟糕，没有有效的方法来修复它。我最终只是从头开始。我在新插件中使用的唯一代码是我最初提交的代码。 现在该项目已准备好发布。但是，我不确定如何执行此操作。我看到的选择如下： 创建一个新的仓库，而忽略现有仓库。我不确定我是否应该提到以前的仓库和它的贡献者。我没有使用任何代码/资源，而是创建了一个全新的代码库。尽管该插件执行的功能与旧的相同，但它以全新的方式和更有效的方式进行了操作。 我分叉现有的存储库，删除现有的代码，然后提交新代码。我真的是Git的新手，所以我不确定这是否可行。 我将对现有回购的更改提交给我，看看当前的贡献者怎么说。 在这三个选项中，我强烈倾向于第一个。但！我是开源的新手，我想确保自己按照正确的礼节做事。我不想让我的第一个项目浮出水面，成为一场灾难。选项2听起来不错，但是我不确定是否应该这样做。我不确定历史记录和差异会如何工作。我们最多只谈论500-1000行代码。因此，这不是一个庞大的代码库。 感谢您提供的任何输入！

12 open-source  github  workflows  etiquette 

我正在尝试提出一个个人工作流程。我整理了一个发行版的假设生命周期的流程图：一个开发人员推向公开的github repo +一个帮助提供某些功能并修复bug的朋友。 这是版本控制的合理方法吗？ 主要思想是保持公共仓库整洁： 每个新版本都会进入自己的分支，直到完成后最终在master分支中对其进行标记。 为了防止异常，所有工作都在“功能”或“修补程序”分支上进行，而不是在实际的发行分支上进行。 合并到更高级别的分支总是要重新设置基础或进行压缩（以避免混乱）。 如果这太过猛烈，我不介意，因为对我而言，重点就在于学习大型项目可能需要的技能。唯一的问题是，如果我在做完全错误或不必要的事情。 编辑2：修正原始流程图中的错误主意，并使它更易于浏览。

12 project-management  programming-practices  version-control  git  workflows 

使用git，maven和jenkins进行以下操作的首选方式是： 我正在开发一个应用程序，我想维护它的“ dev”和“ release”分支。我希望詹金斯同时建立两者。发行工件可能具有1.5.2之类的版本，而dev-builds仅为0.0.1-SNAPSHOT。我不想有2个不同的pom.xml文件。 我查看了配置文件，但是它们似乎无法更改工件版本。我研究的一种方法可能是在测试版本中添加“限定符”。当然，我可以重命名该文件，因为关于此的真实工件信息并不重要，因为该应用程序是独立的。 这样做的首选方式是什么？还是您会怎么做？

12 git  workflows  versioning  jenkins  maven