CARVIEW |
Navigation Menu
-
Notifications
You must be signed in to change notification settings - Fork 2
Publishing your changes
If you've added to or changed the contents of the database
folder (by adding or editing tasks, solutions, or topics) you'll probably eventually want to publish that work. When you're ready, proceed as follows.
(On this page, I assume you're using the GitHub Desktop application for source control, but if you're a git pro, just replace these instructions with your preferred method of using git.)
- Proofread your changes! As discussed in the various bullet points on this page, always proofread changes before publishing them, to ensure that you're publishing what you mean to be.
- Open GitHub Desktop and ensure it's showing you the How to Data repository.
- If others have edited the site since you last opened the app, you'll see a button entitled "Pull origin," which means "transfer, from the original repository, to my computer, all the changes that have been published since I last checked." If you see that button, as in the example screenshot below, click it. (In fact, it's best to pull other people's changes before you make any changes on your own copy, but if many people are working simultaneously, that isn't always feasible.)
- You should find that GitHub Desktop lists ONLY the changes you made, which should all be inside the
database
folder and will therefore start with that folder name, as shown in the screenshot below.- You may also see changes in the
jekyll-input
folder that came about because you rebuilt some solutions for previewing purposes. It is okay to leave those changes there, and include them in your "commit" (described below). - If there are any changes you don’t recognize, such as in the
docs
folder, you should remove them. Those arise only if you do Step 2 on Tab 3, which you shouldn't need to do. - For any changed file that you didn't intend to change (including any changes in the
docs
folder), right-click the changed file and choose "Discard Changes." This will restore the file to the contents it had when you last downloaded it, erasing any inadvertent changes.
- You may also see changes in the
Now you should see only the changes you made and want to share. Sharing in git is a two-step process: First you commit, which means you let the repository know you want your changes to be remembered. Second you push, which means you send those committed changes up to the cloud where the site maintainer will receive them and decide whether to build them into the official website.
- Write a short summary of the changes you made, in the text field that says "Summary (required)," as shown in the screenshot below. For example, you might write "Improving variable name in Python code" or "Adding new Excel solution." Use only a few words. If you need to say a lot, use the optional Description field below the Summary.
- Click the commit button to "save" your changes to the repository. Do not be alarmed if they seem to disappear! That is the correct behavior, because GitHub Desktop is showing you uncommitted changes, so when you commit them, they are no longer shown. You can click the "History" tab to see the full history of the entire repository, including the change you just committed, to verify that it worked as expected.
Now your changes are committed and it's time to push them to the cloud. Note that it's acceptable to make several commits before you push, and thus send several changes at once. For example, you might add one new solution each day, committing each one separately, and then push them all at the end of the week. Many little commits is actually good practice. Even if you've made many changes and see them all in GitHub Desktop at the same time (say, 10 changed files) you aren't required to commit them all at once. Use the check boxes on the left to choose just one or two files that belong together, commit those with an appropriate Summary, then move on to others. You may make your commits as small as you like, as long as each one has been proofread to ensure that the content being committed is actually correct.
Because most contributors to How to Data are not the site maintainer, you cannot directly push your commits to the main repository without permission. Instead, what you do is ask the site maintainer to pull your commits into the official repository. So what you'll actually do at this point is create a "pull request," meaning you're asking for your work to get included in the official site.
- In GitHub Desktop, when you have no changes left to commit, you will see the "Preview Pull Request" button as in the screenshot below. Click that button.
-
All the changes you've committed recently will be shown to you and you can review them again if you choose.
-
Click "Create Pull Request." GitHub Desktop will open your default browser to take you to GitHub.
-
Type a title and description for your pull request.
-
Click "Create Pull Request" (in the browser this time) and your request will be sent to the site maintainer.