Let me know if there is any effective work around.Īnd that changing the base(the first answer to this question), didn't work for me. I think I'm gonna follow this procedure, which seems to work for me. Until GitHub fixes the issue with PRs in Desktop application. Delete the " feature-merge-to-testing" branch once done.Raise a PR now against the testing branch.Cherry-pick those commits onto " feature-merge-to-testing".Create a branch from testing name it " feature-merge-to-testing".Now the work around for GitHub Desktop Users: You may get confused if there areĪ lot of commits. If you have countable commits (4-5 max) on your feature branch, only I use GitHub Desktop app and this happens to me more than often and I couldn't do anything about it until today. This is frustrating and my colleagues don't face this issue because they use command prompt. The problem arises for me when I merge master into my feature branch, then work and commit into my feature branch and when I raise a PR against testing, it shows changes that are already in testing again. Testing branch would already have master changes. I'll consider 3 branches, master, testing, feature. Lastly, push the changes to remote using git push origin new-branch-name and create a pull request.If you run git log on this new branch which you created, you can see that only the changes you have added exist after your target branch's head, as expected.You can do this multiple times, changing the id each time to get another commit. On the new branch, do git cherry-pick commit-id where commit-id is the long number that you copied from git log which identifies the commit you want to push.Create a new branch from your target branch (e.g main) using git checkout -b new-branch-name when you are on the target branch.The commit IDs are the long numbers that each commit contains. You can scroll through the git log output using the up/down arrows on the keyboard. if the branch name is tangled, do git checkout tangled and then git log. checkout the branch where you made changes and copy the commit IDs of the commits you want.Update your local target branch using git pull.If the rebase process gets to tangled up for you as it did for me, another option is to use git cherry-pick. Then create a new branch with what you've just stashed. Example if I had 4 commits that weren't in my PR that got squash merged then I'd do: On your local main, undo and stash all changes that haven't been merged with main. GitHub can't tell that the squashed commit is identical the sum of the non-squash commits and causes an extra diff. It's worth noting that this isn't a git problem. But then on GitHub I see more changes than I expect. Locally while I'm still on featureBranch I merge it with main.This happens because a problem in how GitHub shows squash merged changes. the diff on GH was much closer to what I changed.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |