1

I have a GitHub fork with an additional branch for a pull-request purpose.

I want to keep this branch integrated by merging from master often (I keep my master branch fresh by pulling from the upstream repo).

If I just merge from master, all pulled commits are squashed into a single merge commit.

Will it break my pull-request or will GitHub still be able to diff properly? And if it does break, is there any other suggestion on keeping my pull-request branch integrated?

Thanks!

yurmix
  • 852
  • 2
  • 8
  • 21

1 Answers1

0

normally, you should keep merges out of feature branches (might consider rebasing instead). if you create a pr, they will probably ask you to clean up history before accepting it. This might help you do just that with somewhat little effort when you want to squash/update before creating the pr: How to squash/rebase in a single shot

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • My purpose is to create a CI enviroment on my side, so to avoid finding breaking changes at the last minute. Since the pr review process can take weeks and meanwhile my code is not being tested against newly merged code, I'm faced with this issue. Do you suggest that I merge from the feature branch to my local master repo and not the other way? – yurmix Feb 25 '19 at 23:59
  • I wish I understood all that you said. There are basically two techniques to get changes together from two branches that have diverged.... one is the one you are using: merge. This brings together the changes from both branches on a single shot at the cost of creating a merge revision which gatekeepers tend to like to get rid of when the time to merge a PR come. The other technique is "rebasing". Exactly the same result (bringing the changes from both branches together) with the _advantage_ of not creating a merge revision. – eftshift0 Feb 26 '19 at 00:07
  • This might help you get the big picture: https://www.atlassian.com/git/tutorials/merging-vs-rebasing – eftshift0 Feb 26 '19 at 00:09