Version Control for Designers | Notes - BKJackson/BKJackson_Wiki GitHub Wiki
About Version Control
aka, source control, revision control
a system that maintains versions of files at progressive stages of development
every file in the system has a full history of changes and can easily be restored to any version in its history
Advantages of Version Control
allows programmers to maintain separate "production" versions of code that are always deployable
allows simultaneous development of different features on the same codebase
keeps track of all old versions of files
prevents work from being overwritten
allows a team to share code and communicate work between programmers
The Repository
files and their versions live in a repository
works like a database that can return any version of any file within
can also return a history of changes across the entire project
Committing
after making changes, users can then commit the changes back to the repository, which creates a new version with metadata about the files that were changed and who changed them
Pushing
pushes individual changes to the shared remote repository for the team
syntax:
$ git push <repository> <branch>
example:
$ git push origin master
by default, git push (and git pull) will push (or pull) all branches common to the origin and the local repository
note that this is missing info on remotes
Pulling
updates local repository and working copy to the latest revision committed to the remote repository
pulls all changesets down from the remote repository and merges them with your current changes (if there are any)
your local repository takes and implements the changes in the same order as they were committed
team members can also pull changes from other repositories
.gitignore
use this file to tell Git to ignore certain files or directories
Branching
branches are similar to drafts
the master branch can be considered the folder of final drafts
other branches, such as a dev branch, can be considered the folder for drafts in active development
Best practice: always create a branch before starting work on a feature, then merge it later with the master
useful for multiple developers to work together on something that requires isolation from the main code base
syntax to create a new branch:
$ git checkout -b <branch_name>
any modified files will be listed
syntax to switch between branches:
$ git checkout <branch_name>
Merging
once the code in a development branch is finished, the changes are merged into the master branch
the draft branch can then be removed
to pull changes from master into your branch, type:
$ git pull origin
$ git merge master
to merge your changes back with the master, type:
$ git checkout master
$ merge redesign
to delete your redesign branch, type:
$ git branch -d redesign
to delete the redesign branch on the remote repository, type:
$ git push origin :redesign
Cloning
repository users can clone a working copy with the latest files and make changes to it
cloning creates the repository and checks out the latest version, which is referred to as 'head'
keeps the address of the original repository, aliased as 'origin'
you can send back changes to the remote repository only if you have authorization
JSpec Folder
contains JSpec source code
in each git repository
SSH Authorization
by default, git uses the ssh protocol
requires that you have secure access to the remote repository
you can add an entire directory:
$ git add public/
if you make any changes to a file after staging and before committing, you need to add the file again
to remove a file from staging:
$ git reset HEAD <filename>
Diff
git diff only shows changes that haven't been staged
adding the option '--cached' will show you staged changes only
Undoing Your Changes
to revert a file back to the copy in the repository, check it out again:
$ git checkout <filename>
to revert to an older revision, find the revision ID with 'git log' and revert with 'git checkout':
$ git log index.html
$ git checkout <revision ID> index.html
to unstage the file and checkout again:
$ git reset HEAD index.html
$ git checkout index.html
Collaboration
to find out who last changed a file:
$ git blame <file>
Best Practices
Commit and pull often
committing often helps prevent you from losing work and allows you to step back over small changes
pulling often keeps your code up to date and cuts down on duplicated work