Rewrite2 #27
Merged
Rewrite2 #27
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The existing workflow suggests using error prone commands such as `git rebase`. This workflow avoids such commands and tries to infuse other best practices.
- Add a horizontal rule before details section - Add bold to note at the top - Remove meta comment at the top
Closed
- Remove squash since this can be done by the maintainer when accepting a pull-request. - Move multi-round before conflict since it is easier and gives participants a chance to practice the basic workflow before having to deal with a conflict. - Minor renames in contributor.md.
|
@burdged - I decided to give this activity a full overhaul. What do you think? Can we merge it to master and use it in a couple weeks? |
Push changes is used during work and during cleanup. We're on different branches in each case (feature and master). Rather than specifying each explicitly (`git push origin master` and `git push origin FEATURE_BRANCH`) or asking folks to figure out which branch needs pushing (`git push origin BRANCH_THAT_NEEDS_PUSHING`), we will have them push up all branches with `git push`. It is usually considered best practice not to push all branches in case you are midway through a change in a branch that you don't want pushed. But at this stage, it overcomplicates things.
I changed my mind from the last commit. Rather than use `git push`, wanting to use the best practice of specifying the remote and branch in a push, and believing that students will learn parallel forms faster than variations, I have made two recipes for push: one for pushing the feature branch, and one for pushing master.
The goal is to synchronize master with our repositories. So we need to push to origin after pulling from upstream.
For consistency.
This was referenced Jun 7, 2018
Closed
Closed
Closed
From burged The formation of teams was already a bullet item in the README -- maybe pull that bulleted item from the README -- it makes more sense for the formation of teams to be here.
|
I think I addressed all the issues. I've tagged the current version of master as v1.0.0, so we can easily get back to it if we want it. But I think we're ready to merge. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goals
git rebase).git commit -v; checking what files will be committed before committing, and modifying .gitignore if it's wrong.).git branch feature; git checkout featureinstead ofgit checkout -b feature; it might seem like the latter is easier, but then you must know the purpose of -b, and when to leave it off).To-do
Issues