我经常犯这个错误,想知道是否有更好的解决方案,以及我的当前解决方案是否存在风险。
以下是工作流程:
1. git checkout master 2. git pull 3. git submodule update --init --recursive 4. (编辑、调试、测试) 5. git commit -a 6. git push origin HEAD:refs/for/master 7. (更多编辑、测试等) 8. git commit -a 9. gitk 10. (咒骂) 11. git rebase -i HEAD~2 #将我的两个提交合并 12. git checkout -b task_id 13. git checkout master 14. git rebase -i HEAD~2 #选择先前用户的提交,删除自己的提交
我的错误在于,在第5步左右,我应该像第12步那样创建一个新分支,将这项工作与其他所有任务分开,以便我可以轻松地回到它或按所需顺序重新基于不同的补丁。相反,我将新代码推送到主分支,大约在第10步时,我意识到master不再指向公司批准的最新版本,而是指向我的努力。因此,在使用交互式rebase将自己的提交压缩为一个后,我又进行了另一个交互式rebase,将master指向它应该指向的东西--即已通过审查流程的其他人的工作。
编辑以澄清:当我“推送到主分支”时,这不会将我的更改发布给其他人。有一些提交钩子魔法会创建一个Gerrit代码审查任务,只有在从那里获得批准后,我的提交才会合并到远程存储库中。对于误导您所有人,我表示歉意。我的问题是双重的。这种做法有多糟糕,存在哪些风险,如何改进?我不是要求帮助避免最初的错误。我认为我只需要更加注意我正在推送到哪个分支。问题是如何最好地将master指向先前的提交,而不影响/冒险/丢失任何内容。
以下是工作流程:
1. git checkout master 2. git pull 3. git submodule update --init --recursive 4. (编辑、调试、测试) 5. git commit -a 6. git push origin HEAD:refs/for/master 7. (更多编辑、测试等) 8. git commit -a 9. gitk 10. (咒骂) 11. git rebase -i HEAD~2 #将我的两个提交合并 12. git checkout -b task_id 13. git checkout master 14. git rebase -i HEAD~2 #选择先前用户的提交,删除自己的提交
我的错误在于,在第5步左右,我应该像第12步那样创建一个新分支,将这项工作与其他所有任务分开,以便我可以轻松地回到它或按所需顺序重新基于不同的补丁。相反,我将新代码推送到主分支,大约在第10步时,我意识到master不再指向公司批准的最新版本,而是指向我的努力。因此,在使用交互式rebase将自己的提交压缩为一个后,我又进行了另一个交互式rebase,将master指向它应该指向的东西--即已通过审查流程的其他人的工作。
编辑以澄清:当我“推送到主分支”时,这不会将我的更改发布给其他人。有一些提交钩子魔法会创建一个Gerrit代码审查任务,只有在从那里获得批准后,我的提交才会合并到远程存储库中。对于误导您所有人,我表示歉意。我的问题是双重的。这种做法有多糟糕,存在哪些风险,如何改进?我不是要求帮助避免最初的错误。我认为我只需要更加注意我正在推送到哪个分支。问题是如何最好地将master指向先前的提交,而不影响/冒险/丢失任何内容。