Github surprise

Three months ago I asked GH if it’s somehow possible to search pull requests by branch. It was not possible at that time.

It’s a nice surprise that they eventually implemented it… but it’s even more surprising that they e-mailed me about that! (after three months!)

You can now search for pull requests by branch name.

`is:open base:staging` will find all open pull requests that will be merged into a “staging” branch (https://github.com/search?q=is:open+base:staging)

`is:open head:feature` will find all open pull requests that want to merge code from a “feature” branch (https://github.com/search?q=is%3Aopen+head%3Afeature)

The search uses prefix matching so the entire branch name does not have to be typed into the search field. The search for `is:open head:feature` will also match a branch named “feature-api-enhancement”.

We hope you enjoy this new feature. As always, please send us an email if you have any questions.

TwP

I wonder what kind of system they use – my support request/ticket must have been linked with feature/user story.

Neat.

Share Button

Promocja w Helion

W prawdzie dużo lepiej jest czytać książki w oryginale (zachęcam gorąco – z pierwszą się przemęczyć, każda kolejna będzie łatwiejsza), ale wiadomo – od czegoś trzeba zacząć. I w helionie można zaoszczędzić i kupić 2 książki w cenie 1.

Owocnych zakupów – promocja trwa do jutra ;)

Share Button

Thought about code review

Do you wonder how to teach your team to make code reviews that are not a waste of time? My suggestions so far:

1. If you focus on code formatting you’re not doing it right. When you have tools, hooked (pre-commit hook) which checks that for you – it’s better.

We have githooks autoinstalator

We even have githooks autoinstalator

2. Use your brainpower for something simple tools can not do – try to understand what you read. As long as code compiles it’s ok for machine. Reviews are meant to make your team write code for (other) people.

constvscomment

3. Reviewer HAVE TO spot issues. She/he can have solutions, but when there’s none – a discussion should be initialized.

imposibru

4. Review doesn’t have to be 1 on 1. Invite rest of the team for their feedback.
invitation

5. Some action points after review would be “make refactor of this… some day”. This is at your team discretion if it’s possible to apply suggestions after review – sometimes it just can not be done.

This doesn't elaborate on point above -- I just think it's funny.

This doesn’t elaborate on point above — I just think it’s funny.

6. Sometimes you have to back your opinion. I remember explaining many times why commented code is worse than deleted code. Now others slap me with this when I leave some code for later:

comment

Share Button