Difference between revisions of "Workshop: Introduction to version control"
Line 1: | Line 1: | ||
''(Generally, this workshop is offered at least once a week on a rotating basis. Check the [http://designandbuildlab.com/?page_id=445/ Lab calendar] for up-to-date availability!)'' | ''(Generally, this workshop is offered at least once a week on a rotating basis. Check the [http://designandbuildlab.com/?page_id=445/ Lab calendar] for up-to-date availability!)'' | ||
− | '''Version control''' is a technique for managing the complexity of | + | '''Version control''' is a technique for managing the complexity of a digital project, especially those which are done collaboratively. |
− | When a project is in its infancy, it is fairly straightforward to keep track of the files contained within; it can, however, become unmanageable very quickly - especially if revisions happen frequently. Version control can be imagined as a series of '''snapshots''' of a project's | + | When a project is in its infancy, it is fairly straightforward to keep track of the files contained within; it can, however, become unmanageable very quickly - especially if revisions happen frequently. Version control can be imagined as a series of '''snapshots''' of a project's changes as time progresses. Each snapshot allows you to see exactly the state of the project at that time; you can travel back to any of these snapshots at any time, and fast forward back to the future. |
− | The version control information (the files, the snapshot information, et al.) are held ''locally'' in a folder called a '''repository''', or repo. You can additionally sync this repo to a server somewhere else - called a '''remote'''. This can serve as a backup, as well as a way to ''share | + | The version control information (the files, the snapshot information, et al.) are held ''locally'' in a folder called a '''repository''', or repo. You can additionally sync this repo to a server somewhere else - called a '''remote'''. This can serve as a backup, as well as a way to ''share the repo with others'' who may also be working on the project. |
A '''version control system''' (VCS) is a tool that handles all of this complexity: the repo itself, the snapshots, the remote(s), et al. There are many VCs's; the most popular is called '''[https://git-scm.com/downloads git]'''. | A '''version control system''' (VCS) is a tool that handles all of this complexity: the repo itself, the snapshots, the remote(s), et al. There are many VCs's; the most popular is called '''[https://git-scm.com/downloads git]'''. | ||
+ | |||
+ | === Why use version control? === | ||
+ | The two advantages that version control provides: | ||
+ | # ''You are able to travel back in time to any point in a project and utilize it from that moment''; and | ||
+ | # if you use a remote, ''collaboration is not only straightforward, it is encouraged''. | ||
=== Terminology === | === Terminology === | ||
Line 19: | Line 24: | ||
'''branch''': a particular timeline of snapshots - the main branch is typically called "master"; other branches may be used to develop new features without risking the master branch's stability | '''branch''': a particular timeline of snapshots - the main branch is typically called "master"; other branches may be used to develop new features without risking the master branch's stability | ||
− | |||
− | |||
− | |||
− | |||
− | |||
== Utilizing version Control == | == Utilizing version Control == | ||
− | |||
− | |||
− | |||
− | |||
− | |||
=== Required tools === | === Required tools === | ||
* A VCS - preferably '''[https://git-scm.com/downloads git]'''. | * A VCS - preferably '''[https://git-scm.com/downloads git]'''. | ||
Line 38: | Line 33: | ||
Git is accessed through the command line interface (CLI) of your choice: | Git is accessed through the command line interface (CLI) of your choice: | ||
*''Windows'': you can use Git Bash (which was installed when you installed git.) | *''Windows'': you can use Git Bash (which was installed when you installed git.) | ||
− | *''Linux/ | + | *''Linux/MacOS'': terminal (which is installed with the operating system) |
=== Setting up a repo === | === Setting up a repo === |
Revision as of 23:30, 22 October 2018
(Generally, this workshop is offered at least once a week on a rotating basis. Check the Lab calendar for up-to-date availability!)
Version control is a technique for managing the complexity of a digital project, especially those which are done collaboratively.
When a project is in its infancy, it is fairly straightforward to keep track of the files contained within; it can, however, become unmanageable very quickly - especially if revisions happen frequently. Version control can be imagined as a series of snapshots of a project's changes as time progresses. Each snapshot allows you to see exactly the state of the project at that time; you can travel back to any of these snapshots at any time, and fast forward back to the future.
The version control information (the files, the snapshot information, et al.) are held locally in a folder called a repository, or repo. You can additionally sync this repo to a server somewhere else - called a remote. This can serve as a backup, as well as a way to share the repo with others who may also be working on the project.
A version control system (VCS) is a tool that handles all of this complexity: the repo itself, the snapshots, the remote(s), et al. There are many VCs's; the most popular is called git.
Contents
Why use version control?
The two advantages that version control provides:
- You are able to travel back in time to any point in a project and utilize it from that moment; and
- if you use a remote, collaboration is not only straightforward, it is encouraged.
Terminology
repository: the location and contents of a project, including all version control information
commit (n): a particular snapshot of a project
commit (v): to take a snapshot of a project
remote: a copy of project, stored on a server somewhere else
branch: a particular timeline of snapshots - the main branch is typically called "master"; other branches may be used to develop new features without risking the master branch's stability
Utilizing version Control
Required tools
- A VCS - preferably git.
- A web-based system to host your remotes.
Git is accessed through the command line interface (CLI) of your choice:
- Windows: you can use Git Bash (which was installed when you installed git.)
- Linux/MacOS: terminal (which is installed with the operating system)
Setting up a repo
There are several ways to do this; the easiest way is to create a new repo on Bitbucket or Github, and then duplicate it on your local machine using a CLI of your choice:
- Navigate to the place you'd like to save the repo folder:
cd [path]
- Locate and copy the url for the git remote; in bitbucket, this is in the top-right corner of the repo's main page.
- Use the clone function of git to download a copy of the repo locally:
git clone [the_link_you_copied_in_step_2.git]
You can now begin adding files in your repo!
Working with a repo
Typical workflow
When working on a project locally, your workflow will typically consist of the following:
- Modify files within the repository's folder (e.g. changing lines of code).
- Stage those changes:
git add [filename]
- Commit those changes to the repository:
git commit -m "[a message describing the changes]"
If you have a remote set up, then two steps bookend the workflow above:
- Pull any changes from the remote repository to your local copy:
git pull
- Modify files within the repository's folder (e.g. changing lines of code).
- Stage those changes:
git add [filename]
- Commit those changes to the repository:
git commit -m "[a message describing the changes]"
- Push the new commit to the remote repository:
git push [remote name] [branch name]
Common git commands
Command | Syntax | Function | Example usage |
---|---|---|---|
status | git status [options]
|
checks the status of the repo; shows a visual distinguishing among files which have and haven't been included in the repo, files which have been modified and staged, et al. | git status
|
add | git add [filename]
|
stages files; these files are ready to be committed. | git add README.md
|
commit | git commit -m "[commit message]"
|
commits changes to the repo, or "taking a snapshot". | git commit -m "changed header"
|
log | git log [options]
|
shows a list of all the previous commits in the current branch. | git log
|
checkout | git checkout [branch or snapshot name]
|
rolls the repository over in time to a particular snapshot; typically snapshots are referenced by a hash | git checkout a65f27
|
pull | git pull [options]
|
checks the remote for any new commits not on your local timeline; if so, downloads them to your local repo, then fast-forwards your local repo to the current snapshot | git pull
|
push | git push [remote name] [branch name]
|
connects to the remote and copies any new snapshots on your system to it | git push origin master
|
Flow chart
More information
Git's reference manual
Git cheat sheet