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 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:
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.
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 or BitBucket. 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, 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
Top comments (0)