什么是适当的礼节和推荐的GitHub工作流程，以同时促进上游回购和从上游回购回馈？
我是GitHub和VCS的新手。我多年来一直使用各种语言进行编程，但是我一直在自定义项目（未公开发布）中一直独自工作。我最近开始在我正在研究的项目中使用从GitHub下载的jQuery UI小部件。该存储库不再由原始作者维护。另一个fork已合并了一些原始的请求请求。这是我分叉的那个。 我发现了几个错误，并提出了相应的修复程序。我想提供这些修复程序，但是我还想作很多其他更改，供我们自己使用，这些更改将破坏某些现有功能。另外，我想从另一个分支中引入一个想法。 我仍在学习GIT和GitHub，并试图找出解决所有问题的最佳方法。我已经阅读了很多有关不同概念/任务的文章（在这里，SO，GitHub帮助页面，Pro Git）：工作流，合并，拉取请求，挑选，重新设置，分支。我的灰质是游泳，所以我需要开始这样做，这样我才能更好地了解自己阅读的内容。 主要问题： 我想（在某处）我读到您一次只能在一个分支上有一个请求请求。那么这是否意味着我应该为每个错误提供一个单独的分支，然后为每个错误执行一个单独的提取请求？ 我想清理空白问题，而且我似乎还记得读过，最好在单独的提交中执行此操作。我应该在我的主数据库还是在另一个分支中进行此操作？我不想对如此琐碎的事情进行拉取请求，但是如果我在分支之前进行空格更改，这会影响对错误修复的拉取请求吗？一些fork进行了空格清理，这实际上使diff变得毫无用处。 我当时想用叉子创建问题，以作为记录bug的一种方式，即使我已经针对它们进行了修复。这是一个好主意吗？如何将问题，提交和合并合并到主节点？如果我向上游发出拉取请求，我的问题也会出现在上游还是会丢失该文档链接？我无法针对上游仓库打开问题（没有问题标签）。 在我想使用他的想法时，最好的办法是赞扬另一个叉子作者？我无法完全使用他的代码，尤其是因为他的更改是针对较旧版本的上游应用的，并且与我的其他更改不兼容。但是我想用这个主意，我想在应得的信贷额上给予好评。我应该只在提交消息中链接到他的回购（或个人资料或特定提交）吗？ 更改自述文件和主文件顶部的DocBlock的礼节是什么？可以进行更改，添加我的名字，添加指向我的repo和演示的链接，删除指向原始演示的链接（因为我的fork最终将与原始版本不兼容）吗？当然，我将保留原始作者姓名和许可证信息。作为记录，它已获得MIT许可。 作为从未使用过VCS的独立开发人员，我习惯于重写历史记录。我是一个完美主义者，喜欢事物要整洁。记录历史的想法使我有点紧张，我想第一次做对。我创建了一个新的供您玩耍/学习的仓库，但是我急于继续固定jQuery UI小部件，以便继续进行我的项目。