git 工作流程包含来自许多分支的许多（但不是全部）提交
我有一个 git 仓库。它已经被分叉了好几次，并且在它之上进行了许多独立的提交。一切正常，就像许多 github 托管项目中发生的情况一样。
现在，如果我想查看所有单独提交的内容并应用我喜欢的内容，我应该遵循什么确切的工作流程。
我遵循的工作流程（这不是最佳方案）是创建一个名为 github-username 的分支，并将更改合并到我的 master 中，并撤消我手动不需要的提交中的任何更改（数量不多，所以它有效）。
我想要的是能够单独查看来自不同分叉的所有提交，并挑选并将它们应用到我的主控之上。
为此要遵循什么工作流程？什么 gui（gitk？）使我能够看到所有不同的个人提交。
我意识到合并应该是工作流程的主要部分，而不是挑选，因为它创建了不同的提交（从 git 的角度来看）。即使在我的基础上重新调整其他人的更改也可能无法保留图表上的历史记录以表明我已经重新调整了他的提交。那么，我如何忽略其中许多提交的少数提交呢？
我认为 github 应该在每个提交节点之后的图表中添加一个“在我的 master 之上应用此提交”的内容；所以我可以在完成所有这些操作后拉它。
I have a git repo. It has been forked several times and many independent commits are made on top of it. Everything normal, like what happens in many github hosted projects.
Now, what exact workflow should I follow, if I want to see all that commits individually and apply the ones I like.
The workflow I followed, which is not the optimal is to create a branch of the name github-username and merge the changes into my master and undo any changes in the commit I dont need manually (there are not many, so it worked).
What I want is the ability to see all commits from different forks individually and cherry pick and apply them on top of my master.
What is the workflow to follow for that? And what gui (gitk?) enables me to see all different individual commits.
I realize that merge should be a primary part of the workflow and not cherry-pick as it creates a different commit (from git's point of view). Even rebasing other's changes on top of mine might not preserve the history on the graph to indicate that it is his commits I have rebased. So then, How do I ignore just a few commits from a lot of them?
I think github should have a "apply this commit on top of my master" thing in their graph after each commit node; so I can just pull it, after doing all that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这通常是您使用遥控器的目的。对于每个 fork，您可以添加一个新的远程：
git remote add; <网址>。然后您可以获取所有远程提交： git fetch。然后您可以在远程分支上使用任何您想要的可视化工具。就像你有 origin/master 一样，你也会有 /master。从那里，从不同的远程进行挑选就像从原产地的分支进行挑选一样容易。无论如何，原始远程都不是远程存储库的特殊情况。它恰好是您最初克隆的远程存储库的默认名称。如果您不喜欢名称来源，可以重命名它。
如果您不知道，所有 GUI 工具都可以让您看到的不仅仅是当前分支的历史记录。当你启动像 tig、qgit 或 gitk 这样的东西时，你只需要传递 --all 就可以让它向你显示它知道的每个分支，本地的和远程的。
This is usually what you'd use remotes for. For each fork, you can add a new remote:
git remote add <name> <url>. Then you can fetch all their remote commits:git fetch <name>. Then you can use any visualization tool you want on the remote branches. Just like you have origin/master, you'll have /master. From there a cherry-pick from a different remote is just as easy as a cherry-pick from a branch on origin.The origin remote isn't a special case of a remote repo in any way. It just happens to be the default name of the remote repo that you cloned from originally. It's possible to rename it if you don't like the name origin.
In case you don't know, all the gui tools let you see more than just your current branch's history. When you start up something like tig, qgit, or gitk you just need to pass --all to make it show you every branch it knows about, local and remote.