Back to Basics #2 - Git Basic
Tags: git, github, linux, beginners
Published: 2020-06-23 00:13:37

There was a time when developers didn't control very well changes made by an entire team on a project. I did not live that time and I believe you have not lived it either. However, many companies today still suffer to implement version control of the software produced by the development team. Folders like "Final", "Final 2.0", and "FINAL FOR REAL THIS TIME" still exist on many development teams and that is sad to say the least. For this reason, it is essential that developers know how to do this version control in the right way, understanding that controlling changes in the work and recording who made each change in the right way is a piece of cake.

## Knowing Git

Git is currently the most widely used version control system in the world. This is due to its ease of use, to how lean it has been since its development and also because it is a native technology on all machines that run a linux kernel. In fact, Git is an invention of our friend [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) and arose out of a real need (as all good ideas emerge): as soon as Linux stopped being just an individual project and Linus decided to share it with some friends, many changes in files did not make sense or, at least, did not feel like it at first glance. For Linus, this demonstrated some important needs when working as a team on that project that he loved:

- It is necessary for the developer to add some kind of explanation for the change that was made so that no one gets lost when seeing a changed and possibly unreadable code;

- It is necessary that the change is recorded with its date, a history of the old data compared to the new data and who is responsible for that change;

- It is necessary that these changes if they are interpreted as unimportant or unproductive, can be discarded without harming the legacy code, or simply what was there before the change;

With that in mind, Linus created Git. Git separated the legacy code into a priority _branch_, requiring each developer, wishing to make a change, not to change that _branch_ directly, but to copy a new _branch_ in which he would include his modifications and, later, submit a request for _merge_ with the priority _branch_. That way, he would be able to control the legacy code and choose for himself what should and shouldn't be changed in his code.

## The tree metaphor

Perhaps it is a little difficult for some people to understand the concept of _branch_. For English speakers, the metaphor is a little more intelligible, as it applies to other areas, as in the case of companies that have headquarters (_head offices_) and offices (_branches_), but the thing is very simple to understand:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/hsaqkzk20twvet9juznx.png)

In the example above, we see in blue what the priority _branch_ would be. After its second version, a developer wants to program a new feature or a fix. What it does is open a second _branch_, represented in purple. Thus, both the priority _branch_ does not need to stop its advance hoping that this new functionality will get out of the way in the workflow: both evolve in parallel. The same process can be seen later in the example shown in green.

An essential fact to understand the Git version control that is not shown in the image is the aforementioned _merge_. _Merge_ occurs when the developer finishes the functionality he had in mind when developing his _branch_. The objective is to make this functionality enter the legacy code, in the priority _branch_. _Merge_ can be understood as a blend, a process that keeps what's there and inserts what's new without breaking everything.

Thus, we can see that version control behaves following the metaphor of a tree, in which there is a trunk (the priority _branch_) and for each change, a branch is created that carries with it all the properties of the tree to which it belongs.

## What about Github?

Github is a web interface for viewing the flow of Git. It is something like a social network for controlling and viewing Git repositories and version controls that previously were only on one machine or on a private network of users. We can say that Github is for Git as Wix is for Front End development. It allows this technology that was made thinking about enabling and improving collective software development to be even broader, more collaborative, and easier to use.

## Hands-on

Now that you know a little more about why Git exists and its importance for a developer, it's time for you to get your hands dirty and unlock your skills with Git (and Github) once and for all!

First, if you don't already have a Github account, create now at [Join Github](https://github.com/join).

### Repositories

Repositories can be local or remote. Local means that it is being saved on your machine, with version control registered on your computer. A remote repository is a code repository that has its version control and _branches_ stored in an online repository distribution and control portal, such as Github, [GitLab](https://about.gitlab.com/) or [BitBucket](https://bitbucket.org/). By copying a remote repository, you can join the workflow of a new or ongoing project, bringing to your computer the code of all _branches_ that you are authorized to access and change.

### Adding remote repositories

As already mentioned, remote repositories are versions of projects that are stored somewhere on the internet. Adding a remote repository is basically telling your Git where your code is being stored. You can add it using the URL for the repository (or for some user's fork).

```
git remote add <name> <repository-url>
```

The ** name ** is a unique remote repository name on your machine. It can be anything, but it necessarily needs to be different from other names you've already given for repositories you've already added.

To see the list of remote repositories you have already added, run the following command:

```
git remote -v
```

### Changing remote repositories

You may want to change the URL assigned to any of the remote repositories you have added.

To do this, use the following command:

```
git remote set-url <valid-repository-name> <new-url>
```

Remember to run _**git remote -v**_ after changing the URL to confirm that your change worked.

### Creating a branch (locally and remotely)

Then you choose a repository (or create it) and want to start coding. Okay, but before that you need a _branch_ to call yours. To create a _branch_ locally, run the following command:

```
git branch <new-branch-name>
```

Next, check if your _branch_ is listed among your _branches_ with

```
git branch
```

To change work _branch_, just run
```
git checkout <branch-name>
```

To simplify the job and you don't have to create a new _branch_ and do the _checkout_ with two commands, just use the following command:

```
git checkout -b <new-branch-name>
```

Cool, now your new _branch_ is created locally! Now, assuming you've made some pretty cool changes to the code and want to upload a [Pull Request](https://help.github.com/pt/github/collaborating-with-issues-and-pull-requests/about-pull-requests), you just need to execute the following commands:

```
git add .
git commit -m 'Your commit description'
git push origin <branch-name>
```

The first command (_**add**_) adds the changed files to your _commit_, the point indicates that all changed files should be added to _commit_. If you want to add only one or more changes, just add the file path for the change. In case you don't remember the path, just use the command that lists all the changes:

```
git status
```

The second command (_**commit**_) creates a new commit for your _branch_. The **- m** flag is for you to add the _commit_ message directly in the same command, which is the parameter that follows next between single quotes.

### Deleting a _branch_ (locally e remotely)

To delete a local _branch_, there is no secret. Just use the command::

```
git branch -d <branch-name>
```

Always remember to confirm that the _branch_ was actually deleted using _**git branch**_.

To delete a remote _branch_, just use the following commando:

```
git push origin --delete <branch-name>
```

Remembering that for Git, **_ origin_** indicates the origin of this repository, that is, the repository that is online, while its copy is remote. That is why the reference **_origin_** is used.

### Undo a _commit_

To undo a commit locally, just use the command _**git reset**_. For example, if you want to undo your last _commit_, run the following command:

```
git reset --soft HEAD~1
```

The **_--soft_** flag keeps changes made to files you added to _commit_, only _commit_ is reversed. However, if you prefer to revert _commit_ and the changes made and added to it, run this command in place of the previous one:

```
git reset --hard HEAD~1
```

The parameter _**HEAD~1**_ points to your last commit. If you prefer to undo any previous _commit_, you can use the command **_ git reflog_** to have a record of all previous _commit_. Having access to the previous _commits_, just use the same command _**reset**_ replacing _**HEAD~1**_ with the hash referring to the _commit_ that you want to undo:

```
git reset --soft <commit-hash>
```

To undo a remote _commit_, you can use the command **_git revert_** to undo the _commit_ locally and then _**push**_ changes to the remote _branch_.

To do this, first run _**reflog**_ and then _**revert**_:

```
git reflog
git revert <hash-do-commit>
```

Finally, push it to the desired remote _branch_.

**Did you like the article? Do you think there was a missing question to be addressed?**

**Please comment and let me know if this content helped you in any way.**

_**See you later, aligator!**_

_Originally posted in Portuguese [here](https://lucasrafaldini.github.io/blog/2020/06/22/back-to-basics-o-basico-do-git)_