Sorting conflicts
So, we've seen how we can get our own code onto GitHub. What about working with other people on projects?.
Working with other people on small projects is simple. You talk to each other, and you make sure you're not working on the same files at the same time. Everyone syncs at the start of the day, and there's no conflicts because only one person is working on a file between syncs.
However, Git was designed to work with much more overlap. We've already looked at pull requests. What we haven't yet looked at is what happens if two collaborators are working on a file at the same time, and one updates the GitHub website "origin" repo, and the other then updates without having done a sync pull. At that point, the second is pushing into a commit they haven't had. This causes a "conflict" – there are two sets of differences that need to be merged into one main online repo. These may even be for the same line. This is something only a human can sort out, so it has to be done manually.
If you get into this situation, the second person to push their repo to GitHub will get a warning that there's a conflict. If you OK the warning, and right-click on the file in GitHub Desktop under Changes (it usually has an orange warning strip next to it), you'll get options to undo your changes, but also to open the file. If you open the file (and we'll recreate this situation in a second), you'll see that GitHub Desktop has altered the conflicted file so it looks like this (with more or less text in the conflict area, depending on your line breaks):
That is our globe now... the world of the electron
<<<<<<<HEAD
and the bulb
=======
and the muppets
>>>>>>> branch-main
, the beauty of the baud.
It is up to the second person to open this file in a text editor, and manually sort it out, talking to the other person if necessary. Once they're happy
with the changes, and have deleted all the conflict markers (in bold, above), they should just have this kind of thing:
That is our globe now... the world of the electron and muppets, the beauty of the bulb.
At which point they can push, and the system will assume they've resolved the issue. When the first person pulls, they'll see the history of the changes.
If you've got someone working through this with you, pair up, and have a go at this. Here's the sequence:
Person 1:
Add Person 2 as a collaborator to your project.
Person 2:
Clone the project – put it somewhere that isn't your project's directory.
Person 1:
Edit the text file, and push it to GitHub.
Person 2:
Edit the text file differently, and try and push it to GitHub.
Resolve the conflicts.
Push the file to GitHub.
Person 1:
Sync the new commit with your local copy.
Once you've done that, try swapping rôles. See how the system responds when: a) you don't work on the same line in the file (for example, someone adds a line rather than altering a pre-existing one) and b) when one person deletes the whole file.
Right, we should now know the basics of working with Git and GitHub. Let's look at some of the things we can do with it, and then go on to build an online portfolio.