summaryrefslogtreecommitdiff
path: root/doc/gitlab-basics/start-using-git.md
blob: 3e3f96fb31f7ae9489fcd8d1976b1f7b9c343896 (plain)
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
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
---
type: howto, tutorial
---

# Start using Git on the command line

While GitLab has a powerful user interface, if you want to use Git itself, you will
have to do so from the command line. If you want to start using Git and GitLab together,
make sure that you have created and/or signed into an account on GitLab.

## Open a shell

Depending on your operating system, you will need to use a shell of your preference.
Here are some suggestions:

- [Terminal](http://blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line) on macOS
- [GitBash](https://msysgit.github.io) on Windows
- [Linux Terminal](http://www.howtogeek.com/140679/beginner-geek-how-to-start-using-the-linux-terminal/) on Linux

## Check if Git has already been installed

Git is usually preinstalled on Mac and Linux, so run the following command:

```bash
git --version
```

You should receive a message that tells you which Git version you have on your computer.
If you don’t receive a "Git version" message, it means that you need to
[download Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git).

After you are finished installing Git, open a new shell and type `git --version` again
to verify that it was correctly installed.

## Add your Git username and set your email

It is important to configure your Git username and email address, since every Git
commit will use this information to identify you as the author.

In your shell, type the following command to add your username:

```bash
git config --global user.name "YOUR_USERNAME"
```

Then verify that you have the correct username:

```bash
git config --global user.name
```

To set your email address, type the following command:

```bash
git config --global user.email "your_email_address@example.com"
```

To verify that you entered your email correctly, type:

```bash
git config --global user.email
```

You'll need to do this only once, since you are using the `--global` option. It tells
Git to always use this information for anything you do on that system. If you want
to override this with a different username or email address for specific projects,
you can run the command without the `--global` option when you’re in that project.

## Check your information

To view the information that you entered, along with other global options, type:

```bash
git config --global --list
```

## Basic Git commands

Start using Git via the command line with the most basic commands as described below.

### Initialize a local directory for Git version control

If you have an existing local directory that you want to *initialize* for version
control, use the `init` command to instruct Git to begin tracking the directory:

```bash
git init
```

This creates a `.git` directory that contains the Git configuration files.

Once the directory has been initialized, you can [add a remote repository](#add-a-remote-repository)
and [send changes to GitLab.com](#send-changes-to-gitlabcom). You will also need to
[create a new project in GitLab](../gitlab-basics/create-project.html#push-to-create-a-new-project)
for your Git repository.

### Clone a repository

To start working locally on an existing remote repository, clone it with the command
`git clone <repository path>`. By cloning a repository, you'll download a copy of its
files to your local computer, automatically preserving the Git connection with the
remote repository.

You can either clone it via HTTPS or [SSH](../ssh/README.md). If you chose to clone
it via HTTPS, you'll have to enter your credentials every time you pull and push.
With SSH, you enter your credentials only once.

You can find both paths (HTTPS and SSH) by navigating to your project's landing page
and clicking **Clone**. GitLab will prompt you with both paths, from which you can copy
and paste in your command line.

As an example, consider this repository path:

- HTTPS: `https://gitlab.com/gitlab-org/gitlab-ce.git`
- SSH: `git@gitlab.com:gitlab-org/gitlab-ce.git`

To get started, open a terminal window in the directory you wish to clone the repository
files into, and run one of the following commands.

Clone via HTTPS:

```bash
git clone https://gitlab.com/gitlab-org/gitlab-ce.git
```

Clone via SSH:

```bash
git clone git@gitlab.com:gitlab-org/gitlab-ce.git
```

Both commands will download a copy of the files in a folder named after the project's
name. You can then navigate to the directory and start working
on it locally.

### Switch to the master branch

You are always in a branch when working with Git. The main branch is the master branch,
but you can use the same command to switch to a different branch by changing `master`
to the branch name.

```bash
git checkout master
```

### Download the latest changes in the project

To work on an up-to-date copy of the project (it is important to do this every time
you start working on a project), you `pull` to get all the changes made by users since
the last time you cloned or pulled the project. Use `master` for the `<name-of-branch>`
to get the main branch code, or the branch name of the branch you are currently working
in.

```bash
git pull REMOTE <name-of-branch>
```

When you first clone a repository, REMOTE is typically `origin`. This is where the
repository was cloned from, and it indicates the SSH or HTTPS URL of the repository
on the remote server. `<name-of-branch>` is usually `master`, but it may be any existing
branch.

### View your remote repositories

To view your remote repositories, type:

```bash
git remote -v
```

### Add a remote repository

To add a link to a remote repository:

```bash
git remote add <source-name> <repository-path>
```

You'll use this source name every time you [push changes to GitLab.com](#send-changes-to-gitlabcom),
so use something easy to remember and type.

### Create a branch

To create a new branch, to work from without affecting the `master` branch, type the
following (spaces won't be recognized in the branch name, so you will need to use a
hyphen or underscore):

```bash
git checkout -b <name-of-branch>>
```

### Work on an existing branch

To switch to an existing branch, so you can work on it:

```bash
git checkout <name-of-branch>
```

### View the changes you've made

It's important to be aware of what's happening and the status of your changes. When
you add, change, or delete files/folders, Git knows about it. To check the status of
your changes:

```bash
git status
```

### View differences

To view the differences between your local, unstaged changes and the repository versions
that you cloned or pulled, type:

```bash
git diff
```

### Add and commit local changes

You'll see any local changes in red when you type `git status`. These changes may
be new, modified, or deleted files/folders. Use `git add` to first stage (prepare)
a local file/folder for committing. Then use `git commit` to commit (save) the staged
files:

```bash
git add <file-name OR folder-name>
git commit -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"
```

### Add all changes to commit

To add and commit (save) all local changes quickly:

```bash
git add .
git commit -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"
```

NOTE: **Note:**
The `.` character typically means _all_ in Git.

### Send changes to GitLab.com

To push all local commits (saved changes) to the remote repository:

```bash
git push <remote> <name-of-branch>
```

For example, to push your local commits to the _`master`_ branch of the _`origin`_ remote:

```bash
git push origin master
```

### Delete all changes in the branch

To delete all local changes in the branch that have not been added to the staging
area, and leave unstaged files/folders, type:

```bash
git checkout .
```

Note that this removes *changes* to files, not the files themselves.

### Unstage all changes that have been added to the staging area

To undo the most recently added, but not committed, changes to files/folders:

```bash
git reset .
```

### Undo most recent commit

To undo the most recent commit, type:

```bash
git reset HEAD~1
```

This leaves the changed files and folders unstaged in your local repository.

CAUTION: **Warning:**
A Git commit should not usually be reverse, particularly if you already pushed it
to the remote repository. Although you can undo a commit, the best option is to avoid
the situation altogether by working carefully.

### Merge a branch with master branch

When you are ready to make all the changes in a branch a permanent addition to
the master branch, you `merge` the two together:

```bash
git checkout <name-of-branch>
git merge master
```

<!-- ## Troubleshooting

Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.

Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->