🆘 NEED HELP? 🆘 Book a 1:1 Consultation with CoderDave: geni.us/cdconsult We can talk about GitHub, Azure DevOps, or any other DevOps tool or project you need help with! 🙏🏻SUPPORT THE CHANNEL🙏🏻 Buy me a coffee: www.buymeacoffee.com/CoderDave PayPal me donation: paypal.me/dabenveg
Haha right... I’m trying posting videos at different times to see the response... from my perspective it’s still Friday 😁(this was at 1 am 😄) I have a live next Tuesday 3pm, curious to see how many people (if any) will show up since it’s too late for US...
Hey Dave, thanks for the video. After getting email notification from the reviewer, how do I fix changes ? 1. Do I update the PR fixes within the git ? (which will be big hassle) 2. Raise new PR with the fixes ? Please do advice and if possible please make a video. Thank you!
Hey there. If the reviewer asked for changes, there are 2 things you can do. 1. If you visit the PR page on GitHub, you will see the review. If the reviewer has proposed some changes, you can "accept them" directly and commit via button-click on the PR directly 2. If instead there are no proposed changes, but just text comments asking you to change something, you can simply keep committing to the same branch on your local computer, and when you push it to the origin (GitHub) you will see the content of your PR changing
On very large PRs I prefer the individual comments because then we can work in parallel: the other developer can already start thinking about my comment and potential changes, while I can continue reviewing. But I guess for smaller ones I should use the Start a review. Also will try the "suggestion" function, havent done that yet 😅
I see your point. However, I have 2 comments. First, if you use the single comment, the PR opener will be flooded by notifications :D and if there are more than 1 reviewer... well... notifications hell haha Second, in my opinion there should never be a huge PR... work, to be optimal, should always be split in smaller chunks... that is much easier to handle ;)
Hey there, I think this is a great introduction, to me more complex questions arise. So: Like as you've mentioned, usually there are bigger PRs, so there are like 20 changes. After pushing from the DEV side, this interface seems to be completely useless to me. As a reviewer I want to re-check the code adaptions. So when checking the interface many things are "outdated" now. I cannot see the change. Or they are still valid, but I can also NOT see the change. I definitely remember on prior versions to be able to see all the changed parts of code, even with those comments. For me it's really hard to work on those comments now. Do you have and ideas / suggestions / proposals for that way? All the best, stay safe!
Hey 👋 I guess you mean after having other changes pushed to the branch, right? I’m the PR you still have the list of commits, so you can check that to see what changed. And also after merging the PR to the target branch you can rely to the change sets (list of commits), because the whole set of commits is preserved together with the comments (unless you do a squash merge)
@@CoderDave That doesn't work as of today. I click on "Show changes since your last review", which seems to be a very useful tool, but the previous comments are all gone. What I want to see is: 1. The comment I previously made 2. How the code was when I made this comment 3. The new code that pretends to be fixing the comment I made bonus: why does the commiter have the power to resolve the comments? That just seems ridiculous to me. They should be able to ack the comment, and say that they attempted to fix it, but it's should be the reviewer's responsibility to mark the conversation as resolved.
@@BruceRicard This is an excellent question. I get his points about doing the review then comments, but afterwards...handling comment updates, marking the conversation as resolved, and seeing changes over time all seem a bit confusing. Another PR can be submitted, but then you have to open the old pr along with the new to see what was updated based on your previous comments.
This question is why I watched this video in the first place. As far as I can tell, Github doesn't have a good answer especially if you use a rebase workflow like we do. Which is truly unbelievable. Guess it's time to finally pull the trigger on a Gitlab migration.
@@AlecThilenius While I have not used it directly, I have a colleague who is using vscode to review his Pull Requests, and all the issues mentioned above that everyone is having seem to be fixed with it. I have tried investigating a solution like GitKraken, and their solution for Pull Requests just doesn't seem to fix the above issues.
Hello. Nice video, thanks. Question for you, is there a way, to see the list of files that are modified in a tree view or something like it? I came from Bitbucket where there was the list of file on the left and on the right pane, all changes. It was really easy to see all files that changed for this particular Pull Request.
hey! Unfortunately it is not possible out of the box, but you could use an extension like this one: chrome.google.com/webstore/detail/better-pull-request-for-g/nfhdjopbhlggibjlimhdbogflgmbiahc
Hey Daniel, great news! Looks like the folks at GitHub hear you! There is now the beta available for the file tree in PRs. Just go to your user settings > Feature Preview > Pull Request File Tree > Enable No go to a PR, and in the Files tab you will se the new file tree layout 🥳🥳🥳
@@CoderDave Thanks, I just saw that yesterday. We found at work another way also, just click on . On your keyboard, it will open a Visual Studio Code inside Chrome. So it is easier to do the code review.
Happy to be helpful. The problem about merge conflicts is that they are highly dependent on the language you use, and each conflict is different from another one so not sure how helpful a video like that could be 🤔
@@CoderDave yes, that is a fair point. and in my case, though i use windows as my desktop, all my coding is linux-based and i don't use C# or azure. having said that, many merge conflicts are to do with getting tangled up (or lost) in git and trying to understand the many (imo) weird error messages that git throws and the many different commands one needs for stashing, cleaning, unstaging, etc etc. thus some merge conflict walkthroughs might actually be very useful for almost anyone trying to get to grips with git at a higher level.
I don't know why Google showed you my content... but on a video titled "How to Review a Pull Request" you commenting "Why are you talking about Pull Requests" makes me think that perhaps it is not Google's fault...
🆘 NEED HELP? 🆘
Book a 1:1 Consultation with CoderDave: geni.us/cdconsult
We can talk about GitHub, Azure DevOps, or any other DevOps tool or project you need help with!
🙏🏻SUPPORT THE CHANNEL🙏🏻
Buy me a coffee: www.buymeacoffee.com/CoderDave
PayPal me donation: paypal.me/dabenveg
Ah, another "three minute Thursday here in the US" : - ) Seriously, I like these and know why you post them at this time. A good one today!
Haha right... I’m trying posting videos at different times to see the response... from my perspective it’s still Friday 😁(this was at 1 am 😄)
I have a live next Tuesday 3pm, curious to see how many people (if any) will show up since it’s too late for US...
Thank you very much! 3 mins and I am off to do my review. Very efficient :-)
Glad it was helpful!
simple and to the point. Great one.
Happy you liked it 😀
thank you so much！I'm new to code review and this video helps me know how should i start it
Very happy to know it help ☺️
Hey Dave, thanks for the video. After getting email notification from the reviewer, how do I fix changes ?
1. Do I update the PR fixes within the git ? (which will be big hassle)
2. Raise new PR with the fixes ?
Please do advice and if possible please make a video. Thank you!
Hey there.
If the reviewer asked for changes, there are 2 things you can do.
1. If you visit the PR page on GitHub, you will see the review. If the reviewer has proposed some changes, you can "accept them" directly and commit via button-click on the PR directly
2. If instead there are no proposed changes, but just text comments asking you to change something, you can simply keep committing to the same branch on your local computer, and when you push it to the origin (GitHub) you will see the content of your PR changing
On very large PRs I prefer the individual comments because then we can work in parallel: the other developer can already start thinking about my comment and potential changes, while I can continue reviewing.
But I guess for smaller ones I should use the Start a review. Also will try the "suggestion" function, havent done that yet 😅
I see your point. However, I have 2 comments. First, if you use the single comment, the PR opener will be flooded by notifications :D and if there are more than 1 reviewer... well... notifications hell haha
Second, in my opinion there should never be a huge PR... work, to be optimal, should always be split in smaller chunks... that is much easier to handle ;)
Great in short. Thanks a lot. I was searching for it.
Happy to help :)
Hey there, I think this is a great introduction, to me more complex questions arise.
So: Like as you've mentioned, usually there are bigger PRs, so there are like 20 changes.
After pushing from the DEV side, this interface seems to be completely useless to me. As a reviewer I want to re-check the code adaptions. So when checking the interface many things are "outdated" now. I cannot see the change. Or they are still valid, but I can also NOT see the change.
I definitely remember on prior versions to be able to see all the changed parts of code, even with those comments.
For me it's really hard to work on those comments now.
Do you have and ideas / suggestions / proposals for that way?
All the best, stay safe!
Hey 👋 I guess you mean after having other changes pushed to the branch, right?
I’m the PR you still have the list of commits, so you can check that to see what changed.
And also after merging the PR to the target branch you can rely to the change sets (list of commits), because the whole set of commits is preserved together with the comments (unless you do a squash merge)
@@CoderDave That doesn't work as of today. I click on "Show changes since your last review", which seems to be a very useful tool, but the previous comments are all gone. What I want to see is:
1. The comment I previously made
2. How the code was when I made this comment
3. The new code that pretends to be fixing the comment I made
bonus: why does the commiter have the power to resolve the comments? That just seems ridiculous to me. They should be able to ack the comment, and say that they attempted to fix it, but it's should be the reviewer's responsibility to mark the conversation as resolved.
@@BruceRicard This is an excellent question. I get his points about doing the review then comments, but afterwards...handling comment updates, marking the conversation as resolved, and seeing changes over time all seem a bit confusing. Another PR can be submitted, but then you have to open the old pr along with the new to see what was updated based on your previous comments.
This question is why I watched this video in the first place. As far as I can tell, Github doesn't have a good answer especially if you use a rebase workflow like we do. Which is truly unbelievable. Guess it's time to finally pull the trigger on a Gitlab migration.
@@AlecThilenius While I have not used it directly, I have a colleague who is using vscode to review his Pull Requests, and all the issues mentioned above that everyone is having seem to be fixed with it. I have tried investigating a solution like GitKraken, and their solution for Pull Requests just doesn't seem to fix the above issues.
simple and to the point, great one ♥
Glad you liked it!
Thanks a lot!! Simple and straight to the point!!
Happy you found it helpful!
Thank you good tip, I will share this with my team.. subscribed !!
Thanks! Yes it’s something simple but pretty effective 😉
Excellent video, just what I needed🎉
Glad it was helpful!
Thanks mate, quick and informative
Thanks! Always happy to help ☺️
amazing, I made my first review using this today! thanks @CoderDave
Great to know :)
Simple and the best!
Thanks, happy you liked it
great video Dave! this was super helpful
Glad you think so!
great - what are you using for the markup and zoom in the screen capture? it's awesome
Thanks! What I'm using is called "ZoomIt", part of the sysinternals toolset: docs.microsoft.com/en-us/sysinternals/downloads/zoomit
Thanks a lot for this fast and informative content.
😀 always happy to help
Thank you very much for the video. Very useful.
simple, short and useful
Happy you liked it
Helped a lot!
Very happy to know it helped! 😊
Clear and concise, thanks man
You're welcome!
Thanks for this short and informative video.
Glad it was helpful!
How do we make highlight for the specific line we went to comment
Just click on the line number next to it 😉
Thank you dude, it's a valuble and concise info.
Glad you liked it
Thank you very much!!
btw the limit time is not necessary I think 🤔
Happy it’s been helpful. Yes the time limit is something I just use 😁
Fantastic video! Thanks
Glad you liked it!
Thank you for the great video!!
Hello. Nice video, thanks. Question for you, is there a way, to see the list of files that are modified in a tree view or something like it? I came from Bitbucket where there was the list of file on the left and on the right pane, all changes. It was really easy to see all files that changed for this particular Pull Request.
hey! Unfortunately it is not possible out of the box, but you could use an extension like this one: chrome.google.com/webstore/detail/better-pull-request-for-g/nfhdjopbhlggibjlimhdbogflgmbiahc
Hey Daniel, great news! Looks like the folks at GitHub hear you! There is now the beta available for the file tree in PRs.
Just go to your user settings > Feature Preview > Pull Request File Tree > Enable
No go to a PR, and in the Files tab you will se the new file tree layout 🥳🥳🥳
@@CoderDave Thanks, I just saw that yesterday. We found at work another way also, just click on . On your keyboard, it will open a Visual Studio Code inside Chrome. So it is easier to do the code review.
Good explanation. Thanks!
Thanks. Happy to know it was helpful ☺️
Thanks great informative short video.
Glad it was helpful!
nice, keep it simple !! thank you very much man !!
You’re welcome ☺️ and thanks for the compliment
Thank you Dave!
You're very welcome :)
Excellent job
Thank you very much!
Good job!
Thank you! Cheers!
thanks man
Happy to help
thank you. would you consider doing some example solutions for git merge conflict problems?
Happy to be helpful. The problem about merge conflicts is that they are highly dependent on the language you use, and each conflict is different from another one so not sure how helpful a video like that could be 🤔
@@CoderDave yes, that is a fair point. and in my case, though i use windows as my desktop, all my coding is linux-based and i don't use C# or azure. having said that, many merge conflicts are to do with getting tangled up (or lost) in git and trying to understand the many (imo) weird error messages that git throws and the many different commands one needs for stashing, cleaning, unstaging, etc etc. thus some merge conflict walkthroughs might actually be very useful for almost anyone trying to get to grips with git at a higher level.
great, thanks for the amazing guidance
More than welcome ☺️
Thanks!
You're very welcome :)
Thanks a bunch!
Always happy to help
Thanks!
Welcome!
Imsightful
thanks for that tip.
You’re very welcome 🙃
Superb.
Thanks a lot
thanks
You're welcome!
Lovely bro..
Glad you liked it!
Didn't know that. 👍
Glad it provided value :)
why are you commenting on invididual lines of code? I googled for "how comment on a branch" why are you talking about pull requests?
I don't know why Google showed you my content... but on a video titled "How to Review a Pull Request" you commenting "Why are you talking about Pull Requests" makes me think that perhaps it is not Google's fault...
LGTM
yeah, something like that ;)
Thanks for the video! Well explained.
Glad to know you found it helpful 😀
Great explanation! Thank you!
You’re welcome, and thanks for the comment ☺️
Thanks!
Thanks
You’re welcome 😀