No Comments Yet
Be the first to share your thoughts and start the conversation.
Pull Request
Loading...
Loading...
Loading...
0 Comments
Be 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.
