-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
executable file
·116 lines (116 loc) · 9.18 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
<!DOCTYPE html>
<!--[if lt IE 7]> <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]> <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]> <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<title>Learning Github</title>
<meta name="description" content="Github for Web Designers is the companion reference for the lynda.com course of the same name">
<meta name="viewport" content="width=device-width">
<link rel="stylesheet" href="_css/main.css">
<script src="_scripts/modernizr-custom.js"></script>
</head>
<body>
<header>
<h1><a href="index.html" title="home"><span aria-hidden="true" data-icon="" class="github-icon"></span> Github for Web Designers</a></h1>
</header>
<nav id="pageNav" role="navigation" class="cf">
<ul>
<li><a href="index.html" title="concepts" class="current">Concepts</a></li>
<li><a href="reference.html" title="Git reference">Reference</a></li>
<li><a href="glossary.html" title="glossary">Glossary</a></li>
<li><a href="resources.html" title="resources">Resources</a></li>
</ul>
</nav>
<main>
<h2>Welcome</h2>
<p>Hi! Welcome to the companion reference to my <a href="http://www.lynda.com" title="lynda.com">lynda.com</a> <em>Github for Web Designers</em> course. This reference also serves as the exercise files for my course, so you can download the exercise files from this repo as well.</p>
<p>This course is the result of my own frustrations from trying to learn Github. It seemed like every tutorial I took, or article I read, assumed I was a developer and used terms and terminology that I just wasn't familiar with. Perhaps worse than that, because certain things were assumed it would often halt my learning process because I wouldn't understand how to fill in the blanks between steps. I decided to jump in headfirst, make lots of mistakes, and research things that as a designer I wasn't really that interested in. The result was that I learned Github the hard way, and I'm hoping my course means that you don't have to.</p>
<h2>Stuff I learned</h2>
<p>Whenever I learn something new I have those "aha” moments where I break through the murk into moments of clarity. In addition to the reference and glossary that you’ll find here I wanted to list some of the concepts that I found really important when learning Github.</p>
<h4>Take some time to learn Git</h4>
<p>I'll admit it; when I first started learning Github my hope was that it would provide me an interface to do all the things I needed to do without actually having to learn Git. While most of the basic day to day tasks can be performed without ever going into the command line or even understanding the terminology involved, eventually you'll have a situation that you can't fix. Save yourself the trouble and go ahead and learn at least the basics of Git first. I consider this so important that I changed the structure of my course to reflect this; spending a chapter at the beginning of the course teaching those basics. Although you can certainly muddle along it's almost impossible to use Github to its fullest potential without also knowing Git. The desktop apps are great and very intuitive but they have limited feature sets and don't really try to teach you what's going on behind the scenes.</p>
<h4>Understand what is meant by "distributed"</h4>
<p>Git is a distributed version control system, meaning that all copies of the repositories are local. Here are some highligts that you should take away.</p>
<dl>
<dt>No central repository
</dt>
<dd>All copies of it are local and can update other copies</dd>
<dt>Doesn’t create multiple copies of files
</dt>
<dd>Git maintains a single directory structure. "Snapshots" are taken of projects as they progress to save history states.</dd>
<dt>You can branch snapshots to create infinite project variations.
</dt>
<dd>Branching is incredibly powerful and allows you to create several different versions of your project without disturbing the history of the main project.</dd>
</dl>
<h4>The concept of staged files</h4>
<p>This one was tricky for me at first. I assumed that most version control systems automatically tracked and versioned files. That's not how Git works, in Git you have to first stage a file in order to include it in the next snapshot, referred to as a commit.</p>
<dl>
<dt>Files aren’t added to commits automatically
</dt>
<dd>You have to add files manually in order for them to be committed in the next snapshot. This adds a little bit more manual labor to the process, but also gives you much more control over how and when things are recorded.</dd>
<dt>Staged files are ‘frozen’ once staged
</dt>
<dd>If you update a file once it's been staged, the staged version of it doesn't record this. In order to make sure that the most recent changes are committed you'll need to restage the file.</dd>
<dt>You can un-stage files
</dt>
<dd>If you decide that you've made a mistake, it's very easy to un-stage a file so that it's not included in the next commit.</dd>
</dl>
<h4>How important Branching is</h4>
<p>As a designer the ability to branch off from your main project, experiment or refine, and then return back to your main project and merge in those changes is fantastic. No more will I create 15 versions of the same file, or multiple directories of the same project nested inside each other. With branching I can simply create a new branch do what I need to do and then decide whether or not I want to keep or get rid of the changes I've made. It's an incredibly liberating way to work and I would encourage you to learn as much as you can about how branching and merging work.</p>
<dl>
<dt>Branches give you flexibility
</dt>
<dd>Branches allow for simultaneous development, experimentation, and error fixing without disturbing the stable version. </dd>
<dt>You can keep them private
</dt>
<dd>Branches are private, meaning they’re not uploaded to Github unless you want them to be.</dd>
<dt>Understanding merging is key
</dt>
<dd>You need to spend time learning how merging works, I mean <em>really</em> understanding it so that you know what to expect when merging branches.</dd>
<dt>Develop a workflow pattern for branching
</dt>
<dd>If you don’t things can get messy fast. This is even more important in a team environment where you're working with multiple collaborators.</dd>
</dl>
<h4>Github is a publishing platform</h4>
<p>I kind of already knew this when I started learning Github since this was one of the reasons I really wanted to learn it. However, it's important to point out how evolved Github has become as a publishing platform.</p>
<dl>
<dt>Sharing projects publicly
</dt>
<dd>Projects can be shared and distributed with the public without having to buy hosting or register a domain.</dd>
<dt>Collaborators from around the world can/may offer assistance
</dt>
<dd>This is one of the coolest aspects. If you have a really great idea but lack skills in a certain area you can put the project up on Github and ask for assistance. The open source nature of the Github community means that you may get dozens or even hundreds of collaborators helping you with your project. Just keep in mind that open source means just that. You'll need to carefully research the licensing options and understand that you are releasing your project to the world.</dd>
<dt>Github Pages add polish
</dt>
<dd>Github Pages allow you to host a basic site for your project. You can create your own or use their Jekyll template to generate pages. This reference is an example of Github Pages.</dd>
</dl>
<h4>Clarity is important</h4>
<p>There are many places in the Github workflow where you have to compose messages or descriptions for actions. I've learned the hard way that it's really important to be as descriptive as possible. Whether it’s writing the project’s readme file or making commit messages it’s critical that you write clearly and concisely. Not only for others but so that future-you understands it as well.
<figure></figure>
</p>
</main>
<footer>
</footer>
<script>
//use the modernizr load to load up external scripts. This will load the scripts asynchronously, but the order listed matters. Although it will load all scripts in parallel, it will execute them in the order listed
Modernizr.load([
{
load: [
'http://ajax.googleapis.com/ajax/libs/jquery/1.10.1/jquery.min.js',
'_scripts/scripts.js'
//additional scripts can be loaded here, separate with a comma in the order you wish them to execute
]
},
{
// test for media query support, if not load respond.js
test : Modernizr.mq('only all'),
// If not, load the respond.js file
nope : '_scripts/respond.min.js'
}
]);
</script>
</body>
</html>