├── .devcontainer ├── Dockerfile ├── devcontainer.json └── postCreateCommand.sh ├── .editorconfig ├── .github ├── CODEOWNERS ├── SECURITY.md ├── linters │ ├── .ecrc │ ├── .htmlhintrc │ ├── .markdown-lint.yml │ └── .textlintrc └── workflows │ └── super-linter.yml ├── .gitignore ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE ├── README.md ├── docs ├── .nojekyll ├── 01_getting_ready_for_class.md ├── 02_getting_started.md ├── 02a_activity_create_github_issue.md ├── 03_github_flow.md ├── 04_branching_with_git.md ├── 04a_activity_create_branch.md ├── 05_local_git_configs.md ├── 06_working_locally.md ├── 06a_activity_create_file.md ├── 07_collaborating_on_code.md ├── 07a_activity_create_pull_request.md ├── 08_edit_on_github.md ├── 09_merging_pull_requests.md ├── 10_local_history.md ├── 11_streamline_workflow_with_aliases.md ├── 12a_what_is_a_merge_conflict.md ├── 12b_resolving_merge_conflicts.md ├── 13_workflow_review_project_github_games.md ├── 14_git_bisect.md ├── 15_reverting_commits.md ├── 16_helpful_git_commands.md ├── 17_actions_activity.md ├── 17_github_actions.md ├── 17_protected_branches.md ├── 17_tags_and_releases.md ├── 17_view_local_changes.md ├── 17_workflow_discussion.md ├── 18_create_local_repo.md ├── 19_fixing_commit_mistakes.md ├── 19_forgot_to_branch.md ├── 20_personal_access_token.md ├── 20_rewriting_history_git_reset.md ├── 21_git_cherry_pick.md ├── 22_merge_strategies_rebase.md ├── 23_gitignore.md ├── 24_commit_sig_verification.md ├── 25_git_stash.md ├── 26_git_lfs.md ├── 27_git_submodules.md ├── 28_git_subtrees.md ├── App_clean_loaner_pc.md ├── GH4D │ └── index.html ├── GH4DJA │ └── index.html ├── README.md ├── _coverpage.md ├── _sidebar.md ├── app_Day_1_activities.md ├── app_add_human_readable_name.md ├── app_aliases.md ├── app_authentication.md ├── app_case_studies.md ├── app_day2_mergeconflict.md ├── app_evangelize.md ├── app_facilitating_workflow.md ├── app_facilitation_tips.md ├── app_fork_workflow.md ├── app_git_branch_in_terminal.md ├── app_github_events.md ├── app_how_to_generate_locally.md ├── app_issue_template.md ├── app_plan_an_event.md ├── app_supporting_learning_lab.md ├── app_teachback_repo_prep.md ├── app_teaching_script.md ├── app_vi_basics.md ├── book.pdf ├── cover.jpg ├── cover.png ├── img │ ├── actions-components.png │ ├── actions-run.png │ ├── actions.png │ ├── cd.png │ ├── ci.png │ ├── clone-branch-fork.png │ ├── clone-diagram.png │ ├── collaboration-features.png │ ├── commit-and-tree.png │ ├── commit-parent.png │ ├── config-levels.png │ ├── cover.png │ ├── diff-options.png │ ├── fork-from.png │ ├── fork-to.png │ ├── git-bisect.png │ ├── git-rebase.png │ ├── github-ecosystem.png │ ├── github-icon.jpg │ ├── github-workflow.png │ ├── gitignore-create-repo.png │ ├── merging-prs.png │ ├── name-field.png │ ├── origin-upstream.png │ ├── push-pull.png │ ├── python-gitignore.png │ ├── release-actions.png │ ├── repository-intro.png │ ├── reset-modes.png │ ├── reset-visual.png │ ├── staging.png │ ├── two-stage-commit-a.png │ ├── two-stage-commit-b.png │ ├── two-stage-commit-c.png │ ├── two-stage-commit-d.png │ ├── userbar-account-settings.png │ └── yaml.png ├── index.html ├── ja │ ├── 01_getting_ready_for_class.md │ ├── 01f_facilitator_note.md │ ├── 02_getting_started.md │ ├── 02a_activity_create_github_issue.md │ ├── 03_github_flow.md │ ├── 04_branching_with_git.md │ ├── 04a_activity_create_branch.md │ ├── 05_local_git_configs.md │ ├── 06_working_locally.md │ ├── 06a_activity_create_file.md │ ├── 07_collaborating_on_code.md │ ├── 07a_activity_create_pull_request.md │ ├── 08_edit_on_github.md │ ├── 09_merging_pull_requests.md │ ├── 10_local_history.md │ ├── 11_streamline_workflow_with_aliases.md │ ├── 12a_what_is_a_merge_conflict.md │ ├── 12b_resolving_merge_conflicts.md │ ├── 13_workflow_review_project_github_games.md │ ├── 14_git_bisect.md │ ├── 15_reverting_commits.md │ ├── 16_helpful_git_commands.md │ ├── 17_protected_branches.md │ ├── 17_tags_and_releases.md │ ├── 17_view_local_changes.md │ ├── 17_workflow_discussion.md │ ├── 18_create_local_repo.md │ ├── 19_fixing_commit_mistakes.md │ ├── 19_forgot_to_branch.md │ ├── 20_rewriting_history_git_reset.md │ ├── 21_git_cherry_pick.md │ ├── 22_merge_strategies_rebase.md │ ├── 31_merging_tests.md │ ├── 32_setting_up_cicd.md │ ├── 33_interacting_cicd.md │ ├── 33_workflow_review_with_ci.md │ ├── 34_change_yml.md │ ├── 35_circleCI.md │ ├── 35_travisCI.md │ ├── 35_understanding_yml.md │ ├── 37_partner_activity.md │ ├── App_a_workflow_guide.md │ ├── App_b_learn_more_api.md │ ├── App_clean_loaner_pc.md │ ├── README.md │ ├── _sidebar.md │ ├── app_Day_1_activities.md │ ├── app_day2_mergeconflict.md │ ├── app_fork_workflow.md │ ├── app_git_branch_in_terminal.md │ ├── app_how_to_generate_locally.md │ ├── index.md │ ├── preparing_to_teach_github_for_developers.md │ ├── preparing_to_teach_gitonly.md │ └── toc.md └── legacy-manual.pdf ├── practice-repos ├── caption-this │ └── issue_1.md ├── conflict-practice │ ├── pull_request_1.md │ ├── pull_request_2.md │ └── pull_request_3.md └── github-games │ ├── issue_1.md │ └── issue_2.md ├── script ├── README.md ├── ask ├── bootstrap ├── check-caption-repo ├── check-conflict-repos ├── class-setup ├── clean-up-class ├── create-files ├── create-initial-repo ├── create-practice-repos ├── expire-repo ├── generate-pdf ├── grade-client ├── remove-repo ├── reset-game ├── server ├── shared_functions └── teach-class ├── slide_images.md └── slide_template.md /.devcontainer/Dockerfile: -------------------------------------------------------------------------------- 1 | FROM mcr.microsoft.com/devcontainers/base:jammy 2 | 3 | # [Optional] Uncomment this section to install additional OS packages. 4 | # RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \ 5 | # && apt-get -y install --no-install-recommends 6 | 7 | # Install httpie 8 | SHELL ["/bin/bash", "-o", "pipefail", "-c"] 9 | RUN curl -SsL https://packages.httpie.io/deb/KEY.gpg | gpg --dearmor -o /usr/share/keyrings/httpie.gpg \ 10 | && echo "deb [arch=amd64 signed-by=/usr/share/keyrings/httpie.gpg] https://packages.httpie.io/deb ./" > /etc/apt/sources.list.d/httpie.list \ 11 | && apt-get update && export DEBIAN_FRONTEND=noninteractive \ 12 | && apt-get install -y --no-install-recommends \ 13 | httpie=3.2.1 \ 14 | && apt-get clean \ 15 | && rm -rf /var/lib/apt/lists/* 16 | -------------------------------------------------------------------------------- /.devcontainer/devcontainer.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Ubuntu", 3 | "build": { 4 | "dockerfile": "Dockerfile" 5 | }, 6 | "features": { 7 | "ghcr.io/devcontainers/features/node:1": {}, 8 | "ghcr.io/devcontainers/features/sshd:1": {}, 9 | "ghcr.io/devcontainers/features/powershell:1": {} 10 | }, 11 | "postCreateCommand": "bash ./.devcontainer/postCreateCommand.sh" 12 | } 13 | -------------------------------------------------------------------------------- /.devcontainer/postCreateCommand.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | npm install -g docsify-cli 4 | -------------------------------------------------------------------------------- /.editorconfig: -------------------------------------------------------------------------------- 1 | root = true 2 | 3 | [*] 4 | indent_style = space 5 | indent_size = 2 6 | end_of_line = lf 7 | charset = utf-8 8 | trim_trailing_whitespace = false 9 | insert_final_newline = true 10 | 11 | [*.md] 12 | trim_trailing_whitespace = false 13 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | docs/* @githubtraining/github-delivery-reviewers 2 | -------------------------------------------------------------------------------- /.github/SECURITY.md: -------------------------------------------------------------------------------- 1 | If you discover a security issue in this repo, please submit it through the [GitHub Security Bug Bounty](https://hackerone.com/github). 2 | 3 | Thanks for helping make GitHub, and this training manual, safe for everyone. 4 | -------------------------------------------------------------------------------- /.github/linters/.ecrc: -------------------------------------------------------------------------------- 1 | { 2 | "Exclude": ["\\.md$"] 3 | } 4 | -------------------------------------------------------------------------------- /.github/linters/.htmlhintrc: -------------------------------------------------------------------------------- 1 | { 2 | "head-script-disabled": false 3 | } 4 | -------------------------------------------------------------------------------- /.github/linters/.markdown-lint.yml: -------------------------------------------------------------------------------- 1 | --- 2 | ########################### 3 | ########################### 4 | ## Markdown Linter rules ## 5 | ########################### 6 | ########################### 7 | 8 | # Linter rules doc: 9 | # - https://github.com/DavidAnson/markdownlint 10 | # 11 | # Note: 12 | # To comment out a single error: 13 | # 14 | # any violations you want 15 | # 16 | # 17 | 18 | ############### 19 | # Rules by id # 20 | ############### 21 | 22 | MD013: false # Don't enforce line length 23 | MD024: false # Allow multiple headings with the same content 24 | MD026: # Trailing punctuation in heading 25 | punctuation: ".,;:!。，；:" # List of characters not allowed 26 | MD033: false # Allow inline HTML 27 | MD041: false # Don't enforce first line headings 28 | -------------------------------------------------------------------------------- /.github/linters/.textlintrc: -------------------------------------------------------------------------------- 1 | { 2 | "filters": { 3 | "comments": true 4 | }, 5 | "rules": { 6 | "terminology": { 7 | "defaultTerms": true 8 | } 9 | } 10 | } 11 | -------------------------------------------------------------------------------- /.github/workflows/super-linter.yml: -------------------------------------------------------------------------------- 1 | --- 2 | ######################### 3 | ######################### 4 | ## GitHub Super Linter ## 5 | ######################### 6 | ######################### 7 | name: Super Linter 8 | 9 | # 10 | # Documentation: 11 | # https://help.github.com/en/articles/workflow-syntax-for-github-actions 12 | # 13 | 14 | ################################# 15 | # Start the job on pull request # 16 | ################################# 17 | on: 18 | pull_request: 19 | branches: [main] 20 | 21 | ############### 22 | # Set the Job # 23 | ############### 24 | jobs: 25 | build: 26 | # Name the Job 27 | name: Super Linter 28 | # Set the agent to run on 29 | runs-on: ubuntu-latest 30 | 31 | ################## 32 | # Load all steps # 33 | ################## 34 | steps: 35 | ########################## 36 | # Checkout the code base # 37 | ########################## 38 | - name: Checkout Code 39 | uses: actions/checkout@v2 40 | with: 41 | # Full git history is needed to get a proper list of changed files within `super-linter` 42 | fetch-depth: 0 43 | 44 | ################################ 45 | # Run Linter against code base # 46 | ################################ 47 | - name: Super Linter 48 | uses: docker://ghcr.io/github/super-linter:slim-v4 49 | env: 50 | VALIDATE_ALL_CODEBASE: false 51 | DEFAULT_BRANCH: main 52 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 53 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # file auto-generated by Finder (OS X) 2 | .DS_Store 3 | 4 | # the generated manuals 5 | *facilitator-manual.html 6 | *student-manual.html 7 | *facilitator-manual.md 8 | *student-manual.md 9 | 10 | 11 | # Ruby stuff generated by script/bootstrap 12 | /.bundle 13 | /bin 14 | /vendor/gems 15 | 16 | # Jekyll stuff 17 | _site 18 | .sass-cache 19 | 20 | _book 21 | node_modules 22 | log.out -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | [fork]: https://github.com/githubtraining/training-manual/fork 4 | [pr]: https://github.com/githubtraining/training-manual/compare 5 | [code-of-conduct]: CODE_OF_CONDUCT.md 6 | 7 | Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great. 8 | 9 | Contributions to this project are [released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) to the public under the [project's open source license](LICENSE.md). 10 | 11 | Please note that this project is released with a [Contributor Code of Conduct][code-of-conduct]. By participating in this project you agree to abide by its terms. 12 | 13 | ## Submitting a pull request 14 | 15 | 1. [Fork][fork] and clone the repository 16 | 1. Create a new branch: `git checkout -b my-branch-name` 17 | 1. Make your change, add tests, and make sure the tests still pass 18 | 1. Push to your fork and [submit a pull request][pr] 19 | 1. Pat your self on the back and wait for your pull request to be reviewed and merged. 20 | 21 | Here are a few things you can do that will increase the likelihood of your pull request being accepted: 22 | 23 | - Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests. 24 | - Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). 25 | 26 | ## Resources 27 | 28 | - [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/) 29 | - [Using Pull Requests](https://help.github.com/articles/about-pull-requests/) 30 | - [GitHub Help](https://help.github.com) 31 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # GitHub Training Manual 2 | 3 | [![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-v2.0%20adopted-ff69b4.svg)](CODE_OF_CONDUCT.md) 4 | 5 | Welcome to the GitHub Training Manual repository. In this repository, you will find the content used by the [GitHub Professional Services](https://services.github.com/) team during our official GitHub training courses and the scripts used when teaching. 6 | 7 | The content is all written in [Markdown](https://guides.github.com/features/mastering-markdown/), and the scripts are shell scripts. 8 | 9 | ## Technologies used 10 | 11 | This manual is served using GitHub Pages and [docsify](https://docsify.js.org), and can be found at [githubtraining.github.io/training-manual](https://githubtraining.github.io/training-manual/#/). 12 | 13 | ## Goals and scope 14 | 15 | The goal of this project is to serve as a content source for training on Git and GitHub. While GitHub, select GitHub Partners, and select customers may have their own use case directly with GitHub, the content is open source so we can share and improve as a community. You can find more information on contributing in the [contributing guide](CONTRIBUTING.md). 16 | 17 | The topic scope is limited to GitHub's core product features, on GitHub.com and also for GitHub Enterprise users. 18 | 19 | ## Deploy the manual 20 | 21 | These manuals are designed to be generated using [docsify](https://docsify.js.org). To get your own manuals up and running, all you have to do is: 22 | 23 | 1. Fork this repository 24 | 2. In your fork, click on **Settings** 25 | 3. Scroll down to the GitHub Pages section, and set **Source:** to `main branch /docs folder`. 26 | 4. Click **Save**. 27 | 5. Return to the GitHub Pages section of Settings, and you'll receive the URL of your published manual. 28 | 29 | ## Make changes 30 | 31 | The official [docsify documentation](https://docsify.js.org/#/?id=docsify) is your best bet for getting up to speed with the tool. 32 | 33 | In general, you'll find all of the manual content in the [`docs/`](docs/) folder of this repository. All content is written in Markdown, and it's all stitched together in [`docs/_sidebar.md`](docs/_sidebar.md), which specifies the order and hierarchy of the content. 34 | 35 | ## Preview changes on your machine 36 | 37 | You can install, and serve the contents of the `docs/` folder locally with minimal setup. The steps are thoroughly described in the [doscify quick start](https://docsify.js.org/#/quickstart) guide. 38 | 39 | You can also simply run the following scripts: 40 | 41 | ```shell 42 | script/bootstrap 43 | script/server 44 | ``` 45 | 46 | ## Generate a PDF 47 | 48 | Docsify doesn't currently support creating PDFs, but you can generate one using [GitBook legacy](https://docs.gitbook.com/resources/gitbook-legacy). We've tried to make this simple for you by creating [`script/generate-pdf`](script/generate-pdf). The legacy version of GitBook is being shut down soon, but it still works. You'll need to follow the installation instructions below to install GitBook. The previous installation instructions on the GitBook site have been removed. 49 | 50 | ## GitBook dependency 51 | 52 | 53 | 54 | 1. Download and install [Calibre](https://calibre-ebook.com/download). 55 | 56 | 1. Run Calibre once to set up the application. 57 | 58 | 1. Make sure that the [Calibre command line interface](https://manual.calibre-ebook.com/generated/en/cli-index.html) is available on your path. This is located at `/Applications/calibre.app/Contents/MacOS/` on macOS if you are running the application from the default location. 59 | 60 | 61 | 62 | ## Teaching scripts 63 | 64 | Scripts that accompany the manual, and their documentation can be found in the [`script/`](script/) directory. This repository includes development container configuration. So you can run the scripts on the Visual Studio developer container or [GitHub Codespaces](https://github.com/features/codespaces). 65 | 66 | ## License 67 | 68 | Please see the [license](LICENSE) for detailed information. When using the GitHub logos, be sure to follow the [GitHub Logos and Usage](https://github.com/logos) guidelines. 69 | -------------------------------------------------------------------------------- /docs/.nojekyll: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/.nojekyll -------------------------------------------------------------------------------- /docs/02a_activity_create_github_issue.md: -------------------------------------------------------------------------------- 1 | ### Activity: Creating a GitHub issue 2 | 3 | Follow these steps to create an issue in the class repository: 4 | 5 | 1. Click the **Issues** tab. 6 | 1. Click **New Issue**. 7 | 1. Type the following in the Subject line: `YOUR-USERNAME Workflow` 8 | 1. In the body of the issue, include the text below: 9 | 10 | ```md 11 | YOUR-USERNAME will update a file by replacing a caption. 12 | 13 | - [ ] Create a branch 14 | - [ ] Edit the file 15 | - [ ] Commit the changes 16 | - [ ] Create a Pull Request 17 | - [ ] Request a Review 18 | - [ ] Make more changes 19 | - [ ] Get an approval 20 | - [ ] Merge the Pull Request 21 | ``` 22 | 23 | 1. Click the *Submit new issue* button to open your issue. 24 | -------------------------------------------------------------------------------- /docs/03_github_flow.md: -------------------------------------------------------------------------------- 1 | ## Understanding the GitHub flow 2 | 3 | In this section, we discuss the collaborative workflow enabled by GitHub. 4 | 5 | ### The essential GitHub workflow 6 | 7 | ![GitHub Workflow](./img/github-workflow.png) 8 | 9 | The GitHub flow is a lightweight workflow that allows you to experiment with new ideas safely, without fear of compromising a project. 10 | 11 | Branching is a key concept you will need to understand. Everything in GitHub lives on a branch. By default, the "blessed" or "canonical" version of your project lives on a branch called `main`. This branch can actually be named anything, as we will see in a few minutes. 12 | 13 | When you are ready to experiment with a new feature or fix an issue, you create a new branch of the project. The branch will look exactly like `main` at first, but any changes you make will only be reflected in your branch. Such a new branch is often called a "feature" branch. 14 | 15 | As you make changes to the files within the project, you will commit your changes to the feature branch. 16 | 17 | When you are ready to start a discussion about your changes, you will open a pull request. A pull request doesn't need to be a perfect work of art - it is meant to be a starting point that will be further refined and polished through the efforts of the project team. 18 | 19 | When the changes contained in the pull request are approved, the feature branch is merged onto the main branch. In the next section, you will learn how to put this GitHub workflow into practice. 20 | 21 | ### Exploring 22 | 23 | Here are some interesting things you can check out later: 24 | 25 | - *[guides.github.com/introduction/flow/](https://guides.github.com/introduction/flow/)* An interactive review of the GitHub Workflow. 26 | -------------------------------------------------------------------------------- /docs/04_branching_with_git.md: -------------------------------------------------------------------------------- 1 | ## Branching with Git 2 | 3 | The first step in the GitHub Workflow is to create a branch. This will allow us to experiment with new features without accidentally introducing untested changes on our production branch. 4 | 5 | ### Branching defined 6 | 7 | ![GitHub Workflow](./img/github-workflow.png) 8 | 9 | When you create a branch, you are essentially creating an identical copy of the project at that point in time. This isn't the same as creating a physical copy on disk. In the background, a branch is just a pointer. 10 | 11 | Let's learn how you can create a new branch. 12 | 13 | [include](04a_activity_create_branch.md ':include') 14 | 15 | ### Exploring 16 | 17 | Here are some interesting things you can check out later: 18 | 19 | - [A GitHub Training Video on branching](https://youtu.be/H5GJfcp3p4Q) 20 | -------------------------------------------------------------------------------- /docs/04a_activity_create_branch.md: -------------------------------------------------------------------------------- 1 | ### Activity: Creating a branch with GitHub 2 | 3 | Earlier you created an issue about the file you would like to edit. Let's create the branch you will use to edit your file. 4 | 5 | Follow these steps to create a new branch in the class repository: 6 | 7 | > You will need to have collaborator access on the class repository before you can create a branch on GitHub. 8 | 9 | 1. Navigate to **Code** tab of the class repository. 10 | 1. Click the *branch dropdown*. 11 | 1. Enter the branch name `github-username-caption`. 12 | 1. Click on your branch name to create the branch. 13 | 14 | When you create a new branch on GitHub, you are automatically switched to your branch. Now, any changes you make to the files in the repository will be applied to this new branch. 15 | 16 | > A word of caution. When you return to the repository or click the top level repository link, notice that GitHub automatically assumes you want to see the items on the default branch. If you want to continue working on a feature branch, you will need to re-select it using the branch dropdown. 17 | -------------------------------------------------------------------------------- /docs/05_local_git_configs.md: -------------------------------------------------------------------------------- 1 | ## Local Git configuration 2 | 3 | In this section, we will prepare your local environment to work with Git. 4 | 5 | ### Checking your Git version 6 | 7 | First, let's confirm your [Git Installation](https://git-scm.com/downloads): 8 | 9 | ```sh 10 | git version 11 | ``` 12 | 13 | If Git is installed, it will return your version: `git version 2.33.1`. 14 | 15 | If you do not see a Git version listed or this command returns an error, you may need to install Git. 16 | 17 | > To get the latest version of Git, visit [www.git-scm.com](https://www.git-scm.com). 18 | 19 | ### Git configuration levels 20 | 21 | ![Git Configuration Levels](./img/config-levels.png) 22 | 23 | Git allows you to set configuration options at three different levels. 24 | 25 | #### --system 26 | 27 | These are system-wide configurations. They apply to all users on this computer. 28 | 29 | #### --global 30 | 31 | These are the user level configurations. They only apply to your user account. 32 | 33 | #### --local 34 | 35 | These are the repository level configurations. They only apply to the specific repository where they are set. 36 | 37 | > The default value for git config is `--local`. 38 | 39 | ### Viewing your configurations 40 | 41 | If you would like to see which config settings have been added automatically, you can type `git config --list`. This will automatically read from each of the three config files and list the setting they contain. 42 | 43 | ```sh 44 | git config --list 45 | ``` 46 | 47 | You can also narrow the list to a specific configuration level by including it before the list option. 48 | 49 | ```sh 50 | git config --global --list 51 | ``` 52 | 53 | ### Configuring your name and email address 54 | 55 | Git uses the config settings for your user name and email address to generate a unique fingerprint for each of the commits you create. You can't create commits without these settings: 56 | 57 | ```sh 58 | git config --global user.name "First-name Surname" 59 | git config --global user.email "you@email.com" 60 | ``` 61 | 62 | **Example:** 63 | 64 | ```sh 65 | git config --global user.name "Mona Octocat" 66 | git config --global user.email "mona@github.com" 67 | ``` 68 | 69 | > **Tip:** If you make a typo when setting one of your config properties, don't worry. You can rerun the same `git config` command with different values between the double quotes to update the property to a new value. If you typo a property name, you can delete the property with the following command: 70 | > 71 | > ```sh 72 | > git config --global --unset 73 | > ``` 74 | 75 | #### Git config and your privacy 76 | 77 | The instructions for this exercise use the `--global` flag when identifying your `user.name` and `user.email` configuration settings. If you are currently using a computer without a private, personal account, don't apply the `--global` flag. This way, the settings will only be stored in our assignment repository. If you work in another repository on this same computer, you will need to set these configuration options again. 78 | 79 | > For example: 80 | > 81 | > ```sh 82 | > git config user.email "you@email.com" 83 | >``` 84 | 85 | Your name and email address will automatically be stored in the commits you make with Git. If you would like your email to remain private, GitHub allows you to generate a no-reply email address for your account. Click the **Keep my email address private** in the [Settings > Emails section](https://github.com/settings/emails). After enabling this feature, you just need to enter the automatically generated `ID+username@users.noreply.github.com` when configuring your email. 86 | 87 | > For example: 88 | > 89 | > ```sh 90 | > git config --global user.email 18249274+githubteacher@users.noreply.github.com 91 | > ``` 92 | 93 | ### Configuring autocrlf 94 | 95 | ```sh 96 | //for Windows users 97 | git config --global core.autocrlf true 98 | 99 | //for Mac or Linux users 100 | git config --global core.autocrlf input 101 | ``` 102 | 103 | Different systems handle line endings and line breaks differently. If you open a file created on another system and do not have this config option set, Git will think you made changes to the file based on the way your system handles this type of file. 104 | 105 | > Memory Tip: `autocrlf` stands for auto carriage return line feed. 106 | -------------------------------------------------------------------------------- /docs/06a_activity_create_file.md: -------------------------------------------------------------------------------- 1 | ### Activity: Edit Your File 2 | 3 | Now it is time to put an image and a caption into your file: 4 | 5 | 1. Find your file, `##-USERNAME.md`. 6 | 1. Open your file in your favorite text editor. 7 | 1. On line 6, replace the text with your caption. 8 | 1. *Save* your file. 9 | 10 | > Git doesn't care how you work with your files locally. You can work in your favorite IDE or text editor, or you can use VIM through the command line. 11 | > 12 | > To open your file from the command line, many IDEs and text editors offer shortcuts. For example, use `code .` to open it in Visual Studio Code. 13 | -------------------------------------------------------------------------------- /docs/07_collaborating_on_code.md: -------------------------------------------------------------------------------- 1 | ## Collaborating on your code 2 | 3 | Now that you have made some changes in the project locally, let's learn how to push your changes back to the shared class repository for collaboration. 4 | 5 | ### Pushing your changes to GitHub 6 | 7 | ![Pushing to GitHub](./img/push-pull.png) 8 | 9 | In this case, our remote is GitHub.com, but this could also be your company's internal instance of GitHub Enterprise. 10 | 11 | To push your changes to GitHub, you will use the command: 12 | 13 | ```sh 14 | git push 15 | ``` 16 | 17 | > When you push, you will be asked to enter your GitHub username and password. If you would like Git to remember your credentials on this computer, you can cache your credentials using: 18 | 19 | - Windows: `git config --global credential.helper wincred` 20 | - Mac: `git config --global credential.helper osxkeychain` 21 | 22 | [include](07a_activity_create_pull_request.md ':include') 23 | 24 | ### Exploring a pull request 25 | 26 | Now that we have created a Pull Request, let's explore a few of the features that make Pull Requests the center of collaboration: 27 | 28 | #### ![octicon-comment-discussion] Conversation tab 29 | 30 | Similar to the discussion thread on an Issue, a Pull Request contains a discussion about the changes being made to the repository. This discussion is found in the **Conversation** tab and also includes a record of all the commits made on the branch as well as assignments, labels and reviews that have been applied to the pull request. 31 | 32 | #### ![octicon-git-commit] Commits tab 33 | 34 | The **Commits** tab contains more detailed information about who has made changes to the files. Clicking each commit ID will allow you to see the changes applied in that specific commit. 35 | 36 | #### ![octicon-diff] Files changed tab 37 | 38 | The **Files changed** tab allows you to see cumulative effect of all the changes made on the branch. We call this the `diff`. Our diff isn't very interesting yet, but as we make changes your diff will become very colorful. 39 | 40 | ### Code review in pull requests 41 | 42 | To provide feedback on proposed changes, GitHub offers three levels of commenting: 43 | 44 | #### General conversation 45 | 46 | You can provide general comments on the Pull Request within the **Conversation** tab. 47 | 48 | #### Line comments 49 | 50 | In the **Files changed** tab, you can hover over a line to see a blue ![`+`][octicon-diff-added] icon. Clicking this icon will allow you to enter a comment on a specific line. These line level comments are a great way to give additional context on recommended changes. They will also be displayed in the **Conversation** tab. 51 | 52 | #### Review 53 | 54 | When you are making line comments, you can also choose to **Start a Review**. When you create a review, you can group many line comments together with a general message: Comments, Approve, or Request Changes. Reviews have special power in GitHub when used in conjunction with protected branches. 55 | 56 | ### Activity: Code review 57 | 58 | One of the best ways to ensure code quality is to make peer reviews a part of every Pull Request. Let's review your partner's code now: 59 | 60 | 1. Click the **Pull Request** tab. 61 | 1. Use the **Author** drop down to locate your partner's pull request. 62 | 1. Click the **Files Changed** tab. 63 | 1. Hover over a single line in the file to see the blue +. Click the + to add a line comment. 64 | 1. Comment on the line and click **Start a review**. 65 | 1. Add additional line comments to the pull request. 66 | 1. Click **Review changes** in the top right corner. 67 | 1. Choose whether to **Approve** or **Request changes** 68 | 1. Enter a general comment for the review. 69 | 1. Click **Submit review** 70 | 1. Click the **Conversation** tab to check out your completed review. 71 | 72 | [octicon-comment-discussion]:https://unpkg.com/octicons/build/svg/comment-discussion.svg 73 | 74 | [octicon-diff]:https://unpkg.com/octicons/build/svg/diff.svg 75 | 76 | [octicon-diff-added]: https://unpkg.com/octicons/build/svg/diff-added.svg 77 | 78 | [octicon-git-commit]:https://unpkg.com/octicons/build/svg/git-commit.svg 79 | -------------------------------------------------------------------------------- /docs/07a_activity_create_pull_request.md: -------------------------------------------------------------------------------- 1 | ### Activity: Creating a pull request 2 | 3 | Pull Requests are used to propose changes to the project files. A pull request introduces an action that addresses an Issue. A Pull Request is considered a "work in progress" until it is merged into the project. 4 | 5 | Now that you have started to change your file, you will open a pull request to discuss the file with your teammates. Follow these steps to create a Pull Request in the class repository: 6 | 7 | 1. Click the *Pull Request* tab. 8 | 1. Click *New Pull Request*. 9 | 1. In the *base* dropdown, choose `main` 10 | 1. In the *compare* dropdown, choose your branch. 11 | 1. Type a subject line and enter a comment. 12 | 1. Use Markdown formatting to add a header and a checklist to your Pull Request. 13 | 1. Include one of the keywords: `closes`, `fixes`, or `resolves` followed by the issue number you created earlier to note which Issue the Pull Request should close. Example: `This resolves #3` 14 | 1. Click *Preview* to see how your Pull Request will look. 15 | 1. Assign the Pull Request to yourself. 16 | 1. Select your partner as a Reviewer for the Pull Request. 17 | 1. Click *Create pull request*. 18 | 19 | > When you navigate to the class repository, you should see a banner at the top of the page indicating you have recently pushed branches, along with a button that reads *Compare & pull request*. This helpful button will automatically start the pull request process between your branch and the repository's default branch. 20 | -------------------------------------------------------------------------------- /docs/08_edit_on_github.md: -------------------------------------------------------------------------------- 1 | ## Editing files on GitHub 2 | 3 | Since you created the pull request, you will be notified when someone adds a comment or a review. Sometimes, the reviewer will ask you to make a change to the file you just created. Let's see how GitHub makes this easy. 4 | 5 | ### Editing a file on GitHub 6 | 7 | To edit a pull request file, you will need to access the **Files changed** tab. 8 | 9 | 1. Click ![octicon-kebab-horizontal] in the top right corner of the diff. 10 | 1. Click **Edit file** to edit the file using the GitHub file editor. 11 | 1. Make changes to the file based on the comments from your reviewer or your personal perspective. 12 | 13 | ### Committing changes on GitHub 14 | 15 | Once you have made some changes to your file, you will need to create a new commit. 16 | 17 | 1. Scroll to the bottom of the page to find the **Commit changes** dialog box. 18 | 1. Type a **Commit message**. 19 | 1. Choose the option to **Commit directly to your branch**. 20 | 1. Click **Commit changes**. 21 | 22 | ### Activity: Editing files in pull requests 23 | 24 | Go back to your Pull Request and make the edits requested by your collaborators. 25 | 26 | [octicon-kebab-horizontal]: https://unpkg.com/octicons/build/svg/kebab-horizontal.svg 27 | -------------------------------------------------------------------------------- /docs/09_merging_pull_requests.md: -------------------------------------------------------------------------------- 1 | ## Merging pull requests 2 | 3 | Now that you have made the requested changes, your pull request should be ready to merge. 4 | 5 | ### Merge explained 6 | 7 | When you merge your branch, you are taking the content and history from your feature branch and adding it to the content and history of the `main` branch. 8 | 9 | ![Merging Pull Requests](./img/merging-prs.png) 10 | 11 | Many project teams have established rules about who should merge a pull request. 12 | 13 | - Some say it should be the person who created the pull request since they will be the ones to deal with any issues resulting from the merge. 14 | - Others say it should be a single person within the project team to ensure consistency. 15 | - Still others say it can be anyone other than the person who created the pull request to ensure at least one review has taken place. 16 | 17 | This is a discussion you should have with the other members of your team. 18 | 19 | ### Merging your pull request 20 | 21 | Let's take a look at how you can merge the pull request: 22 | 23 | 1. Navigate to your Pull Request 24 | 25 | ?> **Hint:** Use the Author or Assignee drop-downs to find your pull request quickly 26 | 27 | 1. Click **Conversation** 28 | 1. Scroll to the bottom of the Pull Request and click the **Merge pull request** button 29 | 1. Click **Confirm merge** 30 | 1. Click **Delete branch** 31 | 1. Click **Issues** and confirm your original issue has been closed 32 | 33 | GitHub offers three different merge strategies for pull requests: 34 | 35 | - **Create a merge commit** 36 | 37 | This is the traditional option that will perform a standard recursive merge. A new commit will be added that shows the point when the two branches were merged together. 38 | 39 | - **Squash and merge** 40 | 41 | This option will take all the commits on your branch and compress them into a single commit. The commit messages will be preserved in the extended commit message for the commit, but the individual commits will be lost. 42 | 43 | - **Rebase and merge** 44 | 45 | This option will take all the commits and replay them as if they just happened. This allows GitHub to perform a fast-forward merge (and avoids the addition of the merge commit). 46 | 47 | ### Updating your local repository 48 | 49 | When you merged your Pull Request, you deleted the branch on GitHub, but this will not automatically update your local copy of the repository. Let's go back to our command line application and get everything in sync. 50 | 51 | First, we need to get the changes we made on GitHub into our local copy of the repository: 52 | 53 | 1. Start by switching back to your default branch: `git switch main` 54 | 1. Retrieve all the changes from GitHub: `git pull` 55 | 56 | `git pull` is a combination command that retrieves all the changes from GitHub and then updates the branch you are currently on to include the changes from the remote. The two separate commands being run are `git fetch` and `git merge` 57 | 58 | ### Cleaning up the unneeded branches 59 | 60 | If you type `git branch --all` you will probably see that, even though you deleted your branch on the remote, it is still listed in your local copy of the repository, both as a local branch and as a read-only remote tracking branch. Let's get rid of those extra branches. 61 | 62 | 1. Take a look at your local branches: `git branch --all` 63 | 1. Let's see which branches are safe to delete: `git branch --merged` 64 | 1. Delete the local branch: `git branch -d ` 65 | 1. Take another look at the list: `git branch --all` 66 | 1. Your local branch is gone, but the remote tracking branch is still there. Delete the remote tracking branch: `git pull --prune` 67 | 68 | > Adding the `--merged` option to the `git branch` command allows you to see which branches do not contain unique work when compared to the checked out branch. In this case, since we are checked out to main, we will use this command to ensure all the changes on our feature branch have been merged to production before we delete the branch. 69 | 70 | If you would like pruning of the remote tracking branches to be set as your default behavior when you pull, you can use the following configuration option: `git config --global fetch.prune true`. 71 | -------------------------------------------------------------------------------- /docs/10_local_history.md: -------------------------------------------------------------------------------- 1 | ## Viewing local project history 2 | 3 | In this section, you will discover commands for viewing the history of your project. 4 | 5 | ### Using Git log 6 | 7 | When you clone a repository, you receive the history of all the commits made in that repository. The log command allows us to view that history on our local machine. 8 | 9 | Let's take a look at some option switches you can use to customize your view of the project history. You can find these options, and many more, on [git-scm.com](https://git-scm.com/docs/git-log). _(Note: `--graph` is default on most Git Bash for Windows terminals.)_ 10 | 11 | ```sh 12 | git log 13 | git log --oneline 14 | git log --oneline --graph 15 | git log --oneline --graph --decorate 16 | git log --oneline --graph --decorate --all 17 | git log --stat 18 | git log --patch 19 | ``` 20 | 21 | > Use the up and down arrows or press enter to view additional log entries. Type `q` to quit viewing the log and return to the command prompt. 22 | -------------------------------------------------------------------------------- /docs/11_streamline_workflow_with_aliases.md: -------------------------------------------------------------------------------- 1 | # Streamlining your workflow with aliases 2 | 3 | So far we have learned quite a few commands. Some, like the log commands, can be long and tedious to type. In this section, you will learn how to create custom shortcuts for Git commands. 4 | 5 | ## Creating custom aliases 6 | 7 | An alias allows you to type a shortened command to represent a long string on the command line. 8 | 9 | For example, let's create an alias for the log command we learned earlier. 10 | 11 | ### Original command 12 | 13 | ```sh 14 | git log --oneline --graph --decorate --all 15 | ``` 16 | 17 | ### Creating the alias 18 | 19 | ```sh 20 | git config --global alias.lol "log --oneline --graph --decorate --all" 21 | ``` 22 | 23 | ### Using the alias 24 | 25 | ```sh 26 | git lol 27 | ``` 28 | 29 | ## Explore other helpful aliases 30 | 31 | Check out these resources for a list of common aliases: 32 | 33 | - *[git-scm.com/book/en/v2/Git-Basics-Git-Aliases](https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases)* A helpful overview of some of the most common git aliases. 34 | 35 | We also encourage you to read through these three blog posts by GitHub developer Phil Hack. His tips are referenced throughout the manual. 36 | 37 | - [GitHub Flow Aliases](http://haacked.com/archive/2014/07/28/github-flow-aliases/) 38 | - [Git Migrate](http://haacked.com/archive/2015/06/29/git-migrate/) 39 | - [Git Alias Open URL](http://haacked.com/archive/2017/01/04/git-alias-open-url/) 40 | 41 | ### Example aliases 42 | 43 | To edit your global aliases manually, you can open the `.gitconfig` file with your default editor: 44 | 45 | ```sh 46 | git config --global alias.ec "config --global -e" 47 | ``` 48 | 49 | To switch to another branch, you can make a quick shortcut: 50 | 51 | ```sh 52 | git config --global alias.sw "switch" 53 | ``` 54 | 55 | To create and switch to a brand-new branch, you can easily extend your existing shortcut: 56 | 57 | ```sh 58 | git config --global alias.swc "switch -c" 59 | ``` 60 | 61 | You can create aliases that only call one command: 62 | 63 | ```sh 64 | git config --global alias.s "status -s" 65 | ``` 66 | 67 | Clean up branches quickly and easily: 68 | 69 | ```sh 70 | git config alias.dlb '!git checkout && git pull --prune && git branch --merged | grep -v "\*" | xargs -n 1 git branch -d' 71 | ``` 72 | -------------------------------------------------------------------------------- /docs/12a_what_is_a_merge_conflict.md: -------------------------------------------------------------------------------- 1 | ## What is a merge conflict? 2 | 3 | When you work with a team (and even sometimes when you are working alone) you will occasionally create merge conflicts. At first, merge conflicts can be intimidating, but resolving them is actually quite easy. In this section you will learn how! 4 | 5 | These exercises will focus on the technical "how". In real merge conflicts, it's important to know who to ask in case you aren't sure how to resolve the conflict on your own. Usually it's a good idea to ask the person who made the conflicting changes, or someone who referenced in the CODEOWNERS file. 6 | 7 | ### Local merge conflicts 8 | 9 | Merge conflicts are a natural and minor side effect of distributed version control. They only happen under very specific circumstances. 10 | 11 | - Changes to the same "hunk" of the same file 12 | - Two different branches 13 | - Changes on both branches happened since the branches have diverged 14 | -------------------------------------------------------------------------------- /docs/12b_resolving_merge_conflicts.md: -------------------------------------------------------------------------------- 1 | ### Resolving a merge conflict 2 | 3 | Let's try to create a merge conflict, and fix it together. You and a partner will each create separate branches, create a file with the same name, and then try to merge. The first will merge cleanly, the second will have a merge conflict. Work together to resolve the merge conflict. 4 | 5 | 1. In our class repository, create the branch that you will be working on and name it something memorable like `USERNAME-conflict`. 6 | 1. Choose a file that both you and your partner will edit. (One of your files from earlier would work well.) On your branch, edit that file. The filename must be the same filename that your partner uses. Make sure the content inside the file is different, and that neither file is empty. 7 | 1. Create a pull request in the class repository with `base: main` and `compare: USERNAME-conflict`. 8 | 1. You will see that the _first_ pull request can merge well. 9 | 1. When you see the merge conflict in the _second_ pull request, work together to resolve the merge conflict. 10 | 1. Working locally, merge `main` into the feature branch. 11 | 1. When you see there's a conflict, that's OK! The files that have conflicts are listed under `Unmerged Paths`. Type `git status` to verify which file has the conflict. 12 | 1. Open that file in your text editor, and look for the merge conflict markers. (`<<<<<<<`, `=======`, `>>>>>>>`) 13 | 1. Both branches' versions of code are present - pick which one you want to keep, and save the changes. 14 | 1. Add and commit the saved changes to resolve the merge conflict. 15 | 1. Push the feature branch up to the remote, and see the resolution in the pull request. 16 | 1. Merge the pull request. 17 | 18 | ### Resolving a Merge Conflict (practice alone) 19 | 20 | If it's difficult to practice with a partner, you can do that by alone by following below. 21 | 22 | 1. In our class repository, confirm the branch you are in is `main`. 23 | 1. Create a branch and name it as `USERNAME-modify-first`. 24 | 1. In the `USERNAME-modify-first` branch, edit your caption on line 6 of your slide file `_slides/##-USERNAME.md` and commit it. 25 | 1. **Change the branch to `main` again**, create a second branch and name it as `USERNAME-modify-conflict`. 26 | 1. In the `USERNAME-modify-conflict` branch, edit your caption with different string on the same position as the previous step (line 6 of `_slides/##-USERNAME.md`) and commit it. 27 | - Make sure the content inside of the file is different, and that neither file is empty. 28 | 1. Create a pull request in the class repository with `base: main` and `compare: USERNAME-modify-first`. (title: `USERNAME merge first`) 29 | 1. Create a pull request in the class repository with `base: main` and `compare: USERNAME-modify-conflict`. (title: `USERNAME resolve conflict`) 30 | 1. You will see that the _first_ pull request titled `USERNAME merge first` can merge well. 31 | 1. When you see the merge conflict in the _second_ pull request titled `USERNAME resolve conflict`, work by yourself to resolve the merge conflict. 32 | 1. Working locally, switch to `main` branch and pull updates from remote. 33 | 34 | ```sh 35 | git switch main 36 | git pull 37 | ``` 38 | 39 | 1. Fetch the `USERNAME-modify-conflict` branch from remote and switch to the same branch locally. 40 | 41 | ```sh 42 | git fetch 43 | git switch USER-modify-conflict 44 | ``` 45 | 46 | 1. Merge `main` into the feature branch. 47 | 48 | ```sh 49 | git merge main 50 | ``` 51 | 52 | 1. When you see there's a conflict, that's OK! The files that have conflicts are listed under `Unmerged Paths`. Type `git status` to verify which file has the conflict. 53 | 54 | ```sh 55 | git status 56 | ``` 57 | 58 | 1. Open that file in your text editor, and look for the merge conflict markers. (`<<<<<<<`, `=======`, `>>>>>>>`) 59 | 60 | ```sh 61 | # Open the file on Visual Studio Code 62 | code _slides/##-USERNAME.md 63 | ``` 64 | 65 | 1. Both branches' versions of code are present - pick which one you want to keep, and save the changes. 66 | 1. Add and commit the saved changes to resolve the merge conflict. 67 | 68 | ```sh 69 | git add _slides/##-USERNAME.md 70 | git commit 71 | ``` 72 | 73 | 1. Push the feature branch up to the remote, and see the resolution in the pull request. 74 | 75 | ```sh 76 | git push 77 | ``` 78 | 79 | 1. Confirm that the merge conflict in the branch titled `USERNAME resolve conflict` was resolved and merge the pull request. 80 | 81 | > What is a merge message? In this example, we are doing a recursive merge. A recursive merge creates a new commit that permanently records the point in time when these two branches were merged together. We will talk more about Git merge strategies a little later. 82 | -------------------------------------------------------------------------------- /docs/13_workflow_review_project_github_games.md: -------------------------------------------------------------------------------- 1 | ## Project: GitHub Games 2 | 3 | In this section, we will work on a project repository called `github-games`. 4 | 5 | A `github-games` repository has been created for you in the githubschool organization. You can access the repository at `https://github.com/githubschool/github-games-USERNAME`. 6 | 7 | If you're using the Fork and Pull Workflow, [don't forget to look in the appendix for a more thorough explanation](app_fork_workflow.md). 8 | 9 | ### Workflow Review: Updating the README.md 10 | 11 | Now you will practice the GitHub Flow from beginning to end by updating the link in the README to point to your fork of the repository. 12 | 13 | > Remember, your copy of the website will be rendered at `https://githubschool.github.io/github-games-USERNAME`. 14 | > 15 | > This link also appears in the repository description. It is a good idea to edit the website URL in the description, so you can easily access your game. 16 | > 17 | > If you click the link, you will see the text in the `README.md`. We have intentionally broken this repository, so we can fix it together. 18 | 19 | Since this is a review, we have written these steps at a high level. As we complete the review, we will show you a few shortcuts for the commands you learned in the previous activity: 20 | 21 | 1. Clone your copy of the repository: `git clone https://github.com/githubschool/github-games-USERNAME.git` 22 | 1. Create a new branch called `readme-update`: `git switch -c readme-update` 23 | 1. Edit the URL in the README.md. 24 | 1. Commit the changes to your branch. 25 | 1. Push your branch to GitHub: `git push -u origin readme-update` 26 | 1. Create a Pull Request *in your repository* (base: `main`, compare: `readme-update`) 27 | 1. Merge your Pull Request. 28 | 1. Delete the branch on GitHub. 29 | 1. Update your local copy of the repository: `git pull --prune` 30 | 31 | `git switch -c readme-update` is a shortcut command that allows you to combine the creation of the branch and switching to that branch. The `-c` tells Git to create a new branch. 32 | 33 | > `git push -u origin readme-update` is the slightly longer version of the push command that should be used when you push a new branch for the first time. 34 | > 35 | > The `-u` is the short version of the option `--set-upstream`. This option tells Git to create a relationship between our local branch and a remote tracking branch of the same name.\ 36 | > 37 | > You only need to use this long command the first time you push a new branch. After that, you can simply use `git push`. 38 | 39 | `git config --global alias.bclean "!f() { branches=$(git branch --merged ${1-main} | grep -v " ${1-main}$"); [ -z \"$branches\" ] || git branch -d $branches; }; f"` could be helpful here. **Take a peek in the appendix to learn how!** 40 | -------------------------------------------------------------------------------- /docs/14_git_bisect.md: -------------------------------------------------------------------------------- 1 | ## Searching for events in your code 2 | 3 | In this section, we will learn how we can use `git bisect` to find the commit that introduced a bug into our repository. 4 | 5 | ### What is `git bisect`? 6 | 7 | Using a binary search, `git bisect` can help us detect specific events in our code. For example, you could use bisect to locate the commit where: 8 | 9 | - a bug was introduced. 10 | - a new feature was added. 11 | - a benchmark’s performance improved. 12 | 13 | #### How it works 14 | 15 | `git bisect` works by cutting the history between two points in half and then checking you out to that commit. You then check whether the bug/feature exists at that point and tell Git the result. From there, Git will do another division, etc until you have located the desired commit. 16 | 17 | ![Git Bisect](./img/git-bisect.png) 18 | 19 | > When you are doing a bisect, you are essentially in a detached head state. It is important to remember to end the bisect with `git bisect reset` before attempting to perform other operations with Git. 20 | 21 | ### Finding the bug in our project 22 | 23 | #### The long way 24 | 25 | 1. Initiate the binary search: `git bisect start`. 26 | 1. Specify the commit where you noticed the code was broken: `git bisect bad `. 27 | 1. Specify the commit where you knew things were working: `git bisect good `. 28 | 1. Bisect will check you out to the midpoint between good and bad. 29 | 1. Run a test to see if the game would work at this point. Our test is to use `ls` to see if an `index.html` file exists. 30 | 1. If the game is still broken (there *is no* `index.html` file), type: `git bisect bad`. 31 | 1. If the game works (and there *is* an `index.html` file), type: `git bisect good`. 32 | 1. Git will bisect again and wait for you to test. This will happen until Git has enough information to pinpoint the first bad commit. 33 | 1. When Git has detected the error, it will provide a message that `SHA is the first bad commit.` 34 | 1. Exit the bisect process: `git bisect reset`. 35 | 36 | #### The short way 37 | 38 | Bisect can also run the tests on your code automatically. Let's try it again using a shortcut command and a test: 39 | 40 | 1. `git bisect start ` 41 | 1. `git bisect run ls index.html` 42 | 1. `git bisect reset` 43 | -------------------------------------------------------------------------------- /docs/15_reverting_commits.md: -------------------------------------------------------------------------------- 1 | ## Reverting commits 2 | 3 | In this section, we will learn about commands that re-write history and understand when you should or shouldn't use them. 4 | 5 | ### How commits are made 6 | 7 | Every commit in Git is a unique snapshot of the project at that point in time. It contains the following information: 8 | 9 | - Pointers to the current objects in the repository 10 | - Commit author and email (from your config settings) 11 | - Commit date and time 12 | - Commit message 13 | 14 | ![Git's Basic Commit Structure](./img/commit-and-tree.png) 15 | 16 | Each commit also contains the commit ID of its parent commit. 17 | 18 | ![Relationship between commits](./img/commit-parent.png) 19 | 20 | Image source: ProGit v2 by Scott Chacon 21 | 22 | ### Safe operations 23 | 24 | Git's data structure gives it integrity, but its distributed nature also requires us to be aware of how certain operations will impact the commits that have already been shared. 25 | 26 | If an operation will change a commit ID that has been pushed to the remote (also known as a public commit), we must be careful in choosing the operations to perform. 27 | 28 | #### Guidelines for common commands 29 | 30 | | Command | Cautions | 31 | | ------- | -------- | 32 | | `revert` | Generally safe since it creates a new commit.| 33 | | `commit --amend` | Only use on local commits. 34 | | `reset` | Only use on local commits. 35 | | `cherry-pick` | Only use on local commits. 36 | | `rebase` | Only use on local commits. 37 | 38 | ### Reverting a commit 39 | 40 | To get your game working, you will need to reverse the commit that incorrectly renames `index.html`. 41 | 42 | > **Warning**: Before you reverse the commit, it is a good idea to make sure you will not be inadvertently reversing other changes that were lumped into the same commit. To see what was changed in the commit, use `git show SHA`. 43 | 44 | 1. Initialize the revert: `git revert ` 45 | 1. Type a commit message. 46 | 1. Push your changes to GitHub. 47 | -------------------------------------------------------------------------------- /docs/16_helpful_git_commands.md: -------------------------------------------------------------------------------- 1 | ## Helpful Git commands 2 | 3 | In this section, we will explore some helpful Git commands. 4 | 5 | ### Moving and renaming files with Git 6 | 7 | 1. Create a new branch named `slow-down`. 8 | 1. On *line 9* of the `index.html` file, change the background URL to `images/texture.jpg`. 9 | 1. On *line 78*, change the timing for the game to speed it up or slow it down. 10 | 1. Save your changes. 11 | 1. See what git is tracking: 12 | 13 | ```sh 14 | git status 15 | ``` 16 | 17 | 1. Create a new, empty directory: 18 | 19 | ```sh 20 | mkdir images 21 | ``` 22 | 23 | 1. Move the texture file into the directory with git: 24 | 25 | ```sh 26 | git mv texture.jpg images/texture.jpg 27 | ``` 28 | 29 | ### Staging hunks of changes 30 | 31 | Crafting atomic commits is an important part of creating a readable and informative history of the project. 32 | 33 | 1. See what git is tracking: 34 | 35 | ```sh 36 | git status 37 | ``` 38 | 39 | 1. Move some parts of some files to the staging area with the `--patch` flag: 40 | 41 | ```sh 42 | git add -p 43 | ``` 44 | 45 | 1. Stage the hunk related to the image move: y 46 | 1. Leave the hunk related to the speed change in the working area: n 47 | 48 | ?> Wondering what all of those other options are for the hunks? Use ? to see a list of options above the hunk. 49 | 50 | `git config --global alias.cm "!git add -A && git commit -m"` could be helpful here. Check out the appendix to see how! 51 | -------------------------------------------------------------------------------- /docs/17_github_actions.md: -------------------------------------------------------------------------------- 1 | ## ![actions](img/actions.png ':size=5%') GitHub Actions 2 | 3 | Actions are sharable individual tasks that perform units of work; they allow you to automate and execute your software development workflows right in your repository. 4 | 5 | **Example use cases of GitHub Actions:** 6 | 7 | - Build a container and deploy a web service 8 | - Automatically merge an approved pull request 9 | - Welcome new users to your repository during onboarding 10 | - Run unit tests against pull requests 11 | 12 | **Actions can be defined in multiple places:** 13 | 14 | - Directly in your repository 15 | - In an open sourced public repository 16 | - [GitHub Marketplace](https://github.com/marketplace?type=actions) 17 | 18 | ### How it works 19 | 20 | An **event** would _trigger_ a **workflow** which _uses_ an **action** to complete the job. 21 | 22 | ![actions-components](img/actions-components.png) 23 | -------------------------------------------------------------------------------- /docs/17_protected_branches.md: -------------------------------------------------------------------------------- 1 | ## Protected branches & code owners 2 | 3 | In some workflows, you will want to protect critical branches to ensure the code being merged to those branches has passed the required checks and received appropriate peer review. There are several methods for this, including **protected branches** and **code owners**. 4 | 5 | ### Protected branches 6 | 7 | Repository maintainers can prevent merges to specific branches that have not met predefined criteria. These criteria can include peer reviews, tests run by integrations such as a Continuous Integration services or code quality, or until a specific code owner has reviewed and approved changes. 8 | 9 | Let's enable protected branches: 10 | 11 | 1. Select the **Settings** tab. 12 | 1. Select **Branches** from the menu on the left side of the screen. 13 | 1. Click the **Add rule** button next to **Branch protection rules**. 14 | 1. In the **Branch name pattern** text box type the name of the branch you would like to protect, for example, `main`. 15 | 1. Click the **Create** button. 16 | 17 | Without checking any other options, basic branch protection prevents force-pushes and prevents it from being deleted. To learn more about the options available, check out [the documentation for this feature](https://help.github.com/articles/defining-the-mergeability-of-pull-requests/). 18 | 19 | > **Pro-tip:** You can use wildcards (`*`, `?`) and regular expressions to make a branch protection rule apply to multiple branches. Check out the [branch protection documentation](https://help.github.com/en/articles/configuring-protected-branches) for more information on how wildcards and regular expression matching work. 20 | 21 | ### Code owners 22 | 23 | Repository maintainers can define exactly which people and teams need to review sets of changes by creating a **CODEOWNERS** file. For example, you could use CODEOWNERS to ensure: 24 | 25 | - your team's JavaScript expert reviews all files with a `.js` extension 26 | - your technical documentation team reviews all changes in the `docs/` folder 27 | - your security team reviews any new dependencies listed in the `package.json` file 28 | 29 | Let's create a CODEOWNERS file: 30 | 31 | 1. Go out to the **Code** tab of your repository. 32 | 1. Click the **Add file** drop down and then **Create new file**. 33 | 1. In the **Name your file...** text box enter `CODEOWNERS` (no extension necessary). You can add this to a `.github/` directory if desired by entering `.github/CODEOWNERS`. 34 | 1. On the first line, type `* @YOUR_USERNAME` 35 | - This means that you will be the default owner for everything in the repo, unless a later match takes preference. 36 | 1. On the next line, type `*.js @GITHUBTEACHER` 37 | - Order is important. The last matching pattern for a given change takes precedence. 38 | 1. Scroll down, and type a commit message into the **Commit new file** dialog box. 39 | 1. Click the **Commit new file** button to save your changes. 40 | 1. Now that you have created a CODEOWNERS file, go back to your branch protection settings and click the **Edit** button next to `main`. 41 | 1. Under **Protect matching branches**, select the option to **Require pull request reviews before merging** and **Require review from Code Owners**. Remember to click **Save changes**. 42 | 43 | For more information on how to format the CODEOWNERS file, check out [the documentation](https://help.github.com/articles/about-codeowners/) 44 | -------------------------------------------------------------------------------- /docs/17_tags_and_releases.md: -------------------------------------------------------------------------------- 1 | ## Tags and releases 2 | 3 | You may want to put tags or releases on certain commits in your code's history to mark specific states or places in time. To do this, you could use Git's **tag** feature, or you could use GitHub's **release** feature. 4 | 5 | ### Tags 6 | 7 | A tag is a pointer that points to a specific commit. Git tags are of two variants, an _annotated tag_ and a _lightweight tag_. An annotated tag is an immutable object unlike a lightweight tag which is mutable. Let's practice a bit with tags. 8 | 9 | Tags can be created locally with Git, or on GitHub. When creating a tag from the command line, it's recommended to create an "annotated" tag. The following example creates an annotated tag with the `-a` flag, names the tag `v1.0`, and connects it to whichever commit SHA is included. 10 | 11 | - `git tag -a v1.0 ` 12 | 13 | To see all tags, type `git tag --list`. 14 | 15 | Another caveat with tags is that they are not automatically pushed up with commits. To push tags, type `git push --tags`. 16 | 17 | You can also set this as a default with configs using `git config push.followTags true` which will automatically push tags when their associated commits are pushed. [Read more about this config setting](https://git-scm.com/docs/git-config/2.4.1#git-config-pushfollowTags). 18 | 19 | ### Releases 20 | 21 | Releases are a GitHub feature that allow you to add an executable to the tag for easier access by visitors who just want to download and install your software. Releases are tags, because they point to a specific commit and can be named like any other tag. However, releases can also include attached binaries. 22 | 23 | ### Add a release to GitHub Games 24 | 25 | 1. On GitHub, navigate to the **Code** tab of the repository. 26 | 1. Under your repository name, click Releases. 27 | 1. Click Draft a new release. 28 | 1. Type a name for the tag. We recommend you use semantic versioning. 29 | 1. Select a branch that contains the project you want to release. Usually, you'll want to release against your main branch, unless you're releasing beta software. You can also select a recent commit by choosing the recent commits tab. 30 | 1. Type a title and description that describes your release. 31 | 1. If you're ready to publicize your release, click Publish release. Otherwise, click Save draft to work on it later. 32 | 33 | > Notice that you could drag and drop or select files manually in the binaries box, or select "This is a pre-release" to notify users that it's not ready for production. 34 | -------------------------------------------------------------------------------- /docs/17_view_local_changes.md: -------------------------------------------------------------------------------- 1 | ## Viewing local changes 2 | 3 | Now that you have some files in the staging area and the working directory, let's explore how you can compare different points in your repository. 4 | 5 | ### Comparing changes within the repository 6 | 7 | `git diff` allows you to see the difference between any two refs in the repository. The diagram below shows how you can compare the content of your working area, staging, and HEAD (or the most recent commit): 8 | 9 | ![Git Diff Options](./img/diff-options.png) 10 | 11 | Let's try these commands on the repository: 12 | 13 | ```sh 14 | git diff 15 | git diff --staged 16 | git diff HEAD 17 | git diff --color-words 18 | ``` 19 | 20 | `git diff` will also allow you to compare between branches, commits, and tags by simply typing: 21 | 22 | ```sh 23 | git diff 24 | git diff main slow-down 25 | git diff origin/main main 26 | git diff 2710 b745 27 | ``` 28 | 29 | > Notice that, just like merges, diffs are directional. It is easiest to think of it as "diff back to `` starting at ``" or "see what is *not* in `` but *is* in ``". The final example shows how to compare two commits based on their commit hashes. This exact command will not work for everyone since the commits in your own repository will have different hashes. 30 | 31 | There's a helpful alias for opening the remote directly from your command-line. Check out the appendix if you'd like to know more! 32 | -------------------------------------------------------------------------------- /docs/17_workflow_discussion.md: -------------------------------------------------------------------------------- 1 | ## Discussion Guide: Team workflows and branching strategies 2 | 3 | Now is a good time to discuss workflows - what works for you and your team, what might work, and what you've been doing in the past. Here are some topics you will want to discuss with your team as you establish your ideal process. Have a conversation either synchronously or in issues in the class repository about different workflows. 4 | 5 | 1. Which branching strategy will we use? 6 | 1. Which branch will serve as our "main" or deployed code? 7 | 1. How will you protect your code? 8 | 1. Will we use naming conventions for our branches? 9 | 1. How will we use labels and assignees? 10 | 1. Will we use milestones? 11 | 1. Will we have required elements of Issues or Pull Requests (e.g. shipping checklists)? 12 | 1. Who is expected to review your work? Do you plan to involve other teams? 13 | 1. How will we indicate sign-off on Pull Requests? 14 | 1. Who will merge pull requests? 15 | 1. How will you teach your workflow to your team? If it already exists, how is it taught to new hires? 16 | 1. What integrations will be used in different stages of development? Will all teams be using the same tools? 17 | 1. If users have questions about Git, GitHub, or their workflows, who do they ask? How do they know who to ask? 18 | -------------------------------------------------------------------------------- /docs/18_create_local_repo.md: -------------------------------------------------------------------------------- 1 | ### Initializing a new local repository 2 | 3 | Let's create a local repository that we can use to practice the next set of commands. 4 | 5 | 1. Navigate to the directory where you will place your practice repo (`cd ..` to get back to the parent folder). 6 | 1. Create a new directory and initialize it as a git repository: `git init practice-repo` 7 | 1. CD into your new repository: `cd practice-repo` 8 | 1. Create an empty new file named `README.md`: 9 | - Bash: `touch README.md` 10 | - PowerShell: `Out-File README.md` 11 | 1. Add and commit the README.md file. 12 | 13 | Since we will be using this as our practice repository, we need to generate some files and commits. Here are some scripts to make this easier: 14 | 15 | **Bash:** 16 | 17 | ```bash 18 | for d in {1..6}; do touch "file${d}.md"; git add "file${d}.md"; git commit -m "adding file ${d}"; done 19 | ``` 20 | 21 | **PowerShell:** 22 | 23 | ```powershell 24 | for ($d=1; $d -le 6; $d++) { Out-File file$d.md; git add file$d.md; git commit -m "adding file$d.md"; } 25 | ``` 26 | 27 | > You might see a command during this section, `tree .git`. If you're on a machine where `tree .git` doesn't work (probably a Windows machine), try `cmd //c tree` instead. 28 | -------------------------------------------------------------------------------- /docs/19_fixing_commit_mistakes.md: -------------------------------------------------------------------------------- 1 | ## Fixing commit mistakes 2 | 3 | In this activity, we will begin to explore some ways Git and GitHub can help us shape our project history. 4 | 5 | ### Revising your last commit 6 | 7 | `git commit --amend` allows us to make changes to the commit that HEAD is currently pointing to. Two of the most common uses are: 8 | 9 | - Re-writing commit messages 10 | - Adding files to the commit 11 | 12 | Let's see this in action: 13 | 14 | 1. Create a new file: 15 | - Bash: `touch file7.md` 16 | - PowerShell: `Out-File file7.md` 17 | 1. When you are adding files to the previous commit, they should be in the staging area. Move your file to the staging area: `git add file7.md` 18 | 1. `git commit --amend` 19 | 1. The text editor will open, allowing you to edit your commit message. 20 | 21 | >You can actually amend any data stored by the last commit such as commit author, email, etc. 22 | -------------------------------------------------------------------------------- /docs/19_forgot_to_branch.md: -------------------------------------------------------------------------------- 1 | ## Oops, I forgot to create a branch 2 | 3 | If you begin working, but you are still on `main`, don’t panic! Changes aren't “on” a branch until they are committed. Your working directory and staging area are attached to `HEAD`, _not_ a branch. So, you can change branches, and any changes that are not committed will come with you. 4 | 5 | ### Activity: Create a branch after making changes 6 | 7 | 1. Modify file before creating branch 8 | - _Notice that the working directory and staging area are portable - files sitting in each area will remain there when you switch branches!_ 9 | 2. Type `git status`, and notice changes in your working directory 10 | 3. Create a new branch with `git switch -c BRANCH-NAME` 11 | 4. Type `git status` again, to notice which branch you are on, and your working directory 12 | 13 | ## Non-committed conflicts 14 | 15 | What do you think would happen if you made changes to a file, then tried to switch to another branch, but that branch had committed changes that conflict with your new, uncommitted changes? Why? 16 | -------------------------------------------------------------------------------- /docs/20_personal_access_token.md: -------------------------------------------------------------------------------- 1 | ## Interacting with SSO-enabled organizations 2 | 3 | If the repositories you interact with daily are contained in an organization that enforces SSO you might encounter difficulty working with those repositories when trying to perform Git operations like `clone`, `pull`, and `push`. This issue can be remedied by creating a personal access token (PAT) for use with your GitHub account. 4 | 5 | > **Note:** While personal access tokens have multiple uses, this is the most common reason to create one. 6 | 7 | ### Creating a PAT on GitHub.com 8 | 9 | 1. Access your account [Settings](https://github.com/settings/profile) page. 10 | 1. On the Settings page, click **Developer settings**. 11 | 1. On the Developer settings page, click **Personal access tokens**. 12 | 1. On the Personal access tokens page, click **Generate new token** in the top right corner of the page. 13 | 1. Enter a descriptive name for the PAT in the **Note** field. For example "Work laptop", "Eclipse IDE", or something else that will make it easier for future you to remember what the PAT is used for. 14 | 1. Select the **repo** checkbox. 15 | 1. Click **Generate token**. 16 | 1. Copy your new PAT, you won't be able to see the token again. 17 | 18 | > **Note:** Read this for more information about [OAuth scopes](https://docs.github.com/apps/building-oauth-apps/scopes-for-oauth-apps/). 19 | 20 | ### Using your new PAT 21 | 22 | 1. Interact with a repository that belongs to an organization with SSO enabled. 23 | 1. After performing a Git operation that prompts you to sign in, such as `git push`, sign in with your username and instead of entering your normal password, use the PAT value from the PAT you created above. 24 | -------------------------------------------------------------------------------- /docs/21_git_cherry_pick.md: -------------------------------------------------------------------------------- 1 | ## Getting it back: `git cherry-pick` 2 | 3 | We just learned how reflog can help us find local changes that have been discarded. So what if: 4 | 5 | ### You just want that one commit 6 | 7 | Cherry-picking allows you to pick up a commit from your reflog or another branch of your project and move it to your current branch. Right now, your file directory and log should look like this: 8 | 9 | ```shell-session 10 | $ ls 11 | README.md 12 | $ git log --oneline 13 | 84nqdkq initializing repo with README 14 | ``` 15 | 16 | Let's cherry-pick the commit where we added file 4: 17 | 18 | 1. Find the commit ID where you added file4.md: `git reflog` 19 | 1. Cherry-pick that commit: `git cherry-pick ` 20 | 21 | Now when you view your directory and log, you should see: 22 | 23 | ```shell-session 24 | $ ls 25 | file4.md 26 | README.md 27 | $ git log --oneline 28 | eanu482 adding file 4 29 | 84nqdkq initializing repo with README 30 | ``` 31 | 32 | Is the commit ID the same as the one you used in the cherry-pick command? Why or why not? 33 | 34 | !> Remember, when using any commands that change history, it's important to make these changes before pushing to GitHub. When you change a commit ID that has been pushed to the remote, you risk creating problems for your collaborators. 35 | 36 | ### Oops, I didn't mean to reset 37 | 38 | Sometimes, you `git reset --hard` a little further than intended and want to restore that work. The good news is, that `git reset --hard` doesn't just work by going back in time, it can also go forward: 39 | 40 | 1. View the history of everywhere HEAD has pointed: `git reflog` 41 | 1. Reset to the point in time when the original `file6.md` was created: `git reset --hard ` 42 | 1. See your restored history: `git log --oneline` 43 | 44 | Take a look at the commit IDs in `git log --oneline` compared to `git reflog`. What do you notice? 45 | 46 | > Why didn't this command cause a merge conflict since we had already cherry-picked file 4? The reason is that `git reset --hard` is not trying to merge the two histories together, it is simply moving the branch to point to a new commit. In this case, this was what we wanted. In other cases, this could cause us to lose any work we may have done after the original reset. 47 | 48 | See how to avoid tragedy with a convenient alias in the appendix. 49 | -------------------------------------------------------------------------------- /docs/22_merge_strategies_rebase.md: -------------------------------------------------------------------------------- 1 | ## Merge strategies: Rebase 2 | 3 | In this section, we will discuss another popular merge strategy, rebasing. 4 | 5 | ### Understanding Git merge strategies 6 | 7 | Git uses three primary merge strategies: 8 | 9 | #### Fast-forward 10 | 11 | A fast-forward merge assumes that no changes have been made on the base branch since the feature branch was created. This means that the branch pointer for base can simply be "fast forwarded" to point to the same commit as the feature branch. 12 | 13 | #### Recursive 14 | 15 | A recursive merge means that changes have been made on both the base branch and the feature branch and git needs to recursively combine them. With a recursive merge, a new "merge commit" is made to mark the point in time when the two branches came together. This merge commit is special because it has more than one parent. 16 | 17 | #### Octopus 18 | 19 | A merge of 3 or more branches is an octopus merge. This will also create a merge commit with multiple parents. 20 | 21 | ### About Git rebase 22 | 23 | `git rebase` enables you to modify your commit history in a variety of ways. For example, you can use it to reorder commits, edit them, squash multiple commits into one, and much more. 24 | 25 | To enable all of this, `rebase` comes in several forms. For today's class, we'll be using interactive rebase: `git rebase --interactive`, or `git rebase -i` for short. 26 | 27 | Typically, you would use `git rebase -i` to: 28 | 29 | - Replay one branch on top of another branch 30 | - Edit previous commit messages 31 | - Combine multiple commits into one 32 | - Delete or revert commits that are no longer necessary 33 | 34 | ### Creating a linear history 35 | 36 | One of the most common uses of rebase is to eliminate recursive merges and create a more linear history. In this activity, we will learn how it is done. 37 | 38 | ![Git Rebase](./img/git-rebase.png) 39 | 40 | #### Setup 41 | 42 | 1. First, switch back to the `main` branch: `git switch main` 43 | 1. Find the SHA of the initial commit: `git log --oneline` 44 | 1. Reset to the SHA of the initial commit: `git reset --hard SHA` 45 | 1. Create a new branch and check out to it: `git switch -c rebase-me` 46 | 1. Cherry-pick files 4-6 onto the `rebase-me` branch using the reflog. 47 | 1. Switch to main: `git switch main` 48 | 1. Cherry-pick files 1-3 onto the `main` branch using the reflog. 49 | 1. Look at your history: `git log --oneline --graph --decorate --all` 50 | 1. If you merged now, it would be a recursive merge. 51 | 52 | #### Begin the rebase 53 | 54 | 1. Switch to the `rebase-me` branch: `git switch rebase-me` 55 | 1. Start the merge: `git rebase -i main` 56 | 1. Your text editor will open, allowing you to see the commits to be rebased. 57 | 1. Save and close the `rebase-todo`. 58 | 1. Watch your rebase happen on the command-line. 59 | 1. Take another look at your history: `git log --oneline --graph --decorate --all` 60 | 1. If you merged now, it would be a fast-forward merge. 61 | 62 | #### Finish the merge 63 | 64 | 1. Switch to main, the branch you will merge into: `git switch main` 65 | 1. Merge your changes in to main: `git merge rebase-me` 66 | 67 | If you'd like some help keeping everything clean with an alias, don't forget to check the appendix! 68 | -------------------------------------------------------------------------------- /docs/23_gitignore.md: -------------------------------------------------------------------------------- 1 | ## Configure Git to ignore files 2 | 3 | While working within your repository, you might notice system or configuration files created by your operating system or text editor. These files are typically things that you don't want git to track or include in the history of your project. Although you can manually ignore those files by never committing them to the history of the project, there is an easier way for you to ignore those files. Git enables you to ignore specific files, files types, and folders through the use of a text file you can add to your repository titled `.gitignore`. This file instructs Git to stop tracking changes of certain files, which means that these files will not be pushed to GitHub from your local machine. 4 | 5 | **Example files that you might want Git to ignore:** 6 | 7 | 1. Secrets, e.g. `*.pem`, `*.key` 8 | 1. Binary files, e.g. `*.pdf`, `*.docx` 9 | 1. Log files, e.g. `*.log` 10 | 1. Build files, e.g. `Build/*` 11 | 12 | ### Readily available `.gitignore` templates 13 | 14 | #### github/gitignore 15 | 16 | The [github/gitignore repository](https://github.com/github/gitignore) is a collection of `.gitignore` templates based on popular programming languages. 17 | 18 | For example, the following snippet shows some suggested files you should start ignoring in a Python project. 19 | 20 | ![python-gitignore](img/python-gitignore.png ':size=60%') 21 | 22 | These templates are also available when you create a new repository: 23 | 24 | ![create-gitignore-repo](img/gitignore-create-repo.png ':size=60%') 25 | 26 | #### gitignore.io 27 | 28 | [This website](https://www.toptal.com/developers/gitignore) is another resource for you to find appropriate `.gitignore` templates when your project contains multiple programming languages. 29 | 30 | ### Activity: Creating a `.gitignore` file 31 | 32 | #### Ignore files for a single repository 33 | 34 | 1. In your Terminal or Git Bash, `cd` to a repository of interest and create a `.gitignore` file: 35 | 36 | ```sh 37 | touch .gitignore 38 | ``` 39 | 40 | For Windows users who are not using a bash-based terminal: 41 | 42 | ```sh 43 | echo >> .gitignore 44 | ``` 45 | 46 | 1. Go to `github/gitignore` and choose a template of your choice and paste it in the file. 47 | 48 | 1. To share the gitignore rules with other users who clone the repository, commit the `.gitignore` file to your repository. 49 | 50 | ```sh 51 | git add .gitignore 52 | git commit -m "add gitignore file" 53 | ``` 54 | 55 | #### Ignore files for all repositories on your local machine 56 | 57 | 1. You can also create a global `.gitignore` file to define a list of rules for ignoring files in every local Git repository. 58 | 59 | To do this, you should be in your root directory: 60 | 61 | ```sh 62 | touch .gitignore_global 63 | ``` 64 | 65 | 1. Let's grab [an example `.gitignore` template](https://gist.github.com/octocat/9257657) and paste it in the file: 66 | 67 | ```md 68 | # Compiled source # 69 | ################### 70 | *.com 71 | *.class 72 | *.dll 73 | *.exe 74 | *.o 75 | *.so 76 | 77 | # Packages # 78 | ############ 79 | # it's better to unpack these files and commit the raw source 80 | # git has its own built in compression methods 81 | *.7z 82 | *.dmg 83 | *.gz 84 | *.iso 85 | *.jar 86 | *.rar 87 | *.tar 88 | *.zip 89 | 90 | # Logs and databases # 91 | ###################### 92 | *.log 93 | *.sql 94 | *.sqlite 95 | 96 | # OS generated files # 97 | ###################### 98 | .DS_Store 99 | .DS_Store? 100 | ._* 101 | .Spotlight-V100 102 | .Trashes 103 | ehthumbs.db 104 | Thumbs.db 105 | ``` 106 | 107 | 1. Configure `git` to use this file: 108 | 109 | For Mac Users: 110 | 111 | ```sh 112 | git config --global core.excludesfile ~/.gitignore_global 113 | ``` 114 | 115 | For Windows Users: 116 | 117 | ```sh 118 | git config --global core.excludesfile %USERPROFILE%\.gitignore_global 119 | ``` 120 | -------------------------------------------------------------------------------- /docs/25_git_stash.md: -------------------------------------------------------------------------------- 1 | ## Git stash 2 | 3 | Git stash takes the changes you have made to your working tree ("dirty") and puts them in a holding pattern until you are ready to re-apply them, so you have a fresh working directory ("clean"). 4 | 5 | Common use cases for using git stash are 6 | 7 | - Needing to change focus from the task you are currently working on to a new task 8 | - Forgetting to switch working branches 9 | - Needing to apply changes to multiple branches 10 | 11 | When these scenarios happen, figuring out what to do with your in-progress work might be difficult. Do you commit it even though it isn't "ready to be committed"? Do you create a new branch with your changes and come back to it? Do you need to delete your changes and just re-create the work when you can come back to this task? Do you manually copy-and-paste the changes across branches? 12 | 13 | There are different solutions to these problems, but this section is going to review the use of `git stash` to store changes you have made in the event that you do not want to commit them to the project's history. 14 | 15 | ### How to use `git stash` 16 | 17 | The `git stash` command enables you to store changes that live in the working directory (unstaged changes) and staging area (staged changes) for later use. These stored changes, like the `reflog`, are only reflected on your *local copy* of the repository. The latest stash is stored in `refs/stash` and older stashes are found in the `reflog` of that reference. 18 | 19 | You can have multiple stashes, and they can be referenced by specifying the stash index, or they can be named using `reflog` syntax (example: `stash@{2.hours.ago}`). You can also add a descriptive message to stashes with `git stash save "message"`. Once you are ready to retrieve those changes, you can apply and delete them with `git pop` or apply and continue to store them with `git stash apply`. 20 | 21 | #### Commands 22 | 23 | - `git stash` 24 | - Use this when you want to record the current working state, but want a clean working directory 25 | - This will "stash" your local modifications and revert the working directory to match the `HEAD` commit 26 | - `git stash push` 27 | - Saves local changes to the stash and then rolls back to `HEAD` in the working tree and index 28 | - `git stash push -m ` gives the message along with the stashed state 29 | - Options include `-m|--message `, `-p|--patch`, `--` 30 | - `git stash list` 31 | - This will list all the stashes you have available 32 | - `git stash show` 33 | - Adds verbosity to `git stash list` and allows you to inspect the stashes 34 | - `stash@{0}` will always be the most recent stash available 35 | - `git stash drop` 36 | - Removes the most recent stash entry from the list (i.e. `stash@{0}`) 37 | - `git stash drop ` will drop the specified stash index (example: `git stash drop 2`) 38 | - **Note:** The stash index will update when you drop a stash 39 | - `git stash clear` 40 | - Deletes all stashes 41 | - `git stash pop` 42 | - Removes a single stash and applies it on top of the current working tree 43 | - The working directory must match the index 44 | - The `git stash pop` can fail with conflicts and will not be removed from the stash list 45 | - You must resolve the conflicts manually and `git stash drop` afterwards 46 | - `git stash apply` 47 | - Similar to `git stash pop`, but does not remove the stash from the stash list 48 | - Can be useful for applying changes to multiple branches 49 | - `git stash branch` 50 | - `git stash branch ` creates and checks out a new branch named `` starting from the point the stash was created and applies the stash; if it is successful, it drops the stash 51 | - Can be useful if you forgot to switch a new branch before starting working 52 | - `git stash create` 53 | - Create a stash entry and return the object name without storing it in the ref namespace 54 | - Useful for scripts 55 | - Easily confused with `git stash push`, but doesn't return a clean working directory 56 | - `git stash store` 57 | - Store a stash made with `git stash create` 58 | - Adds it to the stash ref and updates the stash reflog 59 | - Useful for scripts 60 | - Easily confused with `git stash push`, but doesn't return a clean working directory 61 | -------------------------------------------------------------------------------- /docs/27_git_submodules.md: -------------------------------------------------------------------------------- 1 | ## Git submodules 2 | 3 | In some instances, you might want to store the contents of another repository within your repository based on a specific commit in that other repository's history. Git provides a functionality to cover this need in the form of Git submodules. 4 | 5 | Git submodules enable you to include the contents of another repository based on a specific commit. This means while changes occur in the other repository you are able to continue to utilize that project's history at a specific point. 6 | -------------------------------------------------------------------------------- /docs/28_git_subtrees.md: -------------------------------------------------------------------------------- 1 | ## Git subtrees 2 | 3 | Subtrees are a git tool for including the content of another repository as a dependency of your project. As an example, if you are working on a repository that would benefit from having the contents of another repository, subtrees might be the tool you need. Unlike submodules which require the use of a `.gitmodule` file to manage the inclusion of another repository in your repository, subtrees don't rely on external files to be managed. 4 | 5 | ### Activity: Adding a subtree 6 | 7 | #### Setting up the empty repository for a subtree merge 8 | 9 | 1. Open your preferred command line tool. 10 | 1. Create a new directory and navigate to it. 11 | 12 | ```sh 13 | mkdir test 14 | cd test 15 | ``` 16 | 17 | 1. Initialize a new Git repository. 18 | 19 | ```sh-session 20 | $ git init 21 | Initialized empty Git repository in /Users/octocat/tmp/test/.git/ 22 | ``` 23 | 24 | 1. Create and commit a new file. 25 | 26 | ```sh-session 27 | $ touch .gitignore 28 | $ git add .gitignore 29 | $ git commit -m "initial commit" 30 | [main (root-commit) 3146c2a] initial commit 31 | 0 files changed, 0 insertions(+), 0 deletions(-) 32 | create mode 100644 .gitignore 33 | ``` 34 | 35 | #### Adding a new repository as a subtree 36 | 37 | 1. Add a new remote URL pointing to the separate project that we're interested in. 38 | 39 | ```sh-session 40 | $ git remote add -f spoon-knife git@github.com:octocat/Spoon-Knife.git 41 | Updating spoon-knife 42 | warning: no common commits 43 | remote: Counting objects: 1732, done. 44 | remote: Compressing objects: 100% (750/750), done. 45 | remote: Total 1732 (delta 1086), reused 1558 (delta 967) 46 | Receiving objects: 100% (1732/1732), 528.19 KiB | 621 KiB/s, done. 47 | Resolving deltas: 100% (1086/1086), done. 48 | From git://github.com/octocat/Spoon-Knife 49 | * [new branch] main -> Spoon-Knife/main 50 | ``` 51 | 52 | 1. Merge the `Spoon-Knife` project into the local Git project. This doesn't change any of your files locally, but it does prepare Git for the next step. 53 | 54 | If you're using Git 2.9 or above: 55 | 56 | ```sh-session 57 | $ git merge -s ours --no-commit --allow-unrelated-histories spoon-knife/main 58 | Automatic merge went well; stopped before committing as requested 59 | ``` 60 | 61 | If you're using Git 2.8 or below: 62 | 63 | ```sh-session 64 | $ git merge -s ours --no-commit spoon-knife/main 65 | Automatic merge went well; stopped before committing as requested 66 | ``` 67 | 68 | 1. Create a new directory called **spoon-knife**, and copy the Git history of the `Spoon-Knife` project into it. 69 | 70 | ```sh 71 | git read-tree --prefix=spoon-knife/ -u spoon-knife/main 72 | ``` 73 | 74 | 1. Commit the changes to keep them safe. 75 | 76 | ```sh-session 77 | $ git commit -m "Subtree merged in spoon-knife" 78 | [main fe0ca25] Subtree merged in spoon-knife 79 | ``` 80 | 81 | Although we've only added one subproject, any number of subprojects can be incorporated into a Git repository. 82 | 83 | ?> **Tip**: If you create a fresh clone of the repository in the future, the remotes you've added will not be created for you. You will have to add them again using [the `git remote add` command](https://docs.github.com/github/using-git/adding-a-remote). 84 | 85 | #### Synchronizing with updates and changes 86 | 87 | When a subproject is added, it is not automatically kept in sync with the upstream changes. You will need to update the subproject with the following command: 88 | 89 | ```sh 90 | git pull -s subtree 91 | ``` 92 | 93 | For the example above, this would be: 94 | 95 | ```sh 96 | git pull -s subtree spoon-knife main 97 | ``` 98 | -------------------------------------------------------------------------------- /docs/App_clean_loaner_pc.md: -------------------------------------------------------------------------------- 1 | ## Cleaning out your loaner PC 2 | 3 | If you borrowed a laptop or used a virtual machine for this class, you will want to clear out your configs and credentials before you give it back. Here's how: 4 | 5 | ### Step 1: Clear your configs 6 | 7 | 1. `git config --unset --global user.name` 8 | 1. `git config --unset --global user.email` 9 | 10 | ### Step 2: Clear your command line history 11 | 12 | - **Bash:** `history -c && history -w && exit` 13 | - **Windows command prompt:** Alt+F7 14 | 15 | ### Step 3: Clear the credential manager 16 | 17 | **For Windows:** 18 | 19 | 1. From the **Start** menu, select **Control Panel**. 20 | 1. Click **User Accounts**. 21 | 1. Click **Manage my credentials**. 22 | 1. Click **Credential Manager**. 23 | 1. In the Windows Credentials and Generic Credentials section, remove any stored credentials referencing Git or GitHub. 24 | 25 | **For Mac:** 26 | 27 | 1. Open the **Keychain Access** app. 28 | 1. Delete anything with GitHub. 29 | -------------------------------------------------------------------------------- /docs/GH4D/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | Moved 4 | 5 | 6 | 7 |

