Getting a Pull Request Merged and Wrapping up
Let’s look at the GitHub commits and list of contributors now that our pull request has been merged. And we’ll wrap this series up with a few tips. Feel free to practice on stack-overflow-copy-paste, and see the Pull Request demonstrated in this lesson here.
[00:00] Our pull request has been merged. It's time to celebrate.
[00:03] Let's take a look at the commit history to make sure that our commit is in there. We can see that our commit is here, but we'll also notice this merge commit here.
[00:11] When the project maintainer clicks the green merge button, GitHub runs a git merge command, but it adds a flag to the command which essentially forces a new commit to be created for the merge. Never fear, though. Your work is in the project as you made it.
[00:24] Now, let's look at the contributors graph. For this project, I actually am the only one who's made any changes, but after your pull request is merged you'll see a card representing your contributions, as well.
[00:34] That's our series. I hope you enjoyed it.
[00:36] Before we wrap up, I want to say that most of the Git commands that we have executed in this series are just one way to accomplish the same task. Git is a huge subject which I am unable to cover in depth for this series.
[00:48] There are many ways to do the same thing in Git, so I recommend you spend some time learning this ubiquitous source control management software.
[00:55] I also want to invite you to contribute to this repository, stack-overflow-copy-paste if you want to try this out. I don't expect anyone to actually use this module, but if you want to have a friendly place to practice feel free to file issues and pull requests. I would be more than happy to give you direction.
[01:12] Thank you for watching this series.
I'm glad you like the series! You're right to be concerned about force pushing. It can be dangerous and it can mess up semantic-release. But this is only true when you force push to the master branch. You can force push to any other branch just fine and because semantic-release doesn't do anything with those branches, it doesn't make a difference.
As a related note, I recommend that you protect your master branch from force pushes: https://help.github.com/articles/about-protected-branches/
Love this series, because of this series I filed my first issue on GitHub and I plan on creating my own repo. Thanks!
Thanks for the series!
This series is great! Kent you continue to impact some invaluable knowledge. I have been using OSS for years now and I took your advice to contribute and give back to the community. I just opened my first PR for code sandbox for I used almost everyday nowadays. This year is the year to start giving back to the community and get my name out there on the map. Cheers!
Love the serie, thanks a lot . But I have a small question, when forcing push, won't this break semantic release process and require you to make a manual publish ?