By J.Pisi - TheExpert Developer at SQUAD

Git explained in my own words
After completing my training, I noticed that Git was mentioned very often in job offers. Eager to add a line to my resume, I jumped on Grafikart's tutorial to try to learn a little more about this tool. The goal: not to be completely lost on my first day at work. Here are some simple explanations and a compilation of some of the commands you might encounter in the sometimes hostile jungle of development and organizational tools.
What is git?
Yes, let's start with something simple. It's a versioning tool. It allows you to save different versions of your code. Basically, it's like saving in a video game, without systematically overwriting the last one, so that all your progress is preserved. This way, if you want to replay a section, you can do so using the history. Git allows you to view this history accurately (for better readability, be precise and concise when naming a version).

How do I make a backup?
There are several ways: with a graphical interface via GitHub, or via command line using a terminal*lightning streaking across the sky*. We're not afraid, we'll take the second option! Oh, and by the way, since we're on the console, git help, git commit -help, and git (action) -help will be your friends!
Which gives us:
- After opening my terminal, I navigate to the correct folder using the "cd" command (e.g., cd documents/programming/my-project).
- If it has never been done before, I run "git init" to tell Git that it needs to monitor this folder (it will create a directory).
- I use "git add -all" to tell Git tostage all files to be saved.
- We're almost there: "git commit -m" to save a version of the project at this point. Here, "-m" allows you to write a comment on the progress of the project.Example: git commit -m "Addition of the newsletter."
- "git status" tells me if everything is OK (so use it often).
- "git log –oneline" allows me to see how far I've come by listing all the commits I've made (see image above).
Travel through time!

Thanks to the "checkout" command, you can sort of go back in time. The idea is this: you ask Git to show you what the code looked like in version -n. If you open your directory and your text editor after this command, everything will be back to how it was, but your work will not be lost.
How to do it:
- Preparation: "git status" tells me that everything is fine, and "git log –oneline" displays all commits.
- I use "git checkout" + "code" provided by git log. This is a series of numbers and letters naming the versions and preceding your comments. Example: "git checkout 42e9cf6." You can also do "git checkout 42e9cf6 index.php" to see only one file.
- The "HEAD" is now positioned on the desired commit. What is the HEAD? It represents where you are. If I continue with the time travel analogy, it's the moment when you parked your DeLorean.
- To revert to the most recent version, use "git checkout" + "code" or "git checkout master" (we will come back to this syntax later, with branches).
This mode does not allow you to modify history. If you make changes anyway, Git will not know what to do with them and they will not be attached to any branches.
Change history
So from now on, be careful. Git allows us to modify the commit history. Before going into more detail, keep in mind that this can only be done locally! There are several reasons why you might want to modify the history:
- simply to clean it up and make it more readable.
- return to a version that worked (case of sadness).
A) Merge commits

If I have too many commits and they are not relevant, I can choose to merge some of them using rebase.
- I identify how many commits are affected (git log –oneline).
- I switch to the most recent commit. (git checkout + code).
- "git rebase HEAD~n" (where n represents the number of previous commits targeted) or "git rebase HEAD^" (where each accent represents a previous commit). Example: HEAD~3 === HEAD^^^.
- As it stands, and if you are on Linux, the terminal switches to "nano" mode (*lightning streaks across the sky, again*). We read everything! Many options are available, but it is "squash" that interests us. So we're going to write "squash" instead of "pick" only on the commits we want to integrate into the main branch. Press |ctrl| + |x| and nano will ask us which message to keep. Delete, rewrite, as you wish, and press |ctrl| + |x| again.
- Everything went well, you returned to the terminal, and Git informed you in its poetic prose what it had done.
- There has been a problem... Git will report a conflict between versions (often duplicates). You will need to open your text editor: Git has the good sense to highlight the areas of conflict. Simply delete the content that is bothering you, save, run git commit again, and finish the process with "git rebase --continue."
- Everything is fine! "git log –oneline" to see with our own eyes that everything went well.
- Alert/I'm lost! "git rebase –abort" to undo all of this.
B) Revert: Undo a commit
This function allows you to cancel a commit, and this cancellation will be the subject of a new commit... In other words, undoing a commit is an action that impacts the project and, as such, it appears in the history.
- "git log –oneline" (El Famoso).
- "git revert" + "code".
- Nano allows you to edit the message, |ctrl|+|x| to confirm.
- Back to the terminal, "git log" to check, and it's done.
C) The RESET
At this point, you're starting to play with fire, as any actions you take will be permanent. Concentration, calmness, and careful consideration are required. This mode allows you to clear your history to make it more readable or revert to a previous version. How is this different from revert? These changes will not be committed, meaning you won't receive a notification that a deletion has been made.
- "git reset": allows you to undo the last "git add." So far, so good.
- "git reset --soft" + "code": HEAD reverts to this commit, deletes all subsequent commits, but keeps the changes in your text editor "staged," as if you had run "git add."
- "git reset –mixed" + "code": default mode. Works like the software except that you have to do the "git add" yourself.
- "git reset –hard" + "code": same as above, but also deletes all the changes you made in your editor. You travel back in time to when you were 15, and boom! You're 15 again and have forgotten everything that happened since then! In other words, it's "game over" and you're back to your last save point. Don't mess around with something that has "hard" in its name!
There you have it, we've covered all the main commands except for one. The one that will give your organization another dimension! Or rather, dimensions would be more accurate.
"Branch"
Until now, we have only used one branch, called "master." This would be sufficient if we were working alone, but the problem is that we would quickly become overwhelmed with commits. Git allows us to create branches to make our work clearer.
What is a "branch"? It can be translated as a branch or offshoot, like that of a tree, but I don't think that's the best image. Once the work on a "branch" is complete, it is brought back to the main branch and the one that is no longer needed is deleted. Here is a nice illustration.

