Open Source Comes to Campus/Curriculum/Directory: Difference between revisions

no edit summary
imported>Shauna
No edit summary
imported>Shauna
No edit summary
Line 122:
= The Follow Up =
 
Now, youYou might say, "Wait.! I want a copy of that awesome, full directory for my own site. How do I get those changes back?"
 
There's totally a way to do it, but it's kind of complicated. If your mind is already full with the above activity, you should take a break, and come back to this later if you want to.
Line 128:
Alright. Ready?
 
=== Setting multiple remotes ===
 
 
 
 
 
 
(This section is in progress.)
 
=== Setting multiple remotes ===
 
The copy of the repository you have on your computer is called your "local" copy. The copy on Github is a "remote". You can see what remotes are associated with your local repository by typing the command:
Line 143 ⟶ 135:
 
You should see something like this:
 
origin https://github.com/$yourusername/$your-repository-name (fetch)
origin https://github.com/$yourusername/$your-repository-name (push)
Line 152 ⟶ 145:
git remote add $name $url
 
Replace $name with whatever you want to label the remote, and $url with the github url for the main repository (that is, <code>https://github.com/FOSSdirectory/FOSSdirectory.github.io.git</code>).
When you do the "git remote -v" command, you should see that you now have two sets of fetch/push listings. To get an updated version of the main repository, you can type:
 
git fetch $name
git merge $name/master
 
To update your remote personal repository, you can type:
Line 171 ⟶ 161:
That's it! You can add as many remotes as you'd like, although for the most part people stick to one or two.
 
=== ResolvingPulling Mergefrom Conflictsthe original repository ===
 
You want to get the most up to date version of directory.html from the original repository. To get an updated version of the main repository, you can type:
Your instructor should have showed you what she sees when you submit a pull request. Probably you saw a message from Github saying that the pull request could be "merged automatically". That means that you managed to avoid changing a part of the project that someone else also changed. Yay! That's how we designed this activity. But what happens if you ''do'' change the same part of a project as someone else? It generates what we call a "merge conflict".
 
git fetch $name
(A brief thought experiment to explain merge conflicts: let's say there's a repository with a single file that says, '''Hello [celestial object]!''' If you change that to '''Hello world!''' and submit a pull request, you're creating a diff which says: ''change "[celestial object]" to "world"''. If someone else copied the repository at the same time as you and changed the same line, they might create a diff which says ''change "[celestial object]" to "galaxy"''. If you make your changes to the repository first, it now says '''Hello world!''', so when the other person says ''change "[celestial object]" to "galaxy"'' the repository does not see '''[celestial object]''', and flags that there's a conflict.)
git merge $name/master
 
In our case, though, this will cause a merge conflict. A merge conflict happens when two people (or the same person, at two different points in time) edit the same part of the same file. In our case, this happens both in index.html and directory.html. Let's take a moment to think about it.
To induce a merge conflict in this activity, go to the main github repository and find a change that has been made since the last time you copied the repository ("git clone" gets a copy, as does "git fetch" and "git pull"). Make a change, locally, to the same line. Add and commit those changes.
 
Your personal repository should have an index.html that's been customized to you. The index.html from the original, however, will only be the blank template version. You want to keep '''your''' index.html. Your directory.html is mostly empty, however, while the directory.html from the original has been updated with links. You want to add '''their''' directory.html.
There's two ways that this merge conflict can be solved. You could push your changes to your remote copy, then submit a pull request to your instructor. When viewing the pull request, they would be warned that changes could not be merged automatically:
 
There are two ways to do this. We'll go over both.
[[File:Merge1.png]]
 
=== Option A: Discard/keep within files ===
And would follow the instructions github helpfully provides to merge the changes:
 
This should result in a conflict. There are a number of tools you can use to help visualize merge conflicts. For simple conflicts, though, I like to use a basic editor, such as nano, vim, emacs, or whatever you're most comfortable with. In basic text view, a merge conflict looks like this:
[[File:Merge2.png]]
 
[[File:Merge1merge3.png]]
This involves some concepts like branching, which we haven't gotten to yet.
 
To resolve the conflict, scroll through the document until you find sections with these markings. The "========" line separates the two options that are in conflict. Choose which one you want to keep by deleting the other. Then delete all of the markings. Do this for each conflict and then save and exit the file.
Alternatively, you could fix the merge conflict yourself. To do this, you'd need to get an up-to-date copy of the remote repository. To do this, type:
 
You will then need to [[Open_Source_Comes_to_Campus/Curriculum/Directory#Commit_and_push | add and commit]] your changes.
git fetch [url of main project]
 
=== Option B: Discard/keep whole files ===
(If you do not have the main project as one of your remotes, see the above section on multiple remotes.)
 
Dealing with merge conflicts can get messy, especially when there are a lot of changes and you want to keep things from both versions of the file.
This gets a copy of that repository. Now you need to merge that with your local changes.
 
In our case, though, we don't want to take things from each version of the file. We just want to update one file, directory .html.
git merge
 
Luckily, there's a way to to this at the file level:
This should result in a conflict. There are a number of tools you can use to help visualize merge conflicts. For simple conflicts, though, I like to use a basic editor, such as nano, vim, emacs, or whatever you're most comfortable with. In basic text view, a merge conflict looks like this:
 
git checkout --theirs directory.html
[[File:merge3.png]]
 
To resolve the conflict, scroll through the document until you find sections with these markings. The "========" line separates the two options that are in conflict. Choose which one you want to keep by deleting the other. Then delete all of the markings. Do this for each conflict and then save and exit the file.
 
Again, once you have done this you will need to [[Open_Source_Comes_to_Campus/Curriculum/Directory#Commit_and_push | add and commit]] your changes.
Congrats! You've resolved the conflict! You can commit your changes by:
Anonymous user