A couple of git tricks
While reading the tutorial articles about the git version control system, I noticed one property, most of which are intended for the reader to understand all the advantages of a distributed version control system. In this section, they usually talk about remote repositories, branches, push-ups, pools, etc.
But there is such a moment in the use of a tool (especially if it is studied in different fakas, forums, articles on the Internet) when it seems that the knowledge on working with it has already been obtained enough, but you still feel that in some moments you swim a little. So it’s time to pick up a normal book and start reading it from cover to cover.
Of course, maybe this approach should be applied from the very beginning ... it cannot even be, but it should be applied from the very beginning, but, as usual, there is not always enough time, effort, desire, etc. for a normal study.
')
But the article, in fact, is not about that. I want to tell you about two great git commands that I recently discovered for myself. This is git blame and git bisect
Not rarely does a situation happen when you find some kind of bug in the code, it becomes terribly interesting, who wrote it all and when. (Of course, I also want to know what he thought about and how he pressed the buttons, but then of course the guitar is powerless)
git blame allows you to see when and by whom each line of the file was last edited.
Next team
will show
The output contains a short hash of the commit, the author, the date of the last change, and the code itself. You can quickly switch to the desired commit and understand the cause of the breakdown.
It is also worth noting that if for the command you specify the -C option, you can see where the necessary code fragment appeared initially in the repository, no matter to which file it was originally added.
It is surprising then to discover that the author of these changes is none other than yourself)
The second opportunity I would like to tell you about is the possibility of binary search by commits. For example, give the following situation. In our project, some functionality broke, what problem we cannot understand exactly, but we know for sure that in the last release this functionality worked exactly. So the bisect command allows us to easily roll back the project to a given number of commits and find the commit in which the elusive bug manifests itself for the first time.
First, we launch the search engine and set the value that the current state of the project is inoperative
Next, roll back to the working state of the project - 10 commits back in history.
We look, whether this bug is shown in a current status. Suppose now everything is fine with the project, so we continue to search further
This command rewinds the state of the project to the middle, between a good commit and a bad one, i.e., we are now five commits back in history. If the bug manifests, it is before the current commit, if not, then after. With each such iteration, the distance is halved until we find a bad commit (and most importantly, its author, unfortunately, we did it again).
After the search is completed, we reset the repository to its original state.
Returning to the introduction, I want to say that in teaching the gita for me, this book has become such a book that would dot the whole of e. It may not be the most detailed presentation, but, in my opinion, for the transition from the state “I can do it” to the state “I can do it and understand why it should be done that way” is a very good option. There is also its translation (albeit not quite complete) into Russian.
I want to finish my story on this, I hope the described functionality will be useful in the work not only for those who are just discovering git.
UPD.
For mercurial, this functionality also exists, thanks retran
blame - hg annotate
And for searching there is a special plugin - mercurial.selenic.com/wiki/BisectExtension
For svn there is
svn blame TARGET [@REV]
But there is such a moment in the use of a tool (especially if it is studied in different fakas, forums, articles on the Internet) when it seems that the knowledge on working with it has already been obtained enough, but you still feel that in some moments you swim a little. So it’s time to pick up a normal book and start reading it from cover to cover.
Of course, maybe this approach should be applied from the very beginning ... it cannot even be, but it should be applied from the very beginning, but, as usual, there is not always enough time, effort, desire, etc. for a normal study.
')
But the article, in fact, is not about that. I want to tell you about two great git commands that I recently discovered for myself. This is git blame and git bisect
File abstract
Not rarely does a situation happen when you find some kind of bug in the code, it becomes terribly interesting, who wrote it all and when. (Of course, I also want to know what he thought about and how he pressed the buttons, but then of course the guitar is powerless)
git blame allows you to see when and by whom each line of the file was last edited.
Next team
git blame -L 12,22 products.phpwill show
ebf9cf99 (vasia 2011-11-16 15:07:52 +0400 260)$templates = $controller->getTemplates(); ebf9cf99 (vasia 2011-11-16 15:07:52 +0400 261) foreach($templates as $value) The output contains a short hash of the commit, the author, the date of the last change, and the code itself. You can quickly switch to the desired commit and understand the cause of the breakdown.
It is also worth noting that if for the command you specify the -C option, you can see where the necessary code fragment appeared initially in the repository, no matter to which file it was originally added.
git blame -L 10,19 -C Controller.php 3351a8dc /logistics/pages/Controller.php (vasia 2012-01-24 15:26:04 +0400 10) 0cb0d219 /orders/pages/Controller.php vasia 2012-01-13 09:51:54 +0400 16) It is surprising then to discover that the author of these changes is none other than yourself)
Binary search
The second opportunity I would like to tell you about is the possibility of binary search by commits. For example, give the following situation. In our project, some functionality broke, what problem we cannot understand exactly, but we know for sure that in the last release this functionality worked exactly. So the bisect command allows us to easily roll back the project to a given number of commits and find the commit in which the elusive bug manifests itself for the first time.
First, we launch the search engine and set the value that the current state of the project is inoperative
git bisect start git bisect bad Next, roll back to the working state of the project - 10 commits back in history.
git bisect good HEAD~10We look, whether this bug is shown in a current status. Suppose now everything is fine with the project, so we continue to search further
git bisect goodThis command rewinds the state of the project to the middle, between a good commit and a bad one, i.e., we are now five commits back in history. If the bug manifests, it is before the current commit, if not, then after. With each such iteration, the distance is halved until we find a bad commit (and most importantly, its author, unfortunately, we did it again).
After the search is completed, we reset the repository to its original state.
git bisect resetReturning to the introduction, I want to say that in teaching the gita for me, this book has become such a book that would dot the whole of e. It may not be the most detailed presentation, but, in my opinion, for the transition from the state “I can do it” to the state “I can do it and understand why it should be done that way” is a very good option. There is also its translation (albeit not quite complete) into Russian.
I want to finish my story on this, I hope the described functionality will be useful in the work not only for those who are just discovering git.
UPD.
For mercurial, this functionality also exists, thanks retran
blame - hg annotate
And for searching there is a special plugin - mercurial.selenic.com/wiki/BisectExtension
For svn there is
svn blame TARGET [@REV]
Source: https://habr.com/ru/post/137408/
All Articles