- Github pull request meaning full#
- Github pull request meaning code#
That it is not so stable to be used for our needs. (npm) - I tried and in the end came to the conclusion, Then use adapter to make it compatible with current ASTReader processing logic.Īs prerequisites I've looked through the following packages: I considered to use PEG-based parser to generate custom AST from assembly code,
Github pull request meaning code#
Brief results of discussions with the team, which will help to understand why certain decisions were made.Īn example may look like following: # PremiseĪs we have grammar description and access to an assembly code even from AST,.If you were forced to refactor some function due to it being poorly implemented or affecting your implementation in some way, then it would be better to explain why such change was considered as necessary. If you discovered that the existing code is disturbing you, then it should be outlined.You can also describe key points that will help to understand the changes that will follow.
If there was research about a task-related topic or an investigation for a different implementation approach, then you should provide links to the articles that were helpful in understanding the solution. You should also state the final reason why you have chosen a specific package for the integration into the project. If you made a choice between possible packages and chose the most suitable one, then you should provide links to each package, then describe its “pros and cons” for solving the particular problem. This section is dedicated to preliminary research or other things that were preceding the applied changes. Anyway, there is no need to do that if the changes are backed up by a meaningful description. This becomes even more relevant over time - since after like six months, it will be difficult to remember why the particular change was made. In such cases, you can always refer to the description, where the most important points have already been clarified. You won’t need to answer additional questions about the implemented changes. In the end, this will help to avoid bugs, since if your code needs to be altered in some way, colleagues can find out the requirements for its logic and pay attention to the relevant details. Project colleagues while looking at your commit can find a PR with a description of the changes made and a link to the task with related discussions. There is no longer a need to spend time asking questions, like “Why did you pick this implementation path and not another?” or “ Why did you choose the particular approach or selected some dependency?” 
Reviewers no longer have to guess what you wanted to achieve with the changes. Let’s list the project members, who can benefit from the properly described PR: In this way, the author would save the time and effort of the project team. When the coding part is done, the author of the changes could dedicate some time to the general description of PR, while everything is still fresh in memory. If not, then you will have to answer the questions like “where does this code come from and why is it needed here?”Īs a reviewer, I don’t feel joy during a PR review if I have to spend extra time to understand the logic of code and commits, because the author did not bother to write a proper description. It is good, when the discussion was conducted in the issue tracker or, verbally or in the chat, and was written in the form of short results. Github pull request meaning full#
Providing context for PR is useful since the task itself and its discussion might be not sufficient enough to understand the full picture of the changes.
0 kommentar(er)
