Git Fundamentals (Tutorial): Difference between revisions
Lucasadmin (talk | contribs) Created page with "First of all, we begin by configuring our user name and e-mail address. Thanks to the option --global, the specified parameters will be applied to all the repositories that we create on our machine. 500px|center We now create a folder (mkdir) where we will initialize the repository (git init). 500px|center By using git status, we can check the state of the repository. Currently, no commits have been ma..." |
Lucasadmin (talk | contribs) No edit summary |
||
Line 122: | Line 122: | ||
If we need to undo a modification that has already been pushed, then it is preferred to use the command git revert, which will create a new commit to undo the changes. | If we need to undo a modification that has already been pushed, then it is preferred to use the command git revert, which will create a new commit to undo the changes. | ||
[[Category: Tutorials]] | |||
[[Category: Git]] |
Latest revision as of 14:29, 19 November 2024
First of all, we begin by configuring our user name and e-mail address. Thanks to the option --global, the specified parameters will be applied to all the repositories that we create on our machine.
We now create a folder (mkdir) where we will initialize the repository (git init).
By using git status, we can check the state of the repository. Currently, no commits have been made, and there are no files available to be commited.
Using a flat text editor, we create a text file called README.txt on the folder where we have initialized our repository. Add some text to this file and save it.
If we execute now the git status command, we can see that the newly created file is detected by git, and flagged as "untracked file".
We can indicate Git to begin tracking the file by using the command git add. By checking again the status of the repository, we observe that README.txt is now flagged as "to be committed".
The whole of the files flagged as "to be committed" can be committed by using the command git commit. The option -m allows to add a message to be associated with the commit, which will help to understand which are the changes implemented by each commit when we revise the history of commits later.
If the status of the repository is checked again after the commit operation, we can see that, once again, Git tells us that there are not any changes pending to be committed. However, notice that the message "No commits yet" has disappeared, since we have effectively registered our first commit.
Now, we add some modifications to README.txt and we save the file.
By using the command git status we can see that README.txt is flagged as modified. If this is not the case, please verify that you have effectively saved the file after including the modifications.
By using the command git diff, Git shows to us the modifications that have been made to the file.
Following the same procedure as above, we can add the file to the staging area and commit the modifications.
Let's now simulate that we make an undesired modification to our file, so we make a typo voluntarily and then we save the file.
If we check the status of our git repository, the README.txt file appears as modified. We can undo this modification by using the command git reset --hard.
If we now check the file, we find out that the typo has been removed. The state of the file is that of the last commit.
The command git log allows us to visualize the history of our repository. By adding the flag --graph, git will decorate a bit the displayed information, in order to make it easier to understand.
Let's now simulate that we introduce an error to our document and that we accidentally commit the file with this erroneous information. First, we write the name of the authors of the poem, but we are not very strong in Spanish romantic poetry and we type the name of another author and save the file.
After this, we commit our changes as we have been doing in the former steps.
If we check the log of the repository, we can see that there is a new commit corresponding to this new modification.
Suddenly, we realize that Becquer is not the author of the poem, and we remember that the correct author is Espronceda. Since we are in a very simple scenario, it would be quite easy for use to just modify the line of README.txt with the line of the author and make a new commit. Although this is a viable solution in this scenario because the modifications to correct are not very significant, in the real world we will probably find ourselves in a situation where we need to roll back to a previous commit because it is not practical to undo the modifications manually.
We can achieve this by using the command git reset --mixed HEAD~. HEAD~ indicates to git that it must come back one commit from the current position of the HEAD pointer. We could use HEAD~N (being N a natural number) to indicate a greater number of commits for the roll back. In addition, the option --mixed indicates Git to roll back in the project history but keep the changes in the files.
This means that if we check the status of the repository, README.txt will appear as modified.
By using the diff command, we can see that these4 modifications correspond to the author name.
However, checking the log we can see that this modification does not make part of the history of the repository.
If we now want to definitely suppress these changes from README.txt, we can use the command git reset --hard as we did before.
And verify that the text file does not contain the name of the wrong author anymore.
Instead of this two step process, we could have directly used git reset --hard HEAD~. This would have make the project roll back one commit and discard any modifications. Nevertheless, this can be a dangerous operation, since we are not verifying the changes that are going to be discard. For this reason, it is preferred to do a --mixed reset and, after verifying that the current state of the project is as desired, permanently discard the undone changes.
We add now the correct author name to the poem and save the file.
After this, we commit this modification but we accidentally make a typo when introducing the commit message.
The misspelled message is now registered in the project history for all the eternity... Unless we do something to correct it!
The command git commit --amend allows us to modify the last commit. If we add other files (git add filename) before launching it, we can incorporate additional modifications to the commit. In addition, thanks to the amending operation we can also specify a new commit message.
If we check now the history of the repository, we see that the typo has is corrected.
It is important to emphasize that the reset and amend operations should not be used on commits that have already been pushed to a git server, since they make create a conflict with the work of other developers. We should only use this operations on commits that have not yet been pushed to the server.
If we need to undo a modification that has already been pushed, then it is preferred to use the command git revert, which will create a new commit to undo the changes.