Version control is a system that manages changes to a file or files. These changes are kept as logs in a history, with detailed information on what file(s) was changed, what was changed within the file, who changed it, and a message on why the change was made. This is extremely useful, especially when working in teams or for yourself 6 months in the future (because you will forget things)!
To understand how incredibly powerful version control is, think about these questions: How many files of different versions of a manuscript or thesis do you have laying around after getting feedback from your supervisor or co-authors? Have you ever wanted to experiment with your code or your manuscript and need to make a new file so that the original is not touched? Have you ever deleted something and wish you hadn’t? Have you ever forgotten what you were doing on a project? All these problems are fixed by using version control (git)!
We are going to go over a typical workflow. This could be either a solo workflow or a collaborative workflow.
Git:
git init; the saved
history of the folder and files) in that foldergit add), saving it to the
history (git commit)git status)git diff)git add; this is an
area before going into the history)git commit)git log)Github:
git remote; the command is usually provided from GitHub)git
push)git pull)Tips:
Create a folder and create a git repository (which is the stored
history) in that folder. (Note: ## is a comment, not a command).
cd ~/Desktop ## Move to your desktop
mkdir playing ## Create a folder (aka directory)
cd playing
git init ## Create the repository (init = initialize)
Now, create a file, get git to track it, and save it to the history.
touch bio.txt ## Command to create a file called bio.txt
ls ## Check that you created the file, ls = list files
git add bio.txt ## Track the file
## Save the file to the history with a message (-m)
git commit -m "Initial commit"
Now, open the bio.txt file and add:
Then:
git status ## Check the activity
git diff bio.txt ## Compare to the one in the history
git add bio.txt ## This sends it to the staging area
git commit -m "Added my bio" ## This sends it to the history
For a description on what the different stages are (working directory, staging area, and committed history) see the below links:
Then, to see what has happened in your history:
git log ## View the log of your history
Next, we’ll create a GitHub account, create a GitHub repository (a remote repository), and upload the repository on your computer (called the local repository) onto the remote repository (GitHub):
git remote add origin https://github.com/yourusername/playing.git
git push origin master
git pull
Now you know about a typical workflow! There are lots of commands and options in git, you really can do almost anything. However, these are the basic tools that are used most frequently. If you have any questions, please check out StackOverflow for literally any question on or about Git!! Or just google it! Google usually shows answers from StackOverflow.
git pull origin master,git checkout -b MyNewBranchgit add,git commit -m "description of your commit", andgit push origin MyNewBranch| Term | Description |
|---|---|
| Origin (repo) | Your remote repo (on Github); it is the “origin” for your local copy. Either it is a repo you created yourself or it is a fork of someone else’s GitHub repo. |
| Upstream (repo) | The main repo (on GitHub) from which you forked your GiHub repo. |
| Local (repo) | The repo on your local computer. |
| Main/Master | The main branch (version) of your repo. |
| Term | Explanation |
|---|---|
| Fork | Make a copy of someone else’s GitHub repo in your own GitHub account. |
| Clone | Make a copy of the your GitHub repo on your local computer. In CLI: ‘git clone’ copies a remote repo to create a local repo with a remote called origin automatically set up. |
| Pull | You incorporate changes into your repo. |
| Add | Adding snapshots of your changes to the “Staging” area. |
| Commit | Takes the files as they are in your staging area and stores a snap shot of your files (changes) permanently in your Git directory. |
| Push | You “push” your files (changes) to the remote repo. |
| Merge | Incorporate changes into the branch you are on. |
| Pull Request | Term used in collaboration. You “issue a pull request” to the owner of the upstream repo asking them to pull your changes into their repo (accept your work). |
You only have to do this once; global settings apply to all your git repos.
Note: Any Local settings you initiate within individual git repositories will over ride global settings.
Command line git syntax is: git verb
$ git config --global user.name "Albert Einstein"
$ git config --global user.email "bertie@worlduniversity.edu"
$ git config --global color.ui "auto"
Use your own name and email address instead of Einstein’s. This user name and email will be associated with your subsequent Git activity, which means that any changes pushed to a Git host server will include this information.
For this lesson, we will be interacting with GitHub and so the email address used should be the same as the one used when setting up your GitHub account. If you are concerned about privacy, please review GitHub’s instructions for keeping your email address private. If you elect to use a private email address with GitHub, then use that same email address for the user.email value, e.g. username@users.noreply.github.com replacing username with your GitHub one. You can change the email address later on by using the git config command again.
Set up your favorite text editor (default editor):
$ git config --global core.editor "nano -w"
$ git config --global core.editor "atom --wait"
See https://swcarpentry.github.io/git-novice/02-setup/ for settings for other text editors
This exercise is based on the SWC Git Novice lesson https://swcarpentry.github.io/git-novice/08-collab/
One of you will be the “Owner” and one of you will be the “Collaborator.”
$ git clone URL-of-Origin-Repo Directory-Address-of-Local-RepoGo to your cloned repo:
$ cd ~/.../yourClone
Open editor and revise working file:
atom tenlines.txt
Commit your changes to your local repo:
$ git add tenlines.txt
$ git commit -m "your commit message"
Push your changes to the Owner’s repo on GitHub:
$ git push origin master
Look at Owner’s GitHub repo and see new commit(s) from Collaborator.
Download (pull) Collaborators changes to Owner’s local repo:
$ git pull origin master
When two or more people work on the same files, conflicts are bound to occur. Version control will help notify us when there are conflicts. It will be up to the humans to sort out which changes to retain.
The file “tenlines.txt” currently looks like this:
$ cat tenlines.txt
Let’s say Person A adds a line to the file and review:
$ atom tenlines.txt
$ cat tenlines.txt
and pushes changes to GitHub:
$ git add tenlines.txt
$ git commit -m "added a line in local copy and pushed to remote"
$ git push origin master
Now, Person B modifies her local file without first updating it (pulling the repo) from GitHub:
Add a line to the file and review:
$ atom tenlines.txt
$ cat tenlines.txt
Commit the changes locally:
$ git add tenlines.txt
$ git commit -m "added a line in local copy"
But when we push, Git will not allow this because there were changes to the same line in the two files:
$ git push origin master
To resolve the conflict, you need to pull the changes from GitHub, merge them into your local copy, and then push it back to GitHub
$ git pull origin master
Git tells us there is a conflict and tells you the file it’s in.
Let’s look at the file:
cat tenlines.txt
Git has put some new info in our file:
<<<<<<<<<<<<< HEAD
our text
========
Other persons's text
>>>>>>>>
You need to open your text editor and make the changes which is the accepted version by you and your collaborator:
atom tenfiles.txt
Then, to finish mergining, you need to add, commit, and push your changes back to GitHub:
$ git add tenlines.txt
You can verify the status of your repo first, then commit and push:
$ git status
$ git commit -m "Merged changes from GitHub"
$ git push origin master
Git keeps track that a conflict has been resolved and what was merged into what so when Person A who made the first changes pulls from GitHub, she doesn’t have to fix things and merge again.
Person A pull and sees new version of the file:
$ git pull origina master
$ cat tenlines.txt
This exercise is based on the 10 mins GitHub “Hello World” tutorial https://guides.github.com/activities/hello-world/
Your Name's Project.readme-edits, into the new branch text box.readme-edits branch, which is a copy of main.You are now on your readme-edits branch.
README.md file.readme-edits, to compare with the original, master.You will merge your readme-edits branch into your master branch.
One of you is the Project Lead. The other will be the Contributor.
Your Name's Project.$ cd ~/GitRepos/MyProjectgit init..git file in your directory: ls -agit clone URL-of-Origin-Repo Directory-Address-of-Local-Repo
e.g.
git clone https://github.com/chungkky/2017-08-02_Collaborating-with-Git.git ~/GitHubRepros_KC/2017-08-02_Collaborating-with-Git
cd - change directoryls - list the files and folders in a foldertouch - create an empty fileinit - start or initialize a git repositoryadd - put a file into the staging area, so that git starts
tracking itcommit - send files in the staging/index area into the history
(the git repository)status - check the status of the folder and the git repositorydiff - compare a file to the a file in the historylog - view the commit history in the git repositoryHere are a few great resources (excluding StackOverflow) to use if you ever need help: