PrintIntroduction to Online VCS
Some popular online hosting solutions for VCS and DVCS code repositories include: GitHub, Bitbucket, Google Code and Microsoft CodePlex. These online repositories are often used as the main trunk repositories for open-source projects with many developers who may be geographically dispersed. For the purposes of this class, we will focus on GitHub.
Introduction to GitHub
GitHub takes all of Git’s version control components, adds a graphical user interface to repositories, change history, and branch documentation, and adds several social components. Users can add comments, submit issues, and get involved in the bug tracking process. Users can follow other GitHub users or specific projects to be notified of project updates. GitHub can either be used entirely online or with an application download for easily managing and syncing local and online repositories. Optional (not required for class): Click here for the desktop application download.
The following exercise will cover the basics of Git and how they’re used in the GitHub website.
Git Exercise in GitHub
- Go to GitHub's website and sign up for an account using any email and password you like. If you already have a GitHub account, feel free to use that.
- Follow the instructions posted at the GitHub Guides Hello World page.
GitHub's change log
GitHub has the ability to display everything that changed with every commit. Take a look at GitHub's Kansasgis/NG911 page. If you click on one of the titles of one of the commits, it displays whatever basic description the developer included of the changes and then as you scroll down, you can see every code change that occurred - red highlighting what was removed and green highlighting what was added. If you mouse over the code, a plus sign graphic shows up, and users can leave comments and such.
Resolving conflicts on GitHub
Conflicts occur if two branches being merged have had different changes in the same places. Git automatically flags conflicts and will not complete the merge like normal; instead, the user will be notified that the conflicts must be resolved. Some conflicts can be resolved inside GitHub, and other types of conflicts have to be resolved in the Git command line [4]. Due to the complexity of resolving conflicts in the command line, it’s best to plan ahead and silo projects as much as possible to avoid conflicts.
Git adds three different markers to the code to flag conflicts:
<<<<<<<HEAD – This marker indicates the beginning of the conflict in the base branch. The code from the base branch is located directly under this marker.
======= – This marker divides the base branch code from the other branch.
>>>>>>> BRANCH-NAME – This marker will have the name of the other branch next to it and indicates the end of the conflict.
Here’s a full example of how Git flags a conflict between branches:
<<<<<<<HEAD myString = “Monty Python and the Holy Grail is the best. ” ======= myString = “John Cleese is hilarious.” >>>>>>> cleese-branch
To resolve the conflict, the user needs to pick what myString will equal. Possible resolution options-
Keeping the base branch -
myString = “Monty Python and the Holy Grail is the best.”
Using the other branch -
myString = “John Cleese is hilarious.”
Combining branches, in this case combining the options -
myString = “Monty Python and the Holy Grail is the best. John Cleese is hilarious.”
GitHub has an interface that can be activated for resolving basic conflicts by clicking on the “Resolve Conflicts” button under the “Pull Requests” tab. This interface steps through each conflict and the user must decide which version to take, keep their changes, use the other changes, or work out a way to integrate both sets of changes. Inside the GitHub interface, the user must also remove the Git symbols for the conflict. The user steps through every conflict in that particular file to decide how to resolve the conflict and then will eventually click on the “Mark as resolved” button. The next file in the project with conflicts will show up and the user will repeat all of the steps until the conflicts are resolved. At this point, the user will click “Commit merge” and then “Merge pull request.”
For more complex types of conflicts like one branch deleting a file that the other keeps, the resolution has to take place in the Git command line. This process can hopefully be avoided, but basic instructions are available at GitHub Help: Resolving a merge conflict using the command line.
Resources:
[4] https://help.github.com/articles/resolving-a-merge-conflict-on-github/