You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Version control is a way to manage and track any changes you make to your files. If you've been using online services such as Google Docs or Wikipedia, then you'll already have been working with documents and pages that use a version control system.
8
+
Version control is a way to manage and track any changes you make to your files. If you've been using online services such as Google Docs or Wikipedia, then you'll already have been working with documents and pages that use a version control system.
9
9
10
-
### Google docs revision history
10
+
### Google Docs revision history
11
11
12
-
Google docs, for example, keeps a revision history of any document you create and modify.
12
+
Google Docs, for example, keeps a revision history of any document you create and modify.
13
13
14
14
Have a look [at this Google document](https://docs.google.com/document/d/10kHJKXHLa-V8G6vVQoDiS6cTPvJoXnj_-SDvfQdziFk/edit?usp=sharing).
15
15
16
16
- Select to see the revision history (you must be logged in with your Google account to do that!)
- Try and have a look at the first revision of the page, by going back. It's dated back to 2005!
35
35
- Click **curr**, that will show you the [differences between the first and the latest entry](https://en.wikipedia.org/w/index.php?title=Women_in_computing&diff=583521812&oldid=19298328)
- When used on a regular basis, version control helps you to store your files safely. It makes it easy to figure out what broke your code, as you can roll back to a previous version and work out when things last worked as expected.
42
-
- With no version control in place you'll only have one copy of your file, then when it breaks there's no way to get back to good code!
42
+
- With no version control in place you'll only have one copy of your file, then when it breaks there's likely no way to get back to working code!
43
43
44
44
- It is also helpful when working with other people as it combines all the changes together and tracks who, why and when it changed.
45
45
- In the work environment this may be essential to know for example, what issue the change fixes or customer requirement it relates to.
46
46
47
47
## Code version control systems
48
48
49
-
There are a number of different version control systems. The most popular ones are **svn** (or Subversion), **cvs**, **Mercurial** and **Git**.
49
+
There are a number of different version control systems. The most popular ones are **SVN** (or Subversion), **CVS**, **Mercurial** and **Git**. Some are paid for and others are free.
50
50
51
-
We will be using **Git**.
51
+
We will be using **Git** with **Github**:
52
52
53
-
### Why Git?
53
+
-**Git** is a tool that makes sharing code and collaborating with other developers easy. It also keeps our code tracked and safe.
54
+
-**Github** is the web based hosting service for our code repositories that we interact with through the Github web pages.
54
55
55
-
There are a number of reasons we chose Git, namely;
56
+
We'll use Git installed on our system to manage code we work on and then push our code to Github hosted repositories.
56
57
57
-
- A lot of learning resources are publicly available
58
+
### Why Git and Github?
58
59
59
-
- Does not require you to be connected to the internet to use
60
+
There are a number of reasons we chose Git and Github, namely;
60
61
61
-
-All your tracked changes stay on your machine until you are happy with them, and want to make them part of your codebase
62
+
-Lots of learning resources are publicly available
62
63
63
-
- Will tell you if someone has made changes since you last pushed code and urge you to update first and resolve issues
64
-
65
-
- Github and online collaboration. Open source code is a big part of today's life. By being able to retrieve and help existing projects, you can also contribute to them
66
-
67
-
Some popular projects using Git:
68
-
69
-
- Android
70
-
71
-
- Linux
72
-
73
-
- Python
74
-
75
-
- Ruby
76
-
77
-
- PHP
64
+
- Git does not require you to be connected to the internet to use
78
65
79
-
# A bit more about Git
66
+
- All your tracked changes stay on your machine until you are happy with them, and want to make them part of your codebase on Github
80
67
81
-
## Terminology
82
-
83
-
As with any technology and related tool, there's a lot of terminollgy used. Here's some of the most common terms and their definitions:
68
+
- Will tell you if someone has made changes since you last pushed code and urge you to update first and resolve issues
84
69
85
-
-**Repository**: A repository is where code is stored
70
+
-Github makes online collaboration easy. Open source code is a big part of today's life. By being able to retrieve and help existing projects, you can also contribute to them
86
71
87
-
-**Checkout**: When you retrieve code from a **repository**, to you local machine
72
+
### Projects on Github
73
+
Once you've worked through the Git and Github tutorials here at codebar, there are an incredible range of projects that you'll be able to access for free. These projects include operating systems, games, programming languages, books and more.
88
74
89
-
-**Commit**: Applying any changes you have made to the **repository**
75
+
-Go retro with a **Windows 95** simulation: [https://github.com/felixrieseberg/windows95](https://github.com/felixrieseberg/windows95)
90
76
91
-
#### Aim for small and focused changes
77
+
- Learn more with free **Programming Books**: [https://github.com/EbookFoundation/free-programming-books](https://github.com/EbookFoundation/free-programming-books)
92
78
93
-
When using version control, you should commit every time you do a small piece of work, rather than working for hours in a row, changing too many things and then committing them is a great way to introduce issues that are hard to track down.
79
+
- Grab some free **Games** kept on Github: [https://github.com/leereilly/games](https://github.com/leereilly/games)
94
80
95
-
For example, if you want to change the position of an element, the colour of all the links on your page and the font size dimensions of all paragraphs, you should do three commits, using messages that describe what you are doing each time.
- Ideas for **cool projects** you can build or contribute to [https://github.com/open-source-ideas/open-source-ideas](https://github.com/open-source-ideas/open-source-ideas)
98
84
99
-
Every time you commit a change use a message that describes your change clearly. In a few months time you will have difficulty remembering why you applied a change if your messages say _changing some CSS_, _another commit_ or _more changes_
85
+
- Grab a copy of an extensive **Git Cheatsheet** for reference [https://github.com/arslanbilal/git-cheat-sheet](https://github.com/arslanbilal/git-cheat-sheet)
100
86
101
-
Try using messages such as _repositioned image to look better on page_ or _resolved positioning issue for Firefox_.
87
+
To find more projects, just enter a search in Github and see what comes back!
102
88
103
-
# The next step!
104
89
105
-
Sign up to [Github](https://github.com/)
90
+
## Key Terms and Definitions for Git
106
91
107
-
Download [Github Desktop](https://desktop.github.com/) (for Mac or Windows).
92
+
As with any technology and related tool, there's a lot of terminology related to Git and Github. Here's some of the most common terms and their definitions:
108
93
109
-
## Now what?
94
+
-**Repository**: A repository is where code is stored, it can be a local or remote repository. Also called a 'repo'
110
95
111
-
Now that you have the Github client setup on your machine, we will spend some time adding what you have created in the HTML & CSS lessons to an internet repository! Before you start make sure the Github client is running and you are signed in.
96
+
-**Clone**: Copy a repository so you can pull it down to your local machine and start editing the code
112
97
113
-
1. Create a new repository by clicking the `Create New Repository` button
98
+
-**Pull**: Get the latest version of code from a reposity
114
99
115
-
100
+
-**Push**: Send your code changes to the remote repository
116
101
117
-
2. In your text editor, open the directory you just created and create a README.md file with the following content:
102
+
-**Add**: Adds your chosen changes to the local Stage area, ready for a commit and push
118
103
119
-
_This is where I store the work I have done at codebar._
104
+
-**Stage**: An index of changes you are preparing to commit to the repository
120
105
121
-
3. Go back to the Github client and commit the file by filling out the `Summary` field and hitting the `Commit to master` button
122
-
123
-
106
+
-**Status**: Shows the state of the working directory and the Staging area
124
107
125
-
4. Now, create a new branch called **gh-pages**
108
+
-**Commit**: Applying any changes you have made into the repository
126
109
127
-
128
110
129
-
5. In the directory, create a subdirectory **lesson1** and move the **html** file you created at the first session and all the other relevant files and directories (e.g. /images)
130
111
131
-
6. Now, link the file from the root of your project by creating an `index.html` file and adding a link to the page
112
+
## Good Practices when Working with Git
132
113
133
-
```
134
-
<a href='lesson1/index.html'>Lesson 1 - Introduction to HTML </a>
135
-
```
136
-
> Don't forget to rename index to whatever you have named your file!
114
+
### Aim for small and focused changes
137
115
138
-
7. Commit your changes to the gh-pages branch
116
+
When using version control, you should commit every time you do a small piece of work, rather than working for hours in a row. Changing too many things and then committing them is a common way to introduce issues that are hard to track down. What's more, it makes it harder to review changes you made and need merging into the current code base.
139
117
140
-
118
+
For example, if you want to change the position of an element, the colour of all the links on your page and the font size dimensions of all paragraphs, you should do three commits, using messages that describe what you are doing each time.
141
119
142
-
8. Once you committed your changes publish your work by clicking the `Publish repository` button
120
+
### Write meaningful commit messages
143
121
144
-
122
+
Every time you commit a change use a message that describes your change clearly. In a few months time you will have difficulty remembering why you applied a change if your messages say _changing some CSS_, _another commit_ or _more changes_.
145
123
146
-
9. View your work on the web!
124
+
Try using messages such as _repositioned image to look better on page_ or _resolved positioning issue for Firefox_.
147
125
148
-
To access your work, go to `http://<username>.github.io/codebar`
126
+
### Always check for updates by others
127
+
When you come back to coding, be sure to `pull` any changes into your local repository that others may have committed to the repository since you last worked on the code. If there are changes you don't pull in you can get **Merge Conflicts**, where two sets of changes, the ones from other people and yours, need to be worked through to decide which change is kept. Resolving merge conflicts is notoriously tricky - small, frequent commits followed by a pull are a great way to avoid merge conflicts.
149
128
150
-
10. Repeat the process to list the rest of the tutorials you have worked on on the page as well.
151
129
152
-
## Bonus
130
+
## The next step
153
131
154
-
This is your personal page. Use what you learned in the previous lessons to style it, make it look pretty, and what we learned today to commit and publish your changes.
132
+
Get set-up with [Git and GitHub](../set-up/tutorial.html).
155
133
156
134
-----
157
135
158
-
This ends our _Introduction to version control and git_ lesson. Is there something you don't understand? Try and go through the provided resources with your coach. If you have any feedback, or can think of ways to improve this tutorial [send us an email](mailto:[email protected]) and let us know.
136
+
This ends our **Introduction to version control with Git** lesson. Is there something you don't understand? Try and go through the provided resources with your coach. If you have any feedback, or can think of ways to improve this tutorial [send us an email](mailto:[email protected]) and let us know.
0 commit comments