3. Git Pulling & Merging
Last updated
Last updated
GitHub enables developers across the world to collaborate on projects. In this lesson, we'll learn how to use GitHub to create and manage branches, merge branches, create pull requests, and resolve merge conflicts.
Objectives
You will be able to…
Pull changes from a repository
Resolve merge conflicts
Key Terms
Pull — to download changes from a remote repository
Merge - to combine two or more branches into one
Merge Conflict — a situation in which two or more branches need to be merged but have modified the same lines of code, causing the merge to fail. This happens all the time and can be resolved through the Github GUI or the CLI.
Important Git commands
git pull — download changes from a remote repository
An app published to the App Store (or Play Store, I see you Android users) is essentially the same as a repository uploaded to GitHub.
Just like downloading an app, anyone can download a repo from GitHub using the git clone command.
To demonstrate this, find a partner (or simply play the role of two developers). Then do the following:
Have one developer create a new repo called git-pulling-practice. Make sure it includes a README.md file. Then, share the URL with their partner.
Have both developers use their VS Code Terminal to navigate to their unit-0 folder and clone the repo onto their computers using git clone
If working solo, clone the repo a second time but rename the second copy. You can do this by adding an additional input to the git clone command for the new name, resulting in something like this: git clone <git_repo_url> git-pulling-practice-copy.
Have both developers navigate into the repo using the cd command.
If working solo, open two VS Code Terminal windows for this, navigating each terminal to one of the copies of the repo so that you can easily switch back and forth between "developer 1" (the first clone) and "developer 2" (the second clone).
Tada! Now you have the same repository on two computers!
git pull synchronizes local repositoriesIn the last lesson, you learned about the git push command which uploads a local repository's commits to the remote repository (GitHub).
git pull does the opposite. If the local repository (on your computer) is missing commits that are on the remote repository (on GitHub), git pull will download those commits.
Let's put this into practice. With your partner do the following:
Have the developer who first created the repo on GitHub make some edits to README.md.
That same developer should then stage their changes (git add README.md), commit (git commit -m "description of commit") and then push that commit (git push)!
Double check on GitHub that the commit shows up on the remote repository's commit history.
Now, the second developer should run the command git pull (if working solo, switch over to the location of the second copy of the repo and run git pull)
By storing repositories remotely on GitHub, any number of developers can have access to a single repository. This push and pull mechanism is essential for collaboration.
So far only one developer was making changes, while the other developer simply "pulled down" those changes. But what if both developers want to work simultaneously?
Before moving on, the owner of the shared repo should add their partner as a collaborator:
Go into the settings of the repo, go to Collaborators, and click on "Add people".
Add their partner as a collaborator using their GitHub username or Email and have their partner accept the invitation.
For this next part, it is going to be a race, so get your typing fingers ready! Both developers should:
Run git pull to make sure that their local repository is in sync with the remote.
Open up the README.md file and replace the content on line 1 with their own name. This is the most important step. It is essential that both developers edit the same line of code
Stage their changes (git add README.md)
Commit (git commit -m "description of commit")
Push (git push)!
Chaos
Whichever developer managed to push their changes first (or has a better internet connection) will have no problem pushing their code.
The developer who pushed second will be given this message:
You are only allowed to push to the remote repository if your local repository has the exact same commit history as the remote repository.
In this case, developer 2 is missing the commit from developer 1 in their local repo and needs to pull down the changes.
So, the developer who pushed last should run git pull
However, in this situation, the conflict will cause a Merge Conflict like this:
Okay take a deep breath. Merge conflicts are often scary when they are first encountered, but they happen all the time and are an entirely expected part of the development process!
Merge conflicts occur when two developers edit the same lines of code in the same repo and unsuccessfully merge those changes together, as happened here.
VS Code provides a nice UI to help us resolve the conflict:
Let's break down what we see here:
The three "markers" outline the two conflicting pieces of code:
<<<<<<< HEAD on line 1
======= on line 3
>>>>>>> b737ff... on line 5
The "current change" is the code already in my local repo.
The "incoming change" is the code that I'm trying to merge into my local repo (from the remote repository).
To resolve this conflict we can:
Use the buttons that VS Code provides:
"Accept Current Change" — replace the code from the remote with your code.
"Accept Incoming Change" — replace your code with the code from the remote.
"Accept Both Changes" — keep both!
"Compare Changes" — see the changes side by side
Alternatively, we can just delete the markers and keep the code you want to keep!
Once you've made your choice, save the file, stage the changes, commit them, and push the changes.
Typically, you can use the commit message "resolving merge conflicts"
Hurrayy!!! You've solved the merge conflict! Piece of cake.
Pay attention to the details and take notes! Do not shy away from the messages in your terminal. Seek to understand them and you'll gain so much more confidence.