Moved

8 |

This page has moved to https://githubtraining.github.io/training-manual/.

9 | 10 | 11 | -------------------------------------------------------------------------------- /docs/GH4DJA/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | Moved 4 | 5 | 6 | 7 |

Moved

8 |

This page has moved to https://githubtraining.github.io/training-manual/#/ja/.

9 | 10 | 11 | -------------------------------------------------------------------------------- /docs/README.md: -------------------------------------------------------------------------------- 1 | ## Welcome to GitHub 2 | 3 | Today you will embark on an exciting new adventure: learning how to use Git and GitHub. 4 | 5 | As we move through today's materials, please keep in mind: this class is for you! Be sure to follow along, try the activities, and ask lots of questions! 6 | 7 | ### License 8 | 9 | The prose, course text, slide layouts, class outlines, diagrams, HTML, CSS, and Markdown code in the set of educational materials located in this repository are licensed as [CC BY 4.0](http://creativecommons.org/licenses/by/4.0/legalcode). The Octocat, GitHub logo and other already-copyrighted and already-reserved trademarks and images are not covered by this license. 10 | 11 | For more information, visit: 12 | -------------------------------------------------------------------------------- /docs/_coverpage.md: -------------------------------------------------------------------------------- 1 | ![logo](./img/cover.png ':no-zoom') 2 | 3 | # [The Official GitHub Training Manual](01_getting_ready_for_class) 4 | 5 | [English](01_getting_ready_for_class) 6 | [日本語](/ja/) 7 | [PDF](book.pdf) 8 | 9 | ![color](#f6f8fa) -------------------------------------------------------------------------------- /docs/_sidebar.md: -------------------------------------------------------------------------------- 1 | - Getting Started 2 | - [Getting Ready for Class](01_getting_ready_for_class.md) 3 | - [Getting Started](02_getting_started.md) 4 | - [GitHub Flow](03_github_flow.md) 5 | 6 | - Project 1: Caption This 7 | - [Branching with Git](04_branching_with_git.md) 8 | - [Local Git Configs](05_local_git_configs.md) 9 | - [Working Locally](06_working_locally.md) 10 | - [Collaborating on Code](07_collaborating_on_code.md) 11 | - [Editing on GitHub](08_edit_on_github.md) 12 | - [Merging Pull Requests](09_merging_pull_requests.md) 13 | - [Local History](10_local_history.md) 14 | - [Streamline Workflow with Aliases](11_streamline_workflow_with_aliases.md) 15 | 16 | - Project 2: Merge Conflicts 17 | - [Defining a merge conflict](12a_what_is_a_merge_conflict.md) 18 | - [Resolving merge Conflicts](12b_resolving_merge_conflicts.md) 19 | 20 | - Project 3: GitHub Games 21 | - [Workflow Review](13_workflow_review_project_github_games.md) 22 | - [Protected Branches & CODEOWNERS](17_protected_branches.md) 23 | - [Git Bisect](14_git_bisect.md) 24 | - [Reverting Commits](15_reverting_commits.md) 25 | - [Helpful Git Commands](16_helpful_git_commands.md) 26 | - [Viewing Local Changes](17_view_local_changes.md) 27 | - [Tags & Releases](17_tags_and_releases.md) 28 | - [Workflow Discussion](17_workflow_discussion.md) 29 | 30 | - Project 4: Local Repository 31 | - [Create a Local Repo](18_create_local_repo.md) 32 | - [Fixing Commit Mistakes](19_fixing_commit_mistakes.md) 33 | - [Forgot to branch?](19_forgot_to_branch.md) 34 | - [Rewriting History with Git Reset](20_rewriting_history_git_reset.md) 35 | - [Cherry Picking](21_git_cherry_pick.md) 36 | - [Merge Strategies](22_merge_strategies_rebase.md) 37 | 38 | - Advanced Topics 39 | - [Personal Access Tokens](20_personal_access_token.md) 40 | - [GitHub Actions](17_github_actions.md) 41 | - [Automate Releases](17_actions_activity.md) 42 | - [.gitignore File](23_gitignore.md) 43 | - [Commit signature verification](24_commit_sig_verification.md) 44 | - [Git Stash](25_git_stash.md) 45 | - [Git LFS](26_git_lfs.md) 46 | - [Git submodules](27_git_submodules.md) 47 | - [Git subtrees](28_git_subtrees.md) 48 | 49 | - Appendix 50 | - **GitHub Resources** 51 | - [Day 1 Activity Instructions](app_Day_1_activities.md) 52 | - [Day 2 Activity Instructions](app_day2_mergeconflict.md) 53 | - [Fork and Pull Workflow and Multiple Remotes](app_fork_workflow.md) 54 | - [End of Training: Cleaning Loaner PCs](App_clean_loaner_pc.md) 55 | - **Tool tips** 56 | - [Add your human-readable name](app_add_human_readable_name.md) 57 | - [How to Generate Jekyll Sites Locally](app_how_to_generate_locally.md) 58 | - [Add Branch to Terminal Prompt](app_git_branch_in_terminal.md) 59 | - [Alias Pro Tips](app_aliases.md) 60 | - [Vi Basics](app_vi_basics.md) 61 | - **Community Resources** 62 | - [GitHub Events](app_github_events.md) 63 | - [Plan an event](app_plan_an_event.md) 64 | - [Facilitating workflow conversations](app_facilitating_workflow.md) 65 | - [Case studies](app_case_studies.md) 66 | - [Prepare for being an ambassador](app_evangelize.md) 67 | - [Issue templates](app_issue_template.md) 68 | - [Supporting Learning Lab](app_supporting_learning_lab.md) 69 | - **Teaching Resources** 70 | - [GitHub Training Scripts](app_teaching_script.md) 71 | - [Teachback: Prepare repositories](app_teachback_repo_prep.md) 72 | - [Teacher/Facilitation Tips](app_facilitation_tips.md) 73 | - [Authentication Troubleshooting Guide](app_authentication.md) 74 | -------------------------------------------------------------------------------- /docs/app_Day_1_activities.md: -------------------------------------------------------------------------------- 1 | ## Day 1 Activities 2 | 3 | ### Add a new slide 4 | 5 | Just like we did in class, open a new pull request adding a new slide to the deck. 6 | 7 | 1. Create a new branch, and switch to that branch: 8 | 9 | ```sh 10 | git switch -c NEWBRANCHNAME 11 | ``` 12 | 13 | 1. Create a new file in the `_slides` directory: 14 | 15 | ```sh 16 | touch 00-USERNAME.md 17 | ``` 18 | 19 | 1. Follow the directions for the same activity we created together, where it says "[Activity: Edit Your File](06_working_locally)". 20 | 1. Instead of just adding the caption, you will need to find a new image from the image list and use that to fill in this template: 21 | 22 | ```markdown 23 | --- 24 | layout: slide 25 | --- 26 | 27 | SLIDE-CAPTION 28 | 29 | IMAGE-URL 30 | {: .center} 31 | ``` 32 | 33 | 1. Save and commit your changes on your new branch. 34 | 1. If working locally, push your changes up to the remote: 35 | 36 | ```sh 37 | git push -u origin NEWBRANCHNAME 38 | ``` 39 | 40 | 1. Open a pull request 41 | In the body of the pull request, @ mention anyone you'd like to review your changes. 42 | 1. Once the tests pass on your pull request, merge the pull request. 43 | 44 | ### Add a caption to an existing slide 45 | 46 | Add a caption to an existing slide in someone else's pull request. 47 | 48 | 1. Find a pull request that you'd like to add a caption to. 49 | 1. See what image they have chosen by clicking 'files changed', and then 'view'. 50 | 1. Edit the file, either in the browser or locally, to add a line with your caption. (Please do not erase work that others have added to this file.) 51 | - If you are working locally, you will need to check out to the branch. 52 | - Make sure you have all the remote changes updated in your local repository: `git pull`. 53 | - Look for the name of the branch in the pull request, and check out to that branch locally: `git switch BRANCHNAME`. 54 | 1. Save the changes, and commit the file. 55 | - If you are working locally, push the changes up to the remote: `git push`. 56 | 1. Do not merge the pull request, simply `@` mention the user who opened the pull request to let them know about your changes. 57 | 58 | ### Improve the `README.md` 59 | 60 | Improve our `README.md` by adding some of your favorite resources. 61 | 62 | 1. Create branch, and switch to that branch: `git switch -c NEWBRANCHNAME`. 63 | 1. Edit the README.md to be better in some way. This could mean adding a new resource, or making the existing descriptions more clear. Save and commit your changes. 64 | 1. If working locally, push your changes up to the remote: `git push -u origin NEWBRANCHNAME`. 65 | 1. Open a pull request 66 | In the body of the pull request, with `base: main` and `compare: NEWBRANCHNAME`. 67 | 1. `@` mention anyone you'd like to review your changes. 68 | 1. Once the tests pass on your pull request, merge the pull request. 69 | 70 | ### Restyle slides 71 | 72 | If you'd like a more advanced challenge, and you have an eye for style, change the colors, font, and other aspects of the class slide deck. **Note: If multiple participants attempt this, there may be merge conflicts.** 73 | 74 | 1. Create a new branch and check out to it: `git switch -c NEWBRANCHNAME`. 75 | 1. Find the file `_sass/solarized/solarized.scss`. 76 | 1. Make changes in the file. 77 | - Lines 12-19 affect colors 78 | - Lines 33-35 affect font and font size 79 | - Lines 52-55 affect headers 80 | 1. Save and commit your changes on your branch. 81 | 1. Push your branch to the remote: `git push -u origin NEWBRANCHNAME`. 82 | 1. Open a pull request with `base: main` and `compare: NEWBRANCHNAME`. 83 | 1. `@` mention anyone you'd like to review your changes. 84 | 1. Once the tests pass on your pull request, merge the pull request. 85 | -------------------------------------------------------------------------------- /docs/app_add_human_readable_name.md: -------------------------------------------------------------------------------- 1 | ## Add your human-readable name 2 | 3 | Adding your human-readable name to your profile enables people to find and @mention you without knowing your GitHub username. This can be especially helpful for repositories owned by an organization so other users can easily find you. It's important to note that your name may appear around GitHub where you contribute or are @mentioned. You can remove it at any time. 4 | 5 | ### What is an @mention? 6 | 7 | An @mention is when you mention a GitHub username in an issue or pull request. The person @mentioned is notified and subscribed to future updates. You @mention by typing the `@` symbol plus the username. If you don't know their username, you might be able to find them by the first name or surname, if they've added it to their profile. You can also @mention teams. Read [Mentioning people and teams](https://docs.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax#mentioning-people-and-teams) for more information. 8 | 9 | ### Changing your profile name 10 | 11 | 1. In the upper-right corner of any page, click your profile picture dropdown, then click **Settings**. 12 | 13 | ![Profile picture dropdown screenshot](./img/userbar-account-settings.png) 14 | 15 | 1. Under "Name", type the name you want to be displayed on your profile 16 | 17 | ![Profile name screenshot](./img/name-field.png) 18 | 19 | 1. Click the "Update profile" button at the bottom of the page. 20 | -------------------------------------------------------------------------------- /docs/app_authentication.md: -------------------------------------------------------------------------------- 1 | ## Authentication troubleshooting guide 2 | 3 | The following are reasons you may be having trouble performing network operations, these include: `clone`, `push`, `pull`, and `fetch`. Try diagnosing each problem and solution in the order we've presented them. 4 | 5 | ### 1. Have you told Git to remember your credentials in the past? 6 | 7 | - **Yes** - You may have cached outdated credentials. Ask Git to forget them with `git config --global --unset credential.helper`. You may have to try `--system` instead of `--global`. Additionally, you may need to [clear the credentials from your credential manager](./App_clean_loaner_pc). 8 | - **No / I don't know / I don't remember** - You should be seeing a prompt to enter your GitHub username and password each time you perform a network operation. If you don't, you've probably cached your credentials without realizing it. 9 | 10 | ### 2. Are you cloning with HTTPS? 11 | 12 | - **Yes** - It's possible you've got [2FA](https://help.github.com/articles/about-two-factor-authentication/) set up. In order to be able to clone from the command line with HTTPS, you need to [use an access token](https://help.github.com/articles/creating-an-access-token-for-command-line-use/). 13 | 14 | If that still doesn't work, you can attempt to [clone with SSH](https://help.github.com/articles/which-remote-url-should-i-use/#cloning-with-ssh-urls). 15 | 16 | - **No / I don't know** - Try [cloning with HTTPS](https://help.github.com/articles/which-remote-url-should-i-use/#cloning-with-https-urls-recommended), which is the recommended method for cloning. 17 | 18 | ### 3. Are you behind a firewall? 19 | 20 | - **Yes** - The company firewall may be blocking access to GitHub, ask your employer or network administrator to [whitelist GitHub.com](https://help.github.com/articles/troubleshooting-connectivity-problems/). If a proxy is necessary, that can be configured [with Git](https://git-scm.com/docs/git-config#git-config-httpproxy). 21 | 22 | If the server you are cloning your repository from is anything other than GitHub.com, there might be something wrong with the SSL certificate. You could allow Git to accept a self-signed certificate with `git config --global http.verify false` 23 | 24 | - **No** - It's possible that you've previously configured a proxy to bypass a firewall. You can unset such a proxy with the command `git config --global --unset http.proxy`. You may need to use `--system` instead of `--global`. 25 | 26 | - **I don't know** - Ask your employer or network administrator if you're behind a firewall. 27 | -------------------------------------------------------------------------------- /docs/app_evangelize.md: -------------------------------------------------------------------------------- 1 | ## Adopting the dream 2 | 3 | As an ambassador, initiating actionable changes within the organization is your main priority. You'll need to evangelize Git's version control benefits and GitHub's collaboration and platform features within the organization. Knowing how and where to spread your Git and GitHub knowledge is one thing, but knowing how to tackle issues, deal with reluctant mindsets, or providing clear expectations is a situation you need to be ready for. Take some time to think about and answer the following questions in the next section. 4 | 5 | ### Discussion activity: Understand your role as an Ambassador 6 | 7 | #### Be a Git and GitHub evangelist 8 | 9 | - What does it mean to evangelize Git and GitHub? 10 | - What are some specific ways you can do this? 11 | - What can you do if they use a different tool that can be accomplished with Git or GitHub? 12 | - What challenges do you foresee being a Git and GitHub evangelist? 13 | 14 | **Need some extra help with the above questions? See below for some extra content:** 15 | 16 | > Promoting Git and GitHub internally doesn't necessarily mean going from cubicle to cubicle spreading the good news, but proactively identifying teams within the organization that would benefit from using the GitHub platform to improve their development processes. Identifying how a team is currently working enables you to identify why tools or integrations are needed for the team to be successful on GitHub. If they currently use Jira for their project management tooling, ensuring that they are aware of the Jira and GitHub integration is vital for helping connect the development process dots. If they are using off-the-shelf or homegrown CI solutions, determining how they can connect with GitHub will also help teams transition from their current development platform to GitHub. 17 | 18 | #### Initiate actionable changes within the organization 19 | 20 | - What are your first steps to initiating actionable change? 21 | - How can you do this by taking a proactive approach? 22 | - What challenges do you foresee? 23 | 24 | **Need some extra help with the above questions? See below for some extra content:** 25 | 26 | 27 | > Being able to identify where changes need to be made is the first step to making changes within the organization. While solving current problems within an organization is important, it's also important to think how you can reduce friction and issues in the future. 28 | 29 | > Moving teams within the organization to GitHub promotes a larger pool of potential reviewers or developers through a process known as Innersource. As more and more developers move from their siloed development process to a more open and transparent development method on GitHub, they can request reviews from teams outside their own to help reduce development time and increase the frequency of ships. 30 | 31 | 32 | #### Have a clear understanding of the organization's expectations of you as the ambassador? 33 | 34 | - How can you measure expectations? 35 | - What issues do you foresee if you don't meet their expectations? 36 | - What can be done to have clear expectations from both sides throughout the process? 37 | 38 | **Need some extra help with the above questions? See below for some extra content:** 39 | 40 | > As a GitHub ambassador, individuals within the organization will have the expectation that you will be able to provide succinct solutions to any problems or roadblocks they encounter as they prepare to move or once they have moved to GitHub. It's extremely important to know what expectations each organization has of you as well as your expectations from them. Make this a priority throughout the process. Having clear milestones or checkpoints is a great way to gauge process for you and the organization. 41 | 42 | #### Overcome reluctant mindsets within the organization? 43 | 44 | - How can you help overcome reluctant mindsets withing the organization? 45 | - How can you prevent these mindsets from preventing progress? 46 | - What can you do to help individuals with reactive mindsets to be proactive? 47 | 48 | **Need some extra help with the above questions? See below for some extra content:** 49 | 50 | > Let's face it, we've all been there. Changing a process can be difficult. As an ambassador, changing the mindset of, "It isn't broke, why fix it" can be one of your hardest discussions. It's important to start from what has worked with their process and then see where you can add what is missing instead of starting over completely; although sometimes that may be what is needed. You'll often find out that reluctant mindsets are based on previous issues they faced when a process was changed. Understanding the question behind the question is important with helping these individuals see the same vision you have for their organization. 51 | -------------------------------------------------------------------------------- /docs/app_facilitating_workflow.md: -------------------------------------------------------------------------------- 1 | ## Facilitating workflow conversations 2 | 3 | As a GitHub ambassador within your organization, helping people realize how to utilize GitHub as a platform and effectively collaborate is vital. The following activity focuses on creating a markdown-driven slide deck that can be shared with members of the organization to get a glimpse into how awesome life on GitHub can be. 4 | 5 | When thinking about what content to include in the deck, think back on what drew you to GitHub. Was it the integration of Issue and Pull Requests that makes it easier to get things done? Or was it how easy integrations make including CI or CD in your workflow? 6 | 7 | Regardless of why you ❤️ GitHub, include it in your deck and share it with other people in the organization to help them get excited about moving from their current solution to GitHub. 8 | 9 | ### Activity: Create a conversation starter 10 | 11 | 1. Fork this repository: 12 | 1. Edit the markdown lines of the `index.html` file with the content you'd like to be in your GitHub Pages powered slide deck 13 | 1. Enable GitHub Pages 14 | -------------------------------------------------------------------------------- /docs/app_facilitation_tips.md: -------------------------------------------------------------------------------- 1 | ## Facilitation tips 2 | 3 | ### Time management 4 | 5 | During class, you'll want to let folks take breaks (the attention span only last so long). Use your first break as a *test* to see how the class will respond to future breaks. For example, give them a 10-minute break, while putting a timer on the board. Pro-tip: use [Google](https://www.google.com/search?q=10+minute+timer). Based on how quick people come back from this first break, use that information in future breaks. If they come back early, keep giving a 10-minute break. If they come back late, make the next one 5 minutes. 6 | 7 | Additionally, to help manage your time, make sure to stay on topic. Tangents are ok once in a while, but too much and not only are you starting to lose time, but it becomes distracting to your audience - they are now trying to learn about more than one topic at once. 8 | 9 | ### Addressing logistics 10 | 11 | In the beginning of class, let everyone know where the following exists: 12 | 13 | - Bathrooms 14 | - Food 15 | - Emergency exits/plans 16 | - Parking lot (described below) 17 | 18 | Just ask @hollenberry - he had a fire drill on the last day of one of his trainings! 19 | 20 | ### Keeping the audience on topic 21 | 22 | To help your audience remain on topic, set up a [parking lot](http://www.agile-ux.com/2010/12/16/parking-lot-a-good-facilitation-tool/) before class starts. This helps them to know when they bring something up that's off-topic (maybe for now), that: 23 | 24 | - You've heard them 25 | - It won't be forgotten about 26 | - It will be processed by the end of class 27 | 28 | As one of the last actions you do (for a multi-day class do this daily), "process" the parking lot. Go through with the class and read through to do a check with them if this still needs to be addressed, if it was addressed, and if it still needs to be, how you will get it addressed (either on the spot or follow up). Pro-tip: doing this daily will encourage people to utilize it more because they see it's not just there to gather dust. Also, some crowds will need some help in utilizing this. Sometimes you need to add stick notes for them initially. As class goes on you can start guiding them to make a sticky and put it up there (which helps keep your flow going). 29 | 30 | ### Keeping the audience engaged 31 | 32 | At various times across any course, no matter the topic or audience, you're going to have signs of distraction. Participants might be checking their phone more, having the typical deer in headlights look, etc. There are various things you can do to attempt to get them back on track with you: 33 | 34 | - Move around the room - physically move more while you're talking 35 | - Ask more questions - Ask people what they might expect to see after you run *this* command 36 | - Switch talkers - instead of you talking, ask some off-topic question to a particular person and get them talking 37 | - Switch modes - have them break into pairs or trios and do a short exercise or discuss a particular topic and come back to the rest of the group with a summary in 5 minutes 38 | - Off topic deliberately - announce that your going to go off-topic and explore something that's not typically covered for a moment 39 | -------------------------------------------------------------------------------- /docs/app_fork_workflow.md: -------------------------------------------------------------------------------- 1 | ## Fork and Pull Workflow 2 | 3 | Let's distinguish between a few vocabulary words in Git and discuss a common workflow that involves forking. 4 | 5 | As in the picture below, all of our work generally starts from one parent repository. We call this the **parent** repository, but we can sometimes call it different things depending on _how_ we work with it. 6 | 7 | For example, when we **clone** a repository by creating a local copy on our machine, we refer to that original remote repository as **origin**. 8 | 9 | When we create branches, we can create them on our local **clone** _and_ on the remote **origin**. 10 | 11 | ![Clone vs Branch vs Fork](./img/clone-branch-fork.png) 12 | 13 | Things start to get tricky when we start talking about forking. A **fork** is a remote copy of a repository with a different owner. When you have a new remote **fork**, you would refer to the parent remote as **upstream**. 14 | 15 | ![Fork Workflow](./img/origin-upstream.png) 16 | 17 | If you cloned the fork, you would refer to your own fork as **origin**, and the parent as **upstream**. 18 | 19 | ![Fork Workflow](./img/fork-from.png) 20 | 21 | When you want to return work back to the **origin** or **upstream** repositories, you would push back to **origin**, then open a pull request between the remote forks. 22 | 23 | ![Fork Workflow](./img/fork-to.png) 24 | -------------------------------------------------------------------------------- /docs/app_git_branch_in_terminal.md: -------------------------------------------------------------------------------- 1 | ## Add the Git branch to your terminal prompt 2 | 3 | To show your active Git branch in your terminal prompt, you will need to do the following: 4 | 5 | - If you are on a **Mac**, you can add the code shown below to your `.bash_profile` file. 6 | - If you are on **Linux**, you will add the code shown below to your `.bashrc` file. 7 | - If you are on **Windows**, you probably aren't reading this because Windows provides this behavior by default. 8 | 9 | ### The script 10 | 11 | ```shell 12 | parse_git_branch() { 13 | git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/' 14 | } 15 | export PS1="\w\[\033[36m\]\$(parse_git_branch) \[\033[00m\] > " 16 | ``` 17 | 18 | Or, another option: 19 | 20 | ```shell 21 | function parse_git_branch () { 22 | git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/' 23 | } 24 | 25 | RED="\[\033[0;31m\]" 26 | YELLOW="\[\033[0;33m\]" 27 | GREEN="\[\033[0;32m\]" 28 | NO_COLOR="\[\033[0m\]" 29 | 30 | PS1="$GREEN\u@\h$NO_COLOR:\w$YELLOW\$(parse_git_branch)$NO_COLOR\$ " 31 | ``` 32 | -------------------------------------------------------------------------------- /docs/app_how_to_generate_locally.md: -------------------------------------------------------------------------------- 1 | ## How to generate Jekyll sites locally 2 | 3 | ### Before you begin 4 | 5 | The repositories we use in class are deployed using GitHub Pages, so you don't _need_ to do any local serving. But, if you'd like to see what your changes look like locally before they actually are pushed to the default branch, you can. 6 | 7 | The process may vary in difficulty based on your operating system, and we've found it's a smoother experience in macOS. We're working to improve these instructions for all platforms, so please let us know if you have any recommendations. 8 | 9 | This script uses Ruby. If you don't already have Ruby installed locally, you should follow the [detailed instructions on ruby-lang.org](https://www.ruby-lang.org/en/documentation/installation/). In short: 10 | 11 | - On Windows, you can do so from select version `2.3.3`, ensure you select to "Add Ruby executables to your PATH" during setup, and restart your machine. 12 | - If you need to install Ruby on a Mac, install [Homebrew](https://brew.sh) and then run `brew install ruby`. 13 | 14 | ### Generating locally 15 | 16 | 1. Using a Bash-like terminal, `cd` to the class repository locally. 17 | 1. Check that Ruby is installed. 18 | - On your command line, run `ruby -v` and `gem -v` 19 | - If you see a version `2.3.x` for Ruby, you're 👍. If not, refer to directions above. ☝️ 20 | 1. If there is a `Gemfile.lock` file, delete it. 21 | 1. Install bundler: `gem install bundler`. 22 | 1. Type `script/setup` to install all the proper gems. 23 | 1. Then, type `script/server`. 24 | 1. If all goes well, your terminal will tell you where to access your site in your browser. 🎉 25 | -------------------------------------------------------------------------------- /docs/app_supporting_learning_lab.md: -------------------------------------------------------------------------------- 1 | ## Supporting Learning Lab 2 | 3 | We recommend [Learning Lab](https://lab.github.com/) as a hands-on activity in many settings. It's self-paced, and highly involved, which means that users can get to work in a way that will work for them. 4 | 5 | ### Tips for success 6 | 7 | Facilitating [Learning Lab](https://lab.github.com/) in groups is a slightly different experience than trying it alone. 8 | 9 | #### Equipment 10 | 11 | Things can get very boring, very quickly if everyone will be expected to follow along on their own computer, but someone forgot theirs. Make sure it's clear to everyone participating that they should bring a computer to the event. 12 | 13 | Even if everyone has their computer, a shortage of Wi-Fi or power outlets can be a real downer. If it's a short event, the outlets might not be necessary, but it's always best to plan to have plenty of network connection and power connection. 14 | 15 | #### Visibility 16 | 17 | Introduce participants to Learning Lab by showing it on the screen, and making sure the URL is clearly visible 18 | 19 | #### Environment 20 | 21 | Since everyone will be working on their own, it's usually best if it's a quieter space with plenty of room for everyone to work on their computers. Some situations that _aren't_ ideal might consist of: 22 | 23 | - Too much noise or foot traffic through a common area 24 | - No tables or desks, so people are working with a computer on their legs 25 | - Lunch or cafeteria area where there are food and drinks around computers 26 | 27 | #### Helpers 28 | 29 | Plan to have several "mentors" or "helpers" walking around the room during the hands on time. Frequently, people have questions or are stuck, but don't want to call attention to themselves. Having a helper quietly walking by and asking them how they're doing gives them a low-pressure opportunity to ask for the help they need. 30 | 31 | Anyone helping should be introduced to the group, and differentiated, so others feel comfortable talking with them. At GitHub Workshop events, we typically have all "mentors" wear a GitHub sticker on their name tag. 32 | 33 | ### FAQ 34 | 35 | These are some questions you might expect to get, and how we recommend answering them. 36 | 37 | #### Do I need to have a GitHub account? 38 | 39 | Yes, a GitHub account is necessary to use Learning Lab. 40 | 41 | #### Should I install on all repositories, or just one? 42 | 43 | If you choose to install Learning Lab on all of your repositories, Learning Lab will never gain information from repositories other than the ones you're using in the course. This scope of permission is the fastest way to get started, but if you'd rather install on only one repository, that's fine too. _You need at least one repository to use GitHub Learning Lab._ 44 | 45 | #### Which course should I try? 46 | 47 | We recommend starting with "Introduction to GitHub", and moving on from there. 48 | 49 | #### Can I keep working on this later? 50 | 51 | Yes. If you choose to pause your work or if you'd like to work on another course later, Learning Lab will save your progress. Log in from your GitHub account, and you'll be able to pick up where you left off. 52 | 53 | #### Something's wrong, and I can't fix it 54 | 55 | Hopefully, as the ambassador, you'll be able to figure out what's going on. However, if you have found a bug or the program isn't working as expected, always feel free to do one of the following: 56 | 57 | - Contact us in our shared Slack channel 58 | - Start a thread in the [Community Forum](https://github.community/t5/GitHub-Learning-Lab/bd-p/learn) 59 | 60 | ### Trying it out 61 | 62 | Let's try out [Learning Lab](https://lab.github.com/) now. While you're going through the courses, keep in mind what you might feel if you were doing this in a large group. 63 | -------------------------------------------------------------------------------- /docs/app_teachback_repo_prep.md: -------------------------------------------------------------------------------- 1 | ## Preparing repositories for teach-backs 2 | 3 | ### Project 1: Caption This 4 | 5 | To practice teaching the first activities, please use the same repository you used in class. You will not need to alter this repository in any way to go through the activities. 6 | 7 | ### Project 2: Merge Conflicts 8 | 9 | To prepare your local repository to be ready for teaching, use the following commands. 10 | 11 | ```sh 12 | git switch main 13 | git reset --hard 1095c8c 14 | git push --force 15 | git checkout cb8731a 16 | git switch -c manual2 17 | git push -u origin manual2 18 | (open pull request) 19 | git checkout 6b50ac7 20 | git switch -c css-changes2 21 | git push -u origin css-changes2 22 | (open pull request) 23 | git checkout 945ca60 24 | git switch -c readme-update2 25 | git push -u origin readme-update2 26 | (open pull request) 27 | ``` 28 | 29 | ### Project 3: GitHub Games 30 | 31 | - Edit the repository description to `https://githubtraining.github.io/github-games/` 32 | - In your own copy of GitHub Games: 33 | 34 | ```sh 35 | git switch main 36 | git reset --hard 73c762c 37 | git push --force 38 | ``` 39 | 40 | ### Project 4: Working locally 41 | 42 | Create a new repository for these activities. 43 | -------------------------------------------------------------------------------- /docs/app_teaching_script.md: -------------------------------------------------------------------------------- 1 | ## GitHub training scripts 2 | 3 | We use [scripts](https://github.com/githubtraining/training-manual/tree/main/script) to set up repositories with these class activities. They're located in the same repository as this [training manual](https://github.com/githubtraining/training-manual), inside `/script`. 4 | 5 | ### Prerequisites 6 | 7 | - Note that these scripts are meant to interact with an organization on GitHub.com 8 | - If you're using GitHub Enterprise Server, and access to GitHub.com is limited within your organization, import the following repos and all their branches to your GitHub organization (you'll need access to GitHub.com to perform this one-time operation): 9 | - [caption-this](https://github.com/githubtraining/caption-this) 10 | - [conflict-practice](https://github.com/githubtraining/conflict-practice) 11 | - [github-games](https://github.com/githubtraining/github-games) 12 | 13 | ### Clone the repository 14 | 15 | - Clone the [training manual](https://github.com/githubtraining/training-manual) repo to your local machine 16 | 17 | ### Documentation 18 | 19 | - Follow the directions for setup and use located in the `/script` [`README.md`](https://github.com/githubtraining/training-manual/tree/main/script#readme) file 20 | -------------------------------------------------------------------------------- /docs/app_vi_basics.md: -------------------------------------------------------------------------------- 1 | ## Vi Basics 2 | 3 | Here are some vi basics in case you get stuck or if you'd like to learn how to use the default editor for Git. 4 | 5 | ### Command mode 6 | 7 | Typing `:` will get you into command mode which will allow you to type editor commands. The most common one you'll need is `:wq` which will let you save and exit. `:q!` will let you exit without saving your changes. 8 | 9 | > Memory tip: w = write and q = quit 10 | 11 | ### Editing a file 12 | 13 | You'll need to get into edit mode to edit a file. There are a few common ways to do this. You just need to type the letter (or combo) that represents how you're trying to edit the file. To get out of edit mode once you're done, hit the escape key. 14 | 15 | * i A lowercase `i` will start edit mode where the cursor is located. 16 | * shift + i An uppercase `i` will start edit mode at the beginning of the line where the cursor is located. 17 | * shift + a An uppercase `a` will start edit mode at the end of the line where the cursor is located. 18 | * r A lowercase `r` will let you replace a single letter, but it won't put you into edit mode. 19 | * s A lowercase `s` will let you replace a single letter, and it will also put you into edit mode, so you can continue editing. 20 | * x A lowercase `x` will let you delete a single character, but it won't put you into edit mode. 21 | * dd Typing two lowercase `d`'s in a row will delete the entire line where the cursor is located, but it won't put you into edit mode. 22 | 23 | > **Pro-tip:** If you'd like to get fancy, you can type a number before many of the commands. For example, typing 3x will delete three characters. 24 | -------------------------------------------------------------------------------- /docs/book.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/book.pdf -------------------------------------------------------------------------------- /docs/cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/cover.jpg -------------------------------------------------------------------------------- /docs/cover.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/cover.png -------------------------------------------------------------------------------- /docs/img/actions-components.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/actions-components.png -------------------------------------------------------------------------------- /docs/img/actions-run.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/actions-run.png -------------------------------------------------------------------------------- /docs/img/actions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/actions.png -------------------------------------------------------------------------------- /docs/img/cd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/cd.png -------------------------------------------------------------------------------- /docs/img/ci.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/ci.png -------------------------------------------------------------------------------- /docs/img/clone-branch-fork.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/clone-branch-fork.png -------------------------------------------------------------------------------- /docs/img/clone-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/clone-diagram.png -------------------------------------------------------------------------------- /docs/img/collaboration-features.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/collaboration-features.png -------------------------------------------------------------------------------- /docs/img/commit-and-tree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/commit-and-tree.png -------------------------------------------------------------------------------- /docs/img/commit-parent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/commit-parent.png -------------------------------------------------------------------------------- /docs/img/config-levels.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/config-levels.png -------------------------------------------------------------------------------- /docs/img/cover.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/cover.png -------------------------------------------------------------------------------- /docs/img/diff-options.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/diff-options.png -------------------------------------------------------------------------------- /docs/img/fork-from.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/fork-from.png -------------------------------------------------------------------------------- /docs/img/fork-to.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/fork-to.png -------------------------------------------------------------------------------- /docs/img/git-bisect.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/git-bisect.png -------------------------------------------------------------------------------- /docs/img/git-rebase.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/git-rebase.png -------------------------------------------------------------------------------- /docs/img/github-ecosystem.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/github-ecosystem.png -------------------------------------------------------------------------------- /docs/img/github-icon.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/github-icon.jpg -------------------------------------------------------------------------------- /docs/img/github-workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/github-workflow.png -------------------------------------------------------------------------------- /docs/img/gitignore-create-repo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/gitignore-create-repo.png -------------------------------------------------------------------------------- /docs/img/merging-prs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/merging-prs.png -------------------------------------------------------------------------------- /docs/img/name-field.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/name-field.png -------------------------------------------------------------------------------- /docs/img/origin-upstream.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/origin-upstream.png -------------------------------------------------------------------------------- /docs/img/push-pull.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/push-pull.png -------------------------------------------------------------------------------- /docs/img/python-gitignore.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/python-gitignore.png -------------------------------------------------------------------------------- /docs/img/release-actions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/release-actions.png -------------------------------------------------------------------------------- /docs/img/repository-intro.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/repository-intro.png -------------------------------------------------------------------------------- /docs/img/reset-modes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/reset-modes.png -------------------------------------------------------------------------------- /docs/img/reset-visual.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/reset-visual.png -------------------------------------------------------------------------------- /docs/img/staging.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/staging.png -------------------------------------------------------------------------------- /docs/img/two-stage-commit-a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/two-stage-commit-a.png -------------------------------------------------------------------------------- /docs/img/two-stage-commit-b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/two-stage-commit-b.png -------------------------------------------------------------------------------- /docs/img/two-stage-commit-c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/two-stage-commit-c.png -------------------------------------------------------------------------------- /docs/img/two-stage-commit-d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/two-stage-commit-d.png -------------------------------------------------------------------------------- /docs/img/userbar-account-settings.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/userbar-account-settings.png -------------------------------------------------------------------------------- /docs/img/yaml.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/img/yaml.png -------------------------------------------------------------------------------- /docs/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | GitHub Training Manual 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | -------------------------------------------------------------------------------- /docs/ja/01_getting_ready_for_class.md: -------------------------------------------------------------------------------- 1 | ## クラスの受講準備 2 | 3 | 授業開始を待っている間、数分間で、ローカルの作業環境を設定してください。 4 | 5 | 6 | 7 | ### ステップ1：GitHub.comアカウントの作成 8 | 9 | このクラスでは、GitHub.comのパブリックアカウントを使用します。 それには、いくつかの理由があります。 10 | 11 | - 実際のコードを含むリポジトリで、「練習」して欲しくはないため 12 | - コードなどの修正方法を教えるために、そのいくつかを変更するため （ついては、上記の箇条書きを参照してください） 13 | 14 | お持ちでない場合は、次のステップで無料アカウントを作成できます。 15 | 16 | 1. GitHub.comにアクセスし、「Sign up」をクリックします。 17 | 2. 無料のアカウントを選択します。 18 | 3. 指定したメールアドレスに、確認メールが届きます。 19 | 4. リンクをクリックして、認証手続きを完了します。 20 | 21 | もし、すでにアカウントをお持ちの場合は、組織のネットワーク内からgithub.comに接続できるかご確認ください。 22 | 23 | GitHubは、主要なブラウザの現在のバージョンで動作するようデザインされています。[サポートされているブラウザ](https://docs.github.com/github/getting-started-with-github/supported-browsers)については、こちらをご参照ください。 24 | 25 | ### ステップ2：Gitのインストール 26 | 27 | Gitは、オープンソースのバージョン管理アプリケーションです。 このクラスの受講にあたり、Gitをインストールする必要があります。 28 | 29 | すでにGitをインストールしているかもしれませんね。確認してみましょう！ Macを使用している場合はターミナル、Windowsマシンの場合はPowerShellを開き、次のように入力します。 30 | 31 | ```sh 32 | git version 33 | ``` 34 | 35 | 次のように表示されます。 36 | 37 | ```shell-session 38 | $ git version 39 | git version 2.33.1 40 | ``` 41 | 42 | 一般的には、Git の [最新バージョン](https://git-scm.com/downloads) から2つのマイナーバージョンの範囲を利用することを推奨します。このマイナーバージョンは、 `x.x.x` の並びのうちの2番目の数字です。 43 | 44 | Git for Windows または Git Bash を利用している場合、[2.29.2](https://github.com/git-for-windows/git/releases/tag/v2.29.2.windows.2)以上のバージョンをお勧めします。 45 | 46 | #### Gitのダウンロードとインストール 47 | 48 | Gitをまだインストールしていない場合は、 www.git-scm.com からGitをダウンロードできます。 49 | 50 | Gitのインストールについてさらに資料が必要な場合は、ProGitの章にあるGitのインストールに関する追加情報を参照してください。`http://git-scm.com/book/en/v2/Getting-Started-Installing-Git` 51 | 52 | #### シェルはどこにあるのか 53 | 54 | Gitで使いたいコマンドラインアプリケーションへのショートカットを作成してみましょう。 55 | 56 | - Windowsで作業している場合は、Gitパッケージでインストールされた` Git Bash ` 、または、[Posh-git](http://dahlbyk.github.io/posh-git/)でPowershellを使用します。 57 | - Macやその他のUnixベースのシステムで作業している場合は、ターミナルアプリケーションを使用します。 58 | 59 | ### Step 3: HTTPS でクローンしてみる 60 | 61 | 選択したシェルを開き、下記を入力します。 62 | 63 | ```sh 64 | git clone https://github.com/githubschool/scratch.git 65 | ``` 66 | 67 | クローンが成功する場合は、下記のように表示されます。 68 | 69 | ```shell-session 70 | $ git clone https://github.com/githubschool/scratch 71 | Cloning into 'scratch'... 72 | remote: Counting objects: 6, done. 73 | remote: Compressing objects: 100% (2/2), done. 74 | remote: Total 6 (delta 0), reused 0 (delta 0), pack-reused 0 75 | Unpacking objects: 100% (6/6), done. 76 | ``` 77 | 78 | もしクローンが失敗する場合、[authenticating with GitHub from Git](https://docs.github.com/github/getting-started-with-github/set-up-git#next-steps-authenticating-with-github-from-git) をご参照ください。留意点: 企業のネットワークでは SSH のトラフィックを遮断している場合もあるので、HTTPS での利用を推奨しています。クラスの受講前にクローンが可能かどうかご確認ください。また、2段階認証を有効にしていて HTTPS を利用する場合は、[パーソナルアクセストークンのセットアップ](https://docs.github.com/github/authenticating-to-github/accessing-github-using-two-factor-authentication#using-two-factor-authentication-with-the-command-line)が必要になります。 79 | 80 | #### プロキシの設定 81 | 82 | もし、所属する組織でプロキシを利用している場合は、Git でプロキシの設定を行う必要があります。 Git Bash (Windowsの場合) またはターミナル (Mac または \*nux の場合) を開き、下記の手順を実行してください。 83 | 84 | **プロキシが認証不要の場合:** 85 | 86 | ```sh 87 | git config --global http.proxy https://YOUR.PROXY.SERVER:8080 88 | ``` 89 | 90 | `YOUR.PROXY.SERVER` はご利用のプロキシのURLに置き換えてください。 91 | 92 | **プロキシが認証を要求する場合:** 93 | 94 | ```sh 95 | git config --global http.proxy https://YOUR_PROXY_USERNAME:YOUR_PROXY_PASSWORD@YOUR.PROXY.SERVER:8080 96 | ``` 97 | 98 | `YOUR_PROXY_USERNAME` および `YOUR_PROXY_PASSWORD` を、それぞれプロキシの認証で利用するユーザー名とパスワードに置き換え、`YOUR.PROXY.SERVER` をご利用のプロキシのURLに置き換えてください。 99 | 100 | ### ステップ4：テキストエディタの設定 101 | 102 | このクラスでは、コードの取り扱いにおいて、ベーシックなテキストエディタを使用します。 何らかのテキストエディタをインストール済で、コマンドラインから作業できる状態になっていることを確認しましょう。 103 | 104 | #### エディタの選択 105 | 106 | ほぼすべてのテキストエディタを使用できますが、最適なエディタは次のとおりです。 107 | 108 | - [Visual Studio Code](https://code.visualstudio.com) 109 | - Notepad 110 | - Vi or Vim 111 | - Sublime 112 | - Notepad++ 113 | - GitPad 114 | 115 | まだテキストエディタをインストールしていない場合は、上記のエディタを１つダウンロードしてインストールしてください。また、Visual Studio Code を Git コマンドで利用するデフォルトのテキストエディタとして設定するには、[docs.github.com のこちらの手順](https://docs.github.com/github/using-git/associating-text-editors-with-git)をご参考ください。 116 | 117 | #### コマンドラインでのエディタ 118 | 119 | エディタをインストールしたら、コマンドラインから開けるかどうかを確認します。 120 | 121 | 適切にインストールされている場合、次のコマンドでカレントディレクトリを Visual Studio Code で開くことができます。 122 | 123 | ```sh 124 | code . 125 | ``` 126 | 127 | --- 128 | 129 | ### リサーチ 130 | 131 | おめでとうございます。 これで、あなたのシステムに、作業できるバージョンのGitとテキストエディタがあるはずです。 クラス開始前にまだ時間がある場合は、以下の興味深い資料をご覧ください。 132 | 133 | - **[github.com/explore](https://www.github.com/explore)** - Exploreでは、GitHub Universeにおける興味深いプロジェクトを展示しています。 後で再度見てみたいプロジェクトはありましたか？ 後で見つけやすくするために、リポジトリにStarを付けましょう。 134 | - **[lab.github.com](https://lab.github.com)** - GitHub Learning Lab では、ボットがプロジェクトを案内してくれ、各手順を実践できるように、即座に GitHub リポジトリからのフィードバックを与えてくれます。 135 | -------------------------------------------------------------------------------- /docs/ja/01f_facilitator_note.md: -------------------------------------------------------------------------------- 1 | > 参加者が到着したら、クラスの準備作業として、このセクションを完了するように指示してください。 クラスを開始する前に、参加者全員がこのステップを完了したことを確認してください。 {: .facilitator_note} -------------------------------------------------------------------------------- /docs/ja/02a_activity_create_github_issue.md: -------------------------------------------------------------------------------- 1 | ### 実習：GitHubのIssueを作成する 2 | 3 | 次の手順に従って、クラスのリポジトリでIssueを作成します。 4 | 5 | 1. *Issues*タブをクリック 6 | 1. *New Issue*をクリック 7 | 1. タイトルに次のとおりに入力　`YOUR-USERNAME Workflow` 8 | 1. Issueの本文に、次のテキストを含める 9 | 10 | ```md 11 | YOUR-USERNAME はキャプションを変更し、ファイルを更新します。 12 | 13 | - [ ] ブランチの作成 14 | - [ ] ファイルの変更 15 | - [ ] 変更のコミット 16 | - [ ] Pull Requestの作成 17 | - [ ] レビューのリクエスト 18 | - [ ] 変更を追加 19 | - [ ] 承認を受ける 20 | - [ ] Pull Requestをマージ 21 | ``` 22 | 23 | 1. *Submit new issue* ボタンをクリックし、issueを開きます。 24 | -------------------------------------------------------------------------------- /docs/ja/03_github_flow.md: -------------------------------------------------------------------------------- 1 | ## GitHubのフローを理解する 2 | 3 | このセクションでは、GitHubによって可能となったコラボレーションフローについて説明します。 4 | 5 | ### 重要なGitHubの作業フロー 6 | 7 | ![GitHubの作業フロー](../img/github-workflow.png) 8 | 9 | GitHubのフローは、負荷の少ない作業フローのため、新しいアイデアを安全に試すことができ、プロジェクトの妨げとなる心配はありません。 10 | 11 | ブランチは、理解する必要のある重要な概念です。 GitHubの全ての要素は、ブランチに含まれています。 デフォルトでは、プロジェクトの 「正規」バージョンは、`main`と呼ばれるブランチに含まれています。 このブランチは、実際は、どのような名前でも付けることができます。これから、少しの間、見ていきましょう。 12 | 13 | 新機能を試したり、問題を修正する準備ができたら、プロジェクトの新規ブランチを作成します。 その新規ブランチは、最初は`main`と全く同じように見えますが、変更はユーザのブランチだけに反映されます。 このような新規ブランチは、多くの場合「フィーチャ」ブランチと呼ばれています。 14 | 15 | ユーザがプロジェクト内のファイルを変更すると、そのユーザの変更をフィーチャブランチにコミットすることになります。 16 | 17 | ユーザによる変更点について話し合う準備ができたら、Pull Requestを開きます。 Pull Requestは、完璧な内容である必要はありません。あくまで出発点であり、プロジェクトチームの努力によって、改善され、洗練されていくのです。 18 | 19 | Pull Requestに含まれる変更が承認されると、フィーチャブランチは、mainブランチにマージされます。 次のセクションでは、このGitHubの作業フローの実践方法を学習します。 20 | 21 | ### リサーチ 22 | 23 | 後で参照できる興味深い資料です。 24 | 25 | - *[guides.github.com/introduction/flow/](https://guides.github.com/introduction/flow/)* GitHubの作業フローのインタラクティブなレビュー 26 | -------------------------------------------------------------------------------- /docs/ja/04_branching_with_git.md: -------------------------------------------------------------------------------- 1 | ## GitでBranching（ブランチ作成） 2 | 3 | GitHub作業フローの最初のステップは、ブランチの作成です。 ブランチを作成することで、テストされていない変更を誤って本番ブランチに取り込むことなく、新しい機能を試すことができます。 4 | 5 | ### Branching（ブランチ作成）の定義 6 | 7 | ![GitHub作業フロー](../img/github-workflow.png) 8 | 9 | ブランチを作成するとき、その時点のプロジェクトの実質的なコピーが作成されます。 これは、ディスク上に物理的なコピーを作成することと同じではありません。 バックグラウンドでは、ブランチは単なるポインタに過ぎません。 10 | 11 | 新しいブランチの作成方法を学習しましょう。 12 | 13 | [include](04a_activity_create_branch.md ':include') 14 | 15 | ### リサーチ 16 | 17 | 後で参照できる興味深い資料です。 18 | 19 | - [ブランチ作成についてのGitHubトレーニングビデオ](https://youtu.be/H5GJfcp3p4Q) 20 | -------------------------------------------------------------------------------- /docs/ja/04a_activity_create_branch.md: -------------------------------------------------------------------------------- 1 | ### 実習：GitHubでブランチを作成する 2 | 3 | これまでに、編集したいファイルのIssueを作成しました。 それでは、そのファイルを編集するために使用するブランチを作成しましょう。 4 | 5 | 次の手順に従って、クラスのリポジトリで新規ブランチを作成します。 6 | 7 | > GitHubでブランチを作成する前に、クラスのリポジトリに対するコラボレータとしてのアクセス権が必要になります。 8 | 9 | 1. クラスのリポジトリの*Code* タブに移動します。 10 | 2. *branch dropdown*をクリックします。 11 | 3. ブランチ名「github-username-caption」を入力します。 12 | 4. 入力したブランチ名をクリックしてブランチを作成します。 13 | 14 | GitHubで新しいブランチを作成すると、ユーザのブランチに自動的に切り替わります。 これで、リポジトリのファイルに対する変更が、この新しいブランチに適用されます。 15 | 16 | > 注： リポジトリに戻るか、最上位のリポジトリリンクをクリックするとき、GitHubは、ユーザがデフォルトブランチの項目を表示させたいものとみなすことに、注意してください。 フィーチャブランチで作業を続行したい場合、ブランチのドロップダウンから再選択する必要があります。 17 | -------------------------------------------------------------------------------- /docs/ja/05_local_git_configs.md: -------------------------------------------------------------------------------- 1 | ## ローカルのGitの設定 2 | 3 | このセクションでは、Gitで作業するためのローカル環境を設定します。 4 | 5 | ### Gitのバージョンをチェック 6 | 7 | まず、[Git Installation](https://git-scm.com/downloads)を確認しましょう。 8 | 9 | ```sh 10 | git version 11 | ``` 12 | 13 | Gitがインストールされている場合、`git version 2.33.1` とバージョンが返却されます。 14 | 15 | 掲載されているGitバージョンが表示されていない場合や、このコマンドでエラーが返された場合は、Gitをインストールする必要があるかもしれません。 16 | 17 | > Gitの最新版を入手するには、[www.git-scm.com](https://www.git-scm.com)にアクセスしてください。 18 | 19 | ### Gitの設定レベル 20 | 21 | ![Gitの設定レベル](../img/config-levels.png) 22 | 23 | Gitでは、3つの異なるレベルで設定オプションを設定できます。 24 | 25 | #### --system 26 | 27 | これは、システム全体の設定です。 このコンピュータ上のすべてのユーザに適用されます。 28 | 29 | #### --global 30 | 31 | これは、ユーザレベルの設定です。 該当ユーザのユーザアカウントにのみ適用されます。 32 | 33 | #### --local 34 | 35 | これは、リポジトリレベルの設定です。 設定されている特定のリポジトリにのみ適用されます。 36 | 37 | > git configのデフォルト値は、`--local`です。 38 | 39 | ### 設定の表示 40 | 41 | どの設定が自動的に追加されたのかを確認する場合、`git config --list`と入力します。 これにより、３つの設定ファイルそれぞれを自動的に読み込み、設定ファイルの設定をリスト表示します。 42 | 43 | ```sh 44 | git config --list 45 | ``` 46 | 47 | また、リストオプションの前に含めることで、リストを特定の設定レベルに絞り込むこともできます。 48 | 49 | ```sh 50 | git config --global --list 51 | ``` 52 | 53 | ### ユーザ名とメールの設定 54 | 55 | Gitは、ユーザ名とメールアドレスの設定を使用して、作成されるコミットのそれぞれに一意のフィンガープリント（識別情報）を生成します。 この設定なしでは、コミットを作成できません。 56 | 57 | ```sh 58 | git config --global user.name "First-name Surname" 59 | git config --global user.email "you@email.com" 60 | ``` 61 | 62 | **例:** 63 | 64 | ```sh 65 | git config --global user.name "Mona Octocat" 66 | git config --global user.email "mona@github.com" 67 | ``` 68 | 69 | > **Tip:** もし config プロパティの設定を間違えた場合も心配はいりません。ダブルクオートで囲んだ値で同じ `git config` コマンドを再実行することで、プロパティを新しい値で更新することができます。 もし、プロパティの名前を間違えた場合は、下記のコマンドでプロパティを削除することができます: 70 | > 71 | > ```sh 72 | > git config --global --unset 73 | > ``` 74 | 75 | #### Gitの設定とプライバシー 76 | 77 | この演習の手順では、あなたの` user.name `と` user.email `の設定を識別するとき、`--global`フラグを使用します。 現在、個人のアカウントを使用せずにコンピュータを使用している場合は、 `--global`を適用しないでください。 この方法によって、設定は、本クラスで割り当てたリポジトリにのみ保存されます。 同じコンピュータ上の別のリポジトリで作業する場合は、この設定オプションを再度設定する必要があります。 78 | 79 | > 例えば 80 | > 81 | > ```sh 82 | > git config user.email "you@email.com" 83 | > ``` 84 | 85 | ユーザの名前とメールアドレスは、Gitでユーザが作成したコミットに自動的に保存されます。 メールを非公開にしたい場合は、GitHubによって、そのユーザアカウント用の返信受付不可のメールアドレスを生成することができます。 [Settings > Emails セクション](https://github.com/settings/emails)の**Keep my email address private**をクリックしてください。 この機能を有効にしたら、自動的に生成された` ID +username@users.noreply.github.com `をメールを設定するときに入力するだけです。 86 | 87 | > 例えば 88 | > 89 | > ```sh 90 | > git config --global user.email 18249274+githubteacher@users.noreply.github.com 91 | > ``` 92 | 93 | ### Autocrlfの設定 94 | 95 | ```sh 96 | //for Windows users 97 | git config --global core.autocrlf true 98 | //for Mac or Linux users 99 | git config --global core.autocrlf input 100 | ``` 101 | 102 | 異なるシステムでは、行末と行区切りについて異なった扱いがされます。 他のシステムで作成されたファイルを開き、この一連の設定をしていない場合、Gitは、ファイルを開いたあなたが、その種類のファイルを扱うあなたのシステムの設定に基き、変更を加えたものとみなします。 103 | 104 | > ヒント：` autocrlf `は、auto carriage return line feed の略語です。 105 | -------------------------------------------------------------------------------- /docs/ja/06_working_locally.md: -------------------------------------------------------------------------------- 1 | ## ローカルでのGitの作業 2 | 3 | コマンドラインを使用して、Gitを現在の作業フローに簡単に統合できます。 4 | 5 | ### リポジトリのローカルコピーの作成 6 | 7 | ![リポジトリのクローン](../img/clone-diagram.png) 8 | 9 | ローカルで作業する前に、リポジトリのクローンを作成する必要があります。 10 | 11 | リポジトリをクローンするとき、そのリポジトリ内の履歴を含むすべてのコピーが作成されます。 これは、gitのような分散型バージョン管理システムのメリットの１つです。コミット履歴をレビューするために低速の集中型サーバにクエリする必要はなく、ローカルでクエリは高速に実行されます。 12 | 13 | クラスのリポジトリを、あなたのローカルのパソコンにクローンしましょう。 14 | 15 | 1. GitHubのクラスのリポジトリの**Code**タブに移動します。 16 | 2. 緑色の**Code**ボタンをクリックします。 17 | 3. あなたのクリップボードに、*clone URL*をコピーします。 18 | 4. コマンドラインのアプリケーションを開きます。 19 | 5. GitHubからリポジトリの完全なコピーを取得します。`git clone ` 20 | 6. クローンが完了したら、クローンにより作成された新しいディレクトリに移動します。`cd ` 21 | 22 | ### 私たちのお気に入りの Gitコマンド　`git status` 23 | 24 | ```shell-session 25 | git status 26 | On branch main 27 | Your branch is up-to-date with 'origin/main'. 28 | nothing to commit, working tree clean 29 | ``` 30 | 31 | `git status` は、リポジトリの現在の状態とそれに含まれるファイルを確認するためのコマンドです。 現在のところ、mainブランチにいることが表示されています。すべてがorigin/mainに合わせて最新版になり、ワーキングツリーはクリーンです。 32 | 33 | ### ローカルでのブランチの使用 34 | 35 | ```sh 36 | git branch 37 | ``` 38 | 39 | `git branch`と入力すると、ローカルのブランチの一覧が表示されます。 40 | 41 | ```sh 42 | git branch --all 43 | git branch -a 44 | ``` 45 | 46 | リモートブランチの読み取り専用のコピーを含むすべてのブランチを表示したい場合、`--all` のオプション、または、単に `-a` と追記します。 47 | 48 | > `--all` および `-a` は、ブランチコマンドの実質的な同義語です。 Gitは、しばしば、文字数の多いオプションと文字数の少ないオプションを提供します。 49 | 50 | ### ブランチの切り替え 51 | 52 | ```sh 53 | git switch 54 | ``` 55 | 56 | オンラインで作成したブランチをチェックアウトするには、git switchとブランチの名前を入力します。 Gitは、そのブランチが切り替わったことを伝えるメッセージを表示し、かつ、同じoriginからのリモートブランチを追跡するように設定されます。 57 | 58 | > ブランチ名の前に、`remotes/origin`を入力する必要はありません。ブランチ名のみで大丈夫です。 ブランチ名の前に`remotes/origin`を入力すると、分離されたHEAD状態になります。 後ほど詳しく学習しますが、今は、この状態が、あるべき状態ではないことを覚えておいてください。 59 | 60 | [include](06a_activity_create_file.md ':include') 61 | 62 | ### 2 段階コミット 63 | 64 | ファイルを作成した後、リポジトリの最初のスナップショットを作成します。 コマンドラインから作業する場合は、２段階コミットという概念に慣れておく必要があります。 65 | 66 | ![２段階コミット - パート１](../img/two-stage-commit-a.png) 67 | 68 | ローカルで作業する場合、ファイルは、４つの状態のいずれかになります。 その状態は、untracked（未追跡）、modified（変更された）、staged（ステージされた）またはcommitted（コミットされた）です。 69 | 70 | Untrackedファイルは、一度もコミットされていない新しいファイルです。 71 | 72 | Gitはこれらのファイルを追跡し、3つの作業ツリーで、そのファイルと変更を整理して履歴を追跡します。 その３つの作業ツリーは、Working、Staging （インデックスとも言う）、およびHistoryです。 ファイルに変更を加えている時、その変更は作業ツリーで発生しているのです。 73 | 74 | ![２段階コミット - パート２](../img/two-stage-commit-b.png) 75 | 76 | ファイルをバージョン管理に追加するには、個別の作業単位を表す一連のファイルを作成します。 この作業単位をステージングエリアに作成します。 77 | 78 | ![２段階コミット - パート３](../img/two-stage-commit-c.png) 79 | 80 | 組み立てた作業単位についてよければ、ステージングエリアのすべてのもののスナップショットを取得します。 このスナップショットを、コミットと呼びます。 81 | 82 | ![２段階コミット - パート４](../img/two-stage-commit-d.png) 83 | 84 | ファイルをバージョン管理されたディレクトリの一部にするためには、最初に `git add` を行い、次に `git commit` を行います。 今すぐ、やってみましょう。 85 | 86 | 1. まず、作業ツリーの状態を確認しましょう。`git status` 87 | 2. ファイルを作業ツリーからステージングエリアに移動します。`git add my-file.md` 88 | 3. 移動したかどうかステータスを確認します。`git status` 89 | 4. それでは、最初のスナップショットを取得します。`git commit` 90 | 5. Gitがデフォルトのテキストエディタを開き、コミットメッセージを要求します ファイルの先頭行にメッセージを入力してください。 ＃が付いていない行のすべてが、コミットメッセージに含まれます。 91 | 6. コミットメッセージを保存して閉じます。 92 | 7. リポジトリのステータスをもう一度確認します。`git status` 93 | 94 | > 優れたコミットメッセージは、 95 | > 96 | > - 短いこと。 50文字以下が理想的です。 97 | > - コミットによって行われる変更を記述すること。 98 | > - プロジェクトの進捗状況について記載すること。 99 | -------------------------------------------------------------------------------- /docs/ja/06a_activity_create_file.md: -------------------------------------------------------------------------------- 1 | ### 実習：ファイルの編集 2 | 3 | 今度は、画像とキャプションをファイルに入れてみましょう。 4 | 5 | 1. あなたのファイル `##-USERNAME.md` を見つけます。 6 | 1. お好みのテキストエディタで、ファイルを開きます。 7 | 1. ファイルの 6行目を、お好きな文字列（キャプション）に置き換えます。 8 | 1. ファイルを *Save*（保存）します。 9 | 10 | > ローカルでのファイルの取り扱い方法について、Gitは制限をしません。 お好みのIDEならびにテキストエディタで作業でき、または、コマンドラインでVIMを使用することができます。 11 | > 12 | > コマンドラインからファイルを開くために、多くのIDEやテキストエディタにショートカット機能があります。 例えば、 `code .`を使うと Visual Studio Codeでプロジェクトを開くことができます。 13 | -------------------------------------------------------------------------------- /docs/ja/07_collaborating_on_code.md: -------------------------------------------------------------------------------- 1 | ## コードについてのコラボレーション 2 | 3 | ローカルでプロジェクトにいくつか変更を加えたため、コラボレーションのためにその変更をクラスの共有リポジトリにプッシュし戻す方法を学習しましょう。 4 | 5 | ### 変更をGitHubにプッシュ 6 | 7 | ![GitHubにプッシュ](../img/push-pull.png) 8 | 9 | 今回このクラスでは、リモートはGitHub.comですが、あなたの勤務先のGitHub Enterpriseの内部インスタンスにすることもできます。 10 | 11 | 変更をGitHubにプッシュするには、次のコマンドを使います。 12 | 13 | ```sh 14 | git push 15 | ``` 16 | 17 | > プッシュすると、GitHubのユーザ名とパスワードを入力するよう求められます。 Gitにこのコンピュータの資格情報を記憶させたい場合は、次の方法で資格情報をキャッシュすることができます。 18 | 19 | - Windows: `git config --global credential.helper wincred` 20 | - Mac: `git config --global credential.helper osxkeychain` 21 | 22 | [include](07a_activity_create_pull_request.md ':include') 23 | 24 | ### Pull Requestについて知ろう 25 | 26 | Pull Requestを作成したので、コラボレーションの中心的な要素となっているPull Requestの機能を、いくつか学習しましょう。 27 | 28 | #### ![octicon-comment-discussion] Conversation タブ 29 | 30 | Issueのディスカッションスレッドと同様に、Pull Requestには、リポジトリに対する変更に関する議論が含まれています。 このディスカッションはCoversationタブにあり、ブランチに対するすべてのコミットやPull Requestに適用された割り当て、ラベル、およびレビューの履歴も含まれています。 31 | 32 | #### ![octicon-git-commit] Commits タブ 33 | 34 | Commits viewには、ファイルを変更したユーザに関する詳細情報が含まれています。 それぞれのコミットIDをクリックすることで、その特定のコミットに適用された変更が表示されます。 35 | 36 | #### ![octicon-diff] Files changed タブ 37 | 38 | Files changed viewでは、ブランチで行われたすべての変更の累積的な結果を確認することができます。 これを`diff`（差分）と呼びます 。 私たちのdiffはまだあまり目を引くものではありませんが、変更を重ねると、diffはとてもカラフルになります。 39 | 40 | ### Pull Requestのコードレビュー 41 | 42 | 提案された変更に対するフィードバックを伝えるために、GitHubは3つのレベルのコメントを用意しています。 43 | 44 | #### General Conversation 45 | 46 | *Conversation*タブ内では、Pull Requestに関する一般的なコメントを行うことができます。 47 | 48 | #### 行コメント 49 | 50 | Files changed viewでは、青色の ![`+`][octicon-diff-added] アイコンを表示させるために、行の上にマウスを合わせます。 このアイコンをクリックすると、特定の行にコメントを入力できます。 この行レベルのコメントは、提案された変更についての追加情報を伝えるのに最適な方法です。 Conversation viewにも表示されます。 51 | 52 | #### レビュー 53 | 54 | 行コメントを作成しているとき、 *Start a Review*を選択することもできます。 レビューを作成するときは、コメント、承認、または変更の要求など、一般的なメッセージとともに多くの行コメントをグループ化できます。 レビューは、保護されたブランチと組み合わせて使用すると、特別な力を発揮します。 55 | 56 | ### 実習：コードレビュー 57 | 58 | コードの品質を保証するための最適な方法の１つは、ピアレビューをPull Requestの一部にすることです。 それでは、パートナーのコードをレビューしてみましょう。 59 | 60 | 1. *Pull Request*タブをクリックする。 61 | 2. *Author*ドロップダウンを使用して、パートナーのPull Requestを見つける。 62 | 3. *Files Changed*タブをクリックする。 63 | 4. ファイル内のいずれかの1行にカーソルを合わせると、青色の+が表示される。 その + をクリックして、行コメントを追加する。 64 | 5. 行にコメントを付けて、*Start review*をクリックする。 65 | 6. これらの手順を繰り返して、ファイルにコメントを２つ、３つ追加する。 66 | 7. 右上隅にある*Review*をクリックする。 67 | 8. *Approve* または *Request changes*を選択する。 68 | 9. レビューの一般的なコメントを入力する。 69 | 10. *Submit review*をクリックする。 70 | 11. 完了したレビューを確認するために、*Conversation* viewをクリックする。 71 | 72 | [octicon-comment-discussion]:https://unpkg.com/octicons/build/svg/comment-discussion.svg 73 | 74 | [octicon-diff]:https://unpkg.com/octicons/build/svg/diff.svg 75 | 76 | [octicon-diff-added]: https://unpkg.com/octicons/build/svg/diff-added.svg 77 | 78 | [octicon-git-commit]:https://unpkg.com/octicons/build/svg/git-commit.svg 79 | -------------------------------------------------------------------------------- /docs/ja/07a_activity_create_pull_request.md: -------------------------------------------------------------------------------- 1 | ### 実習：Pull Requestの作成 2 | 3 | Pull Requestは、プロジェクトのファイルに対する変更を提案するために使用します。 Pull Requestは、Issueを解決するアクションを取り入れます。 Pull Requestは、プロジェクトにマージされるまで「作業中」とみなされます。 4 | 5 | これで、ファイルの変更を開始しました。チームメイトとファイルについて議論するために、Pull Requestを開きましょう。 次の手順に従って、クラスのリポジトリでPull Requestを作成します。 6 | 7 | 1. *Pull Request*タブをクリックする。 8 | 2. *New Pull Request*をクリックする。 9 | 3. *base*ドロップダウンで、`main`を選択する。 10 | 4. *compare*ドロップダウンで、あなたのブランチを選択する。 11 | 5. タイトルと説明を入力する。 12 | 6. Markdown記法を使用して、Pull Requestにヘッダとチェックリストを追加する。 13 | 7. `closes`、`fixes`、`resolves`のいずれかのキーワード１つを入力し、続いて、このPull RequestがどのIssueをクローズするものかを記載するために、以前作成したIssueの番号を記載する。 （例）`This resolves #3` 14 | 8. Pull Requestがどのように表示されるのかを確認するために、*Preview*をクリックする。 15 | 9. このPull Requestを自分に割り当てる。 16 | 10. *Create pull request*をクリックする。 17 | 18 | > クラスのリポジトリに移動すると、ページの上部に、ブランチを最近プッシュしたことを表すバナーと、 *Compare & pull request*のボタンが表示されているはずです。 このボタンによって、ユーザのブランチとリポジトリのデフォルトのブランチとの間で、Pull Requestの処理を自動的に開始します。 19 | -------------------------------------------------------------------------------- /docs/ja/08_edit_on_github.md: -------------------------------------------------------------------------------- 1 | ## GitHub上のファイルの編集 2 | 3 | Pull Requestを作成したことから、誰かがコメントやレビューを追加した際、その通知を受けることになります。 レビュアーから、作成したばかりのファイルの変更を要求されることもあります。 GitHubで、スムーズにファイル編集を行う方法を確認してみましょう。 4 | 5 | ### GitHubでのファイル編集 6 | 7 | Pull Requestのファイルを編集するには、*Files Changed* タブにアクセスする必要があります。 8 | 9 | 1. diff の右上にある ![octicon-kebab-horizontal] をクリックします。 10 | 1. **Edit file** をクリックし、GitHub ファイルエディタを使用してファイルを編集します。 11 | 1. レビュアーのコメントやあなた自身の考えに基づき、ファイルに変更を加えます。 12 | 13 | ### GitHubで変更をコミット 14 | 15 | ファイルに変更を加えたら、新しいコミットを作成する必要があります。 16 | 17 | 1. ページの一番下までスクロールして、 *Commit changes*を見つける。 18 | 2. *コミットメッセージ*を入力する。 19 | 3. *Commit directly to your branch*オプションを選択する。 20 | 4. *Commit changes*をクリックする。 21 | 22 | ### 実習：Pull Requestでファイルを編集する 23 | 24 | Pull Requestに戻って、コラボレータが要求した編集を行いましょう。 25 | 26 | [octicon-kebab-horizontal]: https://unpkg.com/octicons/build/svg/kebab-horizontal.svg 27 | -------------------------------------------------------------------------------- /docs/ja/09_merging_pull_requests.md: -------------------------------------------------------------------------------- 1 | ## Pull Requestのマージ 2 | 3 | 要求された変更を行ったので、あなたのPull Requestをマージする準備は完了しました。 4 | 5 | ### マージの説明 6 | 7 | ブランチをマージするとき、あなたのフィーチャブランチからコンテンツと履歴が取り出され、` main `のブランチのコンテンツと履歴に追加されます。 8 | 9 | ![Pull Requestのマージ](../img/merging-prs.png) 10 | 11 | 多くのプロジェクトチームでは、誰がPull Requestをマージするべきか、ルールを定めています。 12 | 13 | - マージの結果生じた問題を処理することになるため、Pull Requestの作成者が適任だと言う人もいます。 14 | - 一貫性を確保するためには、プロジェクトチーム内にいるただ一名であるべきとの意見もあります。 15 | - また、少なくとも１回のレビューが行われるよう、Pull Requestの作成者以外であるべきとの意見もあります。 16 | 17 | この点は、チームの他のメンバーと話し合うべきです。 18 | 19 | ### 自分のPull Requestのマージ 20 | 21 | Pull Requestをマージする方法を見てみましょう。 22 | 23 | 1. 自分のPull Requestに移動する。 24 | 25 | ?> **ヒント:** 自分のPull Requestをリクエストをすばやく見つけるには、AuthorまたはAssigneeのドロップダウンを使用します 26 | 27 | 2. *Conversation*をクリックする。 28 | 3. Pull Requestの一番下までスクロールし、*Merge pull request*をクリックする。 29 | 4. *Confirm merge*をクリックする。 30 | 5. *Delete branch*をクリックする。 31 | 6. *Issues*をクリックし、自分のIssueがクローズされたことを確認する。 32 | 33 | GitHubは、Pull Requestのマージする方法を３つ、用意しています。 34 | 35 | - **Create a merge commit:** 36 | 37 | 標準的な再帰的マージを実行する従来のオプションです。 ２つのブランチがマージされた時点を示す、新しいコミットが追加されます。 38 | 39 | - **Squash and merge:** 40 | 41 | このオプションは、ブランチ上のすべてのコミットを、１つのコミットに圧縮します。 コミットメッセージは、そのコミットの展開されたコミットメッセージに保存されますが、個々のコミットは失われます。 42 | 43 | - **Rebase and merge:** 44 | 45 | このオプションは、ちょうどコミットされたかのように、すべてのコミットを再生します。 これにより、GitHubは、fast forwardマージを実行できます。（そして、マージコミットの追加を避けることができます） 46 | 47 | ### ローカルリポジトリの更新 48 | 49 | 自分のPull Requestをマージしたとき、GitHub上のブランチを削除しましたが、リポジトリのローカルコピーは自動的に更新されません。 コマンドラインアプリケーションで、すべてを同期しましょう。 50 | 51 | まず、GitHubで行った変更を、リポジトリのローカルコピーに取り込む必要があります。 52 | 53 | 1. デフォルトブランチに戻ることから始めましょう。`git switch main` 54 | 2. GitHubからすべての変更を取得する。` git pull ` 55 | 56 | ` git pull `は、GitHubからのすべての変更を取得し、リモートからの変更を含めるために、現在位置するブランチを更新するための組み合わせコマンドです。 実行される２つの個別コマンドは、` git fetch `と` git merge ` です。 57 | 58 | ### 不要なブランチの削除 59 | 60 | `git branch --all`を入力すると、リモートのブランチを削除していたとしても、リポジトリのローカルコピーに、ローカルブランチおよび読み取り専用のリモート追跡ブランチの両方としてリストされていることが分かるでしょう。 この余計なブランチを削除しましょう。 61 | 62 | 1. 自分のローカルブランチを確認　` git branch --all ` 63 | 2. 削除しても問題ないブランチを確認　`git branch --merged` 64 | 3. そのローカルブランチを削除　`git branch -d ` 65 | 4. リストを再度確認　`git branch --all` 66 | 5. ローカルブランチは削除されたが、リモート追跡ブランチは、まだ存在する。 よって、リモートトラッキングブランチを削除　`git pull --prune` 67 | 68 | > `--merged` オプション `git branch` コマンドに追加することで、チェックアウトしたブランチと比較する際、独自の作業内容を有していないブランチを特定することができます。 この場合、mainにチェックアウトしたため、ブランチの削除前に、フィーチャブランチにおける変更のすべてが本番ブランチにマージされたことを確かめることができます。 69 | 70 | リモート追跡ブランチの削除を、Pullする際のデフォルト処理として設定したい場合、次の設定オプションを使用します。`git config --global fetch.prune true` 71 | -------------------------------------------------------------------------------- /docs/ja/10_local_history.md: -------------------------------------------------------------------------------- 1 | ## ローカルプロジェクト履歴の確認 2 | 3 | このセクションでは、プロジェクト履歴を確認するためのコマンドを学習します。 4 | 5 | ### Git Logの使い方 6 | 7 | リポジトリをクローンすると、そのリポジトリで作成されたコミット履歴を全て取得できます。 「log」コマンドを使用すると、ローカル環境でコミット履歴を見ることができます。 8 | 9 | プロジェクト履歴の表示をカスタマイズできるオプションを見てみましょう。これらのオプションの詳細については、[git-scm.com](https://git-scm.com/docs/git-log) をご参照ください。 _(Note: `--graph` オプションは、Windows ターミナルにおけるほとんどの Git Bash でデフォルトで指定されています。)_ 10 | 11 | ```sh 12 | git log 13 | git log --oneline 14 | git log --oneline --graph 15 | git log --oneline --graph --decorate 16 | git log --oneline --graph --decorate --all 17 | git log --stat 18 | git log --patch 19 | ``` 20 | 21 | > ↑↓のボタンやエンターキーを使うことで、ログ項目の続きを確認できます。 `q`を入力すると、ログの確認を終了し、コマンドプロンプトに戻ります。 22 | -------------------------------------------------------------------------------- /docs/ja/11_streamline_workflow_with_aliases.md: -------------------------------------------------------------------------------- 1 | ## エイリアスによる作業フローの効率化 2 | 3 | たくさんのコマンドを学習してきましたね。 その中で、logのような、長くて入力しにくいコマンドもありましたよね。 このセクションでは、Gitコマンドのカスタムショートカットの作り方を学習していきましょう。 4 | 5 | ### カスタムエイリアスの作り方 6 | 7 | エイリアスを使うことで、長い文字列を短いコマンドで表すことが可能です。 8 | 9 | 例として、前回学習したlogのコマンドにエイリアスを作成してみましょう。 10 | 11 | #### オリジナルコマンド 12 | 13 | ```sh 14 | git log --oneline --graph --decorate --all 15 | ``` 16 | 17 | #### エイリアスの作成 18 | 19 | ```sh 20 | git config --global alias.lol "log --oneline --graph --decorate --all" 21 | ``` 22 | 23 | #### エイリアスの使い方 24 | 25 | ```sh 26 | git lol 27 | ``` 28 | 29 | #### 他の便利なエイリアスについてのリサーチ 30 | 31 | 以下のリソースで、一般的なエイリアスの一覧を見ることができます。 32 | 33 | - *[git-scm.com/book/en/v2/Git-Basics-Git-Aliases](https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases)* 一般的な git エイリアスの役に立つ概要。 34 | 35 | また、GitHub の開発者である Phil Hack が投稿したこの 3つのブログ記事もおすすめします。彼のヒントはマニュアルからも参照されています。 36 | 37 | - [GitHub Flow Aliases](http://haacked.com/archive/2014/07/28/github-flow-aliases/) 38 | - [Git Migrate](http://haacked.com/archive/2015/06/29/git-migrate/) 39 | - [Git Alias Open URL](http://haacked.com/archive/2017/01/04/git-alias-open-url/) 40 | 41 | ### エイリアスの例 42 | 43 | 手動でエイリアスを編集する場合、gitconfig ファイルをデフォルトのエディタで開くことができるエイリアス 44 | 45 | ```sh 46 | git config --global alias.ec "config --global -e" 47 | ``` 48 | 49 | 別のブランチに切替えるためのクイックショートカットとしてのエイリアス 50 | 51 | ```sh 52 | git config --global alias.sw "switch" 53 | ``` 54 | 55 | 既存のショートカットを用いて作成した新しいブランチを作成するためのエイリアス 56 | 57 | ```sh 58 | git config --global alias.swc "switch -c" 59 | ``` 60 | 61 | 1つのコマンドで実行できるようにしたエイリアス 62 | 63 | ```sh 64 | git config --global alias.s "status -s" 65 | ``` 66 | 67 | ブランチを素早く簡単にクリーンアップするためのエイリアス 68 | 69 | ```sh 70 | git config alias.dlb '!git checkout && git pull --prune && git branch --merged | grep -v "\*" | xargs -n 1 git branch -d' 71 | ``` 72 | -------------------------------------------------------------------------------- /docs/ja/12a_what_is_a_merge_conflict.md: -------------------------------------------------------------------------------- 1 | ## マージコンフリクトとは？ 2 | 3 | チームで作業していると（もしくは一人で作業していたとしても）、マージコンフリクトが発生することがあります。最初は、マージコンフリクトにびっくりするかもしれませんが、それを解決するのは実際とても簡単です。このセクションではその方法について学んでいきましょう！ 4 | 5 | この演習では、技術的に "どうするか" について焦点を当てます。実際のマージコンフリクトでは、そのコンフリクトをどう解決すればいいかわからない場合に、誰に尋ねればよいかを知ることが重要です。通常は、その競合する変更を行った人か、 CODEOWNERS ファイルで指定された人に尋ねると良いでしょう。 6 | 7 | ### ローカル環境におけるマージコンフリクト 8 | 9 | マージコンフリクトは、分散型バージョン管理の自然で軽微な副作用で、特定の状況下でのみ発生します。 10 | 11 | - 同じファイルの同じ "ハンク"（変更範囲）を変更した場合 12 | - 2つの異なるブランチ間 13 | - ブランチが分岐した後、両方のブランチで変更があった場合 14 | -------------------------------------------------------------------------------- /docs/ja/12b_resolving_merge_conflicts.md: -------------------------------------------------------------------------------- 1 | ### マージコンフリクトの解決 2 | 3 | マージコンフリクトを作成し、修正していきましょう。 パートナーと別々のブランチを作成後、同一ファイル名でファイルを作成し、マージしてみましょう。 1番目のブランチは正常にマージしますが、2番目のブランチにはマージコンフリクトが発生してしまいます。 協力して、マージコンフリクトを解決しましょう。 4 | 5 | 1. クラスのリポジトリで、 `USERNAME-conflict` のようなわかりやすい名前で、作業するブランチを作成します。 6 | 1. パートナーと両方で編集するためのファイルを選択します。（先の作業で作成したファイルの一つがよいでしょう）まず、あなたのブランチでそのファイルを編集します。そのファイル名は、パートナーが編集するファイルと同じファイル名である必要があります。そのファイルの中身が異なっていて、空でないことを確認してください。 7 | 1. クラスのリポジトリで、`base: main` と `compare: USERNAME-conflict` で Pull Request を作成します。 8 | 1. *1番目* の Pull Request が問題なくマージできることを確認します。 9 | 1. *2番目* の Pull Request では、マージコンフリクトが発生するので、協力してマージコンフリクトを解決しましょう。 10 | 1. ローカル環境で、 `main` ブランチをフィーチャーブランチにマージします。 11 | 1. マージコンフリクトが発生しても大丈夫！コンフリクトがあるファイルは `Unmerged Paths` に表示されます。 `git status` を実行して、どのファイルにコンフリクトがあるかを確認します。 12 | 1. そのファイルをテキストエディタで開き、マージコンフリクトのマーカーを探します。 (`<<<<<<<`, `=======`, `>>>>>>>`) 13 | 1. 両方のブランチのコードがあるので、残したい方を選択し、変更を保存します。 14 | 1. マージコンフリクトを解決するために、保存した変更をステージに追加しコミットします。 15 | 1. そのフィーチャーブランチをリモートにプッシュし、 Pull Request で解決したことを確認します。 16 | 1. Pull Request をマージします。 17 | 18 | ### マージコンフリクトの解決（一人で演習を行う場合） 19 | 20 | パートナーとの作業が難しい場合など、一人で演習を行う場合は下記をご参考ください。 21 | 22 | 1. GitHub の class repository で、 `main` ブランチにいることを確認します。 23 | 1. `USERNAME-modify-first` ブランチを作成します。 24 | 1. `USERNAME-modify-first` ブランチのまま、自分のスライドファイル `_slides/##-USERNAME.md` の 6行目を変更し、コミットします。 25 | 1. **一度 `main` ブランチを開きなおして**から、2つ目として `USERNAME-modify-conflict` ブランチを作成します。 26 | 1. `USERNAME-modify-conflict` ブランチのまま、先ほど変更した同じファイルの同じ位置（ `_slides/##-USERNAME.md` の 6行目）を別の文字列に変更し、コミットします。 27 | - ここでのポイントは、変更する対象が、"同じファイル", "変更箇所が同じハンクで変更内容が異なる", "ファイルが空でない" 場合にコンフリクトが発生するという点です。 28 | 1. `base: main` と `compare: USERNAME-modify-first` で Pull Request を作成します（タイトル: `USERNAME merge first`） 29 | 1. `base: main` と `compare: USERNAME-modify-conflict` で Pull Request を作成します（タイトル: `USERNAME resolve conflict`） 30 | 1. `USERNAME merge first` の Pull Request をマージします。 31 | 1. `USERNAME resolve conflict` の Pull Request でマージコンフリクトが発生していることを確認し、マージコンフリクトを解消しましょう。 32 | 1. ローカル環境で、下記の操作を行い、 `main` ブランチの更新取込みを行います。 33 | 34 | ```sh 35 | git switch main 36 | git pull 37 | ``` 38 | 39 | 1. `git fetch` でリモート（ GitHub 上）の情報を取込み、リモートで作成した `USERNAME-modify-conflict` ブランチをアップストリームに設定した上で、ローカルのブランチを切り替えます。 40 | 41 | ```sh 42 | git fetch 43 | git switch USER-modify-conflict 44 | ``` 45 | 46 | 1. `main` ブランチをフィーチャーブランチにマージします。 47 | 48 | ```sh 49 | git merge main 50 | ``` 51 | 52 | 1. マージコンフリクトが発生しても大丈夫！コンフリクトがあるファイルは `Unmerged Paths` に表示されます。 `git status` を実行して、どのファイルにコンフリクトがあるかを確認します。 53 | 54 | ```sh 55 | git status 56 | ``` 57 | 58 | 1. そのファイルをテキストエディタで開き、マージコンフリクトのマーカーを探します。 (`<<<<<<<`, `=======`, `>>>>>>>`) 59 | 60 | ```sh 61 | # Visual Studio Code で開く場合 62 | code _slides/##-USERNAME.md 63 | ``` 64 | 65 | 1. マーカーに囲まれた両ブランチのコードのうち、残したい方を残し、変更を保存します。 66 | 1. マージコンフリクトを解決するために、保存した変更をステージに追加しコミットします。 67 | 68 | ```sh 69 | git add _slides/##-USERNAME.md 70 | git commit 71 | ``` 72 | 73 | 1. そのフィーチャーブランチをリモートにプッシュします。 74 | 75 | ```sh 76 | git push 77 | ``` 78 | 79 | 1. `USERNAME resolve conflict` の Pull Request で解決したことを確認し、マージします。 80 | 81 | > マージメッセージとは？ 今回の場合では、再帰的なマージを行っています。 再帰的なマージは、この２つのブランチがマージされた時点を永続的に記録する、新しいコミットを作成します。 Gitのマージの活用については、後ほど説明します。 82 | -------------------------------------------------------------------------------- /docs/ja/13_workflow_review_project_github_games.md: -------------------------------------------------------------------------------- 1 | ## プロジェクト: GitHub Games 2 | 3 | このセクションでは、`github-games`というプロジェクトのリポジトリで作業します。 4 | 5 | `github-games`のリポジトリはすでに githubschool organization にて作成してあります。 `https://github.com/githubschool/github-games-USERNAME` でアクセスできます。 6 | 7 | フォークとプルの作業フローを使っている場合は、[付録で詳しい説明を読んでください。](app_fork_workflow.md) 8 | 9 | ### 作業フローレビュー: README.mdの更新 10 | 11 | READMEにあるリンクを、自分のリポジトリのフォークへ飛ぶように更新し、GitHubのフローを一通り練習してみましょう。 12 | 13 | > あなたのウェブサイトは `https://githubschool.github.io/github-games-USERNAME` にあります。 14 | > 15 | > このリンクはリポジトリの説明欄にも記載されています。 簡単に自分のゲームにアクセスできるよう、説明欄にあるウェブサイトのURLを編集しておくと良いです。 16 | > 17 | > リンクをクリックしたら、`README.md`にあるテキストが表示されます。 このリポジトリの修正方法を学習するために、わざとリポジトリを壊しました。 18 | 19 | これは復習なので、以下の手順は省略して記載しています。 復習をしながら、前の課題で学習したコマンドのショートカットを使ってみましょう。 20 | 21 | 1. リポジトリのコピーをクローンします。`git clone https://github.com/githubschool/github-games-USERNAME.git` 22 | 2. `readme-update` という新しいブランチを作成します。 `git switch -c readme-update` 23 | 3. README.mdにあるURLを編集します。 24 | 4. 変更を自分のブランチにコミットします。 25 | 5. ブランチをGitHubにプッシュします。`git push -u origin readme-update` 26 | 6. *自分のリポジトリで* Pull Request を作成します。 (base: `main`, compare: `readme-update`) 27 | 7. 自分の Pull Request をマージします。 28 | 8. GitHubのブランチを削除します。 29 | 9. リポジトリのローカルコピーを更新します。`git pull --prune` 30 | 31 | `git switch -c readme-update` は、ブランチの作成（`git branch readme-update`）とブランチ切替え（`git switch readme-update`）を合わせたショートカットコマンドです。 `-c` はGitに新しいブランチを作成するよう命令します。 32 | 33 | > `git push -u origin readme-update` は、初めて新しいブランチをプッシュするときに使用するプッシュコマンドの少々長いバージョンです。 34 | > 35 | > `-u` は `--set-upstream` というオプションの短いバージョンです。 このオプションは、ローカルブランチと同一名のリモート追跡ブランチを繋げるようGitに伝えます。 36 | > 37 | > 初めて新しいブランチをプッシュするときのみ、この長いコマンドを使用する必要があります。 その後は、 `git push` だけで可能になります。 38 | 39 | `git config --global alias.bclean "!f() { branches=$(git branch --merged ${1-main} | grep -v " ${1-main}$"); [ -z \"$branches\" ] || git branch -d $branches; }; f"` このコマンドが便利です。**詳しくは appendix をご参照ください。** 40 | -------------------------------------------------------------------------------- /docs/ja/14_git_bisect.md: -------------------------------------------------------------------------------- 1 | ## コードでのイベント検索方法 2 | 3 | このセクションでは、リポジトリにバグが入ってしまったコミットを `git bisect` で検索する方法を学習しましょう。 4 | 5 | ### `git bisect` とは？ 6 | 7 | `git bisect` はバイナリー検索を使うことで、コードでの具体的なイベントを検出できます。 例えば、bisectを使って、以下のようなイベントがあったコミットを探し出すことができます。 8 | 9 | - バグが入ってしまった 10 | - 新しい機能が追加された 11 | - ベンチマークのパフォーマンスが向上した 12 | 13 | #### Bisectの仕組み 14 | 15 | `git bisect` は、２点間にある履歴を半分にし、そのコミットをチェックアウトします。 ユーザは、その時点でのバグや機能の有無を確認し、Gitにその結果を伝えます。 その後Gitは、探しているコミットが見つかるまで同じ過程を繰り返します。 16 | 17 | ![Git Bisect](../img/git-bisect.png) 18 | 19 | > Bisectが行われているときは、本質的に切り離されたHEAD (detached HEAD) の状態になっています。 Git で他の操作を行う前に、`git bisect reset` を実行して bisect を終了しましょう。 {: .warning} 20 | 21 | ### プロジェクトでのバグの探し方 22 | 23 | #### 詳細方法 24 | 25 | 1. バイナリ検索を始めます。`git bisect start` 26 | 2. コードが壊れているコミットを指定します。 `git bisect bad ` 27 | 3. コードがちゃんと機能していたコミットを指定します。`git bisect good ` 28 | 4. Bisectはその中間のコミットをチェックアウトします。 29 | 5. テストを実行し、ゲームが機能しているかどうかを確認します。 実行するテストは、`ls` を使って、`index.html` の有無を確認します。 30 | 6. ゲームがまだ壊れていたら（ `index.html` というファイルが存在*していなかったら*）、 `git bisect bad` と入力します。 31 | 7. ゲームが機能していたら（そして、`index.html` というファイルが存在*していたら*）、 `git bisect good` と入力します。 32 | 8. Gitは、改めてbisectを行い、テストの実行を待ちます。 この過程は、Gitが最初に問題が発生したコミットを突き止めるのに十分な情報を集めるまで続きます。 33 | 9. Gitがエラーを検出すると、`SHA is the first bad commit.` というメッセージが表示されます。 34 | 10. Bisectのプロセスを終了します。`git bisect reset` 35 | 36 | #### ショートカットを使用する方法 37 | 38 | Bisectは、コードに対し自動的にテストを実行することもできます。 ショートカットのコマンドとテストを使って、もう一度やってみましょう。 39 | 40 | 1. `git bisect start ` 41 | 1. `git bisect run ls index.html` 42 | 1. `git bisect reset` 43 | -------------------------------------------------------------------------------- /docs/ja/15_reverting_commits.md: -------------------------------------------------------------------------------- 1 | ## コミットの打ち消し 2 | 3 | このセクションでは、履歴を書き換えるコマンドと、そのコマンドを使う場面を学習します。 4 | 5 | ### コミットの仕組み 6 | 7 | Gitのコミットは、それぞれ、その時点でのユニークなスナップショットです。 以下の情報が含まれています。 8 | 9 | - リポジトリにある現在のオブジェクトへのポインタ 10 | - コミット作者とメールアドレス（コンフィグレーションの設定から） 11 | - コミットの日付と時間 12 | - コミットメッセージ 13 | 14 | ![Gitの基本的なコミットの構造](../img/commit-and-tree.png) 15 | 16 | 他にも、それぞれのコミットには親コミットのコミットIDも含まれています。 17 | 18 | ![コミット同士の関係](../img/commit-parent.png) 19 | 20 | 画像ソース：Scott ChaconのProGit v2 21 | 22 | ### 安全な操作 23 | 24 | Gitのデータ構造は整合性を提供しますが、分散的な性質があるため、特定の操作がすでに共有されたコミットに対してどんな影響を及ぼすかを意識しなければいけません。 25 | 26 | その操作がリモート（公開コミットとも言われます）にプッシュされているコミットのコミットIDを変更するとしたら、操作の選択を十分に考慮しなければいけません。 27 | 28 | #### 一般的なコマンドの注意事項 29 | 30 | | コマンド | 注意事項 | 31 | | ---------------- | ----------------------- | 32 | | `revert` | 新しいコミットを作成するため、比較的安全です。 | 33 | | `commit --amend` | ローカルなコミットにのみ使ってください。 | 34 | | `reset` | ローカルなコミットにのみ使ってください。 | 35 | | `cherry-pick` | ローカルなコミットにのみ使ってください。 | 36 | | `rebase` | ローカルなコミットにのみ使ってください。 | 37 | 38 | ### コミットの打ち消し方法 39 | 40 | ゲームを機能させるためには、`index.html` を間違った名前に変更したコミットを打ち消す必要があります。 41 | 42 | > **注意**：コミットを打ち消す前に、同じコミットの他の変更が取り消されないかを確認しましょう。 `git show SHA` で、コミットの変更を確認できます。 43 | 44 | 1. 打ち消しを開始します。`git revert ` 45 | 2. コミットメッセージを入力します。 46 | 3. GitHubに変更をプッシュします。 47 | -------------------------------------------------------------------------------- /docs/ja/16_helpful_git_commands.md: -------------------------------------------------------------------------------- 1 | ## 役に立つGitのコマンド 2 | 3 | このセクションでは、役に立つGitのコマンドを見ていきます。 4 | 5 | ### Gitでのファイル移動と改名 6 | 7 | 1. `slow-down` という新しいブランチを作成します。 8 | 1. index.htmlというファイルの*9行目* で、背景のURLを *(images/texture.jpg)* に変更します。 9 | 1. ゲームを加速または、減速させるために、*78行目*でタイミングを変更します。 10 | 1. 変更を保存します。 11 | 1. Gitが何を追跡しているのかを確認します。 12 | 13 | ```sh 14 | git status 15 | ``` 16 | 17 | 1. 新しい空のディレクトリを作成します。 18 | 19 | ```sh 20 | mkdir images 21 | ``` 22 | 23 | 1. Gitでテクスチャーファイルをそのディレクトリに移動させます。 24 | 25 | ```sh 26 | git mv texture.jpg images/texture.jpg 27 | ``` 28 | 29 | ### 変更した一連の範囲（ハンク）をステージング 30 | 31 | 読みやすく有益なプロジェクト履歴を作成するには細かいコミットの作成が重要です。 32 | 33 | 1. Gitが何を追跡しているのかを確認します。 34 | 35 | ```sh 36 | git status 37 | ``` 38 | 39 | 2. `--patch` というフラグを使用し、ファイルの一部をステージングエリアに移動させます。 40 | 41 | ```sh 42 | git add -p 43 | ``` 44 | 45 | 3. 画像移動に関するハンクをステージングします。y 46 | 4. 速度変更に関するハンクはワーキングエリアに残します。n 47 | 48 | ?> 他のハンクのオプションが気になりますか？ ? を使用し、ハンクのオプション一覧を見ることができます。 49 | 50 | `git config --global alias.cm "!git add -A && git commit -m"` このコマンドがここで便利です。詳しくは appendix をご参照ください。 51 | -------------------------------------------------------------------------------- /docs/ja/17_protected_branches.md: -------------------------------------------------------------------------------- 1 | ## 保護されたブランチ と CODEOWNERS 2 | 3 | 作業フローによっては、重要なブランチにマージするコードに、必要な確認やピアレビューを受けさせるため、そのブランチを保護したいという時があると思います。 **Protected Branches** や **Code Owners** など、方法はいくつかあります。 4 | 5 | ### 保護されたブランチ 6 | 7 | リポジトリメンテナは、特定ブランチへの定められた基準に満たないマージを阻止することができます。 その基準は、ピアレビューや、継続的インテグレーションサービスとコードクオリティなどのインテグレーションによるテスト、特定のコード所有者の変更へのレビューと承認などです。 8 | 9 | 保護されたブランチを有効にしましょう。 10 | 11 | 1. **Settings** のタブを選択します。 12 | 1. 画面の左側のメニューから **Branches** を選択します。 13 | 1. **Branch protection rules** の隣にある **Add rule** ボタンをクリックします。 14 | 1. **Branch name pattern** のテキストボックスに保護したいブランチの名前を入力します。例えば、 `main`。 15 | 1. **Create** ボタンをクリックします。 16 | 17 | 他のオプションにチェックを付けない場合の基本的なブランチ保護は、フォースプッシュとそのブランチの削除を防ぎます。 利用可能なオプションの詳細については、[この機能のドキュメント](https://help.github.com/articles/defining-the-mergeability-of-pull-requests/) を参照してください。 18 | 19 | > **Pro-tip:** Branch protection rule を複数のブランチに適用させるには、ワイルドカード (`*`, `?`) や正規表現を利用することができます。ワイドカードや正規表現がどうマッチングするかについての詳細は [branch protection documentation](https://help.github.com/en/articles/configuring-protected-branches) をご参照ください。 20 | 21 | ### Code owners 22 | 23 | リポジトリメンテナは、**CODEOWNERS** を作成することで、変更を確認する必要のある人やチームを細かく決めることができます。 例えば、CODEOWNERSは以下のように使用できます。 24 | 25 | - チームのJavascriptの専門家には、全ての`.js` 拡張子のファイルを確認させる 26 | - 技術仕様書チームには、全ての`docs/` フォルダの変更を確認させる 27 | - セキュリティチームには、`package.json` に書いてある、新しい依存ファイルを確認させる 28 | 29 | CODEOWNERS のファイルを作成しましょう。 30 | 31 | 1. リポジトリの **Code** タブを開きます。 32 | 1. **Add file** のドロップダウンをから **Create new file** をクリックします。 33 | 1. **Name your file...** のテキストボックスに `CODEOWNERS` (拡張子は不要) と入力します。 `.github/CODEOWNERS` と入力することで、 `.github/` ディレクトリに追加することができます。 34 | 1. 最初の一行目 に`* @YOUR_USERNAME` を入力します。 35 | - 以降の行に記載された一致する項目が優先されない限り、あなたがリポジトリの全てのデフォルトのオーナーであることを意味します。 36 | 1. 次の行に、`*.js @githubteacher` を入力します。 37 | - 記載する順番が重要になります。 指定された変更の最後に一致する項目が優先されます。 38 | 1. 下へスクロールし、 **Commit new file** のダイアログボックスにコミットメッセージを入力します。 39 | 1. 変更を保存するために、 **Commit new file** ボタンをクリックします。 40 | 1. CODEOWNERS のファイルを作成したので、ブランチ保護設定に戻り、`main` の横にある **Edit** ボタンをクリックします。 41 | 1. **Protect matching branches** 配下の **Require pull request reviews before merging** と and **Require review from Code Owners** のオプションを選択します。忘れずに **Save changes** をクリックして保存します。 42 | 43 | CODEOWNERS ファイルの書き方の詳細については、[ドキュメント](https://help.github.com/articles/about-codeowners/) を参照してください。 44 | -------------------------------------------------------------------------------- /docs/ja/17_tags_and_releases.md: -------------------------------------------------------------------------------- 1 | ## タグとリリース 2 | 3 | 特定の状態やある時点をマークしておくために、コード履歴で、あるコミットにタグまたはリリースを付けたい時があると思います。 そのような時は、Gitの **tag** の機能もしくは、GitHubの **release** の機能を使いましょう。 4 | 5 | ### タグ 6 | 7 | タグとは、特定のコミットを指すポインタです。 コミットと違って、タグは、不変 *ではありません* 。 移動や変更が可能です。 タグの練習をしてみましょう。 8 | 9 | タグは、Gitを使ってローカルでも作成可能ですし、GitHub上でも作成できます。 タグをコマンドラインから作成する場合は、「注釈」タグをつけるのがおすすめです。 次の例では、`-a` フラグを使って注釈タグを作成し、タグを `v1.0` と名づけ、指定のコミットSHAに付けます。 10 | 11 | - `git tag -a v1.0 ` 12 | 13 | `git tag --list` を入力して、タグの一覧を見ることができます。 14 | 15 | タグの注意すべき点は、コミットするとき、タグが自動的にはプッシュされないということです。 タグをプッシュするときは、`git push --tags`を入力します。 16 | 17 | configの `git config push.followTags true` というコマンドを使って、デフォルトを、関連コミットがプッシュされたときにタグも自動的にプッシュされるように設定できます。 [このコンフィグレーションの設定の詳細](https://git-scm.com/docs/git-config/2.4.1#git-config-pushfollowTags). 18 | 19 | ### リリース 20 | 21 | リリースとは、ソフトウェアをダウンロード、インストールするだけのユーザが、簡単にアクセスできるよう、タグに実行ファイルを追加できるGitHubの機能です。 特定のコミットを指し、他のタグと同様に名前を付けることができるので、リリースもタグということになります。 ただしリリースには、添付されたバイナリを含むことも可能です。 22 | 23 | ### GitHub Gamesにリリースを追加しましょう 24 | 25 | 1. GitHubで、リポジトリの **Code** のタブに移動します。 26 | 2. リポジトリの名前の下でReleasesをクリックします。 27 | 3. Draft a new releaseをクリックします。 28 | 4. タグの名前を入力します。 セマンティックバージョニングの使用をおすすめします。 29 | 5. リリースしたいプロジェクトが含まれているブランチを選択します。 通常、ベータ版ソフトウェアでない限り、mainブランチからリリースします。 直近のcommitsのタブをクリックし、直近のコミットを選択することもできます。 30 | 6. リリースを説明するタイトルと詳細を入力します。 31 | 7. リリースを公開する準備ができたら、Publish releaseをクリックします。 まだリリースを公開しない場合は、後で作業できるよう、Save draftをクリックします。 32 | 33 | > ファイルをドラッグアンドドロップしたり、バイナリボックスで手動でファイルを選択したり、プロダクションの準備ができていないことをユーザに通知するための「This is a pre-release」を選択したりすることができます。 34 | -------------------------------------------------------------------------------- /docs/ja/17_view_local_changes.md: -------------------------------------------------------------------------------- 1 | ## ローカル変更の表示 2 | 3 | ステージングエリアとワーキングディレクトリにファイルが入っているので、リポジトリのさまざまな点を比較する方法を見てみましょう。 4 | 5 | ### リポジトリでの変更を比較する方法 6 | 7 | `git diff` でリポジトリにある2つのrefの違いを見ることができます。 以下の図は、ワーキングエリアやステージング、HEAD（最新コミット）の内容を比較する方法を表しています。 8 | 9 | ![Git diffのオプション](../img/diff-options.png) 10 | 11 | リポジトリにこのコマンドを使ってみましょう。 12 | 13 | ```sh 14 | git diff 15 | git diff --staged 16 | git diff HEAD 17 | git diff --color-words 18 | ``` 19 | 20 | `git diff` は、以下のように入力するだけでブランチとコミットとタグの間を比較することもできます。 21 | 22 | ```sh 23 | git diff 24 | git diff main slow-down 25 | git diff origin/main main 26 | git diff 2710 b745 27 | ``` 28 | 29 | > diffは、マージと同様、方向性があることに気をつけましょう。"diff は `` から `` に戻る" または "`` の時点で**含まれず** `` の時点に**含まれる**もの" というように考えると分かりやすいです。この最後の例は、そのコミットハッシュに基づいて 2つのコミットをどう比較するかを示しています。なお、個々のリポジトリのコミットには異なるハッシュが割り当てられているので、これらのコマンドそのものは機能しません。 30 | 31 | コマンドラインからリモートを直接開くことができる便利なエイリアスがあります。詳しくは appendix をご参照ください。 32 | -------------------------------------------------------------------------------- /docs/ja/17_workflow_discussion.md: -------------------------------------------------------------------------------- 1 | ## Discussion Guide: チームにおける作業フローとブランチ戦略について 2 | 3 | そろそろ、あなたやチームにとって効果的なことや、有益になりそうなこと、過去に学習した事柄について話し合う良い時期かと思います。ここに、理想的なプロセスを確立するために、チームと話し合う必要があるいくつかのトピックを紹介します。このタイミングで、またはクラスのリポジトリの Issues を利用して、さまざまな作業フローについて話し合ってみましょう。 4 | 5 | 1. どのブランチ戦略を採用しますか？ 6 | 1. どのブランチをmainとして、もしくは、デプロイするコードとして扱うのか？ (Which branch will serve as our "main" or deployed code?) 7 | 1. コードをどう保護するか？ 8 | 1. ブランチの命名規則をどうするか？ 9 | 1. ラベルや担当者（assignee）をどう活用するか？ 10 | 1. マイルストーンを利用するか？ 11 | 1. IssuesやPull Requestsに対してガイドラインとして必要な要素を付け加えますか？（例えばShipping Checklistなど） (Will we have required elements of Issues or Pull Requests (e.g. shipping checklists)?) 12 | 1. あなたの作業をレビューしてもらいたい人は誰ですか？他のチームに協力してもらうことを計画していますか？ 13 | 1. Pull Request の承認を示すにはどうすればよいか？ (How will we indicate sign-off on Pull Requests?) 14 | 1. だれが Pull Request をマージするか？ 15 | 1. チームの作業フローについてどう伝えていくか？もしフローがすでにあるなら、新しいメンバーにどう伝えていくか？ 16 | 1. 開発のそれぞれの段階に対してどんなインテグレーションを利用するか？すべてのチームが同じツールを利用するか？ 17 | 1. Git, GitHub, 作業フローについて質問がある場合は、誰に聞きますか？誰がその疑問を持っていると把握できますか？ 18 | -------------------------------------------------------------------------------- /docs/ja/18_create_local_repo.md: -------------------------------------------------------------------------------- 1 | ### 新しいローカルリポジトリの初期化方法 2 | 3 | 次のコマンドを練習するために、ローカルリポジトリを作成しましょう。 4 | 5 | 1. 練習のリポジトリを置くディレクトリに移動します（`cd ..` で親フォルダに戻れます）。 6 | 1. 新しいディレクトリを作成し、gitのリポジトリとして初期化します。 `git init practice-repo` 7 | 1. `cd` コマンドで新しいリポジトリに移動します。 `cd practice-repo` 8 | 1. `README.md` という新しいファイルを作成します。 9 | - Bash: `touch README.md` 10 | - PowerShell: `Out-File README.md` 11 | 1. README.md ファイルをステージングに追加し、コミットします。 12 | 13 | これを練習用のリポジトリとして使うので、いくつかのファイルとコミットを作成する必要があります。 以下のスクリプトで簡単に作成できます。 14 | 15 | **Bash:** 16 | 17 | ```bash 18 | for d in {1..6}; do touch "file${d}.md"; git add "file${d}.md"; git commit -m "adding file ${d}"; done 19 | ``` 20 | 21 | **PowerShell:** 22 | 23 | ```powershell 24 | for ($d=1; $d -le 6; $d++) { Out-File file$d.md; git add file$d.md; git commit -m "adding file$d.md"; } 25 | ``` 26 | 27 | > このセクションの間、`tree .git` というコマンドを見るかもしれません。もし、あなたの作業環境で `tree .git` が実行できない場合（おそらく Windows マシン）は、代わりに `cmd //c tree` を試してみてください。 28 | -------------------------------------------------------------------------------- /docs/ja/19_fixing_commit_mistakes.md: -------------------------------------------------------------------------------- 1 | ## コミットの誤りの修正 2 | 3 | 今回は、GitとGitHubでプロジェクト履歴を形作るいくつかの方法を学習します。 4 | 5 | ### 最新コミットの修正 6 | 7 | `git commit --amend` を使うことで、HEADが現在指しているコミットを変更することができます。 最も一般的な用途は以下の2つです。 8 | 9 | - コミットメッセージを書き換える 10 | - コミットにファイルを追加する 11 | 12 | では、実践してみましょう。 13 | 14 | 1. 新しいファイルを作成します。 15 | - Bash: `touch file7.md` 16 | - PowerShell: `Out-File file7.md` 17 | 1. 前のコミットにファイルを追加するときは、そのファイルをステージングエリアに入れる必要があります。ファイルをステージングエリアに移動します。 `git add file7.md` 18 | 1. `git commit --amend` 19 | 1. テキストエディタが開き、コミットメッセージを編集できます。 20 | 21 | > コミット作者やメールなど、最後のコミットが保存しているデータを修正することができます。 22 | -------------------------------------------------------------------------------- /docs/ja/19_forgot_to_branch.md: -------------------------------------------------------------------------------- 1 | ## あ！ブランチを作り忘れてしまった 2 | 3 | 作業を始めたが、まだ `main` ブランチのままだったとしても、焦らないで！変更は、コミットされるまではまだブランチには反映されていません。作業ディレクトリとステージングエリアは、ブランチ**ではなく**、 `HEAD` にアタッチされています。そのため、ブランチを切り替えることができ、コミットしていない変更はあなたの自由にできます。 4 | 5 | ### 演習: 変更を加えた後にブランチを作成する 6 | 7 | 1. ブランチを作成する前にファイルを変更します 8 | - _作業ディレクトリとステージングエリアは移行可能であることに注目してください - すなわち、それぞれのエリアにあるファイルはブランチを切り替えてもそのままです！_ 9 | 2. `git status` を実行し、作業ディレクトリの変更を確認しましょう。 10 | 3. `git switch -c BRANCH-NAME` を実行し、新しいブランチを作成します。 11 | 4. `git status` を再度実行し、今いるブランチと作業ディレクトリを確認しましょう 12 | 13 | ## コミットしていないコンフリクト 14 | 15 | もしファイルに変更を加えたあと、他のブランチに切替えようとしたが、そのブランチにはあなたの新しいコミットしていない変更と競合するコミット済みの変更がある場合、何が起こるか、どうしてそれが起こるか考えてみましょう。 16 | -------------------------------------------------------------------------------- /docs/ja/20_rewriting_history_git_reset.md: -------------------------------------------------------------------------------- 1 | ## Git Resetによる履歴の書き換え 2 | 3 | 履歴をさらに遡ったコミットを変更したい場合は、より強力なコマンドを使う必要があります。`git reset` 4 | 5 | ### Resetの仕組み 6 | 7 | ブランチで作業をしていて、計画どおりに進まないと判断することがありますよね。 一部または全てのファイルを履歴の違う点の状態にリセットしたいとします。 8 | 9 | ![Git resetの実行前後](../img/reset-visual.png) 10 | 11 | ある時点で、プロジェクトには3つの違うスナップショットが存在します。 1番目のスナップショットは、最新のコミット（HEADとも言われます）です。 2番目は、ステージングエリア（インデックスとも言われます）。 3番目は、新規や削除、変更されたファイルを含むワーキングディレクトリです。 12 | 13 | `git reset` のコマンドには、このスナップショットの一部もしくは、全てを変更できる、3つのモードがあります。 14 | 15 | ブランチの本質が分かると、より理解しやすくなります。それぞれのブランチは最新コミットへのポインタまたは、参照です。 ブランチが常に最新のコミット指すために、コミットを追加したら現在チェックアウトされているブランチは「前進」します。 16 | 17 | ### Resetのモード 18 | 19 | ![resetの3つのモード](../img/reset-modes.png) 20 | 21 | git resetの3つのモードは、`--soft`, `--mixed`, `--hard`です。 今回の例では、ワーキングディレクトリが「クリーン」だとします。つまり、コミットされていない変更がない、という状態です。 22 | 23 | #### `--soft` 24 | 25 | `git reset --soft ` は、現在のブランチを``に指すように移動します。 ただし、ワーキングディレクトリとステージングエリアは変更されません。 現在のブランチが指しているスナップショットがインデックスのスナップショットと異なるため、このコマンドは事実上、そのスナップショットの間の相違点をステージングします。 小さなコミットを大量にしていて、1つのコミットにまとめたいときに適したコマンドです。 26 | 27 | #### `--mixed` 28 | 29 | `git reset --mixed ` は、現在のブランチ*と*ステージングエリアを `` のスナップショットの状態にします。 *これがデフォルトのモードです。* モードのフラグをつけないと、Gitはあなたが`--mixed`を意図していると判断します。 `--mixed` は、ワーキングディレクトリの変更を全て残したいが、その変更をコミットするかどうか、またはどのようにコミットするかを変更したいときに便利です。 30 | 31 | #### `--hard` 32 | 33 | `git reset --hard ` は、最も劇的なオプションです。 Gitは、現在のブランチやステージングエリア*と*ワーキングディレクトリのスナップショットを3つとも `` の状態にします。 これは危険です！ これまでは、ワーキングディレクトリがクリーンであるとしてきました。 クリーンでない場合、コミットされていない変更があったら、`git reset --hard` は、*その変更を全て削除します*。 クリーンなワーキングディレクトリの場合でも、前の変更を元に戻したいときのみに`--hard` を使ってください。 34 | 35 | ### Reset Soft 36 | 37 | 前に作成した練習用リポジトリを使って、`reset --soft` を行ってみましょう。 38 | 39 | 1. プロジェクトの履歴を確認します。 `git log --oneline --decorate` 40 | 1. `HEAD` の現在指している場所を特定します。 41 | 1. 履歴で2つ前のコミットに戻ります。`git reset --soft HEAD~2` 42 | 1. ブランチの先端（そして`HEAD`）が、2つ前のコミットを指していることを確認します。 `git log --oneline --decorate` 43 | 1. 最新の2つのコミットの変更は、ステージングエリアにあります。 `git status` 44 | 1. すべてのファイルはまだローカル環境にあることを確認します。 `ls` 45 | 1. 先ほど作成した追加のファイルを削除しましょう。 `git rm --cached file7.md` 46 | 1. ここで、この追加のファイル以外の変更を再コミットしましょう。 `git commit -m "re-add file 5 and 6"` 47 | 48 | > この例では、チルダ記号は、現在の `HEAD` の場所の2つ前のコミットにリセットしたいとgitに伝えます。 コミットIDの数個の頭文字を使って、リセットする場所を特定することもできます。 49 | 50 | ### Reset Mixed 51 | 52 | 次は、reset のデフォルトモードを試します。`reset --mixed` 53 | 54 | 1. ここでも、最初にプロジェクトの履歴を確認します。 `git log --oneline` 55 | 1. 履歴で1つ前のコミットに戻ります。 `git reset HEAD~` 56 | 1. ブランチの先端がどこを指しているのかを確認します。 `git log --oneline --decorate` 57 | 1. 最新のコミットの変更は、ワーキングディレクトリに戻されています。 `git status` 58 | 1. すべてのファイルはまだローカル環境にあることを確認します。 `ls` 59 | 1. コミットする前に、ファイルをステージングエリアに移動する必要があります。 `git add file5.md file6.md` 60 | 1. ファイルを再コミットします。 `git commit -m "re-add file 5 and 6"` 61 | 62 | > 本質的に同じコミット（ファイル5と6や、同じHEADとコミットメッセージを追加したコミット）をしたが、新たなコミットIDを取得したことに注意しましょう。 これが、すでにリモートにプッシュされているコミットにresetのコマンドを使ってはいけない理由です。 63 | 64 | ### Reset Hard 65 | 66 | 最後にhard resetを行ってみましょう。 67 | 68 | 1. 最初にプロジェクトの履歴を見ましょう。`git log --oneline` 69 | 2. README.mdのファイルしか存在しなかった時点にリセットします。`git reset --hard ` 70 | 3. コミットが全てなくなっていることを確認します。`git log --oneline` 71 | 4. ワーキングディレクトリがクリーンになったことを確認します。`git status` 72 | 5. リポジトリに README.md と file7.md しかないことを確認します。`ls` 73 | 74 | > **注意：** `git reset --hard` は、ワーキングディレクトリやステージングエリア、履歴を書き換えます。 つまり、コミットされていない変更は完全に失われてしまいます。 本当に変更を破棄したい場合以外は、使わないようにしましょう。 75 | 76 | ### 「なくなった」とは、本当になくなった？ 77 | 78 | 答えは、場合によります！ 79 | 80 | ```sh 81 | git reflog 82 | ``` 83 | 84 | reflogとは、HEADが指していた全ての場所の履歴です。 どのようにreflogを使えば、以前にコミットされた変更を復元できるのかを見ていきましょう。 まずは、reflogの制限を意識しておく必要があります。 85 | 86 | - **reflogはあくまでローカルです**。リモートにプッシュされず、ローカルな履歴しか含まれていません。 つまり、他の人のコミットのreflogを見ることは不可能ですし、他の人があなたのreflogを見ることもできません。 87 | - **reflogには時間制限があります**。デフォルトでは、到達可能なコミットは、90日間であればreflogで表示されますが、到達不可能なコミット（ブランチに繋がっていないコミット）は30日間しか表示されません。 88 | 89 | > ときどき、コミットメッセージのことを考えずに、またはあなたの変更を整理する前にコミットとして作業を保存したいと思うことがあるかもしれません。その場合は、"save points" を作成するエイリアスを作成することができます。詳しくはエイリアスに関する appendix をご参照ください。 90 | -------------------------------------------------------------------------------- /docs/ja/21_git_cherry_pick.md: -------------------------------------------------------------------------------- 1 | ## 取り戻しましょう。`git cherry-pick` 2 | 3 | 前回、reflogを使って、破棄されたローカルの変更を見つける方法を学習しました。 今回は以下の場合を学習しましょう。 4 | 5 | ### 1つの特定のコミットが欲しい場合 6 | 7 | チェリーピックは、reflogもしくは、プロジェクトの他のブランチからのコミットを拾い、現在のブランチに移動させることができます。 現在のファイルディレクトリとログは以下のようになっているはずです。 8 | 9 | ```shell-session 10 | $ ls 11 | README.md 12 | $ git log --oneline 13 | 84nqdkq initializing repo with README 14 | ``` 15 | 16 | ファイル4を追加したコミットをチェリーピックしましょう。 17 | 18 | 1. file4.mdを追加したコミットIDを見つけます。`git reflog` 19 | 2. そのコミットをチェリーピックします。`git cherry-pick ` 20 | 21 | ディレクトリとログを見ると、以下のように表示されているはずです。 22 | 23 | ```shell-session 24 | $ ls 25 | file4.md 26 | README.md 27 | $ git log --oneline 28 | eanu482 adding file 4 29 | 84nqdkq initializing repo with README 30 | ``` 31 | 32 | コミットIDは、チェリーピックのコマンドで使用したものと同じでしょうか？ なぜそうなっているのでしょうか？ 33 | 34 | > 履歴を変更するコマンドは、GitHubにプッシュする前に使用することが重要です。 すでにリモートにプッシュされているコミットのIDを変更してしまうと、コラボレータに問題が発生する恐れがあります。 {: .warning} 35 | 36 | ### おっと、誤ってリセットしちゃった 37 | 38 | 時折、`git reset --hard` を意図した範囲よりも広く使用してしまい、それを復元させたいという時があります。 幸いなことに、`git reset --hard` は、遡るだけでなく、前に進めることもできます。 39 | 40 | 1. HEADが指してきた全ての場所の履歴を表示します。`git reflog` 41 | 2. 元の`file6.md`が作成された時点にリセットします。`git reset --hard ` 42 | 3. 復元された履歴を表示します。`git log --oneline` 43 | 44 | `git log --oneline`のコミットIDを `git reflog` と比較してみましょう。 気づきましたか？ 45 | 46 | > すでにファイル4をチェリーピックしたのに、なぜこのコマンドはマージコンフリクトを起こさなかったでしょうか。 その理由は、`git reset --hard` が2つの履歴をマージしようとしているわけではなく、新しいコミットを指すようブランチを移動しただけだからです。 それが今回の狙いでした。 しかし違う場面では、元のリセット後に行った作業が全て失われてしまう可能性があります。 47 | 48 | 便利なエイリアスを利用して悲惨な失敗を回避する方法について、Appendix に記載しています。ご参照ください。 49 | -------------------------------------------------------------------------------- /docs/ja/22_merge_strategies_rebase.md: -------------------------------------------------------------------------------- 1 | ## マージの活用：リベース 2 | 3 | このセクションでは、もう一つの一般的なマージである rebase の活用について説明します。 4 | 5 | ### Gitマージの活用方法 6 | 7 | Gitには3つの主なマージの活用方法があります。 8 | 9 | #### Fast-forward 10 | 11 | fast-forwardのマージは、フィーチャブランチが作成された後に、ベースブランチに変更がないことが前提です。 つまり、ベースブランチのポインタを、単にフィーチャブランチが指しているコミットと同じコミットを指すよう、「fast forward」（早送り）することができます。 12 | 13 | #### 再帰的 14 | 15 | 再帰的マージは、ベースブランチとフィーチャブランチの両方が変更されており、gitが両方を再帰的に結合する必要があるということを意味します。 再帰的なマージでは、2つのブランチが結合された時点に印をつけるため、新しい「マージコミット」が作成されます。 このマージコミットには、複数の親が存在するため特殊です。 16 | 17 | #### タコ足 18 | 19 | 3つ以上のブランチのマージはタコ足マージと言います。 このマージにより、複数の親が存在するマージコミットも作成されます。 20 | 21 | ### Gitリベースについて 22 | 23 | `git rebase` を使うことで、コミット履歴をさまざまな方法で変更できます。 例えば、コミットを並び替えや編集、複数のコミットを1つにsquashすることなど、多数の方法があります。 24 | 25 | 上記の機能を有効とするために、`rebase` にはいくつかの形式が存在します。 今回のクラスでは、インタラクティブリベースを使います。`git rebase --interactive` または `git rebase -i` （ショートカット） 26 | 27 | 通常、`git rebase -i`は以下のように使用します。 28 | 29 | - あるブランチを他のブランチでリプレーする 30 | - 以前のコミットメッセージの編集 31 | - 複数のコミットを1つにまとめる 32 | - 不要になったコミットの打ち消しまたは、削除 33 | 34 | ### 直線的な履歴の作成方法 35 | 36 | リベースの最も一般的な用途の1つは、再帰的なマージをなくし、より直線的な履歴を作成することです。 この課題では、そのやり方を学習します。 37 | 38 | ![Gitリベース](../img/git-rebase.png) 39 | 40 | #### 準備 41 | 42 | 1. はじめに、 `main` ブランチに切替えておきます。 `git switch main` 43 | 1. 最初のコミットのSHAを見つけます。`git log --oneline` 44 | 1. 最初のコミットのSHAにリセットします。`git reset --hard SHA` 45 | 1. 新しいブランチを作成し、そのブランチにチェックアウトします。`git switch -c rebase-me` 46 | 1. reflogを使用し、ファイル4-6を `rebase-me` のブランチにチェリーピックします。 47 | 1. mainブランチに切替えます。`git switch main` 48 | 1. reflogを使用し、ファイル1-3を `main` のブランチにチェリーピックします。 49 | 1. 履歴を確認します。`git log --oneline --graph --decorate --all` 50 | 1. この時点で仮にマージすると、再帰的なマージとなります。 51 | 52 | #### リベースを開始 53 | 54 | 1. `rebase-me` のブランチに切替えます。`git switch rebase-me` 55 | 1. マージを開始します。`git rebase -i main` 56 | 1. テキストエディタが開き、リベースされるコミットが表示されます。 57 | 1. `rebase-todo` を保存し、閉じます。 58 | 1. リベースがコマンドラインで実行されます。 59 | 1. 再度、履歴を確認します。`git log --oneline --graph --decorate --all` 60 | 1. この時点で仮にマージすると、fast-forwardマージとなります。 61 | 62 | #### マージの完了 63 | 64 | 1. マージ先であるmainブランチに切替えます。`git switch main` 65 | 1. 変更をmainにマージします。`git merge rebase-me` 66 | 67 | エイリアスを利用してすべてをクリーンに保つ方法を探しているなら、 Appendix をチェックすることを忘れないで！ 68 | -------------------------------------------------------------------------------- /docs/ja/31_merging_tests.md: -------------------------------------------------------------------------------- 1 | ## マージのテストと`.yml`ファイル 2 | 3 | 継続的インテグレーションを使用する前に、`.yml`ファイルと、このプロジェクトのために作成したテストを追加する必要があります。 4 | 5 | 1. 使用しているCI/CDサービスに応じて、適切なブランチから、`base: main`に`-tests`という名前の Pull Request を作成します。 6 | 2. Pull Request はマージ**しないでください**。 7 | 8 | > `.yml` ファイルを開くと、重要な情報が表示されます。 その情報については、後で詳しく説明します。 それを見てみて、どういう意味だと思いますか？ どんな質問が浮かびますか？ 9 | -------------------------------------------------------------------------------- /docs/ja/32_setting_up_cicd.md: -------------------------------------------------------------------------------- 1 | ## CI/CDの設定 2 | 3 | `github-games`に組み込まれているテストから始めていきましょう。 4 | 5 | 1. CI/CDインテグレーションサイトを開きます。 6 | 2. 新しいアカウントの作成プロンプトか、もしくは、ログインのプロンプトが出たら、GitHub経由で認証をします。 7 | 3. `github-games` のリポジトリを選択し、新しいプロジェクトを追加します。 （*全て*ではなく、適切なリポジトリだけを選択するように注意しましょう。 ） 8 | 9 | まだ何も起きないかと思います。 CI/CD サービスは、コンフィグレーションの情報を含む特別な `.yml` ファイルを探します。 このファイルには、プロジェクトの言語や依存ファイル、実行するテスト、デプロイメントの構築方法の情報が含まれています。 -------------------------------------------------------------------------------- /docs/ja/33_interacting_cicd.md: -------------------------------------------------------------------------------- 1 | ## CI/CDの使い方 2 | 3 | ### ワークフローのレビュー：テストに合格するため、README.mdを更新しましょう 4 | 5 | READMEにあるリンクを、自分のリポジトリのフォークへ飛ぶように更新し、GitHubのフローを最初から練習してみましょう。 6 | 7 | > あなたのウェブサイトは`https://githubschool.github.io/github-games-username`にあります。 8 | > 9 | > このURLにアクセスすると、`README.md` にあるテキストが表示されます。 このリポジトリの修正方法を学習するために、わざとリポジトリを壊しました。 マージするテストでもこのURLを確認します。 10 | 11 | GitHubのフローを練習する前に、自分のリポジトリでGitHub Pagesを有効にし、GitHub PagesのURLを取得する必要があります。 12 | 13 | 1. *Settings*のタブをクリックして、リポジトリの設定にアクセスします。 14 | 2. *Options* のパネルで（デフォルトで開いている）、*GitHub Pages* のセクションまでスクロールします。 15 | 3. *Source* にある*None*のドロップダウンをクリックして、`main branch`を選択します。 16 | 4. *Save* をクリックして、保存します。 17 | 5. 改めてGitHub Pagesのセクションまで下にスクロールすると、新しいテキストボックスに公開サイトのURLが表示されます。 このURLは、後で`README.md` のファイルを変更するために使用します。 18 | 19 | 現在のテストでは、`README.md`にあるURLの正確さを確認します。 GitHubのフローを使用し、URLが**正しくなく** 、失敗するビルドで、Pull Request を作成します。 現在のテストはこちらにあります。`tests/test_verifyurl.rb` 20 | 21 | このセクションの目的は、テストを見て、失敗したビルドのエラーメッセージを解読し、ワークフローを練習することです。 ツールのこんなにも大量のフィードバックを見ると、圧倒されますよね！ もっと深く掘り下げたいのであれば、掘り下げても良いですが、圧倒されてしまったら、まずは修正すべき場所を明確にするために、エラーメッセージを探すことに集中しましょう。 22 | 23 | 1. リポジトリのコピーをクローンします。`git clone https://github.com/githubschool/github-games-USERNAME.git`. 24 | 2. Pull Request にあるブランチにチェックアウトします。`git switch CISERVICE-tests` 25 | 3. テストを*失敗させる*ために、`README.md` のURLを編集します。 26 | 4. ブランチの変更をコミットします。 27 | 5. ブランチをGitHubにプッシュします。`git push` 28 | 6. テストが失敗することを確認します。 29 | 7. 再度ローカルで作業し、テストを*合格させる*ために、URLをリポジトリでGitHub Pagesを有効にしたときのURLに変更します。 変更をコミットします。 30 | 8. ブランチをリモートにプッシュします。 31 | 9. 再度テストを実行します。 合格していない場合は、テストを見てどんな変更が必要かを確認します。 32 | 10. テストが全て合格していたら、Pull Request をマージします。 33 | 11. GitHubのブランチを削除します。 34 | 12. リポジトリのローカルコピーを更新します。`git pull --prune` 35 | 36 | > このブランチに `ruby tests/test_verifyurl.rb` を実行して、このテストをローカルで確認することもできます。 各々のマシンでどのように異なって見えるのかや、外部でテストを実行することでプロセスが円滑になることがポイントです。 *（この方法を使用するためには、ローカルでRubyをインストールする必要があります。）* 37 | -------------------------------------------------------------------------------- /docs/ja/33_workflow_review_with_ci.md: -------------------------------------------------------------------------------- 1 | ## プロジェクト: GitHub Games 2 | 3 | このセクションでは、`github-games` というプロジェクトのリポジトリで作業します。 4 | 5 | `github-games` のリポジトリはすでにgithubschool organizationにて作成してあります。 `https://github.com/githubschool/github-games-username` でアクセスできます。 -------------------------------------------------------------------------------- /docs/ja/34_change_yml.md: -------------------------------------------------------------------------------- 1 | ## `.yml` ファイルの変更 2 | 3 | 先ほどのコースで `.yml` ファイルを `gh-pages` ブランチにマージしましたが、`.yml` ファイルの役割についてはあまり説明しませんでした。 `.yml` ファイルは、継続的インテグレーションのプロバイダが、テスト環境の設定方法と実行するテストを理解するために使用します。 4 | 5 | 既存の `.yml` ファイルを私たちのプロジェクトにマージしたとき、環境設定方法を特定し、READMEとリンクがユーザ名に一致していることを確認するテストを入れました。 6 | 7 | #### `.yml` ファイルに変更を加えましょう 8 | 9 | `/tests` のディレクトリに追加のテストを作成しました。 新しいテストの追加や、それを壊したり、試したりする過程を最初からやってみましょう。 10 | 11 | 1. `tests/` ディレクトリには、新しいテストがいくつかあります。 `tests/test_speedmax.rb` というテストを `.yml` ファイルに追加します。 12 | 2. `gh-pages` に基づいた新しいブランチを作成します。 13 | 3. そのブランチで `.yml` ファイルを開きます。 開いたファイルの中で、URLを確認する他のテストが実行されているのと同じ場所に `tests/test_speedmax.rb` を追加します。 14 | 4. Pull Request を作成します。 15 | 5. 新しいテストの内容を確認します。 どのような機能だと思いますか？ そのテストを実装する理由は？ 他のやり方はあるでしょうか？ どんな場合に合格して、どんな場合に失敗しますか？ 16 | 17 | *注釈：`.yml` ファイルの変更は、コミットされた場合、テストに含まれます。 ファイルをロックすることはできないので、Pull Request で `.yml` ファイルの変更を確認することが重要です。* 18 | 19 | #### スピードテストを壊しましょう 20 | 21 | 1. テストファイルについて持っている知識を使って、テストが失敗するように変更を加えます。 （78行目の `min:` を `0.0` から `1.0` の範囲外の値に変えます。） 22 | 23 | #### 保護されたブランチを有効にしましょう 24 | 25 | 1. テストに失敗していても、Pull Request はマージ*できる*ことを確認します。 26 | 2. 自分のリポジトリで、`Settings` のタブをクリックします。 27 | 3. 左のナビゲーションパネルで `Branches` を選択します。 28 | 4. `Protected Branches` で、`Choose a branch` をクリックして、`gh-pages` を選択します。 29 | 5. `Protect this branch` を選択してから、デフォルトブランチの保護方法を選択します。 30 | 31 | #### スピードテストを修正しましょう 32 | 33 | 1. CI/CDサービスからステータスチェックが返されたら、テストが合格するようにファイルを修正します。 34 | 2. Pull Request をマージします。 -------------------------------------------------------------------------------- /docs/ja/35_circleCI.md: -------------------------------------------------------------------------------- 1 | ## CircleCI 2 | 3 | ### CircleCIのドキュメント 4 | 5 | CircleCIのドキュメントは、[circleci.com で見ることができます ](https://circleci.com/docs/)。 6 | 7 | ### サポート 8 | 9 | CircleCIの[コミュニティフォーラム](https://discuss.circleci.com/)は全てのユーザが利用可能で、[Premium Support](https://circleci.com/support/premium-support/)は、それ以上を求めているチームが利用できます。 -------------------------------------------------------------------------------- /docs/ja/35_travisCI.md: -------------------------------------------------------------------------------- 1 | ## Travis CI 2 | 3 | ### Travis CIのドキュメント 4 | 5 | Travis CIのドキュメントは [travis-ci.org](https://docs.travis-ci.com/) で見ることができます。 6 | 7 | ### `travis.yml` 8 | 9 | `travis.yml` ファイルで可能なコンフィグレーションの全ての設定を見るには、[このURLにアクセスしてください](https://githubteacher.github.io/travis-ci) 。 *注釈：Travis CI は、このリソースを保守していません。 最新情報については、docs.travis-ci.comを参照してください。* 10 | 11 | ### サポート 12 | 13 | `support@travis-ci.com` にてTravisのサポートにお問い合わせください。 -------------------------------------------------------------------------------- /docs/ja/35_understanding_yml.md: -------------------------------------------------------------------------------- 1 | ## `.yml`ファイルを理解する 2 | 3 | 前のセクションでは、`.yml` ファイルに変更を加えましたが、その具体的な機能と意味はなんでしょうか？ 4 | 5 | プロジェクトをテストするには、CIサービスプロバイダーが、コードに実行するテスト及び、テストされるビルド環境の仕様情報を知る必要があります。 設定をコードから自動的に察知できるプロバイダもあれば、詳細な仕様が必要なプロバイダもあります。 上記の仕様は、`.yml` ファイルに保存されており、プロジェクトの他の部分と同様に、バージョン管理下に置かれます。 6 | 7 | ![YAMLファイルのビジュアルダイアグラム](../img/yaml.png) 8 | 9 | `.yml` ファイルは、3つの主要な部分を持つ、To Doリストのようなものです。 10 | 11 | - 環境のセットアップ 12 | - テスト実行 13 | - デプロイメント 14 | 15 | 他にも、上記の主要な部分の一部として、さまざまなステップがあります。 ビルドの前やその一部として、もしくは、ビルドとテストのアウトプットや結果に基づいて実行したいスクリプトがあれば、それも可能です。 `.yml` ファイルの内容は、サービスプロバイダによって異なるので、`.yml` を作成するときに、各プロバイダのドキュメントを参照すると良いです。 16 | 17 | > 注釈：私たちが使用する例は比較的単純ですが、テスト環境の機能性はこれらの例よりもはるかに深いものになります。 テスト環境の目的は、できる限りプロダクション環境に近づけてテストすることです。 可能性は無限大です。複数のバージョンや言語、環境とマシーンをテストしたければ、全て可能です！ 前述したとおり、.yml ファイルの扱いは各 CI ベンダによって異なるので、テストを行う `.yml` ファイルを作成するときは、そのプロバイダのドキュメントを参照しましょう。 18 | -------------------------------------------------------------------------------- /docs/ja/37_partner_activity.md: -------------------------------------------------------------------------------- 1 | ## パートナー課題：失敗する Pull Request を作成 2 | 3 | この課題では、パートナーと一緒に作業します。 課題を円滑にするため、`Partner A` 及び `Partner B` を示すことで指示を分けます。 パートナーと話し合って、それぞれの役割を決めましょう。 4 | 5 | #### `PARTNER A` ：壊れているビルドを作成しましょう 6 | 7 | - 以下のコマンドを使って、パートナーのリポジトリへの参照を追加します。 8 | - `git remote add ` 9 | - 例：`git remote add partner https://github.com/githubteacher/github-games` 10 | - パートナーのプロジェクトで、`.yml` ファイルを調べます。 テストに基づいて、Pull Request が失敗するコードはなんでしょうか？ 11 | - GitHubのフローに従って、パートナーのリポジトリでテストが失敗するようなコミットを導入する Pull Request を開きます。 12 | 13 | #### `PARTNER B`： 失敗するビルドに対応しましょう 14 | 15 | - 自分のリポジトリでパートナーが開いた Pull Request を探します。 ビルドステータスが失敗となっているはずです。 16 | - 失敗しているビルドのアウトプットを使って、ビルドが失敗する原因を突き止めます。 17 | - ビルドが合格するための提案を含めて変更を要求して、 Pull Request を正式にレビューします。 18 | 19 | #### `PARTNER A` ：壊れているビルドを修正しましょう 20 | 21 | - パートナーが Pull Request をレビューした後、提案内容の変更をします。（提案内容に同意していなくても） 22 | 23 | #### `PARTNER B`： 成功したビルドをマージしましょう 24 | 25 | - ビルドが合格したら、Pull Request をマージしてお祝いしましょう！ :tada: -------------------------------------------------------------------------------- /docs/ja/App_a_workflow_guide.md: -------------------------------------------------------------------------------- 1 | ## チームの作業フローのためのディスカッションガイド 2 | 3 | 理想的な作業手順を確立するために、チームで議論すべき論点は次のとおりです。 4 | 5 | 1. どのようにブランチを活用するのか？ 6 | 2. どのブランチを、main、または、デプロイされたコードとして機能させるのか？ 7 | 3. ブランチの名前を規則的に付けていくのか？ 8 | 4. labels（ラベル）とassignees（アサインされた人）をどのように活用するのか？ 9 | 5. マイルストーンを設定するのか？ 10 | 6. IssueやPull Requestで必須要素を設けるのか？（例）シッピングのチェックリスト 11 | 7. Pull Requestでサインオフをどのように表すのか？ 12 | 8. 誰がPull Requestをマージするのか？ 13 | -------------------------------------------------------------------------------- /docs/ja/App_b_learn_more_api.md: -------------------------------------------------------------------------------- 1 | ## 追加学習：GitHub API 2 | 3 | - [GitHub API開発者向けドキュメント](https://developer.github.com/v3/) 4 | - [ GitHub APIガイド](https://developer.github.com/guides/) GitHub API を使用するのに有用な、優れたプロジェクト -------------------------------------------------------------------------------- /docs/ja/App_clean_loaner_pc.md: -------------------------------------------------------------------------------- 1 | ## 借りたパソコンから履歴を削除 2 | 3 | このクラスのためにノートパソコンを借りた場合やクラスの仮想マシンを使用した場合、返却前に設定と資格情報を元に戻しましょう。 方法は次のとおりです。 4 | 5 | ### ステップ1：config設定の削除 6 | 7 | 1. `git config --unset --global user.name` 8 | 2. `git config --unset --global user.email` 9 | 10 | ### Step 2: コマンドライン履歴の削除 11 | 12 | - **Bash:** `history -c && history -w && exit` 13 | - **Windowsコマンドプロンプト:** Alt+F7 14 | 15 | ### ステップ3：資格情報マネージャで削除 16 | 17 | **Windowsの場合** 18 | 19 | 1. **スタート**メニューから、**コントロールパネル**を選択 20 | 2. **ユーザアカウント**をクリック 21 | 3. **資格情報の管理**をクリック 22 | 4. **資格情報マネージャー**をクリック 23 | 5. Windows資格情報および汎用資格情報のGitとGitHubを参照する全ての資格情報を削除 24 | 25 | **Macの場合** 26 | 27 | 1. **キーチェーンアクセス**を開く 28 | 2. GitHubに関する全ての情報を削除 -------------------------------------------------------------------------------- /docs/ja/README.md: -------------------------------------------------------------------------------- 1 | ## 開発者向けのGitHubへようこそ 2 | 3 | > 注：本書は更新版のマニュアルであり、新しいカリキュラムにおける学習内容が記載されています。 [旧版のトレーニングマニュアル](https://githubtraining.github.io/training-manual/legacy-manual.pdf)はこちらです。 4 | 5 | 本マニュアルのPDF（英語）は、[こちら](../book.pdf)からダウンロードできます。 6 | 7 | 今日は、GitとGitHubの使い方を学習する、エキサイティングな新しいアドベンチャーに取り組みます。 8 | 9 | 今日の教材を進めていく中で、あなたのためのクラス！であることを、心に留めておいてください。 クラスの進行にあわせて、作業を試し、たくさん質問してください。 10 | 11 | ### ライセンス 12 | 13 | このリポジトリにある教材一式の練習問題、講義テキスト、スライドレイアウト、クラス構成、図表、HTML、CSSやmarkdownコードは、[CC（クリエイティブ・コモンズ） BY 4.0](http://creativecommons.org/licenses/by/4.0/legalcode)としてライセンスされたものです。 オクタキャット、GitHubロゴ、ならびに、既に著作権で保護され、登録されている商標および画像は、このライセンスの対象ではありません。 14 | 15 | 詳細については、 をご覧ください。 16 | -------------------------------------------------------------------------------- /docs/ja/_sidebar.md: -------------------------------------------------------------------------------- 1 | - はじめに 2 | 3 | - [クラスの受講準備](ja/01_getting_ready_for_class.md) 4 | - [はじめに](ja/02_getting_started.md) 5 | - [GitHubのフロー](ja/03_github_flow.md) 6 | 7 | - プロジェクト１：キャプション 8 | 9 | - [GitでBranching（ブランチ作成）](ja/04_branching_with_git.md) 10 | - [ローカルのGit設定](ja/05_local_git_configs.md) 11 | - [ローカルでの作業](ja/06_working_locally.md) 12 | - [コードについてのコラボレーション](ja/07_collaborating_on_code.md) 13 | - [GitHubでのファイル編集](ja/08_edit_on_github.md) 14 | - [Pull Requestのマージ](ja/09_merging_pull_requests.md) 15 | - [ローカル履歴](ja/10_local_history.md) 16 | - [エイリアスによる作業フローの効率化](ja/11_streamline_workflow_with_aliases.md) 17 | 18 | - プロジェクト２：マージコンフリクト 19 | 20 | - [マージコンフリクトの定義](ja/12a_what_is_a_merge_conflict.md) 21 | - [マージコンフリクトの解決](ja/12b_resolving_merge_conflicts.md) 22 | 23 | - プロジェクト３：GitHubゲーム 24 | 25 | - [作業フローのレビュー](ja/13_workflow_review_project_github_games.md) 26 | - [保護されたブランチとCODEOWNERS](ja/17_protected_branches.md) 27 | - [Git Bisect](ja/14_git_bisect.md) 28 | - [コミットの打ち消し](ja/15_reverting_commits.md) 29 | - [役に立つGitのコマンド](ja/16_helpful_git_commands.md) 30 | - [ローカル変更の表示](ja/17_view_local_changes.md) 31 | - [タグとリリース](ja/17_tags_and_releases.md) 32 | - [作業フローディスカッション](ja/17_workflow_discussion.md) 33 | 34 | - プロジェクト４：ローカルリポジトリ 35 | 36 | - [ローカルでのリポジトリ作成](ja/18_create_local_repo.md) 37 | - [コミットの誤りの修正](ja/19_fixing_commit_mistakes.md) 38 | - [ブランチを切り替え忘れた？](ja/19_forgot_to_branch.md) 39 | - [Git Resetによる履歴の書き換え](ja/20_rewriting_history_git_reset.md) 40 | - [チェリーピックとは](ja/21_git_cherry_pick.md) 41 | - [マージ方法](ja/22_merge_strategies_rebase.md) 42 | 43 | - Advanced Topics 44 | - [Personal Access Tokens](20_personal_access_token.md) 45 | - [GitHub Actions](17_github_actions.md) 46 | - [Automate Releases](17_actions_activity.md) 47 | - [.gitignore File](23_gitignore.md) 48 | - [Commit signature verification](24_commit_sig_verification.md) 49 | - [Git Stash](25_git_stash.md) 50 | - [Git LFS](26_git_lfs.md) 51 | - [Git submodules](27_git_submodules.md) 52 | - [Git subtrees](28_git_subtrees.md) 53 | 54 | - Appendix 55 | - **GitHub Resources** 56 | - [１日目の実習手順](ja/app_Day_1_activities.md) 57 | - [２日目の実習手順](ja/app_day2_mergeconflict.md) 58 | - [フォークとプルの作業フロー、および、マルチプルリモート](ja/app_fork_workflow.md) 59 | - [トレーニングの終わりに（借りたパソコン上の履歴削除）](ja/App_clean_loaner_pc.md) 60 | - **Tool tips** 61 | - [Add your human-readable name](app_add_human_readable_name.md) 62 | - [Jekyllサイトをローカルで生成する方法](ja/app_how_to_generate_locally.md) 63 | - [ターミナルプロンプトへのブランチ追加](ja/app_git_branch_in_terminal.md) 64 | - [Alias Pro Tips](app_aliases.md) 65 | - [Vi Basics](app_vi_basics.md) 66 | - **Community Resources** 67 | - [GitHub Events](app_github_events.md) 68 | - [Plan an event](app_plan_an_event.md) 69 | - [Facilitating workflow conversations](app_facilitating_workflow.md) 70 | - [Case studies](app_case_studies.md) 71 | - [Prepare for being an ambassador](app_evangelize.md) 72 | - [Issue templates](app_issue_template.md) 73 | - [Supporting Learning Lab](app_supporting_learning_lab.md) 74 | - **Teaching Resources** 75 | - [GitHub Training Scripts](app_teaching_script.md) 76 | - [Teachback: Prepare repositories](app_teachback_repo_prep.md) 77 | - [Teacher/Facilitation Tips](app_facilitation_tips.md) 78 | - [Authentication Troubleshooting Guide](app_authentication.md) 79 | 80 | - 付属資料 81 | - [作業フローガイド](ja/App_a_workflow_guide.md) 82 | -------------------------------------------------------------------------------- /docs/ja/app_Day_1_activities.md: -------------------------------------------------------------------------------- 1 | ## 1日目の実習 2 | 3 | ### 新しいスライドを追加する 4 | 5 | クラスで作業したように、デッキに新規スライドを追加するために新規Pull Requestを行います。 6 | 7 | 1. 新しいブランチを作成し、そのブランチにチェックアウトします。`git switch -c NEWBRANCHNAME（新規ブランチ名）` 8 | 2. `_posts`ディレクトリに新しいファイルを作成する。そのファイル名は、YYYY-MM-DD-username-description.md （年-月-日-ユーザ名-ファイル内容）のようにする。 (日付は、過去の日付でなければならず、将来の日付は表示されません。) 9 | 3. "[Activity: Edit Your File](https://githubtraining.github.io/training-manual/#/ja/06_working_locally)"にある、一緒に作成した同じ実習の指示に従います。 10 | 4. キャプションをただ追加するのではなく、イメージリストから新しいイメージを見つけ、テンプレートへの入力に使用します。 ``` \--- layout: slide \--- 11 | 12 | IMAGEURL 13 | {: .center} 14 | 15 | CAPTION-HERE 16 | {: .fragment} 17 | ``` 18 | 19 | 5. 新規ブランチに変更を保存してコミットします。 20 | 21 | 6. ローカルで作業している場合は、リモートに変更をプッシュします。`git push -u origin NEWBRANCHNAME`. 22 | 7. Pull Requestを開きます。Pull Requestの本文で、変更をレビューしてもらいたい人に、@メンションします。 23 | 8. Pull Requestがテストに合格したら、Pull Requestをマージします。 24 | 25 | ### 既存のスライドにキャプションを追加する 26 | 27 | 他のユーザのPull Requestにある既存のスライドにキャプションを追加する。 28 | 29 | 1. キャプションを追加したいPull Requestを見つけます。 30 | 2. 「files changed」をクリックして他のユーザが選択したイメージを確認し、次に「view」をクリックします。 31 | 3. キャプションを追加するために、ブラウザーまたはローカルでファイルを編集します。 （他の人がこのファイルに追加した作業は消去しないでください。） 32 | - ローカルで作業している場合は、ブランチにチェックアウトする必要があります。 33 | - ローカルのリポジトリにリモートの変更がすべて反映されていることを確認します。` git pull ` 34 | - Pull Requestにあるブランチ名を探し、ローカルでそのブランチにチェックアウトします。`git switch BRANCHNAME` 35 | 4. 変更を保存し、ファイルをコミットします。 36 | - ローカルで作業している場合は、変更内容をリモートにプッシュします。` git push ` 37 | 5. Pull Requestをマージしないでください。 `@`メンションでPull Requestを作成したユーザに変更を知らせます。 38 | 39 | ### `README.md`を改善する 40 | 41 | お好みのリソースを加えて、 `README.md`を改善しましょう。 42 | 43 | 1. 新しいブランチを作成し、そのブランチにチェックアウトします。`git switch -c NEWBRANCHNAME（新規ブランチ名）` 44 | 2. 何らかの方法で、README.mdを改善します。 改善方法は、新しいリソースの追加や、既存の説明内容の明確化などです。 変更を保存してコミットします。 45 | 3. ローカルで作業している場合は、リモートに変更をプッシュします。`git push -u origin NEWBRANCHNAME（新規ブランチ名）`. 46 | 4. Pull Requestを作成します。Pull Requestの本文には、`base: main` と `compare: NEWBRANCHNAME（新規ブランチ名）`　を記載します。 47 | 5. `@` mention（メンション）を使って、変更をレビューしてもらいたい人に知らせます。 48 | 6. Pull Requestの内容がテストに合格したら、そのPull Requestをマージします。 49 | 50 | ### スライドのスタイル変更 51 | 52 | 高度なチャレンジに取り組みたい場合や、スタイル編集に自信がある場合、クラスのスライドデッキの色、フォントや他の要素を変更してみましょう。 **注：複数の参加者が試すと、マージコンフリクトが発生するおそれがあります。** 53 | 54 | 1. 新しいブランチを作成し、そのブランチにチェックアウトします。`git switch -c NEWBRANCHNAME（新規ブランチ名）` 55 | 2. 次のファイルを探します。`_sass / solarized / solarized.scss` 56 | 3. ファイルに変更を加えます。 57 | - 12〜19行目は、色に影響します。 58 | - 33〜35行目は、フォントとフォントサイズに影響します。 59 | - 52〜55行目は、ヘッダの色に影響します 60 | 4. ブランチに変更を保存してコミットします。 61 | 5. ブランチをリモートにプッシュします。` git push -u origin NEWBRANCHNAME（新規ブランチ名） ` 62 | 6. `base: main`と`compare: NEWBRANCHNAME（新規ブランチ名）`で、Pull Requestを開きます。 63 | 7. `@` mention（メンション）を使って、変更をレビューしてもらいたい人に知らせます。 64 | 8. Pull Requestの内容がテストに合格したら、そのPull Requestをマージします。 65 | -------------------------------------------------------------------------------- /docs/ja/app_day2_mergeconflict.md: -------------------------------------------------------------------------------- 1 | ## ２日目の実習 2 | 3 | ### マージコンフリクトに関する実習 4 | 5 | 本マニュアルを用いた学習方法は人それぞれですが、現在、クラスを受講されている方もいらっしゃると思います。 インストラクターが、マージコンフリクトに関する実習のためにリポジトリを設定した場合は、 6 | 7 | - *受講者全員*に、各自のリポジトリがあります。 自分のリポジトリのマージコンフリクトを修正してください。 実際のユーザ名を使用して、`github.com/githubschool/conflict-practice-username`　で呼び出すことができます。 8 | - 宿題として提出いただくものではありませんが、あとで修正作業が完了したかどうかを確認するスクリプトを実行します。 :wink: 9 | 10 | ### コンフリクトのリポジトリのマージコンフリクトの解決手順 11 | 12 | 1. 自分のリポジトリを、こちらで探してください。 `github.com/githubschool/USERNAME`　のUSERNAMEを自分のユーザ名に置き換えてください。 13 | 2. 自分のリポジトリで、**Pull Requests**のタブに移動してください。 14 | 3. ３つのPull Requestがあり、そのすべてに修正すべきマージコンフリクトがあります。 次の順序で修正することをおすすめします。 15 | - READMEの更新 16 | - ゲームマニュアルの更新 17 | - 些細なCSSの修正 18 | 4. Pull Requestを表示させ、マージコンフリクトの処理手順に従います。 マージコンフリクトが解決したら、Pull Requestをマージします。 -------------------------------------------------------------------------------- /docs/ja/app_fork_workflow.md: -------------------------------------------------------------------------------- 1 | ## フォークとプルの作業フロー 2 | 3 | Gitの使用言語を区別し、フォークに関する共通の作業フローを論じてみましょう。 4 | 5 | 通常、下の写真のように１つの親リポジトリから作業を開始します。 これを、 **親**（parent）リポジトリと呼びます。ですが、*どのように*作業するかによって、別の名前で呼ぶこともあります。 6 | 7 | 例えば、パソコン上にローカルコピーを作成することで、リポジトリを**クローン**（clone）する場合は、そのオリジナルのリモートリポジトリを **origin**と表します。 8 | 9 | ブランチは、ローカルの**クローン**で作成でき、 *かつ*、リモートの**origin**で作成できます。 10 | 11 | ![クローン対ブランチ対フォーク](../img/clone-branch-fork.png) 12 | 13 | フォークについては、話が少し複雑になります。 **フォーク**（fork）は、別のオーナーのリポジトリのリモートコピーです。 新しいリモート**フォーク**があるとき、親リモートを**上流**（upstream）と表します。 14 | 15 | ![フォークの作業フロー](../img/origin-upstream.png) 16 | 17 | フォークをクローンした場合は、自分のフォークを**origin**と表し 、親を**上流**と表します。 18 | 19 | ![フォークの作業フロー](../img/fork-from.png) 20 | 21 | **origin**または**上流**のリポジトリに作業内容を戻したい場合は、**origin**にプッシュし、リモートフォーク間のPull Requestを開きます。 22 | 23 | ![フォークの作業フロー](../img/fork-to.png) 24 | -------------------------------------------------------------------------------- /docs/ja/app_git_branch_in_terminal.md: -------------------------------------------------------------------------------- 1 | ## ターミナルのプロンプトにGitのブランチを追加する 2 | 3 | ターミナルのプロンプトにアクティブなGitのブランチを表示するためには、次のことを行う必要があります。 4 | 5 | - **Mac**の場合、`.bash_profile`に以下のコードを追加します。 6 | - **Linux**の場合、`.bashrc`に以下のコードを追加します。 7 | - **Windows**の場合、デフォルトでこの機能が用意されているため、おそらくこの文章を読んではいないでしょう。 8 | 9 | ### スクリプト 10 | 11 | ```shell 12 | parse_git_branch() { 13 | git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/' 14 | } 15 | export PS1="\w\[\033[36m\]\$(parse_git_branch) \[\033[00m\] > " 16 | ``` 17 | 18 | 別のオプション 19 | 20 | ```shell 21 | function parse_git_branch () { 22 | git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/' 23 | } 24 | 25 | RED="\[\033[0;31m\]" 26 | YELLOW="\[\033[0;33m\]" 27 | GREEN="\[\033[0;32m\]" 28 | NO_COLOR="\[\033[0m\]" 29 | 30 | PS1="$GREEN\u@\h$NO_COLOR:\w$YELLOW\$(parse_git_branch)$NO_COLOR\$ " 31 | ``` -------------------------------------------------------------------------------- /docs/ja/app_how_to_generate_locally.md: -------------------------------------------------------------------------------- 1 | ## Jekyllサイトをローカルで生成する方法 2 | 3 | ### 作業開始にあたって 4 | 5 | クラスで使用するリポジトリはGitHub Pagesによってデプロイされるため、ローカルでの提供は*必要*ありません。 しかし、実際にデフォルトのブランチにプッシュする前に、変更がローカルでどのように表示されるかを確認したい場合は、これを行うことができます。 6 | 7 | 作業の難度はOSによって異なりますが、macOSの方がスムーズに行えます。 すべてのプラットフォームにおける手順の改善に努めていますので、提案がありましたらご教示ください。 8 | 9 | このスクリプトは、Rubyを使用します。 Rubyをローカルにインストールしていない場合は、[ruby-lang.org上の詳細な手順](https://www.ruby-lang.org/en/documentation/installation/)に、従ってください。 要約すると、 10 | 11 | - Windowsでは、 から、バージョン`2.3.3`を選択することでインストールできます。セットアップ中に「Add Ruby executables to your PATH」を選択し、その後マシンを再起動してください。 12 | - MacにRubyをインストールする必要がある場合は、[Homebrew](https://brew.sh)をインストールし、その後 `brew install ruby​​`を実行します。 13 | 14 | ### ローカルでの生成 15 | 16 | 1. Bashのようなターミナルを使って、ローカルのクラスのリポジトリに`cd`（移動）します。 17 | 2. Rubyがインストールされていることを確認します。 18 | - コマンドラインで、`ruby -v` と `gem -v` を実行します。 19 | - Rubyのバージョン`2.3.x`が表示されている場合 、あなたは👍です。 そうでない場合は、上記の指示を参照してください。☝️ 20 | 3. `Gemfile.lock`がある場合、削除する。 21 | 4. Bundlerをインストールします。`gem install bundler` 22 | 5. 適切なgemsのすべてをインストールするために、`script/setup`を入力します。 23 | 6. 次に、`script/server`と入力します。 24 | 7. すべての作業が成功した場合、ターミナルが、ブラウザ上のサイトにアクセスする場所を教えてくれます。🎉 25 | -------------------------------------------------------------------------------- /docs/ja/index.md: -------------------------------------------------------------------------------- 1 | ## インデックス -------------------------------------------------------------------------------- /docs/ja/preparing_to_teach_github_for_developers.md: -------------------------------------------------------------------------------- 1 | ## 講義の準備 2 | 3 | 開発者のためのGitHubは、コマンドラインに慣れているGitとGitHubの新規ユーザを対象としています。 クラスの準備作業として、次のステップを完了してください。 4 | 5 | 1. `githubteacher`アカウントに、クラス用リポジトリを作成する。 6 | 2. `github-games`リポジトリのgithubteacherコピーを削除する。 -------------------------------------------------------------------------------- /docs/ja/preparing_to_teach_gitonly.md: -------------------------------------------------------------------------------- 1 | ## 講義の準備 2 | 3 | Gitエッセンシャルは、コマンドラインに慣れているGitとGitHubの新規ユーザを対象としています。 クラスの準備作業として、次のステップを完了してください。 4 | 5 | 1. `githubteacher` アカウントに、クラス用リポジトリを作成する。 6 | 2. `github-games`リポジトリのgithubteacherコピーを削除する。 -------------------------------------------------------------------------------- /docs/ja/toc.md: -------------------------------------------------------------------------------- 1 | ### ライセンス 2 | 3 | このリポジトリにある教材一式の練習問題、講義テキスト、スライドレイアウト、クラス構成、図表、HTML、CSSやmarkdownコードは、[CC（クリエイティブ・コモンズ） BY 4.0](http://creativecommons.org/licenses/by/4.0/legalcode)としてライセンスされたものです。 オクタキャット、GitHubロゴ、ならびに、既に著作権で保護され、登録されている商標および画像は、このライセンスの対象ではありません。 4 | 5 | 詳細については、http://creativecommons.org/licenses/by/4.0/ をご覧ください。 -------------------------------------------------------------------------------- /docs/legacy-manual.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/githubtraining/training-manual/b693a6840453717b880cdaa6736dd712bdb84abf/docs/legacy-manual.pdf -------------------------------------------------------------------------------- /practice-repos/caption-this/issue_1.md: -------------------------------------------------------------------------------- 1 | ## Comment below to be added as a collaborator 2 | 3 | We will all be using this repository today. Even though it's public right now, you will not be able to make changes until you're given the correct permissions. We've automated this process via the GitHub API. Once you comment, we will add you as a collaborator. 4 | 5 | You'll start to receive a lot of emails. (❗) You can slow these down immediately by clicking the **Unwatch** button at the top of the page and selecting either the **Participating and @mentions** or **Ignore** option. 6 | -------------------------------------------------------------------------------- /practice-repos/conflict-practice/pull_request_1.md: -------------------------------------------------------------------------------- 1 | This pull request edits the wording of some language on the main page. It appears that it has also been edited on main, because there's a merge conflict. Please make sure that all the words are the ones that you'd like to use, and that there aren't any lines of text missing. 2 | 3 | If you need any help resolving this conflict, check out this video: 4 | 5 | 6 | -------------------------------------------------------------------------------- /practice-repos/conflict-practice/pull_request_2.md: -------------------------------------------------------------------------------- 1 | This pull request makes some small changes to the CSS. Pick the CSS that you think makes the most sense given the history of the file on both branches and resolve the merge conflict. 2 | 3 | If you need any help resolving this conflict, check out this video: 4 | 5 | 6 | -------------------------------------------------------------------------------- /practice-repos/conflict-practice/pull_request_3.md: -------------------------------------------------------------------------------- 1 | This pull request updates the README.md. Resolve the merge conflicts and make sure the final version of the README.md is accurate and descriptive. 2 | 3 | If you need any help resolving this conflict, check out this video: 4 | 5 | 6 | -------------------------------------------------------------------------------- /practice-repos/github-games/issue_1.md: -------------------------------------------------------------------------------- 1 | When attempting to access this at ${pages_url}, I am getting a 404. This could be caused by a couple of things: 2 | 3 | - GitHub Pages needs to be enabled on the ${default_branch} branch. You can fix this in the repository settings. 4 | - The **index.html** file is incorrectly named **inde.html**. We will fix this together in class. 5 | 6 | Can you fix the first bullet, please? 7 | -------------------------------------------------------------------------------- /practice-repos/github-games/issue_2.md: -------------------------------------------------------------------------------- 1 | The URL in the repository description and README are pointing to ${CLASS_ORG}'s copy of the game instead of yours. 2 | 3 | Please fix both, so they point to your copy of the game at ${pages_url}. 4 | -------------------------------------------------------------------------------- /script/ask: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | # 3 | # Ask (https://djm.me/ask) 4 | 5 | # This is a general-purpose function to ask yes/no questions in Bash, either 6 | # with or without a default answer. It keeps repeating the question until it 7 | # gets a valid answer. 8 | 9 | # color variables 10 | yellow=$(tput setaf 3) 11 | reset=$(tput sgr0) 12 | 13 | function ask() { 14 | local prompt default reply 15 | 16 | if [ "${2:-}" = "Y" ]; then 17 | prompt="Y/n" 18 | default=Y 19 | elif [ "${2:-}" = "N" ]; then 20 | prompt="y/N" 21 | default=N 22 | else 23 | prompt="y/n" 24 | default= 25 | fi 26 | 27 | while true; do 28 | 29 | # Ask the question (not using "read -p" as it uses stderr not stdout) 30 | echo -ne "${yellow}$1 [$prompt] ${reset}" 31 | 32 | # Read the answer (use /dev/tty in case stdin is redirected from somewhere else) 33 | read -r reply /dev/null; then 10 | echo "Installing Homebrew..." 11 | /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 12 | fi 13 | package_manager="Homebrew" 14 | elif type apt &>/dev/null; then 15 | package_manager="APT" 16 | else 17 | package_manager="Unknown" 18 | fi 19 | } 20 | 21 | determine_package_manager 22 | 23 | # Check if docsify-cli is installed globally (and install it if not) 24 | if ! npm list -g docsify-cli &>/dev/null; then 25 | echo "Installing docsify-cli..." 26 | npm install -g docsify-cli 27 | fi 28 | 29 | # Check if jq is installed (and install it if not) 30 | if ! type -p jq &>/dev/null; then 31 | echo "Installing jq..." 32 | case $package_manager in 33 | "Homebrew") brew install jq ;; 34 | "APT") apt install jq ;; 35 | *) echo "Unable to install jq. Please install and try again." && exit 1 ;; 36 | esac 37 | fi 38 | 39 | # Check if HTTPie is installed (and install it if not) 40 | if ! type -p http &>/dev/null; then 41 | echo "Installing HTTPie..." 42 | case $package_manager in 43 | "Homebrew") brew install httpie ;; 44 | "APT") apt install httpie ;; 45 | "Unknown") # Use the universal installation method (https://httpie.io/docs#installation) 46 | # Make sure we have an up-to-date version of pip and setuptools 47 | python -m pip install --upgrade pip setuptools 48 | # Install HTTPie 49 | python -m pip install --upgrade httpie 50 | # If HTTPie installation is unsuccessful using the method above, try the following: 51 | # Attempt #1: Install without multidict compilation 52 | type -p http &>/dev/null || MULTIDICT_NO_EXTENSIONS=1 python -m pip install --no-cache-dir httpie 53 | # Attempt #2: Install older version that does not require multidict 54 | type -p http &>/dev/null || python -m pip install httpie==2.6.0 55 | ;; 56 | *) echo "Unable to install HTTPie. Please install and try again." && exit 1 ;; 57 | esac 58 | fi 59 | 60 | # Load the error code 61 | ERROR_CODE=$? 62 | 63 | # Check the shell for errors 64 | if [ $ERROR_CODE -eq 0 ]; then 65 | # Success 66 | echo "Bootstrap successful!" 67 | else 68 | # Failure 69 | echo "Error! Failed to bootstrap." 70 | exit 1 71 | fi 72 | -------------------------------------------------------------------------------- /script/clean-up-class: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | # 3 | # Deletes practice repos associated with a given day 1 repo 4 | 5 | # shellcheck disable=SC1091 6 | source "$HOME/.trainingmanualrc" 7 | 8 | # shellcheck source=script/shared_functions 9 | source ./shared_functions 10 | 11 | ################################################################# 12 | # NOTE: You must have a personal access token (PAT) # 13 | # saved to your environment variables to use this script. # 14 | # We recommend a dedicated service account (e.g. githubteacher) # 15 | ################################################################# 16 | 17 | # shell variables 18 | collab_repo=$1 19 | org_url="https://$TOKEN_OWNER:$TEACHER_PAT@$ROOT_URL/$CLASS_ORG" 20 | org_repos_endpoint="https://$INSTANCE_URL/repos/$CLASS_ORG" 21 | 22 | delete_repos() { 23 | for username in "${collaborators[@]:?}"; do 24 | # Clean up conflict and games repos for the user 25 | delete_repo "conflict-practice" "$username" 26 | delete_repo "github-games" "$username" 27 | done 28 | } 29 | 30 | delete_repo() { 31 | practice_repo_name=$1 32 | student=$2 33 | 34 | if repo_is_reachable "$org_url/$practice_repo_name-$student"; then 35 | echo "Deleting $practice_repo_name-$student... " 36 | # delete the existing practice repo 37 | http --auth "$TOKEN_OWNER:$TEACHER_PAT" \ 38 | DELETE "$org_repos_endpoint/$practice_repo_name-$student" >>log.out 2>&1 39 | fi 40 | } 41 | 42 | get_collaborators "$collab_repo" 43 | 44 | delete_repos 45 | -------------------------------------------------------------------------------- /script/expire-repo: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | # 3 | # Expire Repo 4 | 5 | # shellcheck disable=SC1091 6 | source "$HOME/.trainingmanualrc" 7 | 8 | ################################################################# 9 | # NOTE: You must have a personal access token (PAT) # 10 | # saved to your environment variables to use this script. # 11 | # We recommend a dedicated service account (e.g. githubteacher) # 12 | ################################################################# 13 | 14 | function GetPages() { 15 | # Get the number of pages 16 | # shellcheck disable=SC1102 17 | NUM_PAGES=$( (curl -s -S -I -H "Authorization: token $TEACHER_PAT" -X GET "https://$INSTANCE_URL/orgs/$CLASS_ORG/repos" | grep "^Link:") | (sed -n 's/.*=\([0-9]*\)>; rel=\"last\".*/\1/p')) 18 | 19 | # Check the return 20 | if [ -z "$NUM_PAGES" ]; then 21 | NUM_PAGES=1 22 | echo "There is only $NUM_PAGES page" 23 | else 24 | echo "There are $NUM_PAGES pages" 25 | fi 26 | 27 | # Go through the pages 28 | while [ $NUM_PAGES -gt 0 ]; do 29 | echo "Getting results for page $NUM_PAGES" 30 | # Get the repos 31 | GetRepos "$NUM_PAGES" 32 | ((NUM_PAGES = NUM_PAGES - 1)) 33 | 34 | done 35 | } 36 | 37 | function GetRepos() { 38 | # Read in the page number 39 | PAGE_NUM=$1 40 | 41 | # get repos in $CLASS_ORG org that start with conflict-practice or github-games 42 | REPO_LIST=$(curl -s -S -H "Authorization: token $TEACHER_PAT" -X GET "https://$INSTANCE_URL/orgs/$CLASS_ORG/repos?page=$PAGE_NUM" | jq '.[] | .name') 43 | for i in "${REPO_LIST[@]}"; do 44 | i=$(echo "$i" | (sed -e 's/^"//' -e 's/"$//')) 45 | if echo "$i" | grep -iq -e "conflict-practice-" -e "github-games-"; then 46 | echo "Let's see when $i was created" 47 | # Get the date 48 | CheckDates "$i" 49 | fi 50 | done 51 | } 52 | 53 | function CheckDates() { 54 | # Pull in the vars 55 | REPO_NAME=$1 56 | 57 | # Get created time 58 | # shellcheck disable=SC1102 59 | CREATED=$( (curl -s -S -H "Authorization: token $TEACHER_PAT" -X GET "https://$INSTANCE_URL/repos/$CLASS_ORG/$REPO_NAME" | jq .created_at) | (sed -e 's/^"//' -e 's/Z"$//')) >>log.out 2>&1 60 | 61 | # if they were created more than 10 days ago, expire them 62 | if [[ "$COMP_DATE" > "$CREATED" ]]; then 63 | echo "EXPIRED: $REPO_NAME was created on $CREATED" 64 | BeNice "$REPO_NAME" 65 | else 66 | echo "KEEP: $REPO_NAME was created on $CREATED" 67 | fi 68 | } 69 | 70 | function BeNice() { 71 | # Pull in the vars 72 | REPO_NAME=$1 73 | 74 | # Get the user 75 | USER=$(echo "$REPO_NAME" | (sed -n -e 's/.*-//p')) 76 | 77 | # Check the name 78 | if echo "$REPO_NAME" | grep -iq -e "github-games-"; then 79 | TEMPLATE="github-games [here](https://github.com/githubtraining/github-games)" 80 | else 81 | TEMPLATE="conflict-practice (our conflict practice activity) [here](https://github.com/githubtraining/conflict-practice)" 82 | fi 83 | curl -s -S -i -H "Authorization: token $TEACHER_PAT" -d "{ \"title\": \"Thank you for attending GitHub Training\", \"body\": \"@$USER We hope you enjoyed the :octocat: class and we look forward to seeing you in another [class or webinar](https://services.github.com/training/#public) soon. To keep things tidy in the githubschool organization, we are going to remove your practice repository.\n\nIf you would like to revisit these activities in the future, you can access the template repository for $TEMPLATE.\n\nStop by and see us sometime at [services.github.com](https://services.github.com), or take our newest self-paced courses at [lab.github.com](https://lab.github.com). :wave: Until we see you again, good luck in your GitHub adventures :rocket:.\"}" -X POST "https://$INSTANCE_URL/repos/$CLASS_ORG/$REPO_NAME/issues" >>log.out 2>&1 84 | # Delete the repo 85 | ./remove-repo "$REPO_NAME" 86 | } 87 | 88 | # Check the OS 89 | if [ "$OSTYPE" = "msys" ]; then 90 | COMP_DATE=$(date --date='10 days ago' +%Y-%m-%dT%H:%M:%S) 91 | else 92 | COMP_DATE=$(date -v-10d +%Y-%m-%dT%H:%M:%S) 93 | fi 94 | 95 | # Get the pages 96 | GetPages 97 | -------------------------------------------------------------------------------- /script/generate-pdf: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | # 3 | # Generate PDF 4 | 5 | # Header 6 | echo "Creating a PDF... if this fails check out the documentation at: https://toolchain.gitbook.com/ebook.html" 7 | 8 | # NPM Install 9 | npm install -g gitbook-cli svgexport 10 | 11 | # Load the error code 12 | ERROR_CODE=$? 13 | 14 | # Check the shell for errors 15 | if [ $ERROR_CODE -ne 0 ]; then 16 | echo "ERROR! Failed to run npm install" 17 | exit 1 18 | fi 19 | 20 | # Copy the files 21 | cp docs/_sidebar.md docs/SUMMARY.md 22 | 23 | # Load the error code 24 | ERROR_CODE=$? 25 | 26 | # Check the shell for errors 27 | if [ $ERROR_CODE -ne 0 ]; then 28 | echo "ERROR! Failed to run cp" 29 | exit 1 30 | fi 31 | 32 | # Run the gitbook 33 | gitbook pdf docs/ docs/book.pdf 34 | 35 | # Load the error code 36 | ERROR_CODE=$? 37 | 38 | # Check the shell for errors 39 | if [ $ERROR_CODE -ne 0 ]; then 40 | echo "ERROR! Failed to run gitbook" 41 | exit 1 42 | fi 43 | 44 | # Remove dead file 45 | rm docs/SUMMARY.md 46 | 47 | # Load the error code 48 | ERROR_CODE=$? 49 | 50 | # Check the shell for errors 51 | if [ $ERROR_CODE -ne 0 ]; then 52 | echo "ERROR! Failed to run rm" 53 | exit 1 54 | fi 55 | 56 | # Footer 57 | echo "Your PDF is at docs/book.pdf. Commit it to your repo if you'd like to." 58 | -------------------------------------------------------------------------------- /script/remove-repo: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | # 3 | # Remove Repo 4 | 5 | # shellcheck disable=SC1091 6 | source "$HOME/.trainingmanualrc" 7 | 8 | ################################################################# 9 | # NOTE: You must have a personal access token (PAT) # 10 | # saved to your environment variables to use this script. # 11 | # We recommend a dedicated service account (e.g. githubteacher) # 12 | ################################################################# 13 | 14 | # GLOBALS 15 | REPO_NAME=$1 16 | 17 | function DeleteIt() { 18 | echo "Deleting $CLASS_ORG/$REPO_NAME" 19 | curl -s -S -i -H "Authorization: token $TEACHER_PAT" -X DELETE "https://$INSTANCE_URL/repos/$CLASS_ORG/$REPO_NAME" >>log.out 2>&1 20 | 21 | # Load the error code 22 | ERROR_CODE=$? 23 | 24 | # Check the shell for errors 25 | if [ $ERROR_CODE -ne 0 ]; then 26 | echo "ERROR! Failed to Delete it!" 27 | exit 1 28 | fi 29 | } 30 | 31 | # Delete the repo 32 | DeleteIt 33 | -------------------------------------------------------------------------------- /script/server: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | # 3 | # Docsify them documents 4 | 5 | # Run command 6 | docsify serve docs 7 | 8 | # Load the error code 9 | ERROR_CODE=$? 10 | 11 | # Check the shell for errors 12 | if [ $ERROR_CODE -ne 0 ]; then 13 | echo "ERROR! Failed to create docs!" 14 | exit 1 15 | fi 16 | -------------------------------------------------------------------------------- /slide_images.md: -------------------------------------------------------------------------------- 1 | ![riddlocat](https://octodex.github.com/images/riddlocat.png) 2 | ![skitchtocat](https://octodex.github.com/images/skitchtocat.png) 3 | ![luchadortocat](https://octodex.github.com/images/luchadortocat.png) 4 | ![codercat](https://octodex.github.com/images/codercat.jpg) 5 | ![dojocat](https://octodex.github.com/images/dojocat.jpg) 6 | ![dodgetocat](https://octodex.github.com/images/dodgetocat_v2.png) 7 | ![steroidtocat](https://octodex.github.com/images/steroidtocat.png) 8 | ![inflatocat](https://octodex.github.com/images/inflatocat.png) 9 | ![poptocat](https://octodex.github.com/images/poptocat.png) 10 | ![Robotocat](https://octodex.github.com/images/Robotocat.png) 11 | ![saritocat](https://octodex.github.com/images/saritocat.png) 12 | ![jetpacktocat](https://octodex.github.com/images/jetpacktocat.png) 13 | ![cooler-octocat](https://octodex.github.com/images/twenty-percent-cooler-octocat.png) 14 | ![octocat-de-los-muertos](https://octodex.github.com/images/octocat-de-los-muertos.jpg) 15 | ![poptocat2](https://octodex.github.com/images/poptocat_v2.png) 16 | ![minertocat](https://octodex.github.com/images/minertocat.png) 17 | ![femalecodertocat](https://octodex.github.com/images/femalecodertocat.png) 18 | ![cherryontop-o-cat](https://octodex.github.com/images/cherryontop-o-cat.png) 19 | ![orderedlistocat](https://octodex.github.com/images/orderedlistocat.png) 20 | ![herme-t-crabb](https://octodex.github.com/images/herme-t-crabb.png) 21 | ![droidtocat](https://octodex.github.com/images/droidtocat.png) 22 | ![snowoctocat](https://octodex.github.com/images/snowoctocat.png) 23 | ![boxertocat](https://octodex.github.com/images/boxertocat_octodex.jpg) 24 | ![skatetocat](https://octodex.github.com/images/skatetocat.png) 25 | ![labtocat](https://octodex.github.com/images/labtocat.png) 26 | ![Mardigrastocat](https://octodex.github.com/images/Mardigrastocat.png) 27 | ![defunktocat](https://octodex.github.com/images/defunktocat.png) 28 | ![catstello](https://octodex.github.com/images/catstello.png) 29 | ![constructocat](https://octodex.github.com/images/constructocat2.jpg) 30 | ![kimonotocat](https://octodex.github.com/images/kimonotocat.png) 31 | ![octofez](https://octodex.github.com/images/octofez.png) 32 | ![dinotocat](https://octodex.github.com/images/dinotocat.png) 33 | -------------------------------------------------------------------------------- /slide_template.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: slide 3 | title: "Welcome to our slide deck!" 4 | --- 5 | 6 | Caption here 7 | 8 | IMAGE 9 | {: .center} 10 | --------------------------------------------------------------------------------