No Comments Yet
Be the first to share your thoughts and start the conversation.
Pull Request
Loading...
Loading...
Loading...
0 Comments
GSAP Course launch discount ends soon!🎉
Claim Discount
GSAP Course launch discount ends soon!🎉
Claim DiscountBe the first to share your thoughts and start the conversation.
How did you manage to remove the blur property and reach here?
Upgrading gives you access to quizzes so you can test your knowledge, track progress, and improve your skills.
By logging in, you'll unlock full access to this and other free tutorials on JSM Pro.
Why? Logging in lets us personalize your learning experience, track your progress, and keep you in the loop with new workshops, coding tips, and platform updates.
You'll also be the first to know about upcoming launches, events, and exclusive discounts.
No spam—just helpful content to level up your skills.
If that sounds fair, go ahead and log in to continue →
Enter your name and email to get instant access
In this lesson, we explored the process of using pull requests (PRs) in GitHub to facilitate team collaboration on code changes. A pull request allows team members to review changes, provide feedback, and ensure that code merges are seamless and organized.
git pull to reflect updates.00:00:00Â A pull request lets you share your changes with your team for review and feedback.
00:00:06Â Once approved and merged, your changes become a part of the main branch, keeping the codebase stable and organized.
00:00:14Â To open up a pull request, you can click this button right here, compare and pull request, or you can click this pull requests tab right here.
00:00:22Â Select new pull request.
00:00:24Â Select the branch you want to merge from, such as the feature branch, and then the branch you want to merge to.
00:00:31Â Here, you can see all the changes you implemented.
00:00:34Â In this case, we have added one line of text.
00:00:37Â If the changes look good, you can click create pull request.
00:00:40Â If needed, modify the title and describe what your PR will do in more detail.
00:00:46Â And then select create one final time.
00:00:48Â There we go.
00:00:49Â Now your team lead or senior dev can review your PR and give you feedback.
00:00:54Â And if everything looks good and there are no merge conflicts, they can merge it.
00:00:59Â In this case, reload the browser and let's merge it ourselves.
00:01:03Â Yes, we're sure.
00:01:04Â Confirm merge.
00:01:06Â This is where the magic happens.
00:01:09Â Your feature will now seamlessly get merged into the main branch.
00:01:13Â Easy, right?
00:01:14Â So if we go back to code, you can see that we're now on the main branch and we can see the change from the feature branch.
00:01:21Â So why does it still say that we have two branches?
00:01:24Â Well, no worries.
00:01:26Â Once you merge a PR from a specific branch, GitHub and Git still leave it here for you.
00:01:31Â But they tell you that you're one commit behind main and zero commits ahead.
00:01:37Â Which means that everything this branch was supposed to do in this single commit has been done.
00:01:42Â And it has no additional code that you might want to merge.
00:01:45Â So it's safe to say that we can delete it.
00:01:48Â Now, if you go back to code, you can see that there is only one branch, that's the main branch, and it contains the newly merged changes.
00:01:55Â Easy, right?
00:01:57Â This is how teams collaborate without breaking each other's code.
00:02:01Â By doing this, GitHub is essentially executing a Git operation in the background.
00:02:06Â A command that you can do on your own by running git merge and then choose a branch that you want to merge.
00:02:12Â But I typically prefer doing this using GitHub's BRs.
00:02:16Â Now, if we switch back to our local repo and navigate to the main branch, do you think we'll be able to see the changes we just merged?
00:02:24Â Well, let's try.
00:02:25Â Do you remember the command to switch back to main?
00:02:28Â Well, it's git checkout and then main.
00:02:33Â There we go.
00:02:34Â We switched to main and it says it's up to date with origin main.
00:02:38Â So if we had to read me, wait, this doesn't look good.
00:02:42Â It doesn't contain this new line that we added right here.
00:02:45Â And that's because the merged happened on the remote repository, which makes sense, right?
00:02:50Â So how do we bring those changes into our local repo?
00:02:54Â Simple.
00:02:55Â We need to pull them into this branch by running git pull.
00:03:01Â There we go.
00:03:01Â It pulled changes from a remote repo, and we can see them right here in our local one.
00:03:06Â The command we just ran, git pull, is just a shorthand for git pull origin main.
00:03:12Â But by default, GitHub pulls from the remote origin from the same branch you're currently on, so just git pull is fine.
00:03:20Â So, let's repeat things.
00:03:22Â Here is the typical workflow you'll follow most of the time.
00:03:26Â First, clone the repo.
00:03:28Â Second, create a new branch from the main or another branch.
00:03:33Â Third, make your changes.
00:03:35Â Fourth, push the branch to the remote repository.
00:03:38Â Sixth, open up a pull request.
00:03:40Â Seventh, merge the changes.
00:03:43Â Eighth, pull the merge changes into your local main branch, and then repeat from step two.
00:03:49Â You can also find these steps alongside some additional explanations within the Git reference guide.
00:03:55Â So, great job learning about branching.
00:03:58Â I hope this was intuitive, but next, we'll focus on a scary topic, which is resolving merge conflicts.
00:04:06Â something that not a lot of people teach you, but you and I will dive deep into it.