With this image, I don't really see a tree, but rather two railroad tracks that separate and rejoin. But the best comparison is a car factory assembly line.

Thus, a "branch" is used to develop a specific feature before being deleted, with the master branch only accepting commits when they correspond to a certain stage of progress in the project.
Which gives us the following code:
- "git branch" allows me to list the branches.
- "git branch" + "name" to create a new one. Example: "git branch wheels" (where I will find commits for wheels or tires, for example).
- "git checkout" + "branch name" to move the HEAD.
- Use all the functions we saw above.
And to bring the work back to the master, we will use the "merge" command:
- "git checkout master" to move to the main branch.
- "git merge" + "branch name" (wheels in our example).
- "git branch wheel -d", we work cleanly and delete what is no longer useful.
Remote deposit
Until now, we have been working locally. Git also allows us to use a remote repository: a remote (literally "at a distance"). This is a shared folder where everyone can send their work (and retrieve that of others). It can be a USB key, a Dropbox, another file on the same computer, etc. We can also use services such as GitHub or Bitbucket.
How it works:
0/ If you are not using a third-party service, you will need to use "git init –bare" on the folder that will serve as the remote repository.
1/ "git init remote add" + "name of remote" + "path." To initialize the remote repository. By convention, it is called origin. Example: git init remote add origin url.
2/ "git remote -v" allows me to list repositories and "git branch -r" allows me to list remote branches.
3/Let's say I join an ongoing project. I run "git clone" + "path" + "name of the folder where it should be cloned" to retrieve the entire project. If I only want part of it, I add "–depth n" (where n is the number of commits I want to retrieve, starting with the most recent). Example: git clone url golf-site –depth 4
4/ "git push" + "remote" + "branch" allows me to send my work. Example: git push origin master.
"remote contains work that you don't have locally," Caramba! Someone pushed before me! Just update me with a little:
4b/ "git pull –rebase origin master." Note the presence of rebase: it is used to merge cleanly. This means that the annotation "merge of" will not appear in the commit name, making it easier to read. All that's left to do is redo my push from 4/.
5/ "git push origin –delete branch" allows me to delete the remote branch once the feature has been developed.
WHOO!!!
Are you still there? Well done! It's not easy to read all that in one go. I hope you found it useful. We've covered the basics of command lines. Beyond "simple" technical considerations, Git is a management and organization tool that can be used in several ways. One of them is Git Flow. I was planning to talk about it, but...

I'm not ready...
There you go. One last word about GitHub. It offers the possibility to make these commits by drag and drop. Above all, it offers a system of:
- Issues: for reporting problems.
- Fork allows you to clone someone else's work, work on it, and create a new branch #bestPractices.
- Pull Request to submit the branch we just created to the project owner.
In my production environment, we use gitKraken, which offers a graphical interface with attractive colors to represent the different branches. That said, having some basic command line knowledge, at least to name the actions, has been very useful.
Happy coding \o/
The grafikart tutorial:
image credits @deviantart:
Pepe-silvia redrawn by Cicadaqueen
Doc Emmett Brown by ambellinaleander
Goten & Trunks by Vegetaslittlelover
