-
-
Notifications
You must be signed in to change notification settings - Fork 381
proposed changes to the code review lesson #517
Conversation
Our novice lessons don't introduce branching - it's too much on top of everything else for people who've never seen version control before - but the rest looks good to me. |
I had this in mind in the extras section, where |
Putting it in |
In progress. The new still todo:
|
He then [clones](../../gloss.html#repository-clone) his own GitHub repository, | ||
not Dracula's, | ||
to give himself a desktop copy: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've just used fork and clone quite close to each other, and I think learners might be confused about the difference. Maybe an explicit statement to the effect that if Wolfman clones Dracula's repository to his desktop, he won't be able to push changes to it (unless Dracula gives him permission), but forking makes a new repo owned by Wolfman.
to address comment swcarpentry#1 on pull request swcarpentry#517, this makes explicit that you won't always be able to push directly to repositories other people have made.
to address comment swcarpentry#1 on pull request swcarpentry#517, this makes explicit that you won't always be able to push directly to repositories other people have made.
ready for review + merge |
Create an empty lesson on forking and bump the other lesson numbers up accordingly.
Add the first draft of a new lesson about forking. The lesson covers creating a fork, creating pull requests, and reasons for using a fork instead of working off of one repo. Leaves out the details of code review. This encompasses most of the material that is in lesson 03. The plan is to rewrite 03 to focus on pull requests and code review. It should cover using pull requests from different branches in the same repo as well as between forks.
to address comment swcarpentry#1 on pull request swcarpentry#517, this makes explicit that you won't always be able to push directly to repositories other people have made.
remove redundant curriculum with 02-forking, add some additional images to help guide creating a pull request, and add an abstract guide to performing code review
Can the Git topic maintainers please decide whether to merge this one, and if so, resolve the conflicts and push the button? |
I took a stab at rebaseing this myself locally but it looks like |
easier integrate into the project, | ||
and less likely to cause bugs. | ||
|
||
Reviewing code be complex. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewing code can be complex.
Creates a new lesson on forking on GitHub and revises the code review lesson. Closes swcarpentry#517.
Adds a new lesson about forking on GitHub and revises the code review lesson. Closes #517.
I've manually merged and pushed this, thanks for adding the lesson. It occurred to me while reviewing this that there don't seem to be any actual images or descriptions of the mechanics of code review on GitHub. For example that you can leave inline comments by clicking to the "Files" tab and then on lines, or leave comments on a commit by going to the commit view. Something the flesh out in the future. |
Thank you, all involved. It's good to have it landed. |
edit: ok, this is ready for review
I have some ideas for improving
novice/extras/02-review.md
and would like some feedback before I start working. I propose the following:I'm not sure if point 1 needs to be a separate lesson or if this can be structured together as one. Point 2 supports a simplified branching model I see at some companies and expect to see at some labs where individuals all work on branches of the parent repo.