假设我是回购的维护者,并且我想从贡献者那里获取更改,那么有一些可能的工作流程:
cherry-pick每个都从远程提交(按顺序).在这种情况下,git将提交记录为与远程分支无关.merge是分支,拉入所有更改,并添加新的"冲突"提交(如果需要).merge各自从远程分支单独提交(再次按顺序),允许为每个提交记录冲突,而不是将所有冲突组合为一个.rebase(与cherry-pick选项相同？),但我的理解是,这可能会导致贡献者的混淆.也许这消除了选项1.在情况2和3中,git记录了提交的分支历史记录,与1不同.
使用任何一种方法cherry-pick或merge描述的方法之间有什么优点和缺点？我的理解是方法2是常态,但我觉得用单个"冲突"合并解决大型提交并不是最干净的解决方案.
我有一个从原始项目分叉的大型代码库,我正在尝试追踪与原始项目的所有差异.许多文件编辑包括注释掉的调试代码和其他杂项注释.在Ubuntu下名为Meld的GUI差异/合并工具可以忽略注释,但只能忽略单行注释.
有没有其他方便的方法来查找非注释差异,使用GUI工具或Linux命令行工具？如果它有所不同,代码是PHP和Javascript的混合,所以我主要感兴趣忽略//,/* */和#.
我对手动合并拉取请求的正确方法感到困惑，并理解为什么对此有不同的建议。
假设最简单的情况：一个master（长期存在的）分支和一个feature具有多个提交的单个分支，针对这些提交发出了拉取请求，但显示与主分支的合并冲突。
GitHub 说要做：
git fetch origin
git checkout -b feature origin/feature
git merge master
进而
git checkout master
git merge --no-ff feature
git push origin master