Enter Your Email Address to Watch This Lesson

Your link to unlock this lesson will be sent to this email address.

Unlock this lesson and all 905 of the free egghead.io lessons, plus get JavaScript content delivered directly to your inbox!



Existing egghead members will not see this. Sign in.

Just one more step!

Check your inbox for an email from us and click link to unlock your lesson.



Getting a Pull Request Merged and Wrapping up

1:13 JavaScript lesson by

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.


egghead.io comment guidelines

Avatar
egghead.io

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.

Avatar
David

I really love this series, especially with the very real repo for us to practice. Sometimes, even for people very experienced with dev, it's nice to have a "best practices" course so we are aware of how to respect others' projects and contribute in a way that is easiest for the very busy maintainers. Cheers!

In reply to egghead.io
Avatar
Khaled

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 ?

Avatar
Kent C.

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/

In reply to Khaled

Our pull request has been merged. It's time to celebrate.

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.

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.

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.

That's our series. I hope you enjoyed it.

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.

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.

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.

Thank you for watching this series.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?