diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index 00000000..5bf4860b
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,26 @@
+root = true
+
+[*]
+charset = utf-8
+insert_final_newline = true
+trim_trailing_whitespace = true
+
+[*.md]
+indent_size = 2
+indent_style = space
+max_line_length = 100 # Please keep this in sync with bin/lesson_check.py!
+trim_trailing_whitespace = false # keep trailing spaces in markdown - 2+ spaces are translated to a hard break (
)
+
+[*.r]
+max_line_length = 80
+
+[*.py]
+indent_size = 4
+indent_style = space
+max_line_length = 79
+
+[*.sh]
+end_of_line = lf
+
+[Makefile]
+indent_style = tab
diff --git a/.github/workflows/README.md b/.github/workflows/README.md
new file mode 100755
index 00000000..101967e4
--- /dev/null
+++ b/.github/workflows/README.md
@@ -0,0 +1,198 @@
+# Carpentries Workflows
+
+This directory contains workflows to be used for Lessons using the {sandpaper}
+lesson infrastructure. Two of these workflows require R (`sandpaper-main.yaml`
+and `pr-recieve.yaml`) and the rest are bots to handle pull request management.
+
+These workflows will likely change as {sandpaper} evolves, so it is important to
+keep them up-to-date. To do this in your lesson you can do the following in your
+R console:
+
+```r
+# Install/Update sandpaper
+options(repos = c(carpentries = "https://carpentries.r-universe.dev/",
+ CRAN = "https://cloud.r-project.org"))
+install.packages("sandpaper")
+
+# update the workflows in your lesson
+library("sandpaper")
+update_github_workflows()
+```
+
+Inside this folder, you will find a file called `sandpaper-version.txt`, which
+will contain a version number for sandpaper. This will be used in the future to
+alert you if a workflow update is needed.
+
+What follows are the descriptions of the workflow files:
+
+## Deployment
+
+### 01 Build and Deploy (sandpaper-main.yaml)
+
+This is the main driver that will only act on the main branch of the repository.
+This workflow does the following:
+
+ 1. checks out the lesson
+ 2. provisions the following resources
+ - R
+ - pandoc
+ - lesson infrastructure (stored in a cache)
+ - lesson dependencies if needed (stored in a cache)
+ 3. builds the lesson via `sandpaper:::ci_deploy()`
+
+#### Caching
+
+This workflow has two caches; one cache is for the lesson infrastructure and
+the other is for the the lesson dependencies if the lesson contains rendered
+content. These caches are invalidated by new versions of the infrastructure and
+the `renv.lock` file, respectively. If there is a problem with the cache,
+manual invaliation is necessary. You will need maintain access to the repository
+and you can either go to the actions tab and [click on the caches button to find
+and invalidate the failing cache](https://github.blog/changelog/2022-10-20-manage-caches-in-your-actions-workflows-from-web-interface/)
+or by setting the `CACHE_VERSION` secret to the current date (which will
+invalidate all of the caches).
+
+## Updates
+
+### Setup Information
+
+These workflows run on a schedule and at the maintainer's request. Because they
+create pull requests that update workflows/require the downstream actions to run,
+they need a special repository/organization secret token called
+`SANDPAPER_WORKFLOW` and it must have the `public_repo` and `workflow` scope.
+
+This can be an individual user token, OR it can be a trusted bot account. If you
+have a repository in one of the official Carpentries accounts, then you do not
+need to worry about this token being present because the Carpentries Core Team
+will take care of supplying this token.
+
+If you want to use your personal account: you can go to
+
+to create a token. Once you have created your token, you should copy it to your
+clipboard and then go to your repository's settings > secrets > actions and
+create or edit the `SANDPAPER_WORKFLOW` secret, pasting in the generated token.
+
+If you do not specify your token correctly, the runs will not fail and they will
+give you instructions to provide the token for your repository.
+
+### 02 Maintain: Update Workflow Files (update-workflow.yaml)
+
+The {sandpaper} repository was designed to do as much as possible to separate
+the tools from the content. For local builds, this is absolutely true, but
+there is a minor issue when it comes to workflow files: they must live inside
+the repository.
+
+This workflow ensures that the workflow files are up-to-date. The way it work is
+to download the update-workflows.sh script from GitHub and run it. The script
+will do the following:
+
+1. check the recorded version of sandpaper against the current version on github
+2. update the files if there is a difference in versions
+
+After the files are updated, if there are any changes, they are pushed to a
+branch called `update/workflows` and a pull request is created. Maintainers are
+encouraged to review the changes and accept the pull request if the outputs
+are okay.
+
+This update is run ~~weekly or~~ on demand.
+
+### 03 Maintain: Update Pacakge Cache (update-cache.yaml)
+
+For lessons that have generated content, we use {renv} to ensure that the output
+is stable. This is controlled by a single lockfile which documents the packages
+needed for the lesson and the version numbers. This workflow is skipped in
+lessons that do not have generated content.
+
+Because the lessons need to remain current with the package ecosystem, it's a
+good idea to make sure these packages can be updated periodically. The
+update cache workflow will do this by checking for updates, applying them in a
+branch called `updates/packages` and creating a pull request with _only the
+lockfile changed_.
+
+From here, the markdown documents will be rebuilt and you can inspect what has
+changed based on how the packages have updated.
+
+## Pull Request and Review Management
+
+Because our lessons execute code, pull requests are a secruity risk for any
+lesson and thus have security measures associted with them. **Do not merge any
+pull requests that do not pass checks and do not have bots commented on them.**
+
+This series of workflows all go together and are described in the following
+diagram and the below sections:
+
+
+
+### Pre Flight Pull Request Validation (pr-preflight.yaml)
+
+This workflow runs every time a pull request is created and its purpose is to
+validate that the pull request is okay to run. This means the following things:
+
+1. The pull request does not contain modified workflow files
+2. If the pull request contains modified workflow files, it does not contain
+ modified content files (such as a situation where @carpentries-bot will
+ make an automated pull request)
+3. The pull request does not contain an invalid commit hash (e.g. from a fork
+ that was made before a lesson was transitioned from styles to use the
+ workbench).
+
+Once the checks are finished, a comment is issued to the pull request, which
+will allow maintainers to determine if it is safe to run the
+"Receive Pull Request" workflow from new contributors.
+
+### Recieve Pull Request (pr-recieve.yaml)
+
+**Note of caution:** This workflow runs arbitrary code by anyone who creates a
+pull request. GitHub has safeguarded the token used in this workflow to have no
+priviledges in the repository, but we have taken precautions to protect against
+spoofing.
+
+This workflow is triggered with every push to a pull request. If this workflow
+is already running and a new push is sent to the pull request, the workflow
+running from the previous push will be cancelled and a new workflow run will be
+started.
+
+The first step of this workflow is to check if it is valid (e.g. that no
+workflow files have been modified). If there are workflow files that have been
+modified, a comment is made that indicates that the workflow is not run. If
+both a workflow file and lesson content is modified, an error will occurr.
+
+The second step (if valid) is to build the generated content from the pull
+request. This builds the content and uploads three artifacts:
+
+1. The pull request number (pr)
+2. A summary of changes after the rendering process (diff)
+3. The rendered files (build)
+
+Because this workflow builds generated content, it follows the same general
+process as the `sandpaper-main` workflow with the same caching mechanisms.
+
+The artifacts produced are used by the next workflow.
+
+### Comment on Pull Request (pr-comment.yaml)
+
+This workflow is triggered if the `pr-recieve.yaml` workflow is successful.
+The steps in this workflow are:
+
+1. Test if the workflow is valid and comment the validity of the workflow to the
+ pull request.
+2. If it is valid: create an orphan branch with two commits: the current state
+ of the repository and the proposed changes.
+3. If it is valid: update the pull request comment with the summary of changes
+
+Importantly: if the pull request is invalid, the branch is not created so any
+malicious code is not published.
+
+From here, the maintainer can request changes from the author and eventually
+either merge or reject the PR. When this happens, if the PR was valid, the
+preview branch needs to be deleted.
+
+### Send Close PR Signal (pr-close-signal.yaml)
+
+Triggered any time a pull request is closed. This emits an artifact that is the
+pull request number for the next action
+
+### Remove Pull Request Branch (pr-post-remove-branch.yaml)
+
+Tiggered by `pr-close-signal.yaml`. This removes the temporary branch associated with
+the pull request (if it was created).
diff --git a/.github/workflows/pr-close-signal.yaml b/.github/workflows/pr-close-signal.yaml
new file mode 100755
index 00000000..9b129d5d
--- /dev/null
+++ b/.github/workflows/pr-close-signal.yaml
@@ -0,0 +1,23 @@
+name: "Bot: Send Close Pull Request Signal"
+
+on:
+ pull_request:
+ types:
+ [closed]
+
+jobs:
+ send-close-signal:
+ name: "Send closing signal"
+ runs-on: ubuntu-latest
+ if: ${{ github.event.action == 'closed' }}
+ steps:
+ - name: "Create PRtifact"
+ run: |
+ mkdir -p ./pr
+ printf ${{ github.event.number }} > ./pr/NUM
+ - name: Upload Diff
+ uses: actions/upload-artifact@v3
+ with:
+ name: pr
+ path: ./pr
+
diff --git a/.github/workflows/pr-comment.yaml b/.github/workflows/pr-comment.yaml
new file mode 100755
index 00000000..bb2eb03c
--- /dev/null
+++ b/.github/workflows/pr-comment.yaml
@@ -0,0 +1,185 @@
+name: "Bot: Comment on the Pull Request"
+
+# read-write repo token
+# access to secrets
+on:
+ workflow_run:
+ workflows: ["Receive Pull Request"]
+ types:
+ - completed
+
+concurrency:
+ group: pr-${{ github.event.workflow_run.pull_requests[0].number }}
+ cancel-in-progress: true
+
+
+jobs:
+ # Pull requests are valid if:
+ # - they match the sha of the workflow run head commit
+ # - they are open
+ # - no .github files were committed
+ test-pr:
+ name: "Test if pull request is valid"
+ runs-on: ubuntu-latest
+ if: >
+ github.event.workflow_run.event == 'pull_request' &&
+ github.event.workflow_run.conclusion == 'success'
+ outputs:
+ is_valid: ${{ steps.check-pr.outputs.VALID }}
+ payload: ${{ steps.check-pr.outputs.payload }}
+ number: ${{ steps.get-pr.outputs.NUM }}
+ msg: ${{ steps.check-pr.outputs.MSG }}
+ steps:
+ - name: 'Download PR artifact'
+ id: dl
+ uses: carpentries/actions/download-workflow-artifact@main
+ with:
+ run: ${{ github.event.workflow_run.id }}
+ name: 'pr'
+
+ - name: "Get PR Number"
+ if: ${{ steps.dl.outputs.success == 'true' }}
+ id: get-pr
+ run: |
+ unzip pr.zip
+ echo "NUM=$(<./NR)" >> $GITHUB_OUTPUT
+
+ - name: "Fail if PR number was not present"
+ id: bad-pr
+ if: ${{ steps.dl.outputs.success != 'true' }}
+ run: |
+ echo '::error::A pull request number was not recorded. The pull request that triggered this workflow is likely malicious.'
+ exit 1
+ - name: "Get Invalid Hashes File"
+ id: hash
+ run: |
+ echo "json<> $GITHUB_OUTPUT
+ - name: "Check PR"
+ id: check-pr
+ if: ${{ steps.dl.outputs.success == 'true' }}
+ uses: carpentries/actions/check-valid-pr@main
+ with:
+ pr: ${{ steps.get-pr.outputs.NUM }}
+ sha: ${{ github.event.workflow_run.head_sha }}
+ headroom: 3 # if it's within the last three commits, we can keep going, because it's likely rapid-fire
+ invalid: ${{ fromJSON(steps.hash.outputs.json)[github.repository] }}
+ fail_on_error: true
+
+ # Create an orphan branch on this repository with two commits
+ # - the current HEAD of the md-outputs branch
+ # - the output from running the current HEAD of the pull request through
+ # the md generator
+ create-branch:
+ name: "Create Git Branch"
+ needs: test-pr
+ runs-on: ubuntu-latest
+ if: ${{ needs.test-pr.outputs.is_valid == 'true' }}
+ env:
+ NR: ${{ needs.test-pr.outputs.number }}
+ permissions:
+ contents: write
+ steps:
+ - name: 'Checkout md outputs'
+ uses: actions/checkout@v3
+ with:
+ ref: md-outputs
+ path: built
+ fetch-depth: 1
+
+ - name: 'Download built markdown'
+ id: dl
+ uses: carpentries/actions/download-workflow-artifact@main
+ with:
+ run: ${{ github.event.workflow_run.id }}
+ name: 'built'
+
+ - if: ${{ steps.dl.outputs.success == 'true' }}
+ run: unzip built.zip
+
+ - name: "Create orphan and push"
+ if: ${{ steps.dl.outputs.success == 'true' }}
+ run: |
+ cd built/
+ git config --local user.email "actions@github.com"
+ git config --local user.name "GitHub Actions"
+ CURR_HEAD=$(git rev-parse HEAD)
+ git checkout --orphan md-outputs-PR-${NR}
+ git add -A
+ git commit -m "source commit: ${CURR_HEAD}"
+ ls -A | grep -v '^.git$' | xargs -I _ rm -r '_'
+ cd ..
+ unzip -o -d built built.zip
+ cd built
+ git add -A
+ git commit --allow-empty -m "differences for PR #${NR}"
+ git push -u --force --set-upstream origin md-outputs-PR-${NR}
+
+ # Comment on the Pull Request with a link to the branch and the diff
+ comment-pr:
+ name: "Comment on Pull Request"
+ needs: [test-pr, create-branch]
+ runs-on: ubuntu-latest
+ if: ${{ needs.test-pr.outputs.is_valid == 'true' }}
+ env:
+ NR: ${{ needs.test-pr.outputs.number }}
+ permissions:
+ pull-requests: write
+ steps:
+ - name: 'Download comment artifact'
+ id: dl
+ uses: carpentries/actions/download-workflow-artifact@main
+ with:
+ run: ${{ github.event.workflow_run.id }}
+ name: 'diff'
+
+ - if: ${{ steps.dl.outputs.success == 'true' }}
+ run: unzip ${{ github.workspace }}/diff.zip
+
+ - name: "Comment on PR"
+ id: comment-diff
+ if: ${{ steps.dl.outputs.success == 'true' }}
+ uses: carpentries/actions/comment-diff@main
+ with:
+ pr: ${{ env.NR }}
+ path: ${{ github.workspace }}/diff.md
+
+ # Comment if the PR is open and matches the SHA, but the workflow files have
+ # changed
+ comment-changed-workflow:
+ name: "Comment if workflow files have changed"
+ needs: test-pr
+ runs-on: ubuntu-latest
+ if: ${{ always() && needs.test-pr.outputs.is_valid == 'false' }}
+ env:
+ NR: ${{ github.event.workflow_run.pull_requests[0].number }}
+ body: ${{ needs.test-pr.outputs.msg }}
+ permissions:
+ pull-requests: write
+ steps:
+ - name: 'Check for spoofing'
+ id: dl
+ uses: carpentries/actions/download-workflow-artifact@main
+ with:
+ run: ${{ github.event.workflow_run.id }}
+ name: 'built'
+
+ - name: 'Alert if spoofed'
+ id: spoof
+ if: ${{ steps.dl.outputs.success == 'true' }}
+ run: |
+ echo 'body<> $GITHUB_ENV
+ echo '' >> $GITHUB_ENV
+ echo '## :x: DANGER :x:' >> $GITHUB_ENV
+ echo 'This pull request has modified workflows that created output. Close this now.' >> $GITHUB_ENV
+ echo '' >> $GITHUB_ENV
+ echo 'EOF' >> $GITHUB_ENV
+
+ - name: "Comment on PR"
+ id: comment-diff
+ uses: carpentries/actions/comment-diff@main
+ with:
+ pr: ${{ env.NR }}
+ body: ${{ env.body }}
+
diff --git a/.github/workflows/pr-post-remove-branch.yaml b/.github/workflows/pr-post-remove-branch.yaml
new file mode 100755
index 00000000..62c2e98d
--- /dev/null
+++ b/.github/workflows/pr-post-remove-branch.yaml
@@ -0,0 +1,32 @@
+name: "Bot: Remove Temporary PR Branch"
+
+on:
+ workflow_run:
+ workflows: ["Bot: Send Close Pull Request Signal"]
+ types:
+ - completed
+
+jobs:
+ delete:
+ name: "Delete branch from Pull Request"
+ runs-on: ubuntu-latest
+ if: >
+ github.event.workflow_run.event == 'pull_request' &&
+ github.event.workflow_run.conclusion == 'success'
+ permissions:
+ contents: write
+ steps:
+ - name: 'Download artifact'
+ uses: carpentries/actions/download-workflow-artifact@main
+ with:
+ run: ${{ github.event.workflow_run.id }}
+ name: pr
+ - name: "Get PR Number"
+ id: get-pr
+ run: |
+ unzip pr.zip
+ echo "NUM=$(<./NUM)" >> $GITHUB_OUTPUT
+ - name: 'Remove branch'
+ uses: carpentries/actions/remove-branch@main
+ with:
+ pr: ${{ steps.get-pr.outputs.NUM }}
diff --git a/.github/workflows/pr-preflight.yaml b/.github/workflows/pr-preflight.yaml
new file mode 100755
index 00000000..d0d7420d
--- /dev/null
+++ b/.github/workflows/pr-preflight.yaml
@@ -0,0 +1,39 @@
+name: "Pull Request Preflight Check"
+
+on:
+ pull_request_target:
+ branches:
+ ["main"]
+ types:
+ ["opened", "synchronize", "reopened"]
+
+jobs:
+ test-pr:
+ name: "Test if pull request is valid"
+ if: ${{ github.event.action != 'closed' }}
+ runs-on: ubuntu-latest
+ outputs:
+ is_valid: ${{ steps.check-pr.outputs.VALID }}
+ permissions:
+ pull-requests: write
+ steps:
+ - name: "Get Invalid Hashes File"
+ id: hash
+ run: |
+ echo "json<> $GITHUB_OUTPUT
+ - name: "Check PR"
+ id: check-pr
+ uses: carpentries/actions/check-valid-pr@main
+ with:
+ pr: ${{ github.event.number }}
+ invalid: ${{ fromJSON(steps.hash.outputs.json)[github.repository] }}
+ fail_on_error: true
+ - name: "Comment result of validation"
+ id: comment-diff
+ if: ${{ always() }}
+ uses: carpentries/actions/comment-diff@main
+ with:
+ pr: ${{ github.event.number }}
+ body: ${{ steps.check-pr.outputs.MSG }}
diff --git a/.github/workflows/pr-receive.yaml b/.github/workflows/pr-receive.yaml
new file mode 100755
index 00000000..371ef542
--- /dev/null
+++ b/.github/workflows/pr-receive.yaml
@@ -0,0 +1,131 @@
+name: "Receive Pull Request"
+
+on:
+ pull_request:
+ types:
+ [opened, synchronize, reopened]
+
+concurrency:
+ group: ${{ github.ref }}
+ cancel-in-progress: true
+
+jobs:
+ test-pr:
+ name: "Record PR number"
+ if: ${{ github.event.action != 'closed' }}
+ runs-on: ubuntu-latest
+ outputs:
+ is_valid: ${{ steps.check-pr.outputs.VALID }}
+ steps:
+ - name: "Record PR number"
+ id: record
+ if: ${{ always() }}
+ run: |
+ echo ${{ github.event.number }} > ${{ github.workspace }}/NR # 2022-03-02: artifact name fixed to be NR
+ - name: "Upload PR number"
+ id: upload
+ if: ${{ always() }}
+ uses: actions/upload-artifact@v3
+ with:
+ name: pr
+ path: ${{ github.workspace }}/NR
+ - name: "Get Invalid Hashes File"
+ id: hash
+ run: |
+ echo "json<> $GITHUB_OUTPUT
+ - name: "echo output"
+ run: |
+ echo "${{ steps.hash.outputs.json }}"
+ - name: "Check PR"
+ id: check-pr
+ uses: carpentries/actions/check-valid-pr@main
+ with:
+ pr: ${{ github.event.number }}
+ invalid: ${{ fromJSON(steps.hash.outputs.json)[github.repository] }}
+
+ build-md-source:
+ name: "Build markdown source files if valid"
+ needs: test-pr
+ runs-on: ubuntu-latest
+ if: ${{ needs.test-pr.outputs.is_valid == 'true' }}
+ env:
+ GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
+ RENV_PATHS_ROOT: ~/.local/share/renv/
+ CHIVE: ${{ github.workspace }}/site/chive
+ PR: ${{ github.workspace }}/site/pr
+ MD: ${{ github.workspace }}/site/built
+ steps:
+ - name: "Check Out Main Branch"
+ uses: actions/checkout@v3
+
+ - name: "Check Out Staging Branch"
+ uses: actions/checkout@v3
+ with:
+ ref: md-outputs
+ path: ${{ env.MD }}
+
+ - name: "Set up R"
+ uses: r-lib/actions/setup-r@v2
+ with:
+ use-public-rspm: true
+ install-r: false
+
+ - name: "Set up Pandoc"
+ uses: r-lib/actions/setup-pandoc@v2
+
+ - name: "Setup Lesson Engine"
+ uses: carpentries/actions/setup-sandpaper@main
+ with:
+ cache-version: ${{ secrets.CACHE_VERSION }}
+
+ - name: "Setup Package Cache"
+ uses: carpentries/actions/setup-lesson-deps@main
+ with:
+ cache-version: ${{ secrets.CACHE_VERSION }}
+
+ - name: "Validate and Build Markdown"
+ id: build-site
+ run: |
+ sandpaper::package_cache_trigger(TRUE)
+ sandpaper::validate_lesson(path = '${{ github.workspace }}')
+ sandpaper:::build_markdown(path = '${{ github.workspace }}', quiet = FALSE)
+ shell: Rscript {0}
+
+ - name: "Generate Artifacts"
+ id: generate-artifacts
+ run: |
+ sandpaper:::ci_bundle_pr_artifacts(
+ repo = '${{ github.repository }}',
+ pr_number = '${{ github.event.number }}',
+ path_md = '${{ env.MD }}',
+ path_pr = '${{ env.PR }}',
+ path_archive = '${{ env.CHIVE }}',
+ branch = 'md-outputs'
+ )
+ shell: Rscript {0}
+
+ - name: "Upload PR"
+ uses: actions/upload-artifact@v3
+ with:
+ name: pr
+ path: ${{ env.PR }}
+
+ - name: "Upload Diff"
+ uses: actions/upload-artifact@v3
+ with:
+ name: diff
+ path: ${{ env.CHIVE }}
+ retention-days: 1
+
+ - name: "Upload Build"
+ uses: actions/upload-artifact@v3
+ with:
+ name: built
+ path: ${{ env.MD }}
+ retention-days: 1
+
+ - name: "Teardown"
+ run: sandpaper::reset_site()
+ shell: Rscript {0}
diff --git a/.github/workflows/sandpaper-main.yaml b/.github/workflows/sandpaper-main.yaml
new file mode 100755
index 00000000..e17707ac
--- /dev/null
+++ b/.github/workflows/sandpaper-main.yaml
@@ -0,0 +1,61 @@
+name: "01 Build and Deploy Site"
+
+on:
+ push:
+ branches:
+ - main
+ - master
+ schedule:
+ - cron: '0 0 * * 2'
+ workflow_dispatch:
+ inputs:
+ name:
+ description: 'Who triggered this build?'
+ required: true
+ default: 'Maintainer (via GitHub)'
+ reset:
+ description: 'Reset cached markdown files'
+ required: false
+ default: false
+ type: boolean
+jobs:
+ full-build:
+ name: "Build Full Site"
+ runs-on: ubuntu-latest
+ permissions:
+ checks: write
+ contents: write
+ pages: write
+ env:
+ GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
+ RENV_PATHS_ROOT: ~/.local/share/renv/
+ steps:
+
+ - name: "Checkout Lesson"
+ uses: actions/checkout@v3
+
+ - name: "Set up R"
+ uses: r-lib/actions/setup-r@v2
+ with:
+ use-public-rspm: true
+ install-r: false
+
+ - name: "Set up Pandoc"
+ uses: r-lib/actions/setup-pandoc@v2
+
+ - name: "Setup Lesson Engine"
+ uses: carpentries/actions/setup-sandpaper@main
+ with:
+ cache-version: ${{ secrets.CACHE_VERSION }}
+
+ - name: "Setup Package Cache"
+ uses: carpentries/actions/setup-lesson-deps@main
+ with:
+ cache-version: ${{ secrets.CACHE_VERSION }}
+
+ - name: "Deploy Site"
+ run: |
+ reset <- "${{ github.event.inputs.reset }}" == "true"
+ sandpaper::package_cache_trigger(TRUE)
+ sandpaper:::ci_deploy(reset = reset)
+ shell: Rscript {0}
diff --git a/.github/workflows/sandpaper-version.txt b/.github/workflows/sandpaper-version.txt
new file mode 100644
index 00000000..4aa09069
--- /dev/null
+++ b/.github/workflows/sandpaper-version.txt
@@ -0,0 +1 @@
+0.11.15
diff --git a/.github/workflows/update-cache.yaml b/.github/workflows/update-cache.yaml
new file mode 100755
index 00000000..676d7424
--- /dev/null
+++ b/.github/workflows/update-cache.yaml
@@ -0,0 +1,125 @@
+name: "03 Maintain: Update Package Cache"
+
+on:
+ workflow_dispatch:
+ inputs:
+ name:
+ description: 'Who triggered this build (enter github username to tag yourself)?'
+ required: true
+ default: 'monthly run'
+ schedule:
+ # Run every tuesday
+ - cron: '0 0 * * 2'
+
+jobs:
+ preflight:
+ name: "Preflight Check"
+ runs-on: ubuntu-latest
+ outputs:
+ ok: ${{ steps.check.outputs.ok }}
+ steps:
+ - id: check
+ run: |
+ if [[ ${{ github.event_name }} == 'workflow_dispatch' ]]; then
+ echo "ok=true" >> $GITHUB_OUTPUT
+ echo "Running on request"
+ # using single brackets here to avoid 08 being interpreted as octal
+ # https://github.com/carpentries/sandpaper/issues/250
+ elif [ `date +%d` -le 7 ]; then
+ # If the Tuesday lands in the first week of the month, run it
+ echo "ok=true" >> $GITHUB_OUTPUT
+ echo "Running on schedule"
+ else
+ echo "ok=false" >> $GITHUB_OUTPUT
+ echo "Not Running Today"
+ fi
+
+ check_renv:
+ name: "Check if We Need {renv}"
+ runs-on: ubuntu-latest
+ needs: preflight
+ if: ${{ needs.preflight.outputs.ok == 'true'}}
+ outputs:
+ needed: ${{ steps.renv.outputs.exists }}
+ steps:
+ - name: "Checkout Lesson"
+ uses: actions/checkout@v3
+ - id: renv
+ run: |
+ if [[ -d renv ]]; then
+ echo "exists=true" >> $GITHUB_OUTPUT
+ fi
+
+ check_token:
+ name: "Check SANDPAPER_WORKFLOW token"
+ runs-on: ubuntu-latest
+ needs: check_renv
+ if: ${{ needs.check_renv.outputs.needed == 'true' }}
+ outputs:
+ workflow: ${{ steps.validate.outputs.wf }}
+ repo: ${{ steps.validate.outputs.repo }}
+ steps:
+ - name: "validate token"
+ id: validate
+ uses: carpentries/actions/check-valid-credentials@main
+ with:
+ token: ${{ secrets.SANDPAPER_WORKFLOW }}
+
+ update_cache:
+ name: "Update Package Cache"
+ needs: check_token
+ if: ${{ needs.check_token.outputs.repo== 'true' }}
+ runs-on: ubuntu-latest
+ env:
+ GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
+ RENV_PATHS_ROOT: ~/.local/share/renv/
+ steps:
+
+ - name: "Checkout Lesson"
+ uses: actions/checkout@v3
+
+ - name: "Set up R"
+ uses: r-lib/actions/setup-r@v2
+ with:
+ use-public-rspm: true
+ install-r: false
+
+ - name: "Update {renv} deps and determine if a PR is needed"
+ id: update
+ uses: carpentries/actions/update-lockfile@main
+ with:
+ cache-version: ${{ secrets.CACHE_VERSION }}
+
+ - name: Create Pull Request
+ id: cpr
+ if: ${{ steps.update.outputs.n > 0 }}
+ uses: carpentries/create-pull-request@main
+ with:
+ token: ${{ secrets.SANDPAPER_WORKFLOW }}
+ delete-branch: true
+ branch: "update/packages"
+ commit-message: "[actions] update ${{ steps.update.outputs.n }} packages"
+ title: "Update ${{ steps.update.outputs.n }} packages"
+ body: |
+ :robot: This is an automated build
+
+ This will update ${{ steps.update.outputs.n }} packages in your lesson with the following versions:
+
+ ```
+ ${{ steps.update.outputs.report }}
+ ```
+
+ :stopwatch: In a few minutes, a comment will appear that will show you how the output has changed based on these updates.
+
+ If you want to inspect these changes locally, you can use the following code to check out a new branch:
+
+ ```bash
+ git fetch origin update/packages
+ git checkout update/packages
+ ```
+
+ - Auto-generated by [create-pull-request][1] on ${{ steps.update.outputs.date }}
+
+ [1]: https://github.com/carpentries/create-pull-request/tree/main
+ labels: "type: package cache"
+ draft: false
diff --git a/.github/workflows/update-workflows.yaml b/.github/workflows/update-workflows.yaml
new file mode 100755
index 00000000..288bcd13
--- /dev/null
+++ b/.github/workflows/update-workflows.yaml
@@ -0,0 +1,66 @@
+name: "02 Maintain: Update Workflow Files"
+
+on:
+ workflow_dispatch:
+ inputs:
+ name:
+ description: 'Who triggered this build (enter github username to tag yourself)?'
+ required: true
+ default: 'weekly run'
+ clean:
+ description: 'Workflow files/file extensions to clean (no wildcards, enter "" for none)'
+ required: false
+ default: '.yaml'
+ schedule:
+ # Run every Tuesday
+ - cron: '0 0 * * 2'
+
+jobs:
+ check_token:
+ name: "Check SANDPAPER_WORKFLOW token"
+ runs-on: ubuntu-latest
+ outputs:
+ workflow: ${{ steps.validate.outputs.wf }}
+ repo: ${{ steps.validate.outputs.repo }}
+ steps:
+ - name: "validate token"
+ id: validate
+ uses: carpentries/actions/check-valid-credentials@main
+ with:
+ token: ${{ secrets.SANDPAPER_WORKFLOW }}
+
+ update_workflow:
+ name: "Update Workflow"
+ runs-on: ubuntu-latest
+ needs: check_token
+ if: ${{ needs.check_token.outputs.workflow == 'true' }}
+ steps:
+ - name: "Checkout Repository"
+ uses: actions/checkout@v3
+
+ - name: Update Workflows
+ id: update
+ uses: carpentries/actions/update-workflows@main
+ with:
+ clean: ${{ github.event.inputs.clean }}
+
+ - name: Create Pull Request
+ id: cpr
+ if: "${{ steps.update.outputs.new }}"
+ uses: carpentries/create-pull-request@main
+ with:
+ token: ${{ secrets.SANDPAPER_WORKFLOW }}
+ delete-branch: true
+ branch: "update/workflows"
+ commit-message: "[actions] update sandpaper workflow to version ${{ steps.update.outputs.new }}"
+ title: "Update Workflows to Version ${{ steps.update.outputs.new }}"
+ body: |
+ :robot: This is an automated build
+
+ Update Workflows from sandpaper version ${{ steps.update.outputs.old }} -> ${{ steps.update.outputs.new }}
+
+ - Auto-generated by [create-pull-request][1] on ${{ steps.update.outputs.date }}
+
+ [1]: https://github.com/carpentries/create-pull-request/tree/main
+ labels: "type: template and tools"
+ draft: false
diff --git a/.github/workflows/workbench-beta-phase.yml b/.github/workflows/workbench-beta-phase.yml
new file mode 100644
index 00000000..2faa25d9
--- /dev/null
+++ b/.github/workflows/workbench-beta-phase.yml
@@ -0,0 +1,60 @@
+name: "Deploy to AWS"
+
+on:
+ workflow_run:
+ workflows: ["01 Build and Deploy Site"]
+ types:
+ - completed
+ workflow_dispatch:
+
+jobs:
+ preflight:
+ name: "Preflight Check"
+ runs-on: ubuntu-latest
+ outputs:
+ ok: ${{ steps.check.outputs.ok }}
+ folder: ${{ steps.check.outputs.folder }}
+ steps:
+ - id: check
+ run: |
+ if [[ -z "${{ secrets.DISTRIBUTION }}" || -z "${{ secrets.AWS_ACCESS_KEY_ID }}" || -z "${{ secrets.AWS_SECRET_ACCESS_KEY }}" ]]; then
+ echo ":information_source: No site configured" >> $GITHUB_STEP_SUMMARY
+ echo "" >> $GITHUB_STEP_SUMMARY
+ echo 'To deploy the preview on AWS, you need the `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `DISTRIBUTION` secrets set up' >> $GITHUB_STEP_SUMMARY
+ else
+ echo "::set-output name=folder::"$(sed -E 's^.+/(.+)^\1^' <<< ${{ github.repository }})
+ echo "::set-output name=ok::true"
+ fi
+
+ full-build:
+ name: "Deploy to AWS"
+ needs: [preflight]
+ if: ${{ needs.preflight.outputs.ok }}
+ runs-on: ubuntu-latest
+ steps:
+
+ - name: "Checkout site folder"
+ uses: actions/checkout@v3
+ with:
+ ref: 'gh-pages'
+ path: 'source'
+
+ - name: "Deploy to Bucket"
+ uses: jakejarvis/s3-sync-action@v0.5.1
+ with:
+ args: --acl public-read --follow-symlinks --delete --exclude '.git/*'
+ env:
+ AWS_S3_BUCKET: preview.carpentries.org
+ AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
+ AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+ SOURCE_DIR: 'source'
+ DEST_DIR: ${{ needs.preflight.outputs.folder }}
+
+ - name: "Invalidate CloudFront"
+ uses: chetan/invalidate-cloudfront-action@master
+ env:
+ PATHS: /*
+ AWS_REGION: 'us-east-1'
+ DISTRIBUTION: ${{ secrets.DISTRIBUTION }}
+ AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
+ AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 00000000..b8ab7062
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,55 @@
+# sandpaper files
+episodes/*html
+site/*
+!site/README.md
+
+# History files
+.Rhistory
+.Rapp.history
+# Session Data files
+.RData
+# User-specific files
+.Ruserdata
+# Example code in package build process
+*-Ex.R
+# Output files from R CMD build
+/*.tar.gz
+# Output files from R CMD check
+/*.Rcheck/
+# RStudio files
+.Rproj.user/
+# produced vignettes
+vignettes/*.html
+vignettes/*.pdf
+# OAuth2 token, see https://github.com/hadley/httr/releases/tag/v0.3
+.httr-oauth
+# knitr and R markdown default cache directories
+*_cache/
+/cache/
+# Temporary files created by R markdown
+*.utf8.md
+*.knit.md
+# R Environment Variables
+.Renviron
+# pkgdown site
+docs/
+# translation temp files
+po/*~
+# renv detritus
+renv/sandbox/
+*.pyc
+*~
+.DS_Store
+.ipynb_checkpoints
+.sass-cache
+.jekyll-cache/
+.jekyll-metadata
+__pycache__
+_site
+.Rproj.user
+.bundle/
+.vendor/
+vendor/
+.docker-vendor/
+Gemfile.lock
+.*history
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
new file mode 100644
index 00000000..f19b8049
--- /dev/null
+++ b/CODE_OF_CONDUCT.md
@@ -0,0 +1,13 @@
+---
+title: "Contributor Code of Conduct"
+---
+
+As contributors and maintainers of this project,
+we pledge to follow the [The Carpentries Code of Conduct][coc].
+
+Instances of abusive, harassing, or otherwise unacceptable behavior
+may be reported by following our [reporting guidelines][coc-reporting].
+
+
+[coc-reporting]: https://docs.carpentries.org/topic_folders/policies/incident-reporting.html
+[coc]: https://docs.carpentries.org/topic_folders/policies/code-of-conduct.html
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 00000000..ec44704c
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,121 @@
+## Contributing
+
+[The Carpentries][cp-site] ([Software Carpentry][swc-site], [Data
+Carpentry][dc-site], and [Library Carpentry][lc-site]) are open source
+projects, and we welcome contributions of all kinds: new lessons, fixes to
+existing material, bug reports, and reviews of proposed changes are all
+welcome.
+
+### Contributor Agreement
+
+By contributing, you agree that we may redistribute your work under [our
+license](LICENSE.md). In exchange, we will address your issues and/or assess
+your change proposal as promptly as we can, and help you become a member of our
+community. Everyone involved in [The Carpentries][cp-site] agrees to abide by
+our [code of conduct](CODE_OF_CONDUCT.md).
+
+### How to Contribute
+
+The easiest way to get started is to file an issue to tell us about a spelling
+mistake, some awkward wording, or a factual error. This is a good way to
+introduce yourself and to meet some of our community members.
+
+1. If you do not have a [GitHub][github] account, you can [send us comments by
+ email][contact]. However, we will be able to respond more quickly if you use
+ one of the other methods described below.
+
+2. If you have a [GitHub][github] account, or are willing to [create
+ one][github-join], but do not know how to use Git, you can report problems
+ or suggest improvements by [creating an issue][issues]. This allows us to
+ assign the item to someone and to respond to it in a threaded discussion.
+
+3. If you are comfortable with Git, and would like to add or change material,
+ you can submit a pull request (PR). Instructions for doing this are
+ [included below](#using-github).
+
+Note: if you want to build the website locally, please refer to [The Workbench
+documentation][template-doc].
+
+### Where to Contribute
+
+1. If you wish to change this lesson, add issues and pull requests here.
+2. If you wish to change the template used for workshop websites, please refer
+ to [The Workbench documentation][template-doc].
+
+
+### What to Contribute
+
+There are many ways to contribute, from writing new exercises and improving
+existing ones to updating or filling in the documentation and submitting [bug
+reports][issues] about things that do not work, are not clear, or are missing.
+If you are looking for ideas, please see [the list of issues for this
+repository][repo], or the issues for [Data Carpentry][dc-issues], [Library
+Carpentry][lc-issues], and [Software Carpentry][swc-issues] projects.
+
+Comments on issues and reviews of pull requests are just as welcome: we are
+smarter together than we are on our own. **Reviews from novices and newcomers
+are particularly valuable**: it's easy for people who have been using these
+lessons for a while to forget how impenetrable some of this material can be, so
+fresh eyes are always welcome.
+
+### What *Not* to Contribute
+
+Our lessons already contain more material than we can cover in a typical
+workshop, so we are usually *not* looking for more concepts or tools to add to
+them. As a rule, if you want to introduce a new idea, you must (a) estimate how
+long it will take to teach and (b) explain what you would take out to make room
+for it. The first encourages contributors to be honest about requirements; the
+second, to think hard about priorities.
+
+We are also not looking for exercises or other material that only run on one
+platform. Our workshops typically contain a mixture of Windows, macOS, and
+Linux users; in order to be usable, our lessons must run equally well on all
+three.
+
+### Using GitHub
+
+If you choose to contribute via GitHub, you may want to look at [How to
+Contribute to an Open Source Project on GitHub][how-contribute]. In brief, we
+use [GitHub flow][github-flow] to manage changes:
+
+1. Create a new branch in your desktop copy of this repository for each
+ significant change.
+2. Commit the change in that branch.
+3. Push that branch to your fork of this repository on GitHub.
+4. Submit a pull request from that branch to the [upstream repository][repo].
+5. If you receive feedback, make changes on your desktop and push to your
+ branch on GitHub: the pull request will update automatically.
+
+NB: The published copy of the lesson is usually in the `main` branch.
+
+Each lesson has a team of maintainers who review issues and pull requests or
+encourage others to do so. The maintainers are community volunteers, and have
+final say over what gets merged into the lesson.
+
+### Other Resources
+
+The Carpentries is a global organisation with volunteers and learners all over
+the world. We share values of inclusivity and a passion for sharing knowledge,
+teaching and learning. There are several ways to connect with The Carpentries
+community listed at including via social
+media, slack, newsletters, and email lists. You can also [reach us by
+email][contact].
+
+[repo]: https://example.com/FIXME
+[contact]: mailto:team@carpentries.org
+[cp-site]: https://carpentries.org/
+[dc-issues]: https://github.com/issues?q=user%3Adatacarpentry
+[dc-lessons]: https://datacarpentry.org/lessons/
+[dc-site]: https://datacarpentry.org/
+[discuss-list]: https://lists.software-carpentry.org/listinfo/discuss
+[github]: https://github.com
+[github-flow]: https://guides.github.com/introduction/flow/
+[github-join]: https://github.com/join
+[how-contribute]: https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github
+[issues]: https://carpentries.org/help-wanted-issues/
+[lc-issues]: https://github.com/issues?q=user%3ALibraryCarpentry
+[swc-issues]: https://github.com/issues?q=user%3Aswcarpentry
+[swc-lessons]: https://software-carpentry.org/lessons/
+[swc-site]: https://software-carpentry.org/
+[lc-site]: https://librarycarpentry.org/
+[template-doc]: https://carpentries.github.io/workbench/
diff --git a/LICENSE.md b/LICENSE.md
new file mode 100644
index 00000000..7632871f
--- /dev/null
+++ b/LICENSE.md
@@ -0,0 +1,79 @@
+---
+title: "Licenses"
+---
+
+## Instructional Material
+
+All Carpentries (Software Carpentry, Data Carpentry, and Library Carpentry)
+instructional material is made available under the [Creative Commons
+Attribution license][cc-by-human]. The following is a human-readable summary of
+(and not a substitute for) the [full legal text of the CC BY 4.0
+license][cc-by-legal].
+
+You are free:
+
+- to **Share**---copy and redistribute the material in any medium or format
+- to **Adapt**---remix, transform, and build upon the material
+
+for any purpose, even commercially.
+
+The licensor cannot revoke these freedoms as long as you follow the license
+terms.
+
+Under the following terms:
+
+- **Attribution**---You must give appropriate credit (mentioning that your work
+ is derived from work that is Copyright (c) The Carpentries and, where
+ practical, linking to ), provide a [link to the
+ license][cc-by-human], and indicate if changes were made. You may do so in
+ any reasonable manner, but not in any way that suggests the licensor endorses
+ you or your use.
+
+- **No additional restrictions**---You may not apply legal terms or
+ technological measures that legally restrict others from doing anything the
+ license permits. With the understanding that:
+
+Notices:
+
+* You do not have to comply with the license for elements of the material in
+ the public domain or where your use is permitted by an applicable exception
+ or limitation.
+* No warranties are given. The license may not give you all of the permissions
+ necessary for your intended use. For example, other rights such as publicity,
+ privacy, or moral rights may limit how you use the material.
+
+## Software
+
+Except where otherwise noted, the example programs and other software provided
+by The Carpentries are made available under the [OSI][osi]-approved [MIT
+license][mit-license].
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of
+this software and associated documentation files (the "Software"), to deal in
+the Software without restriction, including without limitation the rights to
+use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
+of the Software, and to permit persons to whom the Software is furnished to do
+so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+## Trademark
+
+"The Carpentries", "Software Carpentry", "Data Carpentry", and "Library
+Carpentry" and their respective logos are registered trademarks of [Community
+Initiatives][ci].
+
+[cc-by-human]: https://creativecommons.org/licenses/by/4.0/
+[cc-by-legal]: https://creativecommons.org/licenses/by/4.0/legalcode
+[mit-license]: https://opensource.org/licenses/mit-license.html
+[ci]: https://communityin.org/
+[osi]: https://opensource.org
diff --git a/README.md b/README.md
index 1c4622b9..f651875c 100644
--- a/README.md
+++ b/README.md
@@ -1,24 +1,25 @@
[](https://zenodo.org/badge/latestdoi/122202135)
-[](https://swc-slack-invite.herokuapp.com/)
- [](https://swcarpentry.slack.com/messages/C9X42NTQC)
+[](https://swc-slack-invite.herokuapp.com/)
+[](https://swcarpentry.slack.com/messages/C9X42NTQC)
-git-novice
-==========
+# git-novice
Una introdución para principiantes sobre control de versiones usando Git.
-Puedes encontrar la traducción de este material en
+Puedes encontrar la traducción de este material en [https://swcarpentry.github.io/git-novice-es/](https://swcarpentry.github.io/git-novice-es/)
y también puedes ver el [modelo de documentación][lesson-example]
-para las instrucciones de formato y como mejorar el material,
+para las instrucciones de formato y como mejorar el material,
o también puedes run `make` en este directorio para ver una lista de comandos útiles.
Maintainers:
-* [Ivan Gonzalez][gonzalez_ivan]: [@iglpdc](https://github.com/iglpdc)
-* [Rayna Harris][harris_rayna]: [@raynamharris](https://github.com/raynamharris)
-* [Clara Llebot Lorente][llebot_clara]: [@clarallebot](https://github.com/clarallebot)
+- [Ivan Gonzalez][gonzalez_ivan]: [@iglpdc](https://github.com/iglpdc)
+- [Rayna Harris][harris_rayna]: [@raynamharris](https://github.com/raynamharris)
+- [Clara Llebot Lorente][llebot_clara]: [@clarallebot](https://github.com/clarallebot)
-[llebot_clara]: https://software-carpentry.org/team/#llebot_clara
-[gonzalez_ivan]: https://software-carpentry.org/team/#gonzalez_ivan
-[harris_rayna]: http://software-carpentry.org/team/#harris_rayna
[lesson-example]: https://carpentries.github.io/lesson-example
+[gonzalez_ivan]: https://software-carpentry.org/team/#gonzalez_ivan
+[harris_rayna]: https://software-carpentry.org/team/#harris_rayna
+[llebot_clara]: https://software-carpentry.org/team/#llebot_clara
+
+
diff --git a/config.yaml b/config.yaml
new file mode 100644
index 00000000..5e768052
--- /dev/null
+++ b/config.yaml
@@ -0,0 +1,95 @@
+#------------------------------------------------------------
+# Values for this lesson.
+#------------------------------------------------------------
+
+# Which carpentry is this (swc, dc, lc, or cp)?
+# swc: Software Carpentry
+# dc: Data Carpentry
+# lc: Library Carpentry
+# cp: Carpentries (to use for instructor training for instance)
+# incubator: The Carpentries Incubator
+carpentry: 'swc'
+
+# Overall title for pages.
+title: 'El Control de Versiones con Git'
+
+# Date the lesson was created (YYYY-MM-DD, this is empty by default)
+created:
+
+# Comma-separated list of keywords for the lesson
+keywords: 'software, data, lesson, The Carpentries'
+
+# Life cycle stage of the lesson
+# possible values: pre-alpha, alpha, beta, stable
+life_cycle: 'stable'
+
+# License of the lesson materials (recommended CC-BY 4.0)
+license: 'CC-BY 4.0'
+
+# Link to the source repository for this lesson
+source: 'https://github.com/fishtree-attempt/git-novice-es/'
+
+# Default branch of your lesson
+branch: 'main'
+
+# Who to contact if there are any issues
+contact: 'team@carpentries.org'
+
+# Navigation ------------------------------------------------
+#
+# Use the following menu items to specify the order of
+# individual pages in each dropdown section. Leave blank to
+# include all pages in the folder.
+#
+# Example -------------
+#
+# episodes:
+# - introduction.md
+# - first-steps.md
+#
+# learners:
+# - setup.md
+#
+# instructors:
+# - instructor-notes.md
+#
+# profiles:
+# - one-learner.md
+# - another-learner.md
+
+# Order of episodes in your lesson
+episodes:
+- 01-basics.md
+- 02-setup.md
+- 03-create.md
+- 04-changes.md
+- 05-history.md
+- 06-ignore.md
+- 07-github.md
+- 08-collab.md
+- 09-conflict.md
+- 10-open.md
+- 11-licensing.md
+- 12-citation.md
+- 13-hosting.md
+- 14-supplemental-rstudio.md
+
+# Information for Learners
+learners:
+
+# Information for Instructors
+instructors:
+
+# Learner Profiles
+profiles:
+
+# Customisation ---------------------------------------------
+#
+# This space below is where custom yaml items (e.g. pinning
+# sandpaper and varnish versions) should live
+
+
+url: https://preview.carpentries.org/git-novice-es
+analytics: carpentries
+lang: en
+workbench-beta: 'true'
diff --git a/episodes/01-basics.md b/episodes/01-basics.md
index ba76156f..7b420dd0 100644
--- a/episodes/01-basics.md
+++ b/episodes/01-basics.md
@@ -2,72 +2,93 @@
title: Control Automatizado de Versiones
teaching: 5
exercises: 0
-questions:
-- "¿Qué es el control de versiones y por qué se deberá usar?"
-objectives:
-- "Comprender los beneficios de usar un sistema automático de control de versiones."
-- "Comprender los fundamentos básicos del funcionamiento de Git."
-keypoints:
-- "El control de versiones es como un 'deshacer' sin límites."
-- "El control de versiones permite que mucha gente trabaje en lo mismo en paralelo."
---
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Comprender los beneficios de usar un sistema automático de control de versiones.
+- Comprender los fundamentos básicos del funcionamiento de Git.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Qué es el control de versiones y por qué se deberá usar?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
Empezaremos por explorar cómo el control de versiones puede ser usado
para hacer un seguimiento de lo que hizo una persona y cuándo.
-Incluso si no se está colaborando con otras personas,
+Incluso si no se está colaborando con otras personas,
el control automatizado de versiones es mucho mejor que la siguiente situación:
-[](http://www.phdcomics.com)
+[](https://www.phdcomics.com)
-"Piled Higher and Deeper" por Jorge Cham, http://www.phdcomics.com
+"Piled Higher and Deeper" por Jorge Cham, [http://www.phdcomics.com](https://www.phdcomics.com)
-Todos hemos estado en esta situación alguna vez: parece ridículo tener
-varias versiones casi idénticas del mismo documento. Algunos procesadores de texto
+Todos hemos estado en esta situación alguna vez: parece ridículo tener
+varias versiones casi idénticas del mismo documento. Algunos procesadores de texto
nos permiten lidiar con esto un poco mejor, como por ejemplo el [*Track Changes* de Microsoft Word](https://support.office.com/en-us/article/Track-changes-in-Word-197ba630-0f5f-4a8e-9a77-3712475e806a), el [historial de versiones de Google](https://support.google.com/docs/answer/190843?hl=en) o la [grabación y visualización de cambios de LibreOffice](https://help.libreoffice.org/Common/Recording_and_Displaying_Changes).
-Los sistemas de control de versiones comienzan con una versión básica del documento y
-luego van guardando sólo los cambios que se hicieron en cada paso del proceso. Se puede
-pensar en ello como en una cinta: si se rebobina la cinta y se inicia de nuevo en el documento
+Los sistemas de control de versiones comienzan con una versión básica del documento y
+luego van guardando sólo los cambios que se hicieron en cada paso del proceso. Se puede
+pensar en ello como en una cinta: si se rebobina la cinta y se inicia de nuevo en el documento
base, se puede reproducir cada cambio y terminar con la versión más reciente.
-
+{alt='Changes Are Saved Sequentially'}
Una vez que piensas en los cambios como separados del documento en sí, entonces se puede pensar en "deshacer" diferentes conjuntos de cambios en el documento base y obtener así diferentes versiones del documento. Por ejemplo, dos usuarios pueden hacer conjuntos independientes de cambios basados en el mismo documento.
-
+{alt='Different Versions Can be Saved'}
A menos que haya conflictos, se puede incluso tener dos conjuntos de cambios en el mismo documento base.
-
+{alt='Multiple Versions Can be Merged'}
Un sistema de control de versiones es una herramienta que realiza un seguimiento de estos cambios para nosotros y
nos ayuda a controlar la versión y fusionar nuestros archivos. Nos permite
decidir qué cambios conforman la siguiente versión, a lo que llamamos hacer un
-[**commit**]({{ page.root }}/reference#commit), y mantiene metadatos útiles sobre dichos cambios. El
+[**commit**](../learners/reference.md#commit), y mantiene metadatos útiles sobre dichos cambios. El
historial completo de **commits** para un proyecto en particular y sus metadatos forman un
-[repositorio]({{ page.root }}/reference#repositorio). Los repositorios pueden mantenerse sincronizados
+[repositorio](../learners/reference.md#repositorio). Los repositorios pueden mantenerse sincronizados
en diferentes computadoras, facilitando así la colaboración entre diferentes personas.
-> ## La larga historia de los sistemas de control de versiones
->
-> Los sistemas automatizados de control de versiones no son nada nuevo.
-> Herramientas como RCS, CVS o Subversion han existido desde principios de los 1980 y son utilizadas por muchas grandes empresas.
-> Sin embargo, muchos de estos han sido relegados debido a lo limitado de su capacidad.
-> En particular, los sistemas más modernos, como Git y [Mercurial](http://swcarpentry.github.io/hg-novice/)
-> son *distribuidos*, lo que significa que no necesitan un servidor centralizado para alojar el repositorio.
-> Estos sistemas modernos también incluyen potentes herramientas de fusión que hacen posible que múltiples autores trabajen dentro de
-> los mismos archivos simultáneamente.
-{:.callout}
-
-> ## ¿Qué harías en las siguientes situaciones?
->
-> Imagina que has redactado un excelente párrafo para un artículo que estás escribiendo, pero más tarde lo estropeas. ¿Cómo recuperarías
-> aquella *excelente* versión de la conclusión? ¿Es esto posible?
->
-> Imagina que tienes 5 coautores. ¿Cómo administrarías los cambios y comentarios que ellos hagan en el artículo?
-> Si usas LibreOffice Writer o Microsoft Word, ¿qué sucede si aceptas los cambios realizados con la opción
-> ` Track Changes`? ¿Tienes un historial de esos cambios?
-{: .challenge}
-
-
-{% include links.md %}
+:::::::::::::::::::::::::::::::::::::::::: callout
+
+## La larga historia de los sistemas de control de versiones
+
+Los sistemas automatizados de control de versiones no son nada nuevo.
+Herramientas como RCS, CVS o Subversion han existido desde principios de los 1980 y son utilizadas por muchas grandes empresas.
+Sin embargo, muchos de estos han sido relegados debido a lo limitado de su capacidad.
+En particular, los sistemas más modernos, como Git y [Mercurial](https://swcarpentry.github.io/hg-novice/)
+son *distribuidos*, lo que significa que no necesitan un servidor centralizado para alojar el repositorio.
+Estos sistemas modernos también incluyen potentes herramientas de fusión que hacen posible que múltiples autores trabajen dentro de
+los mismos archivos simultáneamente.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## ¿Qué harías en las siguientes situaciones?
+
+Imagina que has redactado un excelente párrafo para un artículo que estás escribiendo, pero más tarde lo estropeas. ¿Cómo recuperarías
+aquella *excelente* versión de la conclusión? ¿Es esto posible?
+
+Imagina que tienes 5 coautores. ¿Cómo administrarías los cambios y comentarios que ellos hagan en el artículo?
+Si usas LibreOffice Writer o Microsoft Word, ¿qué sucede si aceptas los cambios realizados con la opción
+` Track Changes`? ¿Tienes un historial de esos cambios?
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- El control de versiones es como un 'deshacer' sin límites.
+- El control de versiones permite que mucha gente trabaje en lo mismo en paralelo.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/episodes/02-setup.md b/episodes/02-setup.md
index b696310c..83b37d74 100644
--- a/episodes/02-setup.md
+++ b/episodes/02-setup.md
@@ -2,146 +2,167 @@
title: Configurando Git
teaching: 5
exercises: 0
-questions:
-- "¿Cómo me preparo para utilizar Git?"
-objectives:
-- "Configurar `git` la primera vez que utilice la computadora."
-- "Comprender el significado del flag de configuración `--global`."
-keypoints:
-- "Use `git config` para configurar un nombre de usuario, email, editor, y otras preferencias."
---
-Cuando usamos Git en una computadora por primera vez,
-es necesario configurar algunas cosas. A continuación se presentan algunos ejemplos
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Configurar `git` la primera vez que utilice la computadora.
+- Comprender el significado del flag de configuración `--global`.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Cómo me preparo para utilizar Git?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+Cuando usamos Git en una computadora por primera vez,
+es necesario configurar algunas cosas. A continuación se presentan algunos ejemplos
de configuraciones que estableceremos a medida que trabajemos con Git:
-* nombre y correo electrónico,
-* cuál es nuestro editor de texto preferido,
-* y que queremos utilizar estos ajustes globalmente (es decir, para cada proyecto).
+- nombre y correo electrónico,
+- cuál es nuestro editor de texto preferido,
+- y que queremos utilizar estos ajustes globalmente (es decir, para cada proyecto).
-En la línea de comandos, los comandos de Git se escriben como `git verb`,
-donde` verb` es lo que queremos hacer. Así es como
+En la línea de comandos, los comandos de Git se escriben como `git verb`,
+donde` verb` es lo que queremos hacer. Así es como
Drácula configura su nueva computadora:
-~~~
+```bash
$ git config --global user.name "Vlad Dracula"
$ git config --global user.email "vlad@tran.sylvan.ia"
-~~~
-{: .language-bash}
+```
-Utiliza tu propio nombre y dirección de correo electrónico en lugar de los de Drácula. El nombre de usuario y el correo electrónico se asociarán con tu actividad posterior de Git,
+Utiliza tu propio nombre y dirección de correo electrónico en lugar de los de Drácula. El nombre de usuario y el correo electrónico se asociarán con tu actividad posterior de Git,
lo que significa que cualquier cambio realizado en
-[GitHub](http://github.com/),
-[BitBucket](http://bitbucket.org/),
-[GitLab](http://gitlab.com/) u
-otro servidor de Git
+[GitHub](https://github.com/),
+[BitBucket](https://bitbucket.org/),
+[GitLab](https://gitlab.com/) u
+otro servidor de Git
en una lección posterior incluirá esta información.
-> ## Finales de línea
->
-> Al igual que con otras teclas, cuando haces click en la tecla 'Enter' de tu teclado,
-> tu computadora codifica este input como un caracter.
-> Por razones que son demasiado largas para explicar aquí, diferentes sistemas operativos
-> usan diferentes caracteres para representar el final de una línea.
-> (También son conocidas como *newlines* o *line breaks*.)
-> Como Git usa éstos caracteres para comparar archivos,
-> esto puede causar problemas inesperados cuando se edita un archivo en máquinas diferentes.
->
-> Puedes cambiar el modo en que Git reconoce y codifica finales de línea
-> usando el comando `core.autocrlf` con `git config`.
-> Se recomiendan las siguientes configuraciones:
->
-> En OS X y Linux:
->
-> ~~~
-> $ git config --global core.autocrlf input
-> ~~~
-> {: .language-bash}
->
-> Y en Windows:
->
-> ~~~
-> $ git config --global core.autocrlf true
-> ~~~
-> {: .language-bash}
->
-> Puedes leer más sobre este tema
-> [en esta página de GitHub](https://help.github.com/articles/dealing-with-line-endings/).
-{: .callout}
-
-Para estas lecciones, estaremos interactuando con [GitHub](http://github.com/), por lo tanto la dirección de correo electrónico utilizada debe ser la misma que utilizaste al configurar tu cuenta de GitHub. Si te preocupa la privacidad, revisa [las instrucciones de GitHub para mantener tu dirección de correo electrónico privada][git-privacy].
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Finales de línea
+
+Al igual que con otras teclas, cuando haces click en la tecla 'Enter' de tu teclado,
+tu computadora codifica este input como un caracter.
+Por razones que son demasiado largas para explicar aquí, diferentes sistemas operativos
+usan diferentes caracteres para representar el final de una línea.
+(También son conocidas como *newlines* o *line breaks*.)
+Como Git usa éstos caracteres para comparar archivos,
+esto puede causar problemas inesperados cuando se edita un archivo en máquinas diferentes.
+
+Puedes cambiar el modo en que Git reconoce y codifica finales de línea
+usando el comando `core.autocrlf` con `git config`.
+Se recomiendan las siguientes configuraciones:
+
+En OS X y Linux:
+
+```bash
+$ git config --global core.autocrlf input
+```
+
+Y en Windows:
+
+```bash
+$ git config --global core.autocrlf true
+```
+
+Puedes leer más sobre este tema
+[en esta página de GitHub](https://help.github.com/articles/dealing-with-line-endings/).
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+Para estas lecciones, estaremos interactuando con [GitHub](https://github.com/), por lo tanto la dirección de correo electrónico utilizada debe ser la misma que utilizaste al configurar tu cuenta de GitHub. Si te preocupa la privacidad, revisa [las instrucciones de GitHub para mantener tu dirección de correo electrónico privada][git-privacy].
Si eliges utilizar una dirección de correo electrónico privada con GitHub, usa la misma dirección de correo electrónico para el valor `user.email`, por ejemplo, `username@users.noreply.github.com` reemplazando` username` con tu nombre de usuario de GitHub. Puedes cambiar la dirección de correo electrónico posteriormente utilizando el comando `git config` nuevamente.
Drácula también tiene que establecer su editor de texto favorito, siguiendo esta tabla:
-| Editor | Comando de configuración |
-|:-------------------|:-------------------------------------------------|
-| Atom | `$ git config --global core.editor "atom --wait"`|
-| nano | `$ git config --global core.editor "nano -w"` |
-| TextWrangler (Mac) | `$ git config --global core.editor "edit -w"` |
-| Sublime Text (Mac) | `$ git config --global core.editor "subl -n -w"` |
-| Sublime Text (Win, 32-bit) | `$ git config --global core.editor "'c:/program files (x86)/sublime text 3/sublime_text.exe' -w"` |
-| Sublime Text (Win, 64-bit) | `$ git config --global core.editor "'c:/program files/sublime text 3/sublime_text.exe' -w"` |
-| Notepad++ (Win, 32-bitl) | `$ git config --global core.editor "'c:/program files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"`|
-| Notepad++ (Win, 64-bit) | `$ git config --global core.editor "'c:/program files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"`|
-| Kate (Linux) | `$ git config --global core.editor "kate"` |
-| Gedit (Linux) | `$ git config --global core.editor "gedit --wait --new-window"` |
-| Scratch (Linux) | `$ git config --global core.editor "scratch-text-editor"` |
-| emacs | `$ git config --global core.editor "emacs"` |
-| vim | `$ git config --global core.editor "vim"` |
-| Visual Studio Code | `$ git config --global core.editor "code --wait"` |
+| Editor | Comando de configuración |
+| :------------------------- | :----------------------- |
+| Atom | `$ git config --global core.editor "atom --wait"` |
+| nano | `$ git config --global core.editor "nano -w"` |
+| TextWrangler (Mac) | `$ git config --global core.editor "edit -w"` |
+| Sublime Text (Mac) | `$ git config --global core.editor "subl -n -w"` |
+| Sublime Text (Win, 32-bit) | `$ git config --global core.editor "'c:/program files (x86)/sublime text 3/sublime_text.exe' -w"` |
+| Sublime Text (Win, 64-bit) | `$ git config --global core.editor "'c:/program files/sublime text 3/sublime_text.exe' -w"` |
+| Notepad++ (Win, 32-bitl) | `$ git config --global core.editor "'c:/program files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"` |
+| Notepad++ (Win, 64-bit) | `$ git config --global core.editor "'c:/program files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"` |
+| Kate (Linux) | `$ git config --global core.editor "kate"` |
+| Gedit (Linux) | `$ git config --global core.editor "gedit --wait --new-window"` |
+| Scratch (Linux) | `$ git config --global core.editor "scratch-text-editor"` |
+| emacs | `$ git config --global core.editor "emacs"` |
+| vim | `$ git config --global core.editor "vim"` |
+| Visual Studio Code | `$ git config --global core.editor "code --wait"` |
Es posible reconfigurar el editor de texto para Git siempre que quieras.
-> ## Saliendo de Vim
->
->Ten en cuenta que `vim` es el editor por defecto para muchos programas, si no has utilizado` vim` antes y deseas salir de una sesión, presiona la tecla `Esc` y posteriormente escribe `: q!` y `Enter`.
-{: .callout}
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Saliendo de Vim
+
+Ten en cuenta que `vim` es el editor por defecto para muchos programas, si no has utilizado` vim` antes y deseas salir de una sesión, presiona la tecla `Esc` y posteriormente escribe `: q!` y `Enter`.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
Los cuatro comandos que acabamos de ejecutar sólo se tienen que ejecutar una vez: la flag `--global` le dice a Git que use la configuración para cada proyecto, en tu cuenta de usuario, en esta computadora.
Puedes comprobar tu configuración en cualquier momento:
-~~~
+```bash
$ git config --list
-~~~
-{: .language-bash}
+```
Puedes cambiar la configuración tantas veces como quieras: sólo usa los mismos comandos para elegir otro editor o actualizar tu correo electrónico.
-> ## Proxy
->
-> En algunas redes es necesario usar un
-> [proxy](https://en.wikipedia.org/wiki/Proxy_server). Si este es el caso, es
-> posible que también necesites proporcionarle a Git el proxy:
->
-> ~~~
-> $ git config --global http.proxy proxy-url
-> $ git config --global https.proxy proxy-url
-> ~~~
-> {: .language-bash}
->
-> Para deshabilitar el proxy, utiliza
->
-> ~~~
-> $ git config --global --unset http.proxy
-> $ git config --global --unset https.proxy
-> ~~~
-> {: .language-bash}
-{: .callout}
-
-> ## Ayuda y manual de Git
->
-> Ten presente que si no recuerdas algún comando de `git`, puedes acceder a la lista de comandos utilizando la opción `-h` y al manual de Git con la flag `--help` :
->
-> ~~~
-> $ git config -h
-> $ git config --help
-> ~~~
-> {: .language-bash}
-{: .callout}
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Proxy
+
+En algunas redes es necesario usar un
+[proxy](https://en.wikipedia.org/wiki/Proxy_server). Si este es el caso, es
+posible que también necesites proporcionarle a Git el proxy:
+
+```bash
+$ git config --global http.proxy proxy-url
+$ git config --global https.proxy proxy-url
+```
+
+Para deshabilitar el proxy, utiliza
+
+```bash
+$ git config --global --unset http.proxy
+$ git config --global --unset https.proxy
+```
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Ayuda y manual de Git
+
+Ten presente que si no recuerdas algún comando de `git`, puedes acceder a la lista de comandos utilizando la opción `-h` y al manual de Git con la flag `--help` :
+
+```bash
+$ git config -h
+$ git config --help
+```
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
[git-privacy]: https://help.github.com/articles/keeping-your-email-address-private/
-{% include links.md %}
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- Use `git config` para configurar un nombre de usuario, email, editor, y otras preferencias.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/episodes/03-create.md b/episodes/03-create.md
index f11e964e..986df808 100644
--- a/episodes/03-create.md
+++ b/episodes/03-create.md
@@ -2,52 +2,53 @@
title: Creando un repositorio
teaching: 10
exercises: 0
-questions:
-- "¿Dónde almacena Git la información?"
-objectives:
-- "Crear un repositorio local de Git."
-keypoints:
-- "`git init` inicializa un repositorio."
---
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Crear un repositorio local de Git.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Dónde almacena Git la información?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
Una vez que Git está configurado,
podemos comenzar a usarlo.
Vamos a crear un directorio para nuestro trabajo y nos movemos dentro de ese directorio:
-~~~
+```bash
$ mkdir planets
$ cd planets
-~~~
-{: .language-bash}
+```
-Después le indicamos a Git hacer de `planets` un [repository]({{ page.root }}/reference#repositorio)— un lugar donde
+Después le indicamos a Git hacer de `planets` un [repository](../learners/reference.md#repositorio)— un lugar donde
Git puede almacenar las versiones de nuestros archivos:
-~~~
+```bash
$ git init
-~~~
-{: .language-bash}
+```
Si usamos `ls` para mostrar el contenido del directorio,
parece que nada ha cambiado:
-~~~
+```bash
$ ls
-~~~
-{: .language-bash}
+```
Pero si agregamos la flag `-a` para mostrar todo,
podemos ver que Git ha creado un directorio oculto dentro de `planets` llamado `.git`:
-~~~
+```bash
$ ls -a
-~~~
-{: .language-bash}
+```
-~~~
+```output
. .. .git
-~~~
-{: .output}
+```
Git utiliza este subdirectorio especial para almacenar toda la información del proyecto, incluyendo todos los archivos y subdirectorios. Si alguna vez borramos el directorio `.git`,
perderemos la historia del proyecto.
@@ -55,90 +56,104 @@ perderemos la historia del proyecto.
Podemos revisar que todo esté configurado correctamente
pidiendo a Git que nos informe el estado de nuestro proyecto:
-~~~
+```bash
$ git status
-~~~
-{: .language-bash}
+```
-Si estás utilizando una versión de git distinta a la que yo utilizo, el output puede ser ligeramente distinto.
+Si estás utilizando una versión de git distinta a la que yo utilizo, el output puede ser ligeramente distinto.
-~~~
+```output
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)
-~~~
-{: .output}
-
-> ## Lugares para crear un repositorio Git
->
-> Ademas de rastrear la información sobre los planetas (el proyecto que ya creamos), Drácula también quiere
-> rastrear la información sobre las lunas. A pesar de las preocupaciones de Wolfman, Drácula crea el sub-directorio
-> `moons` dentro de su directorio `planets` ingresando la siguiente secuencia de comandos:
->
-> ~~~
-> $ cd # volver al directorio de inicio
-> $ mkdir planets # crear un nuevo diretorio llamado planets
-> $ cd planets # entrar al directorio planets
-> $ git init # hacer del directorio planets directory un repositorio Git
-> $ mkdir moons # crear un subdirectorio planets/moons
-> $ cd moons # entrar al directorio planets/moons
-> $ git init # hacer del subdirectorio moons un repositorio Git
-> ~~~
-> {: .language-bash}
->
-> ¿Es necesario correr el comando `git init` en el sub-directorio `moons` para poder realizar el seguimiento de los archivos almacenados en este directorio?
->
-> > ## Solución
-> >
-> > No. Dracula no necesita transformar el sub-directorio `moons` en un repositorio Git,
-> > porque el repositorio `planets` realizará el seguimiento de todos los archivos,
-> > sub-directorios y archivos de los sub-directorios dentro del directorio `planets`.
-> > Entonces, a fin de poder hacer un seguimiento de toda la información sobre `moons`,
-> > Dracula sólo necesita agregar el sub-directorio `moons` al directorio `planets`.
-> >
-> > Además, los repositorios Git pueden interferir entre sí si están "anidados" dentro de
-> > otro directorio: el repositorio exterior intentará controlar la versión
-> > del repositorio interno. Por lo tanto, lo mejor es crear cada nuevo repositorio Git
-> > en un directorio separado. Para asegurarte que no hay un repositorio en conflicto
-> > en el directorio, revisa el output de `git status`. Si se parece a
-> > lo siguiente, podrás crear un nuevo repositorio como se ha mostrado
-> > arriba:
-> >
-> > ~~~
-> > $ git status
-> > ~~~
-> > {: .language-bash}
-> >
-> > ~~~
-> > fatal: Not a git repository (or any of the parent directories): .git
-> > ~~~
-> > {: .output}
-> >
-> {: .solution}
-{: .challenge}
-
-> ## Corrigiendo errores de `git init`
->
-> Wolfman le explica a Dracula cómo un repositorio anidado es redudante y puede causar problemas ms adelante.
-> Dracula quiere eliminar el repositorio anidado. Cómo puede Dracula deshacer el último `git init` en el sub-directorio `moons`?
->
-> > ## Solución - USAR CON CUIDADO!
-> >
-> > Para deshacerse de este pequeño error, Dracula puede simplemente eliminar el directorio `.git`
-> > del subdirectorio `moons`. Para ello puede ejecutar el siguiente comando desde el interior del directorio `moons`:
-> >
-> > ~~~
-> > $ rm -rf moons/.git
-> > ~~~
-> > {: .language-bash}
-> >
-> > ¡Pero ten cuidado! Ejecutar este comando en el directorio incorrecto eliminará
-> > toda la historia git de un proyecto que podrías querer conservar.
-> > Por lo tanto, revisa siempre tu directorio actual usando el comando `pwd`.
-> {: .solution}
-{: .challenge}
-
-
-{% include links.md %}
+```
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Lugares para crear un repositorio Git
+
+Ademas de rastrear la información sobre los planetas (el proyecto que ya creamos), Drácula también quiere
+rastrear la información sobre las lunas. A pesar de las preocupaciones de Wolfman, Drácula crea el sub-directorio
+`moons` dentro de su directorio `planets` ingresando la siguiente secuencia de comandos:
+
+```bash
+$ cd # volver al directorio de inicio
+$ mkdir planets # crear un nuevo diretorio llamado planets
+$ cd planets # entrar al directorio planets
+$ git init # hacer del directorio planets directory un repositorio Git
+$ mkdir moons # crear un subdirectorio planets/moons
+$ cd moons # entrar al directorio planets/moons
+$ git init # hacer del subdirectorio moons un repositorio Git
+```
+
+¿Es necesario correr el comando `git init` en el sub-directorio `moons` para poder realizar el seguimiento de los archivos almacenados en este directorio?
+
+::::::::::::::: solution
+
+## Solución
+
+No. Dracula no necesita transformar el sub-directorio `moons` en un repositorio Git,
+porque el repositorio `planets` realizará el seguimiento de todos los archivos,
+sub-directorios y archivos de los sub-directorios dentro del directorio `planets`.
+Entonces, a fin de poder hacer un seguimiento de toda la información sobre `moons`,
+Dracula sólo necesita agregar el sub-directorio `moons` al directorio `planets`.
+
+Además, los repositorios Git pueden interferir entre sí si están "anidados" dentro de
+otro directorio: el repositorio exterior intentará controlar la versión
+del repositorio interno. Por lo tanto, lo mejor es crear cada nuevo repositorio Git
+en un directorio separado. Para asegurarte que no hay un repositorio en conflicto
+en el directorio, revisa el output de `git status`. Si se parece a
+lo siguiente, podrás crear un nuevo repositorio como se ha mostrado
+arriba:
+
+```bash
+$ git status
+```
+
+```output
+fatal: Not a git repository (or any of the parent directories): .git
+```
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Corrigiendo errores de `git init`
+
+Wolfman le explica a Dracula cómo un repositorio anidado es redudante y puede causar problemas ms adelante.
+Dracula quiere eliminar el repositorio anidado. Cómo puede Dracula deshacer el último `git init` en el sub-directorio `moons`?
+
+::::::::::::::: solution
+
+## Solución - USAR CON CUIDADO!
+
+Para deshacerse de este pequeño error, Dracula puede simplemente eliminar el directorio `.git`
+del subdirectorio `moons`. Para ello puede ejecutar el siguiente comando desde el interior del directorio `moons`:
+
+```bash
+$ rm -rf moons/.git
+```
+
+¡Pero ten cuidado! Ejecutar este comando en el directorio incorrecto eliminará
+toda la historia git de un proyecto que podrías querer conservar.
+Por lo tanto, revisa siempre tu directorio actual usando el comando `pwd`.
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- `git init` inicializa un repositorio.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/episodes/04-changes.md b/episodes/04-changes.md
index 389b2125..0109f4c7 100644
--- a/episodes/04-changes.md
+++ b/episodes/04-changes.md
@@ -2,36 +2,36 @@
title: Rastreando Cambios
teaching: 20
exercises: 0
-questions:
-- "¿Cómo registro cambios en Git?"
-- "¿Cómo reviso el estatus de mi repositorio de control de versiones?"
-- "¿Cómo registro notas acerca de los cambios que he hecho y por qué?"
-objectives:
-- "Ir a través del ciclo modificar-agregar-commit para uno o más archivos."
-- "Explicar dónde se almacena la información en cada etapa del flujo de trabajo de un **commit** de Git."
-- "Distinguir entre mensajes descriptivos y no-descriptivos de un **commit**."
-keypoints:
-- "`git status` muestra el estatus de un repositorio."
-- "Los archivos pueden ser almacenados en un directorio de trabajo del proyecto (el cual ven los usuarios), el **staging area** (donde el siguiente **commit** está siendo construido) y el repositorio local (donde los **commits** son registrados permanentemente)."
-- "`git add` pone archivos en el **staging area**."
-- "`git commit` guarda el contenido del **staging area** como un nuevo **commit** en el repositorio local."
-- "Siempre escribe un mensaje de registro cuando hagas un **commit** con cambios."
---
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Ir a través del ciclo modificar-agregar-commit para uno o más archivos.
+- Explicar dónde se almacena la información en cada etapa del flujo de trabajo de un **commit** de Git.
+- Distinguir entre mensajes descriptivos y no-descriptivos de un **commit**.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Cómo registro cambios en Git?
+- ¿Cómo reviso el estatus de mi repositorio de control de versiones?
+- ¿Cómo registro notas acerca de los cambios que he hecho y por qué?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
Primero asegúrate que estamos aún en el directorio correcto.
Deberías estar en el directorio `planets`.
-~~~
+```bash
$ pwd
-~~~
-{: .language-bash}
+```
Si aún estás en `moons` navega de regreso a `planets`
-~~~
+```bash
$ cd ..
-~~~
-{: .language-bash}
+```
Vamos a crear un archivo llamado `mars.txt` que contiene algunas notas
sobre la aptitud del Planeta Rojo como base.
@@ -39,49 +39,42 @@ Usaremos `nano` para editar el archivo;
puedes usar el editor que prefieras.
En particular, éste no tiene que ser el `core.editor` que definiste globalmente con anterioridad. Pero recuerda, los comandos **bash** para crear o editar un nuevo archivo van a depender del editor que tú escojas (podría no ser `nano`). Para un repaso sobre editores de texto, echa un vistazo a ["¿Qué editor usar?"](https://swcarpentry.github.io/shell-novice-es/03-create/) en la lección [La terminal de Unix](https://swcarpentry.github.io/shell-novice-es) .
-~~~
+```bash
$ nano mars.txt
-~~~
-{: .language-bash}
+```
Ingresa el texto siguiente en el archivo `mars.txt`:
-~~~
+```output
Cold and dry, but everything is my favorite color
-~~~
-{: .output}
+```
`mars.txt` ahora contiene una sola línea, la cual podemos ver ejecutando:
-~~~
+```bash
$ ls
-~~~
-{: .language-bash}
+```
-~~~
+```output
mars.txt
-~~~
-{: .output}
+```
-~~~
+```bash
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
Cold and dry, but everything is my favorite color
-~~~
-{: .output}
+```
Si revisamos el estatus de nuestro proyecto otra vez,
Git nos dice que ha reconocido el nuevo archivo:
-~~~
+```bash
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Initial commit
@@ -91,26 +84,23 @@ Untracked files:
mars.txt
nothing added to commit but untracked files present (use "git add" to track)
-~~~
-{: .output}
+```
-El mensaje de "untracked files" significa que
+El mensaje de "untracked files" significa que
un archivo no está siendo rastreado por Git.
Podemos poner los archivos en el **staging area** con `git add`.
-~~~
+```bash
$ git add mars.txt
-~~~
-{: .language-bash}
+```
y luego verifica que hizo lo correcto:
-~~~
+```bash
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Initial commit
@@ -120,31 +110,28 @@ Changes to be committed:
new file: mars.txt
-~~~
-{: .output}
+```
Git ahora sabe que tiene que seguir la pista de `mars.txt`,
pero no ha registrado los cambios con un **commit** aún.
Para que lo haga,
necesitamos ejecutar un comando más:
-~~~
+```bash
$ git commit -m "Start notes on Mars as a base"
-~~~
-{: .language-bash}
+```
-~~~
+```output
[master (root-commit) f22b25e] Start notes on Mars as a base
1 file changed, 1 insertion(+)
create mode 100644 mars.txt
-~~~
-{: .output}
+```
Cuando ejecutamos `git commit`,
Git toma todo lo que le hemos dicho que salve usando `git add`
y almacena una copia permanentemente dentro del directorio especial `.git`.
-Esta copia permanente es llamada un [commit]({{ page.root }}/reference#commit)
-(o [revision]({{ page.root }}/reference#revisin)) y su identificador corto es `f22b25e`
+Esta copia permanente es llamada un [commit](../learners/reference.md#commit)
+(o [revision](../learners/reference.md#revisin)) y su identificador corto es `f22b25e`
(Tu **commit** podría tener otro identificador.)
Usamos la **flag** `-m` (por "message")
@@ -153,40 +140,36 @@ Si ejecutamos `git commit` sin la opción `-m`,
Git ejecutará `nano` (o cualquier otro editor que hayamos configurado como `core.editor`)
para que podamos escribir un mensaje más largo.
-[Los Buenos mensajes en un **commit**][commit-messages] inician con un breve resumen (<50 caracteres) de los
+[Los Buenos mensajes en un **commit**][commit-messages] inician con un breve resumen (\<50 caracteres) de los
cambios hechos en el **commit**. Si quieres entrar en más detalles, agrega
una línea blanca entre la línea del resumen y tus notas adicionales.
Si ejecutamos `git status` ahora:
-~~~
+```bash
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
nothing to commit, working directory clean
-~~~
-{: .output}
+```
nos dice que todo está actualizado.
Si queremos saber lo que hemos hecho recientemente,
podemos pedir a Git que nos muestre la historia del proyecto usando `git log`:
-~~~
+```bash
$ git log
-~~~
-{: .language-bash}
+```
-~~~
+```output
commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
Author: Vlad Dracula
Date: Thu Aug 22 09:51:46 2013 -0400
Start notes on Mars as a base
-~~~
-{: .output}
+```
`git log` lista todos los **commits** hechos a un repositorio en orden cronológico inverso.
El listado de cada **commit** incluye
@@ -197,40 +180,41 @@ el autor del **commit**,
cuándo fue creado,
y el mensaje de registro que se le dio a Git cuando el **commit** fue creado.
-> ## ¿Dónde están mis cambios?
->
-> Si ejecutamos `ls` en este punto, aún veremos un solo archivo llamado `mars.txt`.
-> Esto es porque Git guarda información acerca de la historia de los archivos
-> en el directorio especial `.git` mencionado antes
->para que nuestro sistema de archivos no se abarrote
-> (y para que no podamos editar o borrar accidentalmente una versión anterior).
-{: .callout}
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## ¿Dónde están mis cambios?
+
+Si ejecutamos `ls` en este punto, aún veremos un solo archivo llamado `mars.txt`.
+Esto es porque Git guarda información acerca de la historia de los archivos
+en el directorio especial `.git` mencionado antes
+para que nuestro sistema de archivos no se abarrote
+(y para que no podamos editar o borrar accidentalmente una versión anterior).
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
Ahora supón que Dracula agrega más información al archivo.
(Otra vez, editaremos con `nano` y luego con `cat` mostraremos el contenido del archivo;
podrías usar un editor diferente y no necesitar `cat`.)
-~~~
+```bash
$ nano mars.txt
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
-~~~
-{: .output}
+```
Cuando ejecutamos `git status` ahora
nos dice que un archivo ya sabe que ha sido modificado:
-~~~
+```bash
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Changes not staged for commit:
(use "git add ..." to update what will be committed)
@@ -239,8 +223,7 @@ Changes not staged for commit:
modified: mars.txt
no changes added to commit (use "git add" and/or "git commit -a")
-~~~
-{: .output}
+```
La última línea es la frase clave:
"no changes added to commit".
@@ -253,12 +236,11 @@ nuestros cambios antes de guardarlos. Hacemos esto usando `git diff`.
Esto nos muestra las diferencias entre el estado actual
del archivo y la versión guardada más reciente:
-~~~
+```bash
$ git diff
-~~~
-{: .language-bash}
+```
-~~~
+```output
diff --git a/mars.txt b/mars.txt
index df0654a..315bf3a 100644
--- a/mars.txt
@@ -266,34 +248,32 @@ index df0654a..315bf3a 100644
@@ -1 +1,2 @@
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
-~~~
-{: .output}
+```
-La salida es críptica porque
+La salida es críptica porque
en realidad es una serie de comandos para herramientas como editores y `patch`
que les dice cómo reconstruir un archivo a partir del otro.
Si lo dividimos en secciones:
-1. La primera línea nos dice que Git está produciendo un **output** similar al del comando Unix `diff`
- comparando las versiones anterior y nueva del archivo.
-2. La segunda línea dice exactamente qué versiones del archivo
- está comparando Git;
- `df0654a` y `315bf3a` son etiquetas únicas generadas por computadora para esas versiones.
-3. Las líneas tercera y cuarta muestran una vez más el nombre del archivo que se está cambiando.
-4. Las líneas restantes son las más interesantes, ellas nos muestran las diferencias en cuestión
- y las líneas donde ellas ocurren.
- En particular,
- el marcador `+` en la primera columna muestra dónde agregamos una línea.
+1. La primera línea nos dice que Git está produciendo un **output** similar al del comando Unix `diff`
+ comparando las versiones anterior y nueva del archivo.
+2. La segunda línea dice exactamente qué versiones del archivo
+ está comparando Git;
+ `df0654a` y `315bf3a` son etiquetas únicas generadas por computadora para esas versiones.
+3. Las líneas tercera y cuarta muestran una vez más el nombre del archivo que se está cambiando.
+4. Las líneas restantes son las más interesantes, ellas nos muestran las diferencias en cuestión
+ y las líneas donde ellas ocurren.
+ En particular,
+ el marcador `+` en la primera columna muestra dónde agregamos una línea.
Después de revisar nuestro cambio, es tiempo de hacer un **commit** de eso:
-~~~
+```bash
$ git commit -m "Add concerns about effects of Mars' moons on Wolfman"
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Changes not staged for commit:
(use "git add ..." to update what will be committed)
@@ -302,24 +282,21 @@ Changes not staged for commit:
modified: mars.txt
no changes added to commit (use "git add" and/or "git commit -a")
-~~~
-{: .output}
+```
¡Vaya!:
Git no hará **commit** porque no usamos `git add` primero.
Arreglemos esto:
-~~~
+```bash
$ git add mars.txt
$ git commit -m "Add concerns about effects of Mars' moons on Wolfman"
-~~~
-{: .language-bash}
+```
-~~~
+```output
[master 34961b1] Add concerns about effects of Mars' moons on Wolfman
1 file changed, 1 insertion(+)
-~~~
-{: .output}
+```
Git insiste en que agreguemos archivos al conjunto de cambios que queremos hacer
antes de hacer **commit** de alguna cosa. Esto permite hacer **commit** de nuestros
@@ -332,33 +309,36 @@ y su correspondiente registro bibliográfico,
pero *no* hacer **commit** del trabajo que estamos haciendo sobre la conclusión
(el cual no hemos terminado aún).
-
Para permitir esto,
Git tiene un *staging area* especial
-donde mantiene registro de cosas que han sido agregadas al actual [changeset]({{ page.root }}/reference#changeset)
+donde mantiene registro de cosas que han sido agregadas al actual [changeset](../learners/reference.md#changeset)
pero aún no se han vuelto **commit**.
-> ## Staging Area
->
-> Si piensas en Git como tomar instantáneas de cambios durante la vida de un proyecto,
-> `git add` especifica *qué* irá en una instantánea
-> (poniendo cosas en el **staging area**),
-> y `git commit` entonces *realmente toma* la instantánea, y
-> genera un registro permanente de esto (como un **commit**).
-> Si no tienes nada en el staging area cuando escribes `git commit`,
-> Git te pedirá que uses `git commit -a` o `git commit --all`,
-> ¡Que es como reunir *a todos* para la foto!
-> Sin embargo, es casi siempre mejor
-> agregar explícitamente cosas al **staging area**, porque podrías
-> hacer **commit** de cambios que habías olvidado. (Volviendo a las instantáneas,
-> podrías capturar al extra con el maquillaje incompleto caminando en el escenario para la toma
-> porque usaste `-a`!)
-> Trata de organizar las cosas manualmente
-> o podrías encontrarte buscando "deshacer git commit" más
-> de lo que te gustaría!
-{: .callout}
-
-
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Staging Area
+
+Si piensas en Git como tomar instantáneas de cambios durante la vida de un proyecto,
+`git add` especifica *qué* irá en una instantánea
+(poniendo cosas en el **staging area**),
+y `git commit` entonces *realmente toma* la instantánea, y
+genera un registro permanente de esto (como un **commit**).
+Si no tienes nada en el staging area cuando escribes `git commit`,
+Git te pedirá que uses `git commit -a` o `git commit --all`,
+¡Que es como reunir *a todos* para la foto!
+Sin embargo, es casi siempre mejor
+agregar explícitamente cosas al **staging area**, porque podrías
+hacer **commit** de cambios que habías olvidado. (Volviendo a las instantáneas,
+podrías capturar al extra con el maquillaje incompleto caminando en el escenario para la toma
+porque usaste `-a`!)
+Trata de organizar las cosas manualmente
+o podrías encontrarte buscando "deshacer git commit" más
+de lo que te gustaría!
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+{alt='The Git Staging Area'}
Veamos cómo nuestros cambios a un archivo se mueven de nuestro editor
al **staging area**
@@ -366,25 +346,22 @@ y luego al almacenamiento de largo plazo.
Primero,
agregamos otra línea al archivo:
-~~~
+```bash
$ nano mars.txt
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
-~~~
-{: .output}
+```
-~~~
+```bash
$ git diff
-~~~
-{: .language-bash}
+```
-~~~
+```output
diff --git a/mars.txt b/mars.txt
index 315bf3a..b36abfd 100644
--- a/mars.txt
@@ -394,8 +371,7 @@ index 315bf3a..b36abfd 100644
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidity
-~~~
-{: .output}
+```
Hasta aquí, todo bien:
hemos agregado una línea al final del archivo
@@ -403,11 +379,10 @@ hemos agregado una línea al final del archivo
Ahora pongamos el cambio en el **staging area**
y veamos lo que reporta `git diff`:
-~~~
+```bash
$ git add mars.txt
$ git diff
-~~~
-{: .language-bash}
+```
No hay **output**:
hasta donde Git puede decir,
@@ -416,12 +391,11 @@ y lo que actualmente está en el directorio.
Sin embargo,
si hacemos esto:
-~~~
+```bash
$ git diff --staged
-~~~
-{: .language-bash}
+```
-~~~
+```output
diff --git a/mars.txt b/mars.txt
index 315bf3a..b36abfd 100644
--- a/mars.txt
@@ -430,46 +404,40 @@ index 315bf3a..b36abfd 100644
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidity
-~~~
-{: .output}
+```
esto nos muestra la diferencia entre
el último cambio que sí hizo **commit**
y lo que está en el **staging area**.
Guardemos nuestros cambios:
-~~~
+```bash
$ git commit -m "Discuss concerns about Mars' climate for Mummy"
-~~~
-{: .language-bash}
+```
-~~~
+```output
[master 005937f] Discuss concerns about Mars' climate for Mummy
1 file changed, 1 insertion(+)
-~~~
-{: .output}
+```
revisa nuestro estatus:
-~~~
+```bash
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
nothing to commit, working directory clean
-~~~
-{: .output}
+```
y mira en la historia lo que hemos hecho hasta aquí:
-~~~
+```bash
$ git log
-~~~
-{: .language-bash}
+```
-~~~
+```output
commit 005937fbe2a98fb83f0ade869025dc2636b4dad5
Author: Vlad Dracula
Date: Thu Aug 22 10:14:07 2013 -0400
@@ -487,336 +455,378 @@ Author: Vlad Dracula
Date: Thu Aug 22 09:51:46 2013 -0400
Start notes on Mars as a base
-~~~
-{: .output}
-
-> ## Diferencias basadas en palabras
->
-> A veces, por ejemplo en el caso de documentos de texto, un diff por líneas
-> es demasiado caótico. Es en ese caso donde la opción `--color-words` de
-> `git diff` se vuelve muy útil ya que resalta las palabras
-> modificadas usando colores.
-{: .callout}
-
-> ## Paginación del Registro
->
-> Cuando el **output** de `git log` es demasiado largo para caber en tu pantalla,
-> `git` usa un programa para dividirlo en páginas del tamaño de tu pantalla.
-> Cuando este "paginador" es llamado, notarás que la última línea de tu
-> pantalla es un `:`, en lugar de tu prompt de siempre.
->
-> * Para salir del paginador, presiona `q`.
-> * Para moverte a la siguiente página, presiona la barra espaciadora.
-> * Para buscar `alguna_palabra` en todas las páginas, escribe `/alguna_palabra`
-> y navega entre las coincidencias presionando `n` (next).
-{: .callout}
-
-> ## Tamaño Límite del Registro
->
-> Para evitar que `git log` cubra toda la pantalla de tu terminal, puedes limitar el
-> número de **commits** que Git lista usando `-N`, donde `N` es el número de
-> **commits** que quieres ver. Por ejemplo, si sólo quieres información de
-> el último **commit**, puedes usar:
->
-> ~~~
-> $ git log -1
-> ~~~
-> {: .language-bash}
->
-> ~~~
-> commit 005937fbe2a98fb83f0ade869025dc2636b4dad5
-> Author: Vlad Dracula
-> Date: Thu Aug 22 10:14:07 2013 -0400
->
-> Discuss concerns about Mars' climate for Mummy
-> ~~~
-> {: .output}
->
-> Puedes reducir la cantidad de información usando la
-> opción `--oneline`:
->
-> ~~~
-> $ git log --oneline
-> ~~~
-> {: .language-bash}
-> ~~~
-> * 005937f Discuss concerns about Mars' climate for Mummy
-> * 34961b1 Add concerns about effects of Mars' moons on Wolfman
-> * f22b25e Start notes on Mars as a base
-> ~~~
-> {: .output}
->
-> También puedes combinar las opciones `--oneline` con otras. Una combinación
-> útil es:
->
-> ~~~
-> $ git log --oneline --graph --all --decorate
-> ~~~
-> {: .language-bash}
-> ~~~
-> * 005937f Discuss concerns about Mars' climate for Mummy (HEAD, master)
-> * 34961b1 Add concerns about effects of Mars' moons on Wolfman
-> * f22b25e Start notes on Mars as a base
-> ~~~
-> {: .output}
-{: .callout}
-
-> ## Directorios
->
-> Dos hechos importantes que deberías saber acerca de directorios en Git.
->
-> 1. Git no rastrea directorios por sí mismos, sólo los archivos dentro de ellos.
-> Inténtalo tú mismo:
->
-> ~~~
-> $ mkdir directory
-> $ git status
-> $ git add directory
-> $ git status
-> ~~~
-> {: .language-bash}
->
-> Nota que, nuestro nuevo y vació directorio `directory` no aparece en
-> la lista de archivos no rastreados aún si nosotros explícitamente lo agregamos(_via_ `git add`) a nuestro
-> repositorio. Esta es la razón por la que algunas veces verás archivos `.gitkeep`
-> en directorios que si no fuera por ello estarían vacíos. A diferencia de `.gitignore`,
-> estos archivos no son especiales
-> y su único propósito es poblar un directorio para que Git lo agregue
-> al repositorio. En efecto, podrías nombrar estos archivos como quieras.
->
-> {:start="2"}
-> 2. Si creas un directorio en tu repositorio Git y lo llenas con archivos,
-> podrás agregar todos los archivos en el directorio a la vez haciendo:
->
-> ~~~
-> git add
-> ~~~
-> {: .language-bash}
->
-{: .callout}
+```
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Diferencias basadas en palabras
+
+A veces, por ejemplo en el caso de documentos de texto, un diff por líneas
+es demasiado caótico. Es en ese caso donde la opción `--color-words` de
+`git diff` se vuelve muy útil ya que resalta las palabras
+modificadas usando colores.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Paginación del Registro
+
+Cuando el **output** de `git log` es demasiado largo para caber en tu pantalla,
+`git` usa un programa para dividirlo en páginas del tamaño de tu pantalla.
+Cuando este "paginador" es llamado, notarás que la última línea de tu
+pantalla es un `:`, en lugar de tu prompt de siempre.
+
+- Para salir del paginador, presiona `q`.
+- Para moverte a la siguiente página, presiona la barra espaciadora.
+- Para buscar `alguna_palabra` en todas las páginas, escribe `/alguna_palabra`
+ y navega entre las coincidencias presionando `n` (next).
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Tamaño Límite del Registro
+
+Para evitar que `git log` cubra toda la pantalla de tu terminal, puedes limitar el
+número de **commits** que Git lista usando `-N`, donde `N` es el número de
+**commits** que quieres ver. Por ejemplo, si sólo quieres información de
+el último **commit**, puedes usar:
+
+```bash
+$ git log -1
+```
+
+```output
+commit 005937fbe2a98fb83f0ade869025dc2636b4dad5
+Author: Vlad Dracula
+Date: Thu Aug 22 10:14:07 2013 -0400
+
+ Discuss concerns about Mars' climate for Mummy
+```
+
+Puedes reducir la cantidad de información usando la
+opción `--oneline`:
+
+```bash
+$ git log --oneline
+```
+
+```output
+* 005937f Discuss concerns about Mars' climate for Mummy
+* 34961b1 Add concerns about effects of Mars' moons on Wolfman
+* f22b25e Start notes on Mars as a base
+```
+
+También puedes combinar las opciones `--oneline` con otras. Una combinación
+útil es:
+
+```bash
+$ git log --oneline --graph --all --decorate
+```
+
+```output
+* 005937f Discuss concerns about Mars' climate for Mummy (HEAD, master)
+* 34961b1 Add concerns about effects of Mars' moons on Wolfman
+* f22b25e Start notes on Mars as a base
+```
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Directorios
+
+Dos hechos importantes que deberías saber acerca de directorios en Git.
+
+1. Git no rastrea directorios por sí mismos, sólo los archivos dentro de ellos.
+ Inténtalo tú mismo:
+
+```bash
+$ mkdir directory
+$ git status
+$ git add directory
+$ git status
+```
+
+Nota que, nuestro nuevo y vació directorio `directory` no aparece en
+la lista de archivos no rastreados aún si nosotros explícitamente lo agregamos(*via* `git add`) a nuestro
+repositorio. Esta es la razón por la que algunas veces verás archivos `.gitkeep`
+en directorios que si no fuera por ello estarían vacíos. A diferencia de `.gitignore`,
+estos archivos no son especiales
+y su único propósito es poblar un directorio para que Git lo agregue
+al repositorio. En efecto, podrías nombrar estos archivos como quieras.
+
+{:start="2"}
+2\. Si creas un directorio en tu repositorio Git y lo llenas con archivos,
+podrás agregar todos los archivos en el directorio a la vez haciendo:
+
+```bash
+git add
+```
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
Recapitulando, cuando queremos agregar cambios a nuestro repositorio,
primero necesitamos agregar los archivos cambiados al **staging area**
(`git add`) y luego hacer un **commit** de los cambios al
repositorio (`git commit`):
-
-
-> ## Escogiendo un Mensaje para el **Commit**
->
-> ¿Cuál de los siguientes mensajes de **commit** sería el más apropiado para el
-> último **commit** hecho a `mars.txt`?
->
-> 1. "Changes"
-> 2. "Added line 'But the Mummy will appreciate the lack of humidity' to mars.txt"
-> 3. "Discuss effects of Mars' climate on the Mummy"
->
-> > ## Solución
-> > La respuesta 1 no es suficientemente descriptiva,
-> > y la respuesta 2 es demasiado descriptiva y redundante,
-> > pero la respuesta 3 es buena: corta pero descriptiva.
-> {: .solution}
-{: .challenge}
-
-> ## Haciendo Commit de Cambios a Git
->
-> ¿Cuál comando(s) de abajo debería guardar los cambios de `myfile.txt`
-> a mi repositorio local Git?
->
-> 1. `$ git commit -m "my recent changes"`
->
-> 2. `$ git init myfile.txt`
-> `$ git commit -m "my recent changes"`
->
-> 3. `$ git add myfile.txt`
-> `$ git commit -m "my recent changes"`
->
-> 4. `$ git commit -m myfile.txt "my recent changes"`
->
-> > ## Solución
-> >
-> > 1. Debería crear un **commit** solamente si los archivos ya han sido agregados al **staging area**.
-> > 2. Trataría de crear un nuevo respositorio.
-> > 3. Es correcto: primero agrega el archivo al **staging area**, luego hace **commit**.
-> > 4. Intentaría hacer **commit** al archivo "my recent changes" con el mensaje myfile.txt.
-> {: .solution}
-{: .challenge}
-
-> ## Haciendo **Commit** a Multiples Archivos
->
-> El **staging area** puede tener cambios de cualquier número de archivos
-> a los que quieras hacer **commit**, como una sóla instantánea.
->
-> 1. Agrega algún texto a `mars.txt` anotando tu decisión
-> de considerar Venus como base
-> 2. Crea un nuevo archivo `venus.txt` con tus pensamientos iniciales
-> acerca de Venus como base para tí y tus amigos
-> 3. Agrega los cambios de ambos archivos al **staging area**,
-> y haz un **commit** de esos cambios.
->
-> > ## Solución
-> >
-> > Primero haremos nuestros cambios a los archivos `mars.txt` y `venus.txt`:
-> > ~~~
-> > $ nano mars.txt
-> > $ cat mars.txt
-> > ~~~
-> > {: .language-bash}
-> > ~~~
-> > Maybe I should start with a base on Venus.
-> > ~~~
-> > {: .output}
-> > ~~~
-> > $ nano venus.txt
-> > $ cat venus.txt
-> > ~~~
-> > {: .language-bash}
-> > ~~~
-> > Venus is a nice planet and I definitely should consider it as a base.
-> > ~~~
-> > {: .output}
-> > Ahora puedes agregar ambos archivos al **staging area**. Podemos hacer esto en una sóla línea:
-> >
-> > ~~~
-> > $ git add mars.txt venus.txt
-> > ~~~
-> > {: .language-bash}
-> > O con varios comandos:
-> > ~~~
-> > $ git add mars.txt
-> > $ git add venus.txt
-> > ~~~
-> > {: .language-bash}
-> > Ahora los archivos están listos para hacer **commit**. Puedes verificar esto usando `git status`. Si estás lista para hacer **commit** usa:
-> > ~~~
-> > $ git commit -m "Write plans to start a base on Venus"
-> > ~~~
-> > {: .language-bash}
-> > ~~~
-> > [master cc127c2]
-> > Write plans to start a base on Venus
-> > 2 files changed, 2 insertions(+)
-> > create mode 100644 venus.txt
-> > ~~~
-> > {: .output}
-> {: .solution}
-{: .challenge}
-
-## Repositorio `bio`
->
-> * Crea un nuevo repositorio Git en tu computadora, llamado `bio`.
-> * Escribe una autobiografía de tres líneas en un archivo llamado `me.txt`,
-> haz **commit** de tus cambios
-> * Modifica una línea, agrega una cuarta línea
-> * Muestra las diferencias entre el estado actualizado y el original
->
-> > ## Soluciónn
-> >
-> > Si es necesario, sal de la carpeta `planets`:
-> >
-> > ~~~
-> > $ cd ..
-> > ~~~
-> > {: .language-bash}
-> >
-> > Crea una nueva carpeta llamada `bio` y 'navega' a ella:
-> >
-> > ~~~
-> > $ mkdir bio
-> > $ cd bio
-> > ~~~
-> > {: .language-bash}
-> >
-> > Inicia git:
-> >
-> > ~~~
-> > $ git init
-> > ~~~
-> > {: .language-bash}
-> >
-> > Crea tu archivo de biografía `me.txt` usando `nano` u otro editor de texto.
-> > Una vez hecho, agrega y haz **commit** de tu cambio al repositorio:
-> >
-> > ~~~
-> > $ git add me.txt
-> > $ git commit -m'Adding biography file'
-> > ~~~
-> > {: .language-bash}
-> >
-> > Modifica el archivo como se describe arriba (modifica una línea, agrega una cuarta línea).
-> > Para mostrar las diferencias entre el estado actual y el original, usa `git diff`:
-> >
-> > ~~~
-> > $ git diff me.txt
-> > ~~~
-> > {: .language-bash}
-> >
-> {: .solution}
-{: .challenge}
-
-
-> ## Author y Committer
-> Para cada uno de los **commits** que hayas hecho, Git almacenó tu nombre 2 veces.
-> Tú eres nombrado como el **author** y el **committer**. Puedes observar
-> esto, diciendo a Git que te muestre más información acerca de tus últimos
-> **commits**:
->
-> ~~~
-> $ git log --format=full
-> ~~~
-> {: .language-bash}
->
-> Cuando haces **commit** puedes nombrar a alguien más como el **author**:
->
-> ~~~
-> $ git commit --author="Vlad Dracula "
-> ~~~
-> {: .language-bash}
->
-> Crea un nuevo repositorio y crea dos **commits**: uno sin la
-> opción `--author` y uno nombrando a un colega tuyo como el
-> **author**. Ejecuta `git log` y `git log --format=full`. Piensa acerca de
-> cómo esto puede permitirte colaborar con tus colegas.
->
-> > ## Solución
-> >
-> > ~~~
-> > $ git add me.txt
-> > $ git commit -m "Update Vlad's bio." --author="Frank N. Stein "
-> > ~~~
-> > {: .language-bash}
-> >
-> > ~~~
-> > [master 4162a51] Update Vlad's bio.
-> > Author: Frank N. Stein
-> > 1 file changed, 2 insertions(+), 2 deletions(-)
-> > ~~~
-> > {: .output}
-> >
-> > ~~~
-> > $ git log --format=full
-> > ~~~
-> > {: .language-bash}
-> >
-> > ~~~
-> > commit 4162a51b273ba799a9d395dd70c45d96dba4e2ff
-> > Author: Frank N. Stein
-> > Commit: Vlad Dracula
-> >
-> > Update Vlad's bio.
-> >
-> > commit aaa3271e5e26f75f11892718e83a3e2743fab8ea
-> > Author: Vlad Dracula
-> > Commit: Vlad Dracula
-> >
-> > Vlad's initial bio.
-> > ~~~
-> > {: .output}
-> >
-> {: .solution}
-{: .challenge}
-
-[commit-messages]: http://chris.beams.io/posts/git-commit/
-
-
-{% include links.md %}
+{alt='The Git Commit Workflow'}
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Escogiendo un Mensaje para el **Commit**
+
+¿Cuál de los siguientes mensajes de **commit** sería el más apropiado para el
+último **commit** hecho a `mars.txt`?
+
+1. "Changes"
+2. "Added line 'But the Mummy will appreciate the lack of humidity' to mars.txt"
+3. "Discuss effects of Mars' climate on the Mummy"
+
+::::::::::::::: solution
+
+## Solución
+
+La respuesta 1 no es suficientemente descriptiva,
+y la respuesta 2 es demasiado descriptiva y redundante,
+pero la respuesta 3 es buena: corta pero descriptiva.
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Haciendo Commit de Cambios a Git
+
+¿Cuál comando(s) de abajo debería guardar los cambios de `myfile.txt`
+a mi repositorio local Git?
+
+1. `$ git commit -m "my recent changes"`
+
+2. `$ git init myfile.txt`
+ `$ git commit -m "my recent changes"`
+
+3. `$ git add myfile.txt`
+ `$ git commit -m "my recent changes"`
+
+4. `$ git commit -m myfile.txt "my recent changes"`
+
+::::::::::::::: solution
+
+## Solución
+
+1. Debería crear un **commit** solamente si los archivos ya han sido agregados al **staging area**.
+2. Trataría de crear un nuevo respositorio.
+3. Es correcto: primero agrega el archivo al **staging area**, luego hace **commit**.
+4. Intentaría hacer **commit** al archivo "my recent changes" con el mensaje myfile.txt.
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Haciendo **Commit** a Multiples Archivos
+
+El **staging area** puede tener cambios de cualquier número de archivos
+a los que quieras hacer **commit**, como una sóla instantánea.
+
+1. Agrega algún texto a `mars.txt` anotando tu decisión
+ de considerar Venus como base
+2. Crea un nuevo archivo `venus.txt` con tus pensamientos iniciales
+ acerca de Venus como base para tí y tus amigos
+3. Agrega los cambios de ambos archivos al **staging area**,
+ y haz un **commit** de esos cambios.
+
+::::::::::::::: solution
+
+## Solución
+
+Primero haremos nuestros cambios a los archivos `mars.txt` y `venus.txt`:
+
+```bash
+$ nano mars.txt
+$ cat mars.txt
+```
+
+```output
+Maybe I should start with a base on Venus.
+```
+
+```bash
+$ nano venus.txt
+$ cat venus.txt
+```
+
+```output
+Venus is a nice planet and I definitely should consider it as a base.
+```
+
+Ahora puedes agregar ambos archivos al **staging area**. Podemos hacer esto en una sóla línea:
+
+```bash
+$ git add mars.txt venus.txt
+```
+
+O con varios comandos:
+
+```bash
+$ git add mars.txt
+$ git add venus.txt
+```
+
+Ahora los archivos están listos para hacer **commit**. Puedes verificar esto usando `git status`. Si estás lista para hacer **commit** usa:
+
+```bash
+$ git commit -m "Write plans to start a base on Venus"
+```
+
+```output
+[master cc127c2]
+ Write plans to start a base on Venus
+ 2 files changed, 2 insertions(+)
+ create mode 100644 venus.txt
+```
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+## Repositorio `bio`
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+- Crea un nuevo repositorio Git en tu computadora, llamado `bio`.
+- Escribe una autobiografía de tres líneas en un archivo llamado `me.txt`,
+ haz **commit** de tus cambios
+- Modifica una línea, agrega una cuarta línea
+- Muestra las diferencias entre el estado actualizado y el original
+
+::::::::::::::: solution
+
+## Soluciónn
+
+Si es necesario, sal de la carpeta `planets`:
+
+```bash
+$ cd ..
+```
+
+Crea una nueva carpeta llamada `bio` y 'navega' a ella:
+
+```bash
+$ mkdir bio
+$ cd bio
+```
+
+Inicia git:
+
+```bash
+$ git init
+```
+
+Crea tu archivo de biografía `me.txt` usando `nano` u otro editor de texto.
+Una vez hecho, agrega y haz **commit** de tu cambio al repositorio:
+
+```bash
+$ git add me.txt
+$ git commit -m'Adding biography file'
+```
+
+Modifica el archivo como se describe arriba (modifica una línea, agrega una cuarta línea).
+Para mostrar las diferencias entre el estado actual y el original, usa `git diff`:
+
+```bash
+$ git diff me.txt
+```
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Author y Committer
+
+Para cada uno de los **commits** que hayas hecho, Git almacenó tu nombre 2 veces.
+Tú eres nombrado como el **author** y el **committer**. Puedes observar
+esto, diciendo a Git que te muestre más información acerca de tus últimos
+**commits**:
+
+```bash
+$ git log --format=full
+```
+
+Cuando haces **commit** puedes nombrar a alguien más como el **author**:
+
+```bash
+$ git commit --author="Vlad Dracula "
+```
+
+Crea un nuevo repositorio y crea dos **commits**: uno sin la
+opción `--author` y uno nombrando a un colega tuyo como el
+**author**. Ejecuta `git log` y `git log --format=full`. Piensa acerca de
+cómo esto puede permitirte colaborar con tus colegas.
+
+::::::::::::::: solution
+
+## Solución
+
+```bash
+$ git add me.txt
+$ git commit -m "Update Vlad's bio." --author="Frank N. Stein "
+```
+
+```output
+[master 4162a51] Update Vlad's bio.
+Author: Frank N. Stein
+1 file changed, 2 insertions(+), 2 deletions(-)
+```
+
+```bash
+$ git log --format=full
+```
+
+```output
+commit 4162a51b273ba799a9d395dd70c45d96dba4e2ff
+Author: Frank N. Stein
+Commit: Vlad Dracula
+
+Update Vlad's bio.
+
+commit aaa3271e5e26f75f11892718e83a3e2743fab8ea
+Author: Vlad Dracula
+Commit: Vlad Dracula
+
+Vlad's initial bio.
+```
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
+
+[commit-messages]: https://chris.beams.io/posts/git-commit/
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- `git status` muestra el estatus de un repositorio.
+- Los archivos pueden ser almacenados en un directorio de trabajo del proyecto (el cual ven los usuarios), el **staging area** (donde el siguiente **commit** está siendo construido) y el repositorio local (donde los **commits** son registrados permanentemente).
+- `git add` pone archivos en el **staging area**.
+- `git commit` guarda el contenido del **staging area** como un nuevo **commit** en el repositorio local.
+- Siempre escribe un mensaje de registro cuando hagas un **commit** con cambios.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/episodes/05-history.md b/episodes/05-history.md
index 99fb3ecb..e41f094a 100644
--- a/episodes/05-history.md
+++ b/episodes/05-history.md
@@ -2,51 +2,52 @@
title: Explorando el "History"
teaching: 25
exercises: 0
-questions:
-- "¿Cómo puedo identificar versiones anteriores de archivos?"
-- "¿Cómo puedo revisar mis cambios?"
-- "¿Cómo puedo recuperar versiones anteriores de archivos?"
-objectives:
-- "Explicar qué es el **HEAD** de un repositorio y cómo usarlo."
-- "Identificar y usar el número de **commit** the Git."
-- "Comparar varias versiones de archivos."
-- "Restaurar versiones anteriores de archivos."
-keypoints:
-- "`git diff` despliega diferencias entre **commits**."
-- "`git checkout` recupera versiones anteriores de archivos."
---
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Explicar qué es el **HEAD** de un repositorio y cómo usarlo.
+- Identificar y usar el número de **commit** the Git.
+- Comparar varias versiones de archivos.
+- Restaurar versiones anteriores de archivos.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Cómo puedo identificar versiones anteriores de archivos?
+- ¿Cómo puedo revisar mis cambios?
+- ¿Cómo puedo recuperar versiones anteriores de archivos?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
Como vimos en la lección anterior, podemos referirnos a los **commits** por sus
-identificadores. Puedes referirte al _commit más reciente_ del directorio de trabajo
+identificadores. Puedes referirte al *commit más reciente* del directorio de trabajo
usando el identificador `HEAD`.
Hemos estado agregando una línea a la vez a `mars.txt`, por lo que es fácil rastrear nuestro
progreso, así que hagamos eso usando `HEAD`. Antes de iniciar,
hagamos un cambio en `mars.txt`.
-~~~
+```bash
$ nano mars.txt
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
An ill-considered change
-~~~
-{: .output}
+```
Ahora, veamos lo que tenemos.
-~~~
+```bash
$ git diff HEAD mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
diff --git a/mars.txt b/mars.txt
index b36abfd..0848c8d 100644
--- a/mars.txt
@@ -56,27 +57,24 @@ index b36abfd..0848c8d 100644
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
+An ill-considered change.
-~~~
-{: .output}
+```
-Lo mismo obtendrías si omites `HEAD` (intentalo).
+Lo mismo obtendrías si omites `HEAD` (intentalo).
La verdadera ventaja en todo esto es cuando puedes referirte a **commits** previos. Hacemos
esto agregando `~1` para referirnos al **commit** inmediatamente anterior a `HEAD`.
-~~~
+```bash
$ git diff HEAD~1 mars.txt
-~~~
-{: .language-bash}
+```
Si queremos ver las diferencias entre **commits** anteriores podemos usar `git diff`
nuevamente, pero con la notación `HEAD~1`,`HEAD~2`, y así sucesivamente, para referirse a ellos:
-~~~
+```bash
$ git diff HEAD~2 mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
diff --git a/mars.txt b/mars.txt
index df0654a..b36abfd 100644
--- a/mars.txt
@@ -85,18 +83,15 @@ index df0654a..b36abfd 100644
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidity
-~~~
-{: .output}
-
+```
-También podríamos usar `git show`, que nos muestra qué cambios hemos realizado en un **commit** anterior así como el mensaje del **commit**, en lugar de las _diferencias_ entre un **commit** y nuestro directorio de trabajo, que vemos usando `git diff`.
+También podríamos usar `git show`, que nos muestra qué cambios hemos realizado en un **commit** anterior así como el mensaje del **commit**, en lugar de las *diferencias* entre un **commit** y nuestro directorio de trabajo, que vemos usando `git diff`.
-~~~
+```bash
$ git show HEAD~2 mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
commit 34961b159c27df3b475cfe4415d94a6d1fcd064d
Author: Vlad Dracula
Date: Thu Aug 22 10:07:21 2013 -0400
@@ -110,9 +105,7 @@ index df0654a..315bf3a 100644
@@ -1 +1,2 @@
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
-~~~
-{: .output}
-
+```
De este modo,
podemos construir una cadena de **commits**.
@@ -133,12 +126,11 @@ Nuestro primer **commit** recibió el ID
`f22b25e3233b4645dabd0d81e651fe074bd8e73b`,
así que probemos esto:
-~~~
+```bash
$ git diff f22b25e3233b4645dabd0d81e651fe074bd8e73b mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
diff --git a/mars.txt b/mars.txt
index df0654a..b36abfd 100644
--- a/mars.txt
@@ -147,20 +139,17 @@ index df0654a..b36abfd 100644
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidity
-~~~
-{: .output}
-
+```
Esa es la respuesta correcta,
pero escribir cadenas aleatorias de 40 caracteres es molesto,
entonces Git nos permite usar solo los primeros caracteres:
-~~~
+```bash
$ git diff f22b25e mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
diff --git a/mars.txt b/mars.txt
index df0654a..b36abfd 100644
--- a/mars.txt
@@ -169,36 +158,30 @@ index df0654a..b36abfd 100644
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidity
-~~~
-{: .output}
-
+```
¡Todo bien! Asi que
-podemos guardar cambios en los archivos y ver qué hemos cambiado —ahora
+podemos guardar cambios en los archivos y ver qué hemos cambiado —ahora
¿Cómo podemos restaurar versiones anteriores de las cosas?
Supongamos que accidentalmente sobrescribimos nuestro archivo:
-~~~
+```bash
$ nano mars.txt
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
We will need to manufacture our own oxygen
-~~~
-{: .output}
-
+```
`git status` ahora nos dice que el archivo ha sido cambiado,
pero esos cambios no se han organizado:
-~~~
+```bash
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Changes not staged for commit:
(use "git add ..." to update what will be committed)
@@ -207,26 +190,21 @@ Changes not staged for commit:
modified: mars.txt
no changes added to commit (use "git add" and/or "git commit -a")
-~~~
-{: .output}
-
+```
Podemos volver a poner las cosas tal como estaban
usando `git checkout`:
-~~~
+```bash
$ git checkout HEAD mars.txt
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
-~~~
-{: .output}
-
+```
Como puedes adivinar por su nombre,
`git checkout` recupera (es decir, restaura) una versión anterior de un archivo.
@@ -236,27 +214,23 @@ que es el último **commit** guardado.
Si queremos volver más allá,
podemos usar un identificador de **commit** en su lugar:
-~~~
+```bash
$ git checkout f22b25e mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```bash
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
Cold and dry, but everything is my favorite color
-~~~
-{: .output}
+```
-~~~
+```bash
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
# On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
@@ -267,71 +241,70 @@ Changes to be committed:
# modified: mars.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
-~~~
-{: .output}
-
+```
Ten en cuenta que los cambios están en el **staging area** de almacenamiento.
Nuevamente, podemos volver a poner las cosas tal como estaban
usando `git checkout`:
-~~~
+```bash
$ git checkout -f master mars.txt
-~~~
-{: .language-bash}
-
-> ## No pierdas tu HEAD
->
-> Arriba usamos
->
-> ~~~
-> $ git checkout f22b25e mars.txt
-> ~~~
-> {: .language-bash}
->
-> para revertir `mars.txt` a su estado después del **commit** `f22b25e`.
-> Pero ¡Ten cuidado! El comando `checkout` tiene otras funcionalidades importantes y Git puede malinterpretar tus intenciones si > no sos precisa a la hora de tipear. Por ejemplo,
-> si olvidas `mars.txt` en ese comando, Git te dirá que "You are in
-> 'detached HEAD' state". En este estado, no deberías hacer ningún cambio.
-> Puedes arreglar esto volviendo a conectar tu **head** usando `git checkout master`
-{: .callout}
+```
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## No pierdas tu HEAD
+
+Arriba usamos
+
+```bash
+$ git checkout f22b25e mars.txt
+```
+
+para revertir `mars.txt` a su estado después del **commit** `f22b25e`.
+Pero ¡Ten cuidado! El comando `checkout` tiene otras funcionalidades importantes y Git puede malinterpretar tus intenciones si > no sos precisa a la hora de tipear. Por ejemplo,
+si olvidas `mars.txt` en ese comando, Git te dirá que "You are in
+'detached HEAD' state". En este estado, no deberías hacer ningún cambio.
+Puedes arreglar esto volviendo a conectar tu **head** usando `git checkout master`
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
Es importante recordar que
debemos usar el número de **commit** que identifica el estado del repositorio
*antes* del cambio que intentamos deshacer.
-Un error común es usar el número de
+Un error común es usar el número de
**commit** en el cual hicimos el cambio del cual nos estamos tratando de deshacer.
En el siguiente ejemplo, queremos recuperar el estado antes del más reciente
**commit** (`HEAD~1`), que es **commit** `f22b25e`:
-
-
-
+{alt='Git Checkout'}
Así que, para poner todo junto,
aqui esta como Git trabaja, en forma de dibujo:
-
-
-> ## Simplificando el caso común
->
-> Si lees el **output** de `git status` detenidamente,
-> verás que incluye esta sugerencia:
->
-> ~~~
-> (use "git checkout -- ..." to discard changes in working directory)
-> ~~~
-> {: .language-bash}
->
-> Como deciamos,
-> `git checkout` sin un identificador de versión restaura los archivos al estado guardado en `HEAD`.
-> El doble guión `--` es necesario para separar los nombres de los archivos que se están recuperando
-> del comando mismo:
-> sin esto,
-> Git intentaría usar el nombre del archivo como el identificador del **commit**.
-{: .callout}
+
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Simplificando el caso común
+
+Si lees el **output** de `git status` detenidamente,
+verás que incluye esta sugerencia:
+
+```bash
+(use "git checkout -- ..." to discard changes in working directory)
+```
+Como deciamos,
+`git checkout` sin un identificador de versión restaura los archivos al estado guardado en `HEAD`.
+El doble guión `--` es necesario para separar los nombres de los archivos que se están recuperando
+del comando mismo:
+sin esto,
+Git intentaría usar el nombre del archivo como el identificador del **commit**.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
El hecho de que los archivos puedan revertirse uno por uno
tiende a cambiar la forma en que las personas organizan su trabajo.
@@ -342,199 +315,218 @@ Si la introducción y la conclusión se almacenan en archivos separados,
por otra parte,
retroceder y avanzar en el tiempo se vuelve mucho más fácil.
-> ## Recuperando versiones anteriores de un archivo
->
-> Jennifer ha realizado cambios en el **script** de Python en el que ha estado trabajando durante semanas, y las
-> modificaciones que hizo esta mañana "corrompieron" el **script** y ya no funciona. Ella ha pasado
-> ~ 1hr tratando de solucionarlo, sin tener suerte...
->
-> Por suerte, ¡Ella ha estado haciendo un seguimiento de las versiones de su proyecto usando Git! ¿Cuáles comandos
-> le permitirán recuperar la última versión estable de su **script** Python llamado
-> `data_cruncher.py`?
->
-> 1. `$ git checkout HEAD`
->
-> 2. `$ git checkout HEAD data_cruncher.py`
->
-> 3. `$ git checkout HEAD~1 data_cruncher.py`
->
-> 4. `$ git checkout data_cruncher.py`
->
-> 5. Ambos 2 y 4
-{: .challenge}
-
-
-> ## Revertir un commit
->
-> Jennifer está colaborando en su **script** de Python con sus colegas y
-> se da cuenta que su último **commit** en el repositorio del grupo es incorrecto y quiere
-> deshacerlo. Jennifer necesita deshacer correctamente para que todos en el repositorio
-> del grupo tengan el cambio correcto. `git revert [ID de commit incorrecto]`
-> hará un nuevo **commit** que va a deshacer el commit anterior erroneo de Jennifer.
-> Por lo tanto, `git revert` es diferente de `git checkout [commit
-> ID]` porque `checkout` es para cambios locales no comprometidos con el
-> repositorio de grupo. A continuación se encuentran los pasos correctos y explicaciones para
-> que Jennifer use `git revert`, ¿Cuál es el comando que falta?
->
-> 1. ________ # Mira el historial de git del proyecto para encontrar el ID del **commit**
->
-> 2. Copia el ID (los primeros caracteres del ID, por ejemplo 0b1d055).
->
-> 3. `git revert [commit ID]`
->
-> 4. Escriba el nuevo mensaje del **commit**.
->
-> 5. Salva y cierra
-{: .challenge}
-
-> ## Entendiendo Workflow y History
->
-> ¿Cuál es el **output** de cat venus.txt al final de este conjunto de comandos?
->
-> ~~~
-> $ cd planets
-> $ nano venus.txt #captura el siguiente texto: Venus is beautiful and full of love
-> $ git add venus.txt
-> $ nano venus.txt #agrega el siguiente texto: Venus is too hot to be suitable as a base
-> $ git commit -m "Comment on Venus as an unsuitable base"
-> $ git checkout HEAD venus.txt
-> $ cat venus.txt #esto imprimirá el contenido de venus.txt en la pantalla
-> ~~~
-> {: .language-bash}
->
-> 1.
->
-> ~~~
-> Venus is too hot to be suitable as a base
-> ~~~
-> {: .output}
->
-> 2.
->
-> ~~~
-> Venus is beautiful and full of love
-> ~~~
-> {: .output}
->
-> 3.
->
-> ~~~
-> Venus is beautiful and full of love
-> Venus is too hot to be suitable as a base
-> ~~~
-> {: .output}
->
-> 4.
->
-> ~~~
-> Error because you have changed venus.txt without committing the changes
-> ~~~
-> {: .output}
->
-> > ## Solución
-> >
-> > Vamos línea por línea
-> > ~~~
-> > $ cd planets
-> > ~~~
-> > {: .language-bash}
-> > Entra al directorio 'planets'
-> >
-> > ~~~
-> > $ nano venus.txt #agrega el siguiente texto: Venus is beautiful and full of love
-> > ~~~
-> > {: .language-bash}
-> > Creamos un nuevo archivo y escribimos una oración, pero el archivo no es rastreado por git.
-> >
-> > ~~~
-> > $ git add venus.txt
-> > ~~~
-> > {: .language-bash}
-> > Ahora el archivo está en escena. Los cambios que se han realizado en el archivo hasta ahora se confirmarán en el siguiente **commit**.
-> >
-> > ~~~
-> > $ nano venus.txt #agrega el siguiente texto: Venus is too hot to be suitable as a base
-> > ~~~
-> > {: .language-bash}
-> > El archivo ha sido modificado. Los nuevos cambios no se realizan porque no hemos agregado el archivo.
-> >
-> > ~~~
-> > $ git commit -m "Comment on Venus as an unsuitable base"
-> > ~~~
-> > {: .language-bash}
-> > Los cambios que se incluyeron (Venus is beautiful and full of love) se han confirmado. Los cambios que no se realizaron (Venus is too hot to be suitable as a base) no. Nuestra copia de trabajo local es diferente a la copia en nuestro repositorio local.
-> >
-> > ~~~
-> > $ git checkout HEAD venus.txt
-> > ~~~
-> > {: .language-bash}
-> > Con el **checkout**, descartamos los cambios en el directorio de trabajo para que nuestra copia local sea exactamente la misma que nuestra HEAD, el más reciente **commit**.
-> >
-> > ~~~
-> > $ cat venus.txt #esto imprimirá el contenido de venus.txt a la pantalla
-> > ~~~
-> > {: .language-bash}
-> > Si imprimimos venus.txt obtendremos la respuesta 2.
-> >
-> {: .solution}
-{: .challenge}
-
-> ## Comprobando lo que entendiste de `git diff`
->
-> Considera este comando: `git diff HEAD~3 mars.txt`. ¿Qué predices que hará este comando si lo ejecutas? ¿Qué sucede cuando lo ejecutas? ¿Por qué?
->
-> Prueba éste otro comando, `git diff [ID] mars.txt`, donde [ID] es
-> el identificador único para tu commit más reciente. ¿Qué piensas tú que sucederá,
-> y qué es lo que pasa?
-{: .challenge}
-
-> ## Deshacer los cambios almacenados
->
-> `git checkout` puede usarse para restaurar un **commit** anterior cuando cambios no marcados se han
-> hecho, pero ¿También funcionará para los cambios que se han marcado pero no se han vuelto **commit**?
-> Haz un cambio a `mars.txt`, agrega el cambio y usa` git checkout` para ver si
-> puedes eliminar tu cambio.
-{: .challenge}
-
-> ## Explorar y resumir el History
->
-> Explorar el **history** es una parte importante de git, a menudo es un desafío encontrar
-> el ID de confirmación correcto, especialmente si el **commit** es de hace varios meses.
->
-> Imagina que el proyecto `planets` tiene más de 50 archivos.
-> Deseas encontrar un **commit** con texto específico en `mars.txt`.
-> Cuando escribes `git log`, aparece una lista muy larga,
-> ¿Cómo puede restringir la búsqueda?
->
-> Recuerda que el comando `git diff` nos permite explorar un archivo específico,
-> por ejemplo `git diff mars.txt`. Podemos aplicar una idea similar aquí.
->
-> ~~~
-> $ git log mars.txt
-> ~~~
-> {: .language-bash}
->
-> Desafortunadamente, algunos de estos mensajes en los **commits** son muy ambiguos, por ejemplo `update files`.
-> ¿Cómo puedes buscar a través de estos archivos?
->
-> Tanto `git diff` como `git log` son muy útiles y resumen una parte diferente del **history** para ti.
-> ¿Es posible combinar ambos? Vamos a intentar lo siguiente:
->
-> ~~~
-> $ git log --patch mars.txt
-> ~~~
-> {: .language-bash}
->
-> Deberías obtener una larga lista de output, y deberías poder ver tanto los dos mensajes del **commit** como la diferencia entre cada
-> **commit**.
->
-> Pregunta: ¿Qué hace el siguiente comando?
->
-> ~~~
-> $ git log --patch HEAD~3 *.txt
-> ~~~
-> {: .language-bash}
-{: .challenge}
-
-
-{% include links.md %}
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Recuperando versiones anteriores de un archivo
+
+Jennifer ha realizado cambios en el **script** de Python en el que ha estado trabajando durante semanas, y las
+modificaciones que hizo esta mañana "corrompieron" el **script** y ya no funciona. Ella ha pasado
+\~ 1hr tratando de solucionarlo, sin tener suerte...
+
+Por suerte, ¡Ella ha estado haciendo un seguimiento de las versiones de su proyecto usando Git! ¿Cuáles comandos
+le permitirán recuperar la última versión estable de su **script** Python llamado
+`data_cruncher.py`?
+
+1. `$ git checkout HEAD`
+
+2. `$ git checkout HEAD data_cruncher.py`
+
+3. `$ git checkout HEAD~1 data_cruncher.py`
+
+4. `$ git checkout data_cruncher.py`
+
+5. Ambos 2 y 4
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Revertir un commit
+
+Jennifer está colaborando en su **script** de Python con sus colegas y
+se da cuenta que su último **commit** en el repositorio del grupo es incorrecto y quiere
+deshacerlo. Jennifer necesita deshacer correctamente para que todos en el repositorio
+del grupo tengan el cambio correcto. `git revert [ID de commit incorrecto]`
+hará un nuevo **commit** que va a deshacer el commit anterior erroneo de Jennifer.
+Por lo tanto, `git revert` es diferente de `git checkout [commit ID]` porque `checkout` es para cambios locales no comprometidos con el
+repositorio de grupo. A continuación se encuentran los pasos correctos y explicaciones para
+que Jennifer use `git revert`, ¿Cuál es el comando que falta?
+
+1. \_\_\_\_\_\_\_\_ # Mira el historial de git del proyecto para encontrar el ID del **commit**
+
+2. Copia el ID (los primeros caracteres del ID, por ejemplo 0b1d055).
+
+3. `git revert [commit ID]`
+
+4. Escriba el nuevo mensaje del **commit**.
+
+5. Salva y cierra
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Entendiendo Workflow y History
+
+¿Cuál es el **output** de cat venus.txt al final de este conjunto de comandos?
+
+```bash
+$ cd planets
+$ nano venus.txt #captura el siguiente texto: Venus is beautiful and full of love
+$ git add venus.txt
+$ nano venus.txt #agrega el siguiente texto: Venus is too hot to be suitable as a base
+$ git commit -m "Comment on Venus as an unsuitable base"
+$ git checkout HEAD venus.txt
+$ cat venus.txt #esto imprimirá el contenido de venus.txt en la pantalla
+```
+
+1.
+```output
+Venus is too hot to be suitable as a base
+```
+
+2.
+```output
+Venus is beautiful and full of love
+```
+
+3.
+```output
+Venus is beautiful and full of love
+Venus is too hot to be suitable as a base
+```
+
+4.
+```output
+Error because you have changed venus.txt without committing the changes
+```
+
+::::::::::::::: solution
+
+## Solución
+
+Vamos línea por línea
+
+```bash
+$ cd planets
+```
+
+Entra al directorio 'planets'
+
+```bash
+$ nano venus.txt #agrega el siguiente texto: Venus is beautiful and full of love
+```
+
+Creamos un nuevo archivo y escribimos una oración, pero el archivo no es rastreado por git.
+
+```bash
+$ git add venus.txt
+```
+
+Ahora el archivo está en escena. Los cambios que se han realizado en el archivo hasta ahora se confirmarán en el siguiente **commit**.
+
+```bash
+$ nano venus.txt #agrega el siguiente texto: Venus is too hot to be suitable as a base
+```
+
+El archivo ha sido modificado. Los nuevos cambios no se realizan porque no hemos agregado el archivo.
+
+```bash
+$ git commit -m "Comment on Venus as an unsuitable base"
+```
+
+Los cambios que se incluyeron (Venus is beautiful and full of love) se han confirmado. Los cambios que no se realizaron (Venus is too hot to be suitable as a base) no. Nuestra copia de trabajo local es diferente a la copia en nuestro repositorio local.
+
+```bash
+$ git checkout HEAD venus.txt
+```
+
+Con el **checkout**, descartamos los cambios en el directorio de trabajo para que nuestra copia local sea exactamente la misma que nuestra HEAD, el más reciente **commit**.
+
+```bash
+$ cat venus.txt #esto imprimirá el contenido de venus.txt a la pantalla
+```
+
+Si imprimimos venus.txt obtendremos la respuesta 2.
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Comprobando lo que entendiste de `git diff`
+
+Considera este comando: `git diff HEAD~3 mars.txt`. ¿Qué predices que hará este comando si lo ejecutas? ¿Qué sucede cuando lo ejecutas? ¿Por qué?
+
+Prueba éste otro comando, `git diff [ID] mars.txt`, donde [ID] es
+el identificador único para tu commit más reciente. ¿Qué piensas tú que sucederá,
+y qué es lo que pasa?
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Deshacer los cambios almacenados
+
+`git checkout` puede usarse para restaurar un **commit** anterior cuando cambios no marcados se han
+hecho, pero ¿También funcionará para los cambios que se han marcado pero no se han vuelto **commit**?
+Haz un cambio a `mars.txt`, agrega el cambio y usa` git checkout` para ver si
+puedes eliminar tu cambio.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Explorar y resumir el History
+
+Explorar el **history** es una parte importante de git, a menudo es un desafío encontrar
+el ID de confirmación correcto, especialmente si el **commit** es de hace varios meses.
+
+Imagina que el proyecto `planets` tiene más de 50 archivos.
+Deseas encontrar un **commit** con texto específico en `mars.txt`.
+Cuando escribes `git log`, aparece una lista muy larga,
+¿Cómo puede restringir la búsqueda?
+
+Recuerda que el comando `git diff` nos permite explorar un archivo específico,
+por ejemplo `git diff mars.txt`. Podemos aplicar una idea similar aquí.
+
+```bash
+$ git log mars.txt
+```
+
+Desafortunadamente, algunos de estos mensajes en los **commits** son muy ambiguos, por ejemplo `update files`.
+¿Cómo puedes buscar a través de estos archivos?
+
+Tanto `git diff` como `git log` son muy útiles y resumen una parte diferente del **history** para ti.
+¿Es posible combinar ambos? Vamos a intentar lo siguiente:
+
+```bash
+$ git log --patch mars.txt
+```
+
+Deberías obtener una larga lista de output, y deberías poder ver tanto los dos mensajes del **commit** como la diferencia entre cada
+**commit**.
+
+Pregunta: ¿Qué hace el siguiente comando?
+
+```bash
+$ git log --patch HEAD~3 *.txt
+```
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- `git diff` despliega diferencias entre **commits**.
+- `git checkout` recupera versiones anteriores de archivos.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/episodes/06-ignore.md b/episodes/06-ignore.md
index e56a17e6..4d8375bd 100644
--- a/episodes/06-ignore.md
+++ b/episodes/06-ignore.md
@@ -2,34 +2,38 @@
title: Ignorando cosas
teaching: 5
exercises: 0
-questions:
-- "¿Cómo puedo indicarle a Git que ignore los archivos que no quiero rastrear?"
-objectives:
-- "Configure Git para ignorar archivos específicos."
-- "Explica por qué ignorar los archivos puede ser útil."
-keypoints:
-- "El archivo `.gitignore` le dice a Git qué archivos ignorar."
---
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Configure Git para ignorar archivos específicos.
+- Explica por qué ignorar los archivos puede ser útil.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Cómo puedo indicarle a Git que ignore los archivos que no quiero rastrear?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
¿Qué pasa si tenemos archivos que no queremos que Git rastree,
como archivos de copia de seguridad creados por nuestro editor
o archivos intermedios creados durante el análisis de datos?
Vamos a crear algunos archivos ficticios:
-~~~
+```bash
$ mkdir results
$ touch a.dat b.dat c.dat results/a.out results/b.out
-~~~
-{: .language-bash}
+```
Mira lo que Git dice:
-~~~
+```bash
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Untracked files:
(use "git add ..." to include in what will be committed)
@@ -39,95 +43,85 @@ Untracked files:
c.dat
results/
nothing added to commit but untracked files present (use "git add" to track)
-~~~
-{: .output}
+```
-Colocar estos archivos bajo el control de versiones sería un desperdicio de espacio en disco.
-Y lo que es peor,
-al tenerlos todos listados, podría distraernos de los cambios que realmente importan,
+Colocar estos archivos bajo el control de versiones sería un desperdicio de espacio en disco.
+Y lo que es peor,
+al tenerlos todos listados, podría distraernos de los cambios que realmente importan,
así que vamos a decirle a Git que los ignore.
Lo hacemos creando un archivo en el directorio raíz de nuestro proyecto llamado `.gitignore`:
-~~~
+```bash
$ nano .gitignore
$ cat .gitignore
-~~~
-{: .language-bash}
+```
-~~~
+```output
*.dat
results/
-~~~
-{: .output}
+```
Estos patrones le dicen a Git que ignore cualquier archivo cuyo nombre termine en `.dat`
y todo lo que haya en el directorio `results`.
-(Si alguno de estos archivos ya estaba siendo rastreado,
+(Si alguno de estos archivos ya estaba siendo rastreado,
Git seguirá rastreándolos.)
-Una vez que hemos creado este archivo,
+Una vez que hemos creado este archivo,
la salida de `git status` es mucho más limpia:
-~~~
+```bash
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Untracked files:
(use "git add ..." to include in what will be committed)
.gitignore
nothing added to commit but untracked files present (use "git add" to track)
-~~~
-{: .output}
+```
Lo único que Git advierte ahora, es el archivo `.gitignore` recién creado.
-Podrías pensar que no queremos rastrearlo,
+Podrías pensar que no queremos rastrearlo,
pero todos aquellos con los que compartimos nuestro repositorio probablemente desearán
ignorar las mismas cosas que nosotros.
Vamos a agregar y hacer "commit" de `.gitignore`:
-~~~
+```bash
$ git add .gitignore
$ git commit -m "Add the ignore file"
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
# On branch master
nothing to commit, working directory clean
-~~~
-{: .output}
+```
Como ventaja, usar `.gitignore` nos ayuda a evitar agregar accidentalmente al repositorio los archivos que no queremos rastrear:
-~~~
+```bash
$ git add a.dat
-~~~
-{: .language-bash}
+```
-~~~
+```output
The following paths are ignored by one of your .gitignore files:
a.dat
Use -f if you really want to add them.
-~~~
-{: .output}
+```
-Si realmente queremos anular la configuración de ignorar,
-podemos usar `git add -f` para obligar a Git a añadir algo. Por ejemplo,
+Si realmente queremos anular la configuración de ignorar,
+podemos usar `git add -f` para obligar a Git a añadir algo. Por ejemplo,
`git add -f a.dat`.
También podemos ver siempre el estado de los archivos ignorados si queremos:
-~~~
+```bash
$ git status --ignored
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Ignored files:
(use "git add -f ..." to include in what will be committed)
@@ -138,124 +132,162 @@ Ignored files:
results/
nothing to commit, working directory clean
-~~~
-{: .output}
-
-> ## Ignorar archivos anidados
->
-> Dado un directorio con la siguiente estructura:
->
-> ~~~
-> results/data
-> results/plots
-> ~~~
-> {: .language-bash}
->
-> ¿Cómo ignorarías sólo `results/plots` y no `results/data`?
->
-> > ## Solución
-> >
-> > Como ocurre con la mayoría de los problemas de programación, hay
-> > varias maneras de resolver esto. Si sólo deseas ignorar el
-> > contenido de `results/plots`, puedes cambiar tu `.gitignore` para
-> > ignorar solamente la subcarpeta `/plots/` añadiendo la siguiente línea a su .gitignore:
-> >
-> > `results/plots/`
-> >
-> > Si, en cambio, deseas ignorar todo en `/results/`, pero deseas realizar el
-> > seguimiento de `results/data`, puedes agregar `results/` a su .gitignore y
-> > crear una excepción para la carpeta `results/data/`.
-> > El siguiente reto cubrirá este tipo de solución.
-> >
-> >
-> > A veces el patrón `**` viene muy bien para referirse a múltiples
-> > niveles de directorio. E.g. `**/results/plots/*` hará que git ignore el
-> > directorio `results/plots` en cualquier directorio raíz.
-> {: .solution}
-{: .challenge}
-
-> ## Incluyendo archivos específicos
->
-> ¿Cómo ignorarías todos los archivos `.data` en tu directorio raíz, excepto` final.data`?
-> Sugerencia: Descubre lo que `!` (el signo de exclamación) hace
->
-> > ## Solución
-> >
-> > Agrega las siguientes dos líneas a tu archivo .gitignore:
-> >
-> > ~~~
-> > *.data # ignora todos los archivos .data
-> > !final.data # excepto el archivo final.data
-> > ~~~
-> > {: .language-bash}
-> >
-> > El signo de exclamación incluirá una entrada previamente excluida.
-> {: .solution}
-{: .challenge}
-
-> ## Ignorando todos los archivos de datos en un directorio
->
-> Dado un directorio con la siguiente estructura:
->
-> ~~~
-> results/data/position/gps/a.data
-> results/data/position/gps/b.data
-> results/data/position/gps/c.data
-> results/data/position/gps/info.txt
-> results/plots
-> ~~~
-> {: .language-bash}
->
-> ¿Cuál es la regla más corta en `.gitignore` para ignorar todos los archivos `.data`
-> en `result/data/position/gps`? No ignores el archivo `info.txt`.
->
-> > ## Solución
-> >
-> > Agregando `results/data/position/gps/*.data` coincidirá con cada archivo en
-> > `results/data/position/gps` que termine con `.data`.
-> > El archivo `results/data/position/gps/info.txt` no será ignorado.
-> {: .solution}
-{: .challenge}
-
-> ## El orden de las reglas
->
-> Dado un archivo `.gitignore` con el siguiente contenido:
->
-> ~~~
-> *.data
-> !*.data
-> ~~~
-> {: .language-bash}
->
-> ¿Cuál será el resultado?
->
-> > ## Solución
-> >
-> > El modificador `!` anulará algún patrón ignorado previamente definido.
-> > Debido a que la entrada `!*.data` anula todos los archivos` .data` anteriores en `.gitignore`,
-> > ninguno de ellos será ignorado, y todos los archivos` .data` serán rastreados.
-> >
-> {: .solution}
-{: .challenge}
-
-> ## Archivos de bitácora
->
-> Supón que escribiste un **script** que crea muchos archivos de registro con la estructura `log_01`, `log_02`, `log_03`, etc. Deseas conservarlos pero no rastrearlos a través de `git`.
->
-> 1. Escribe **una entrada** en tu archivo `.gitignore` que excluya los archivos con estructura `log_01`, `log_02`, etc.
->
-> 2. Prueba tu "patrón de ignorar" creando algunos archivos ficticios `log_01`, etc.
->
-> 3. Te das cuenta de que el archivo `log_01` es muy importante después de todo, así que lo tienes que agregar a los archivos rastreados sin cambiar el` .gitignore` de nuevo
->
-> 4. Discute con tu compañero de a lado qué otros tipos de archivos podrían residir en tu directorio que no deseas seguir y por tanto excluir a través de `.gitignore`.
->
-> > ## Solución
-> >
-> > 1. Agrega `log_*` o `log*` como nueva entrada en tu archivo .gitignore
-> > 3. Rastrea `log_01` usando `git add -f log_01`
-> {: .solution}
-{: .challenge}
-
-
-{% include links.md %}
+```
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Ignorar archivos anidados
+
+Dado un directorio con la siguiente estructura:
+
+```bash
+results/data
+results/plots
+```
+
+¿Cómo ignorarías sólo `results/plots` y no `results/data`?
+
+::::::::::::::: solution
+
+## Solución
+
+Como ocurre con la mayoría de los problemas de programación, hay
+varias maneras de resolver esto. Si sólo deseas ignorar el
+contenido de `results/plots`, puedes cambiar tu `.gitignore` para
+ignorar solamente la subcarpeta `/plots/` añadiendo la siguiente línea a su .gitignore:
+
+`results/plots/`
+
+Si, en cambio, deseas ignorar todo en `/results/`, pero deseas realizar el
+seguimiento de `results/data`, puedes agregar `results/` a su .gitignore y
+crear una excepción para la carpeta `results/data/`.
+El siguiente reto cubrirá este tipo de solución.
+
+A veces el patrón `**` viene muy bien para referirse a múltiples
+niveles de directorio. E.g. `**/results/plots/*` hará que git ignore el
+directorio `results/plots` en cualquier directorio raíz.
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Incluyendo archivos específicos
+
+¿Cómo ignorarías todos los archivos `.data` en tu directorio raíz, excepto` final.data`?
+Sugerencia: Descubre lo que `!` (el signo de exclamación) hace
+
+::::::::::::::: solution
+
+## Solución
+
+Agrega las siguientes dos líneas a tu archivo .gitignore:
+
+```bash
+*.data # ignora todos los archivos .data
+!final.data # excepto el archivo final.data
+```
+
+El signo de exclamación incluirá una entrada previamente excluida.
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Ignorando todos los archivos de datos en un directorio
+
+Dado un directorio con la siguiente estructura:
+
+```bash
+results/data/position/gps/a.data
+results/data/position/gps/b.data
+results/data/position/gps/c.data
+results/data/position/gps/info.txt
+results/plots
+```
+
+¿Cuál es la regla más corta en `.gitignore` para ignorar todos los archivos `.data`
+en `result/data/position/gps`? No ignores el archivo `info.txt`.
+
+::::::::::::::: solution
+
+## Solución
+
+Agregando `results/data/position/gps/*.data` coincidirá con cada archivo en
+`results/data/position/gps` que termine con `.data`.
+El archivo `results/data/position/gps/info.txt` no será ignorado.
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## El orden de las reglas
+
+Dado un archivo `.gitignore` con el siguiente contenido:
+
+```bash
+*.data
+!*.data
+```
+
+¿Cuál será el resultado?
+
+::::::::::::::: solution
+
+## Solución
+
+El modificador `!` anulará algún patrón ignorado previamente definido.
+Debido a que la entrada `!*.data` anula todos los archivos` .data` anteriores en `.gitignore`,
+ninguno de ellos será ignorado, y todos los archivos` .data` serán rastreados.
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Archivos de bitácora
+
+Supón que escribiste un **script** que crea muchos archivos de registro con la estructura `log_01`, `log_02`, `log_03`, etc. Deseas conservarlos pero no rastrearlos a través de `git`.
+
+1. Escribe **una entrada** en tu archivo `.gitignore` que excluya los archivos con estructura `log_01`, `log_02`, etc.
+
+2. Prueba tu "patrón de ignorar" creando algunos archivos ficticios `log_01`, etc.
+
+3. Te das cuenta de que el archivo `log_01` es muy importante después de todo, así que lo tienes que agregar a los archivos rastreados sin cambiar el` .gitignore` de nuevo
+
+4. Discute con tu compañero de a lado qué otros tipos de archivos podrían residir en tu directorio que no deseas seguir y por tanto excluir a través de `.gitignore`.
+
+::::::::::::::: solution
+
+## Solución
+
+1. Agrega `log_*` o `log*` como nueva entrada en tu archivo .gitignore
+2. Rastrea `log_01` usando `git add -f log_01`
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- El archivo `.gitignore` le dice a Git qué archivos ignorar.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/episodes/07-github.md b/episodes/07-github.md
index d6b28116..3197f1a0 100644
--- a/episodes/07-github.md
+++ b/episodes/07-github.md
@@ -2,98 +2,100 @@
title: Repositorios remotos en GitHub
teaching: 30
exercises: 0
-questions:
-- "¿Cómo puedo compartir los cambios con otros en la web?"
-objectives:
-- "Explica qué es un repositorio remoto y por qué es útil."
-- "Hacer **push** y **pull** en un repositorio remoto"
-keypoints:
-- "Un repositorio Git local puede ser conectado a uno o más repositorios remotos."
-- "Usa el protocolo HTTPS para conectarte a un repositorio remoto hasta que hayas aprendido como hacerlo con SSH."
-- "`git push` copia los cambios desde el repositorio local a un repositorio remoto."
-- "`git pull` copia los cambios desde un repositorio remoto a un repositorio local."
---
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Explica qué es un repositorio remoto y por qué es útil.
+- Hacer **push** y **pull** en un repositorio remoto
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Cómo puedo compartir los cambios con otros en la web?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
Cuando se trabaja en colaboración con otras personas es cuando el sistema de control de versiones alcanza su pleno potencial. Ya hemos visto la mayor parte de las herramientas que necesitamos para ello, tan sólo nos falta ver cómo copiar los cambios realizados de un repositorio a otro.
-Sistemas como Git ya nos permiten mover el trabajo realizado entre dos repositorios cualesquiera. Sin embargo, en la práctica es más sencillo establecer uno de ellos como repositorio central y tenerlo en la red en lugar de tu computadora particular. La mayoría de desarrolladores usan servicios de alojamiento en la red, tales como [GitHub](http://github.com), [BitBucket](http://bitbucket.org) o [GitLab](http://gitlab.com/), para alojar ese repositorio central; en la última sección de esta lección exploraremos los pros y los contras de cada uno de ellos.
+Sistemas como Git ya nos permiten mover el trabajo realizado entre dos repositorios cualesquiera. Sin embargo, en la práctica es más sencillo establecer uno de ellos como repositorio central y tenerlo en la red en lugar de tu computadora particular. La mayoría de desarrolladores usan servicios de alojamiento en la red, tales como [GitHub](https://github.com), [BitBucket](https://bitbucket.org) o [GitLab](https://gitlab.com/), para alojar ese repositorio central; en la última sección de esta lección exploraremos los pros y los contras de cada uno de ellos.
Empecemos por compartir con todos los demás los cambios que hemos realizado en nuestro proyecto actual. Para ello, ingresa en tu cuenta de GitHub y haz click en el icono que hay en la esquina superior derecha para crear un nuevo repositorio llamado `planets`:
-
+{alt='Creando un Repositorio en GitHub (Paso 1)'}
Dale a tu repositorio el nombre "planets" y haz click en "Create repository":
-
+{alt='Creando un Repositorio en GitHub (Paso 2)'}
Tan pronto es creado el repositorio, GitHub muestra una página con una URL y algo de información sobre cómo configurar tu repositorio local.
-
+{alt='Creando un Repositorio en GitHub (Paso 3)'}
Esto en realidad ejecuta lo siguiente en los servidores de GitHub:
-~~~
+```bash
$ mkdir planets
$ cd planets
$ git init
-~~~
-{: .language-bash}
+```
Nuestro repositorio local contiene nuestro trabajo previo en `mars.txt`, pero el repositorio remoto en GitHub todavía no contiene ningún archivo:
-
+{alt='Repositorio en GitHub recién creado'}
-El siguiente paso es conectar los dos repositorios. Ello se consigue convirtiendo al repositorio en GitHub en un [repositorio remoto]({{ page.root }}/reference#remote) del repositorio local. La página de inicio del repositorio en GitHub incluye la secuencia de caracteres que necesitamos para identificarlo:
+El siguiente paso es conectar los dos repositorios. Ello se consigue convirtiendo al repositorio en GitHub en un [repositorio remoto](../learners/reference.md#remote) del repositorio local. La página de inicio del repositorio en GitHub incluye la secuencia de caracteres que necesitamos para identificarlo:
-
+{alt='Dónde encontrar la URL del Repositorio en GitHub'}
-Haz click en el enlace 'HTTPS' para cambiar el [protocolo]({{ page.root }}/reference#protocolo) de SSH a HTTPS.
+Haz click en el enlace 'HTTPS' para cambiar el [protocolo](../learners/reference.md#protocolo) de SSH a HTTPS.
-> ## HTTPS vs. SSH
->
->Usamos aquí HTTPS porque no necesita ninguna configuración adicional.
->Si en el curso quieres configurar el acceso mediante SSH, que es un poco más seguro,
->puedes seguir cualquiera de los excelentes tutoriales que existen en
->[GitHub](https://help.github.com/articles/generating-ssh-keys),
->[Atlassian/BitBucket](https://confluence.atlassian.com/bitbucket/set-up-ssh-for-git-728138079.html) y
->[GitLab](https://about.gitlab.com/2014/03/04/add-ssh-key-screencast/)
->(este último con capturas animadas de pantalla).
-{: .callout}
+::::::::::::::::::::::::::::::::::::::::: callout
-
+## HTTPS vs. SSH
+
+Usamos aquí HTTPS porque no necesita ninguna configuración adicional.
+Si en el curso quieres configurar el acceso mediante SSH, que es un poco más seguro,
+puedes seguir cualquiera de los excelentes tutoriales que existen en
+[GitHub](https://help.github.com/articles/generating-ssh-keys),
+[Atlassian/BitBucket](https://confluence.atlassian.com/bitbucket/set-up-ssh-for-git-728138079.html) y
+[GitLab](https://about.gitlab.com/2014/03/04/add-ssh-key-screencast/)
+(este último con capturas animadas de pantalla).
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+{alt='Cambiando la URL del Repositorio en GitHub'}
Copia dicha URL desde el navegador, ve al repositorio local `planets` y ejecuta allí este comando:
-~~~
+```bash
$ git remote add origin https://github.com/vlad/planets.git
-~~~
-{: .language-bash}
+```
Asegúrate de usar la URL de tu repositorio en lugar de la de vlad: la única diferencia debería ser tu nombre de usuario en lugar de `vlad`.
Podemos comprobar que el comando ha funcionado bien ejecutando `git remote -v`:
-~~~
+```bash
$ git remote -v
-~~~
-{: .language-bash}
+```
-~~~
+```output
origin https://github.com/vlad/planets.git (push)
origin https://github.com/vlad/planets.git (fetch)
-~~~
-{: .output}
+```
El nombre `origin` es un apodo local para tu repositorio remoto. Se puede usar cualquier otro nombre si se desea, pero `origin` es la elección más habitual.
Una vez seleccionado el apodo local `origin`, el siguiente comando enviará los cambios realizados en nuestro repositorio local al repositorio en GitHub:
-~~~
+```bash
$ git push origin master
-~~~
-{: .language-bash}
+```
-~~~
+```output
Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
@@ -102,155 +104,213 @@ Total 9 (delta 2), reused 0 (delta 0)
To https://github.com/vlad/planets
* [new branch] master -> master
Branch master set up to track remote branch master from origin.
-~~~
-{: .output}
-
-> ## Proxy
->
-> Si la red a la que estás conectado usa un proxy es posible que tu último
-> comando fallara con el siguiente mensaje de error: "Could not resolve hostname".
-> Para solucionarlo es necesario informar a Git sobre el proxy:
->
-> ~~~
-> $ git config --global http.proxy http://user:password@proxy.url
-> $ git config --global https.proxy http://user:password@proxy.url
-> ~~~
-> {: .language-bash}
->
-> Si después te conectas a otra red que no usa un proxy es necesario decirle
-> a Git que deshabilite el proxy:
->
-> ~~~
-> $ git config --global --unset http.proxy
-> $ git config --global --unset https.proxy
-> ~~~
-> {: .language-bash}
-{: .callout}
-
-> ## Gestores de contraseñas
->
-> Si tu sistema operativo tiene un gestor de contraseñas configurado, `git push`
-> intentará usarlo cuando necesite un nombre de usuario y contraseña. Al menos
-> ese es el comportamiento por defecto para Git.language-bash en Windows.
-> Si quieres que haya que introducir el nombre de usuario y contraseña en la terminal,
-> en lugar de usar el gestor de contraseñas, hay que ejecutar el siguiente
-> comando en la terminal antes de lanzar `git push`:
->
-> ~~~
-> $ unset SSH_ASKPASS
-> ~~~
-> {: .language-bash}
->
-> A pesar de lo que se podría deducir por el nombre, [git usa `SSH_ASKPASS`
-> para todas las peticiones de credenciales](http://git-scm.com/docs/gitcredentials#_requesting_credentials),
-> tanto si se está usando git vía SSH como si se está usando vía https, por lo
-> que es posible que quieras deshabilitarlo en ambos casos con `unset SSH_ASKPASS` .
->
-> Otra alternativa es añadir `unset SSH_ASKPASS` al final de tu `~/.bashrc` para que
-> git use por defecto la terminal para los nombres de usuario y las contraseñas.
-{: .callout}
+```
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Proxy
+
+Si la red a la que estás conectado usa un proxy es posible que tu último
+comando fallara con el siguiente mensaje de error: "Could not resolve hostname".
+Para solucionarlo es necesario informar a Git sobre el proxy:
+
+```bash
+$ git config --global http.proxy http://user:password@proxy.url
+$ git config --global https.proxy http://user:password@proxy.url
+```
+
+Si después te conectas a otra red que no usa un proxy es necesario decirle
+a Git que deshabilite el proxy:
+
+```bash
+$ git config --global --unset http.proxy
+$ git config --global --unset https.proxy
+```
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Gestores de contraseñas
+
+Si tu sistema operativo tiene un gestor de contraseñas configurado, `git push`
+intentará usarlo cuando necesite un nombre de usuario y contraseña. Al menos
+ese es el comportamiento por defecto para Git.language-bash en Windows.
+Si quieres que haya que introducir el nombre de usuario y contraseña en la terminal,
+en lugar de usar el gestor de contraseñas, hay que ejecutar el siguiente
+comando en la terminal antes de lanzar `git push`:
+
+```bash
+$ unset SSH_ASKPASS
+```
+
+A pesar de lo que se podría deducir por el nombre, [git usa `SSH_ASKPASS`
+para todas las peticiones de credenciales](https://git-scm.com/docs/gitcredentials#_requesting_credentials),
+tanto si se está usando git vía SSH como si se está usando vía https, por lo
+que es posible que quieras deshabilitarlo en ambos casos con `unset SSH_ASKPASS` .
+
+Otra alternativa es añadir `unset SSH_ASKPASS` al final de tu `~/.bashrc` para que
+git use por defecto la terminal para los nombres de usuario y las contraseñas.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
Nuestros repositorios local y remoto se encuentran ahora en el siguiente estado:
-
+{alt='Repositorio en GitHub después del primer envío'}
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## La opción '-u'
+
+En la documentación puedes ver que en ocasiones se usa la opción `-u` con el comando `git push`.
+Esta opción es sinónimo de la opción `--set-upstream-to` para el comando `git branch` y se usa
+para asociar el **branch** actual con un **branch** remoto, de modo que el comando `git pull`
+pueda usarse sin argumentos. Para hacer esto simplemente ejecuta `git push -u origin master`
+una vez que el repositorio remoto haya sido creado.
+
-> ## La opción '-u'
->
-> En la documentación puedes ver que en ocasiones se usa la opción `-u` con el comando `git push`.
-> Esta opción es sinónimo de la opción `--set-upstream-to` para el comando `git branch` y se usa
-> para asociar el **branch** actual con un **branch** remoto, de modo que el comando `git pull`
-> pueda usarse sin argumentos. Para hacer esto simplemente ejecuta `git push -u origin master`
-> una vez que el repositorio remoto haya sido creado.
-{: .callout}
+::::::::::::::::::::::::::::::::::::::::::::::::::
También podemos hacer **pull**, es decir, traernos cambios desde el repositorio remoto al repositorio local:
-~~~
+```bash
$ git pull origin master
-~~~
-{: .language-bash}
+```
-~~~
+```output
From https://github.com/vlad/planets
* branch master -> FETCH_HEAD
Already up-to-date.
-~~~
-{: .output}
+```
En este caso, hacer **pull** no ha tenido ningún efecto porque los dos repositorios están ya sincronizados. Por el contrario, si alguien antes hubiera subido con **push** algunos cambios al repositorio en GitHub, este comando los habría incorporado a nuestro repositorio local.
-> ## Interfaz gráfica de GitHub
->
-> Navega hasta tu repositorio `planets` en GitHub.
-> En la pestaña Code, localiza el texto "XX commits" (donde "XX" es algún número) y haz click en él.
-> Mueve el cursor sobre los tres botones que hay a la derecha de cada **commit**, y haz click en ellos.
-> ¿Qué información puedes obtener/explorar con estos botones?
-> ¿Cómo obtendrías la misma información en la terminal?
->
-> > ## Solución
-> > El botón más a la izquierda (con el dibujo de un portapapeles) sirve para copiar en el portapapeles el identificador completo del **commit** en cuestión. En la terminal, ```git log``` muestra los identificadores completos de cada **commit**.
-> >
-> > Haciendo click en el botón de en medio, se pueden ver todos los cambios efectuados con el **commit** en cuestión. Las líneas verdes sombreadas indican adiciones y las rojas eliminaciones. En la terminal se puede ver lo mismo con ```git diff```. En particular, ```git diff ID1..ID2``` donde ID1 y ID2 son identificadores de **commits** (e.g. ```git diff a3bf1e5..041e637```) mostrará las diferencias entre esos dos **commits**.
-> >
-> > El botón más a la derecha permite ver todos los archivos que existían en el repositorio en el momento del **commit** en cuestión. Para ver lo mismo en la terminal sería necesario hacer **checkout** del repositorio a ese momento del tiempo. Para ello se ejecutaría ```git checkout ID``` donde ID es el identificador del **commit** que queremos investigar. ¡Si se hace esto hay que acordarse luego de poner el repositorio de nuevo en el estado correcto!
-> {: .solution}
-{: .challenge}
-
-> ## Fecha y Hora en GitHub
->
-> Crea un repositorio remoto en GitHub. Haz **push** de los contenidos de tu repositorio local
-> al remoto. Haz cambios en tu repositorio local y haz **push** de dichos cambios.
-> Ve al repo recién creado en GitHub y comprueba las fechas y horas, también llamadas
-> [timestamps]({{ page.root }}/reference#timestamp) de los ficheros. ¿Cómo registra
-> GitHub los tiempos, y por qué?
->
-> > ## Solución
-> > Github muestra los tiempos en formato relativo legible para los humanos (i.e. "22 hours ago" or "three weeks ago"). Sin embargo, si mueves el cursor sobre un **timestamp**, podrás ver el tiempo exacto en el que se realizó el último cambio al fichero.
-> {: .solution}
-{: .challenge}
-
-> ## Push vs. Commit
->
-> En esta lección hemos introducido el comando "git push".
-> ¿En qué se diferencia "git push" de "git commit"?
->
-> > ## Solución
-> > Cuando enviamos cambios con **push**, estamos interaccionando con un repositorio remoto para actualizarlo con los cambios que hemos hecho localmente (a menudo esto supone compartir con otros los cambios realizados). Por el contrario, **commit** únicamente actualiza tu repositorio local.
-> {: .solution}
-{: .challenge}
-
-> ## Corrigiendo ajustes en el repositorio remoto
->
-> Es muy frecuente cometer un error al especificar la URL del repositorio remoto.
-> Este ejercicio trata de cómo corregir este tipo de errores.
-> Empecemos por añadir un repositorio remoto con una URL inválida:
->
-> ~~~
-> git remote add broken https://github.com/this/url/is/invalid
-> ~~~
-> {: .language-bash}
->
-> ¿Obtienes un error al añadir el repositorio remoto? ¿Se te ocurre algún
-> comando que hiciera obvio que la URL de tu repositorio remoto no es
-> válida? ¿Se te ocurre cómo corregir la URL? (pista: usa `git remote
-> -h`). No olvides eliminar este repositorio remoto una vez que
-> hayas terminado este ejercicio.
->
-> > ## Solución
-> > No aparece ningún error cuando añadimos el repositorio remoto (añadir un repositorio remoto informa a git sobre dicho repositorio, pero no intenta usarlo todavía). Sí veremos un error en cuanto intentemos usarlo con ```git push```. El comando ```git remote set-url``` nos permite cambiar la URL del repositorio remoto para corregirla.
-> {: .solution}
-{: .challenge}
-
-> ## Licencia GitHub y ficheros README
->
-> En esta sección hemos aprendido cómo crear un repositorio remoto en GitHub, pero cuando lo hicimos
-> no añadimos ningún fichero README.md ni ningún fichero de licencia. Si lo hubiéramos hecho, ¿qué crees que habría sucedido
-> cuando intentaste enlazar tus repositorios local y remoto?
->
-> > ## Solución
-> > En este caso, puesto que ya teníamos un fichero README en nuestro propio repositorio (local), habríamos visto un conficto de unión, conocido como **merge conflict** (que es cuando git se da cuenta de que hay dos versiones de un mismo fichero y nos pide que resolvamos las diferencias).
-> {: .solution}
-{: .challenge}
-
-
-{% include links.md %}
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Interfaz gráfica de GitHub
+
+Navega hasta tu repositorio `planets` en GitHub.
+En la pestaña Code, localiza el texto "XX commits" (donde "XX" es algún número) y haz click en él.
+Mueve el cursor sobre los tres botones que hay a la derecha de cada **commit**, y haz click en ellos.
+¿Qué información puedes obtener/explorar con estos botones?
+¿Cómo obtendrías la misma información en la terminal?
+
+::::::::::::::: solution
+
+## Solución
+
+El botón más a la izquierda (con el dibujo de un portapapeles) sirve para copiar en el portapapeles el identificador completo del **commit** en cuestión. En la terminal, `git log` muestra los identificadores completos de cada **commit**.
+
+Haciendo click en el botón de en medio, se pueden ver todos los cambios efectuados con el **commit** en cuestión. Las líneas verdes sombreadas indican adiciones y las rojas eliminaciones. En la terminal se puede ver lo mismo con `git diff`. En particular, `git diff ID1..ID2` donde ID1 y ID2 son identificadores de **commits** (e.g. `git diff a3bf1e5..041e637`) mostrará las diferencias entre esos dos **commits**.
+
+El botón más a la derecha permite ver todos los archivos que existían en el repositorio en el momento del **commit** en cuestión. Para ver lo mismo en la terminal sería necesario hacer **checkout** del repositorio a ese momento del tiempo. Para ello se ejecutaría `git checkout ID` donde ID es el identificador del **commit** que queremos investigar. ¡Si se hace esto hay que acordarse luego de poner el repositorio de nuevo en el estado correcto!
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Fecha y Hora en GitHub
+
+Crea un repositorio remoto en GitHub. Haz **push** de los contenidos de tu repositorio local
+al remoto. Haz cambios en tu repositorio local y haz **push** de dichos cambios.
+Ve al repo recién creado en GitHub y comprueba las fechas y horas, también llamadas
+[timestamps](../learners/reference.md#timestamp) de los ficheros. ¿Cómo registra
+GitHub los tiempos, y por qué?
+
+::::::::::::::: solution
+
+## Solución
+
+Github muestra los tiempos en formato relativo legible para los humanos (i.e. "22 hours ago" or "three weeks ago"). Sin embargo, si mueves el cursor sobre un **timestamp**, podrás ver el tiempo exacto en el que se realizó el último cambio al fichero.
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Push vs. Commit
+
+En esta lección hemos introducido el comando "git push".
+¿En qué se diferencia "git push" de "git commit"?
+
+::::::::::::::: solution
+
+## Solución
+
+Cuando enviamos cambios con **push**, estamos interaccionando con un repositorio remoto para actualizarlo con los cambios que hemos hecho localmente (a menudo esto supone compartir con otros los cambios realizados). Por el contrario, **commit** únicamente actualiza tu repositorio local.
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Corrigiendo ajustes en el repositorio remoto
+
+Es muy frecuente cometer un error al especificar la URL del repositorio remoto.
+Este ejercicio trata de cómo corregir este tipo de errores.
+Empecemos por añadir un repositorio remoto con una URL inválida:
+
+```bash
+git remote add broken https://github.com/this/url/is/invalid
+```
+
+¿Obtienes un error al añadir el repositorio remoto? ¿Se te ocurre algún
+comando que hiciera obvio que la URL de tu repositorio remoto no es
+válida? ¿Se te ocurre cómo corregir la URL? (pista: usa `git remote -h`). No olvides eliminar este repositorio remoto una vez que
+hayas terminado este ejercicio.
+
+::::::::::::::: solution
+
+## Solución
+
+No aparece ningún error cuando añadimos el repositorio remoto (añadir un repositorio remoto informa a git sobre dicho repositorio, pero no intenta usarlo todavía). Sí veremos un error en cuanto intentemos usarlo con `git push`. El comando `git remote set-url` nos permite cambiar la URL del repositorio remoto para corregirla.
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Licencia GitHub y ficheros README
+
+En esta sección hemos aprendido cómo crear un repositorio remoto en GitHub, pero cuando lo hicimos
+no añadimos ningún fichero README.md ni ningún fichero de licencia. Si lo hubiéramos hecho, ¿qué crees que habría sucedido
+cuando intentaste enlazar tus repositorios local y remoto?
+
+::::::::::::::: solution
+
+## Solución
+
+En este caso, puesto que ya teníamos un fichero README en nuestro propio repositorio (local), habríamos visto un conficto de unión, conocido como **merge conflict** (que es cuando git se da cuenta de que hay dos versiones de un mismo fichero y nos pide que resolvamos las diferencias).
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- Un repositorio Git local puede ser conectado a uno o más repositorios remotos.
+- Usa el protocolo HTTPS para conectarte a un repositorio remoto hasta que hayas aprendido como hacerlo con SSH.
+- `git push` copia los cambios desde el repositorio local a un repositorio remoto.
+- `git pull` copia los cambios desde un repositorio remoto a un repositorio local.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/episodes/08-collab.md b/episodes/08-collab.md
index 070508e6..7d53235e 100644
--- a/episodes/08-collab.md
+++ b/episodes/08-collab.md
@@ -2,27 +2,37 @@
title: Trabajos en colaboración
teaching: 5
exercises: 0
-questions:
-- "¿Cómo puedo usar el control de versiones para colaborar con otras personas?"
-objectives:
+---
+
+::::::::::::::::::::::::::::::::::::::: objectives
+
- Clonar un repositorio remoto.
- Colaborar en crear un repositorio común.
-keypoints:
-- '`git clone` copia un repositorio remoto para crear un repositorio local llamado `origin` configurado automáticamente.'
----
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Cómo puedo usar el control de versiones para colaborar con otras personas?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
Para el siguiente paso, formen parejas. Una persona será el "dueño" y la otra el "colaborador". El objetivo es que el colaborador agregue cambios al repositorio del dueño. Vamos a cambiar roles al final, de modo que ambas personas puedan participar como dueño y colaborador
-> ## Practicando por tu cuenta
->
-> Si estás trabajando en esta lección por tu cuenta, puedes hacerlo abriendo una segunda sesión en la
-> ventana de la terminal. Esta ventana representará a tu compañero trabajando en otra computadora. No necesitas darle acceso a nadie en GitHub, pues tú serás ambos "compañeros".
-{: .callout}
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Practicando por tu cuenta
+
+Si estás trabajando en esta lección por tu cuenta, puedes hacerlo abriendo una segunda sesión en la
+ventana de la terminal. Esta ventana representará a tu compañero trabajando en otra computadora. No necesitas darle acceso a nadie en GitHub, pues tú serás ambos "compañeros".
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
El dueño debe dar acceso al colaborador. En GitHub, haz clic en el botón de configuración arriba a la derecha,
luego selecciona "Collaborators" e ingresa el nombre de tu colaborador.
-
+{alt='Adding Collaborators on GitHub'}
Para aceptar la invitación de acceso al repositorio, el colaborador
debe ingresar a [https://github.com/notifications](https://github.com/notifications).
@@ -30,49 +40,43 @@ Una vez allí, se puede aceptar la invitación a dicho repositorio.
Luego, el colaborador debe descargar una copia del repositorio del dueño a su máquina. Esto se conoce como "clonar un repositorio". Para clonar el repositorio del dueño en su carpeta de `Desktop`, el colaborador debe ejecutar las siguientes líneas:
-~~~
+```bash
$ git clone https://github.com/vlad/planets.git ~/Desktop/vlad-planets
-~~~
-{: .language-bash}
+```
Reemplaza 'vlad' con el nombre de usuario del dueño.
-
+{alt='After Creating Clone of Repository'}
El colaborador puede ahora hacer cambios en la versión clonada del repositorio del dueño, en la misma forma en que se hacían previamente:
-~~~
+```bash
$ cd ~/Desktop/vlad-planets
$ nano pluto.txt
$ cat pluto.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
It is so a planet!
-~~~
-{: .output}
+```
-~~~
+```bash
$ git add pluto.txt
$ git commit -m "Add notes about Pluto"
-~~~
-{: .language-bash}
+```
-~~~
+```output
1 file changed, 1 insertion(+)
create mode 100644 pluto.txt
-~~~
-{: .output}
+```
Luego enviar los cambios hacia el *repositorio del dueño* en GitHub haciendo **push**:
-~~~
+```bash
$ git push origin master
-~~~
-{: .language-bash}
+```
-~~~
+```output
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
@@ -80,8 +84,7 @@ Writing objects: 100% (3/3), 306 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/vlad/planets.git
9272da5..29aba7c master -> master
-~~~
-{: .output}
+```
Nota que no es necesario crear un directorio remoto llamado `origin`: Git utiliza este nombre de manera automática cuando clonamos un repositorio. (Esta es la razón por la cual `origin` era una opción sensata a la hora de configurar directorios remotos a mano).
@@ -89,12 +92,11 @@ Ahora echa un vistazo al repositorio del dueño en su sitio de Github (quizá de
Para descargar los cambios hechos por el colaborador desde GitHub, el dueño debe correr las siguientes líneas:
-~~~
+```bash
$ git pull origin master
-~~~
-{: .language-bash}
+```
-~~~
+```output
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
@@ -106,54 +108,83 @@ Fast-forward
pluto.txt | 1 +
1 file changed, 1 insertion(+)
create mode 100644 pluto.txt
-~~~
-{: .output}
+```
Ahora hay tres repositorios sincronizados (el local del dueño, el local del colaborador y el del dueño en GitHub).
-> ## Un flujo de trabajo colaborativo básico
->
-> Es considerado buena práctica estar seguro de que tienes una versión actualizada del repositorio en el que colaboras. Para ello deberías hacer un `git pull` antes de hacer cambios. El enfoque sería:
->
->
-> * actualizar el repositorio local `git pull origin master`,
-> * realizar cambios `git add`,
-> * realizar un **commit** `git commit -m`, y
-> * cargar las actualizaciones a GitHub con `git push origin master`
->
-> Es mejor hacer varias actualizaciones pequeñas que un **commit** grande con cambios enormes. **Commits** pequeños son más fáciles de leer y revisar.
-{: .callout}
-
-> ## Cambiar roles
->
-> Cambien los roles y repitan todo el proceso.
-{: .challenge}
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Un flujo de trabajo colaborativo básico
+
+Es considerado buena práctica estar seguro de que tienes una versión actualizada del repositorio en el que colaboras. Para ello deberías hacer un `git pull` antes de hacer cambios. El enfoque sería:
+
+- actualizar el repositorio local `git pull origin master`,
+- realizar cambios `git add`,
+- realizar un **commit** `git commit -m`, y
+- cargar las actualizaciones a GitHub con `git push origin master`
+
+Es mejor hacer varias actualizaciones pequeñas que un **commit** grande con cambios enormes. **Commits** pequeños son más fáciles de leer y revisar.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Cambiar roles
+
+Cambien los roles y repitan todo el proceso.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
> ## Revisar Cambios
->
+
El dueño hace un **push** de los **commits** al repositorio sin dar información al colaborador. ¿Cómo puede éste saberlo desde la linea de comandos y desde GitHub?
->
->> ## Solution
->>
->> En la linea de comandos, el colaborador puede usar ```git fetch origin master``` para acceder a los cambios remotos en el repositorio local, sin hacer un **merge**. Luego, corriendo ```git diff master origin/master```, el colaborador verá los cambios en la terminal.
->>
->> En GitHub, el colaborador puede realizar su propio **fork** y hallar la barra gris que indica "This branch is 1 commit behind Our-Respository:master.". Lejos, a la derecha de la barra gris, hay un link para comparar. En la página para comparar, el colaborador debe cambiar el **fork** hacia su propio repositorio, luego hacer click en el link para "comparar entre forks" y, finalmente, cambiar el **fork** al repositorio principal. Esto mostrará todos los **commits** que sean distintos.
-> {: .solution}
-{: .challenge}
-
-> ## Comentar cambios en GitHub
->
-> El colaborador podría tener algunas preguntas sobre cambios en una línea hechos por el dueño.
->
-> Con GitHub, es posible comentar la diferencia en un **commit**. Sobre la línea de código a comentar aparece un botón azul para abrir una ventana.
->
-> El colaborador puede escribir sus comentarios y sugerencias usando la interfaz de GitHub.
-{: .challenge}
-
-> ## Historial de versiones, backup y control de versiones
->
-> Algunos softwares que permiten hacer **backups** también permiten guardar un historial de versiones y recuperar versiones específicas. ¿Cómo es esta funcionalidad distinta del control de versiones? ¿Cuáles son los beneficios de usar control de versiones, Git y GitHub?
-{: .challenge}
-
-
-{% include links.md %}
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+::::::::::::::: solution
+
+## Solution
+
+En la linea de comandos, el colaborador puede usar `git fetch origin master` para acceder a los cambios remotos en el repositorio local, sin hacer un **merge**. Luego, corriendo `git diff master origin/master`, el colaborador verá los cambios en la terminal.
+
+En GitHub, el colaborador puede realizar su propio **fork** y hallar la barra gris que indica "This branch is 1 commit behind Our-Respository:master.". Lejos, a la derecha de la barra gris, hay un link para comparar. En la página para comparar, el colaborador debe cambiar el **fork** hacia su propio repositorio, luego hacer click en el link para "comparar entre forks" y, finalmente, cambiar el **fork** al repositorio principal. Esto mostrará todos los **commits** que sean distintos.
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Comentar cambios en GitHub
+
+El colaborador podría tener algunas preguntas sobre cambios en una línea hechos por el dueño.
+
+Con GitHub, es posible comentar la diferencia en un **commit**. Sobre la línea de código a comentar aparece un botón azul para abrir una ventana.
+
+El colaborador puede escribir sus comentarios y sugerencias usando la interfaz de GitHub.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Historial de versiones, backup y control de versiones
+
+Algunos softwares que permiten hacer **backups** también permiten guardar un historial de versiones y recuperar versiones específicas. ¿Cómo es esta funcionalidad distinta del control de versiones? ¿Cuáles son los beneficios de usar control de versiones, Git y GitHub?
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- `git clone` copia un repositorio remoto para crear un repositorio local llamado `origin` configurado automáticamente.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/episodes/09-conflict.md b/episodes/09-conflict.md
index d0c5ab9f..4ce75676 100644
--- a/episodes/09-conflict.md
+++ b/episodes/09-conflict.md
@@ -2,74 +2,66 @@
title: Conflictos
teaching: 15
exercises: 0
-questions:
-- "¿Qué hago cuando mis cambios entran en conflicto con los de otra persona?"
-objectives:
-- "Explicar qué son los conflictos y cuándo pueden ocurrir."
-- "Resolver conflictos que resultan de una fusión."
-keypoints:
-- "Los conflictos ocurren cuando dos o más personas cambian el mismo archivo(s) al mism/o tiempo."
-- "El sistema de control de versiones no permite a las personas sobreescribir ciegamente los
-cambios del otro, pero resalta los conflictos para poder resolverlos."
---
+::::::::::::::::::::::::::::::::::::::: objectives
-Tan pronto como podemos trabajar en paralelo, es probable que alguien deshaga lo que otro hizo. Esto incluso es probable con una única persona: si estamos trabajando en un software al mismo tiempo en nuestra computadora portátil y un servidor en el laboratorio, podríamos hacer cambios diferentes a cada copia del trabajo. El control de versiones nos ayuda a manejar estos [confictos]({{ page.root }}/reference#conflicto) al darnos herramientas para [resolver]({{ page.root }}/reference#resolver) cambios que se hayan sobrepuesto.
+- Explicar qué son los conflictos y cuándo pueden ocurrir.
+- Resolver conflictos que resultan de una fusión.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Qué hago cuando mis cambios entran en conflicto con los de otra persona?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+Tan pronto como podemos trabajar en paralelo, es probable que alguien deshaga lo que otro hizo. Esto incluso es probable con una única persona: si estamos trabajando en un software al mismo tiempo en nuestra computadora portátil y un servidor en el laboratorio, podríamos hacer cambios diferentes a cada copia del trabajo. El control de versiones nos ayuda a manejar estos [confictos](../learners/reference.md#conflicto) al darnos herramientas para [resolver](../learners/reference.md#resolver) cambios que se hayan sobrepuesto.
Para ver cómo podemos resolver conflictos, primero debemos crear uno. Actualmente, el archivo `mars.txt` se ve de la siguiente manera en dos copias de diferentes compañeros en nuestro repositorio `planetas`:
-~~~
+```bash
$ cat mars.txt
-~~~
-{: .language-bash}
-
+```
-~~~
+```output
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
-~~~
-{: .output}
+```
Agreguemos una línea únicamente a la copia de uno de los dos compañeros:
-~~~
+```bash
$ nano mars.txt
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-
-~~~
+```output
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
This line added to Wolfman's copy
-~~~
-{: .output}
-
+```
y luego hacer `push` al cambio en GitHub:
-
-~~~
+```bash
$ git add mars.txt
$ git commit -m "Add a line in our home copy"
-~~~
-{: .language-bash}
+```
-~~~
+```output
[master 5ae9631] Add a line in our home copy
1 file changed, 1 insertion(+)
-~~~
-{: .output}
+```
-~~~
+```bash
$ git push origin master
-~~~
-{: .language-bash}
+```
-~~~
+```output
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
@@ -77,53 +69,43 @@ Writing objects: 100% (3/3), 352 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/vlad/planets
29aba7c..dabb4c8 master -> master
-~~~
-{: .output}
+```
Ahora haremos que el otro compañero
haga un cambio diferente a su copia
*sin* actualizar desde GitHub:
-~~~
+```bash
$ nano mars.txt
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-
-~~~
+```output
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
We added a different line in the other copy
-~~~
-{: .output}
-
+```
Podemos hacer **commit** del cambio localmente
-~~~
+```bash
$ git add mars.txt
$ git commit -m "Add a line in my copy"
-~~~
-{: .language-bash}
+```
-
-~~~
+```output
[master 07ebc69] Add a line in my copy
1 file changed, 1 insertion(+)
-~~~
-{: .output}
-
+```
pero Git no nos dejará hacer **push** en GitHub:
-~~~
+```bash
$ git push origin master
-~~~
-{: .language-bash}
+```
-~~~
+```output
To https://github.com/vlad/planets.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/vlad/planets.git'
@@ -131,25 +113,22 @@ hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
-~~~
-{: .output}
-
-
+```
+{alt='The Conflicting Changes'}
Git detecta que los cambios hechos en una copia se sobreponen con los cambios hechos en la otra
y nos impide destruir nuestro trabajo previo.
-Lo que debemos hacer es traer -`pull`- los cambios desde GitHub,
-[unirlos]({{ page.root }}/reference#mezclar) dentro de la copia en la que estamos trabajando actualmente,
+Lo que debemos hacer es traer -`pull`\- los cambios desde GitHub,
+[unirlos](../learners/reference.md#mezclar) dentro de la copia en la que estamos trabajando actualmente,
y luego hacer `push` al resultado.
Empecemos haciendo `pull` a lo siguiente:
-~~~
+```bash
$ git pull origin master
-~~~
-{: .language-bash}
+```
-~~~
+```output
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 3 (delta 1)
@@ -159,18 +138,16 @@ From https://github.com/vlad/planets
Auto-merging mars.txt
CONFLICT (content): Merge conflict in mars.txt
Automatic merge failed; fix conflicts and then commit the result.
-~~~
-{: .output}
+```
`git pull` nos dice que hay un conflicto,
y marca ese conflicto en el archivo afectado:
-~~~
+```bash
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
@@ -179,8 +156,7 @@ We added a different line in the other copy
=======
This line added to Wolfman's copy
>>>>>>> dabb4c8c450e8475aee9b14b4383acc99f42af1d
-~~~
-{: .output}
+```
Nuestro cambio —señalado en `HEAD`— es precedido por `<<<<<<<`.
Luego, Git insertó `=======` como un separador entre los cambios conflictivos
@@ -195,30 +171,27 @@ el cambio hecho en el repositorio remoto, redactar algo nuevo para reemplazar am
o eliminar el cambio completamente.
Reemplacemos ambos de manera que el archivo quede así:
-~~~
+```bash
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
We removed the conflict on this line
-~~~
-{: .output}
+```
Para finalizar la unión,
agregamos `mars.txt` a los cambios hechos por el **merge**
y luego hacemos **commit**:
-~~~
+```bash
$ git add mars.txt
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
@@ -227,27 +200,23 @@ Changes to be committed:
modified: mars.txt
-~~~
-{: .output}
+```
-~~~
+```bash
$ git commit -m "Merge changes from GitHub"
-~~~
-{: .language-bash}
+```
-~~~
+```output
[master 2abf2b1] Merge changes from GitHub
-~~~
-{: .output}
+```
Ahora podemos hacer **push** a nuestros cambios en GitHub:
-~~~
+```bash
$ git push origin master
-~~~
-{: .language-bash}
+```
-~~~
+```output
Counting objects: 10, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
@@ -255,19 +224,17 @@ Writing objects: 100% (6/6), 697 bytes, done.
Total 6 (delta 2), reused 0 (delta 0)
To https://github.com/vlad/planets.git
dabb4c8..2abf2b1 master -> master
-~~~
-{: .output}
+```
Git lleva el registro de qué hemos unificado con qué,
de manera que no debemos arreglar las cosas a mano nuevamente
cuando el colaborador que hizo el primer cambio hace **pull** de nuevo:
-~~~
+```bash
$ git pull origin master
-~~~
-{: .language-bash}
+```
-~~~
+```output
remote: Counting objects: 10, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 2), reused 6 (delta 2)
@@ -278,23 +245,20 @@ Updating dabb4c8..2abf2b1
Fast-forward
mars.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
-~~~
-{: .output}
+```
Obtenemos el archivo unificado:
-~~~
+```bash
$ cat mars.txt
-~~~
-{: .language-bash}
+```
-~~~
+```output
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
We removed the conflict on this line
-~~~
-{: .output}
+```
No es necesario unificar el contenido nuevamente porque Git sabe que alguien ya ha hecho eso.
@@ -304,7 +268,7 @@ correctamente. Si te encuentras resolviendo muchos conflictos en un proyecto
ten en cuenta estas aproximaciones técnicas para reducirlas:
- Hacer **pull** con mayor frecuencia, especialmente antes de empezar una nueva tarea
-- Usar ramas temáticas para separar trabajo, uniéndolas a la rama principal - `master`- cuando estén completas
+- Usar ramas temáticas para separar trabajo, uniéndolas a la rama principal - `master`\- cuando estén completas
- Hacer comentarios más cortos y concisos
- Cuando sea apropiado, dividir archivos grandes en varios pequeños de manera que sea
menos probable que dos autores alteren el mismo archivo simultáneamente
@@ -312,233 +276,240 @@ ten en cuenta estas aproximaciones técnicas para reducirlas:
Los conflictos también pueden ser minimizados con estrategias de administración de proyectos:
- Aclarar con tus colaboradores quién es responsable de cada área
-- Discutir con tus colaboradores en qué orden deben realizarse las tareas para que
- las tareas que puedan cambiar las mismas líneas no se trabajen simultáneamente.
+- Discutir con tus colaboradores en qué orden deben realizarse las tareas para que
+ las tareas que puedan cambiar las mismas líneas no se trabajen simultáneamente.
- Si los conflictos son de estilo (e.g. tabulaciones vs. espacios), establecer una
convención que rija el proyecto y utilizar herramientas de estilo de código (e.g.
`htmltidy`, `perltidy`, `rubocop`, etc.) para forzarlas, si es necesario
-> ## Solucionando conflictos creados por ti
->
-> Clona el repositorio creado por tu instructor.
-> Agrégale un nuevo archivo
-> y modificar un archivo existente (tu instructor te dirá cuál).
-> Cuando tu instructor te lo pida,
-> trae los cambios -haciendo **pull**- desde el repositorio para crear un conflicto,
-> y luego resuélvelo.
-{: .challenge}
-
-> ## Conflictos en archivos no textuales
->
-> ¿Qué hace Git
-> cuando hay un conflicto en una imagen u otro archivo no de texto
-> que está almacenado con control de versiones?
->
-> > ## Solución
-> >
-> > Intentémoslo. Supón que **Dracula** toma una foto de la superficie de Marte y la llama `mars.jpg`.
-> >
-> > Si no tienes una imagen de Marte, puedes crear un archivo
-> > binario de prueba de la siguiente manera:
-> >
-> > ~~~
-> > $ head --bytes 1024 /dev/urandom > mars.jpg
-> > $ ls -lh mars.jpg
-> > ~~~
-> > {: .language-bash}
-> >
-> > ~~~
-> > -rw-r--r-- 1 vlad 57095 1.0K Mar 8 20:24 mars.jpg
-> > ~~~
-> > {: .output}
-> >
-> > `ls` nos muestra que se creó un archivo de 1-kilobyte. Está lleno de bytes al azar
-> > leídos a partir del archivo especial, `/dev/urandom`.
-> >
-> > Ahora, supón que **Dracula** agrega `mars.jpg` a su repositorio:
-> >
-> > ~~~
-> > $ git add mars.jpg
-> > $ git commit -m "Add picture of Martian surface"
-> > ~~~
-> > {: .language-bash}
-> >
-> > ~~~
-> > [master 8e4115c] Add picture of Martian surface
-> > 1 file changed, 0 insertions(+), 0 deletions(-)
-> > create mode 100644 mars.jpg
-> > ~~~
-> > {: .output}
-> >
-> > Supón que Wolfman agregó una imagen similar al mismo tiempo.
-> > La suya es una imagen del cielo de Marte, pero *también* se llama `mars.jpg`.
-> > Cuando **Dracula** intenta hacer push, recibe un mensaje familiar:
-> >
-> > ~~~
-> > $ git push origin master
-> > ~~~
-> > {: .language-bash}
-> >
-> > ~~~
-> > To https://github.com/vlad/planets.git
-> > ! [rejected] master -> master (fetch first)
-> > error: failed to push some refs to 'https://github.com/vlad/planets.git'
-> > hint: Updates were rejected because the remote contains work that you do
-> > hint: not have locally. This is usually caused by another repository pushing
-> > hint: to the same ref. You may want to first integrate the remote changes
-> > hint: (e.g., 'git pull ...') before pushing again.
-> > hint: See the 'Note about fast-forwards' in 'git push --help' for details.
-> > ~~~
-> > {: .output}
-> >
-> > Hemos aprendido que primero debemos hacer **pull** y resolver conflictos:
-> >
-> > ~~~
-> > $ git pull origin master
-> > ~~~
-> > {: .language-bash}
-> >
-> > Cuando hay un conflicto en una imagen u otro archivo binario, git imprime
-> > un mensaje así:
-> >
-> > ~~~
-> > $ git pull origin master
-> > remote: Counting objects: 3, done.
-> > remote: Compressing objects: 100% (3/3), done.
-> > remote: Total 3 (delta 0), reused 0 (delta 0)
-> > Unpacking objects: 100% (3/3), done.
-> > From https://github.com/vlad/planets.git
-> > * branch master -> FETCH_HEAD
-> > 6a67967..439dc8c master -> origin/master
-> > warning: Cannot merge binary files: mars.jpg (HEAD vs. 439dc8c08869c342438f6dc4a2b615b05b93c76e)
-> > Auto-merging mars.jpg
-> > CONFLICT (add/add): Merge conflict in mars.jpg
-> > Automatic merge failed; fix conflicts and then commit the result.
-> > ~~~
-> > {: .output}
-> >
-> > El mensaje informando el conflicto es básicamente el mismo que se imprimió para `mars.txt`, pero
-> > hay una línea adicional:
-> >
-> > ~~~
-> > warning: Cannot merge binary files: mars.jpg (HEAD vs. 439dc8c08869c342438f6dc4a2b615b05b93c76e)
-> > ~~~
-> > {: .output}
-> >
-> > Git no puede insertar indicadores de conflicto en una imagen como lo hace en los
-> > archivos de texto. Por lo tanto, en vez de editar la imagen, debemos revisar la versión que
-> > queremos mantener. Luego podemos agregar y hacer **commit** a esta versión.
-> >
-> > En la línea agregada de arriba, Git convenientemente nos dio identificadores de **commit**
-> > para las dos versiones de `mars.jpg`. Nuestra versión es `HEAD`, y la de Wolfman
-> > es `439dc8c0...`. Si queremos usar nuestra versión, podemos usar
-> > `git checkout`:
-> >
-> > ~~~
-> > $ git checkout HEAD mars.jpg
-> > $ git add mars.jpg
-> > $ git commit -m "Use image of surface instead of sky"
-> > ~~~
-> > {: .language-bash}
-> >
-> > ~~~
-> > [master 21032c3] Use image of surface instead of sky
-> > ~~~
-> > {: .output}
-> >
-> > En cambio si queremos usar la versión de Wolfman, podemos usar `git checkout` con
-> > el identificador de **commit** de Wolfman, `439dc8c0`:
-> >
-> > ~~~
-> > $ git checkout 439dc8c0 mars.jpg
-> > $ git add mars.jpg
-> > $ git commit -m "Use image of sky instead of surface"
-> > ~~~
-> > {: .language-bash}
-> >
-> > ~~~
-> > [master da21b34] Use image of sky instead of surface
-> > ~~~
-> > {: .output}
-> >
-> > También podemos mantener *ambas* imágenes. La clave es que no podemos mantenerlas con el mismo
-> > nombre. Pero podemos verificar cada versión de forma sucesiva y *renombrarla*, y luego agregar las versiones renombradas.
-> > Primero, revisa cada imagen y renómbrala:
-> >
-> > ~~~
-> > $ git checkout HEAD mars.jpg
-> > $ git mv mars.jpg mars-surface.jpg
-> > $ git checkout 439dc8c0 mars.jpg
-> > $ mv mars.jpg mars-sky.jpg
-> > ~~~
-> > {: .language-bash}
-> >
-> > Luego, elimina la vieja imagen `mars.jpg` y agrega los dos archivos nuevos:
-> >
-> > ~~~
-> > $ git rm mars.jpg
-> > $ git add mars-surface.jpg
-> > $ git add mars-sky.jpg
-> > $ git commit -m "Use two images: surface and sky"
-> > ~~~
-> > {: .language-bash}
-> >
-> > ~~~
-> > [master 94ae08c] Use two images: surface and sky
-> > 2 files changed, 0 insertions(+), 0 deletions(-)
-> > create mode 100644 mars-sky.jpg
-> > rename mars.jpg => mars-surface.jpg (100%)
-> > ~~~
-> > {: .output}
-> >
-> > Ahora ambas imágenes de Marte estan ingresadas en el repositorio, y `mars.jpg`
-> > ya no existe.
-> {: .solution}
-{: .challenge}
-
-
-> ## Una típica sesión de trabajo
->
-> Te sientas en tu computadora para trabajar en un proyecto compartido que es mantenido en un
-> repositorio Git remoto. Durante tu sesión de trabajo, realizas las siguientes acciones,
-> pero no en éste orden:
->
->
-> - *Hacer cambios* agregando el número `100` al archivo de texto `numbers.txt`
-> - *Actualizar repositorio remoto* para actualizar el repositorio local
-> - *Celebrar* tu éxito con cerveza(s)
-> - *Actualizar repositorio local* para actualizar el repositorio remoto
-> - *Realizar cambios* con los cuales voy a hacer commit
-> - *Hacer commit a los cambios* al repositorio local
->
-> ¿En qué orden deberías hacer estas acciones para minimizar la posibilidad de conflictos?
-> Pon los comandos de arriba en orden en la columna *acción* de la tabla de abajo.
-> Cuando tengas el orden correcto, ve si puedes escribir los comandos correspondientes en la columna
-> *comando*. Algunos campos ya están completados para ayudarte a
-> comenzar.
->
-> |orden|acción . . . . . . . . . . |comando . . . . . . . . . . |
-> |-----|---------------------------|----------------------------|
-> |1 | | |
-> |2 | | `echo 100 >> numbers.txt` |
-> |3 | | |
-> |4 | | |
-> |5 | | |
-> |6 | ¡Celebrar! | `AFK` |
->
-> > ## Solución
-> >
-> > |orden|acción . . . . . . . . . . |comando . . . . . . . . . . |
-> > |-----|-------------------|----------------------------------------------|
-> > |1 | Actualizar repositorio local | `git pull origin master` |
-> > |2 | Hacer cambios | `echo 100 >> numbers.txt` |
-> > |3 | Realizar cambios | `git add numbers.txt` |
-> > |4 | Hacer commit a los cambios | `git commit -m "Agregar 100 a numbers.txt"` |
-> > |5 | Actualizar repositorio remoto | `git push origin master` |
-> > |6 | ¡Celebrar! | `AFK` |
-> >
-> {: .solution}
-{: .challenge}
-
-
-{% include links.md %}
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Solucionando conflictos creados por ti
+
+Clona el repositorio creado por tu instructor.
+Agrégale un nuevo archivo
+y modificar un archivo existente (tu instructor te dirá cuál).
+Cuando tu instructor te lo pida,
+trae los cambios -haciendo **pull**\- desde el repositorio para crear un conflicto,
+y luego resuélvelo.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Conflictos en archivos no textuales
+
+¿Qué hace Git
+cuando hay un conflicto en una imagen u otro archivo no de texto
+que está almacenado con control de versiones?
+
+::::::::::::::: solution
+
+## Solución
+
+Intentémoslo. Supón que **Dracula** toma una foto de la superficie de Marte y la llama `mars.jpg`.
+
+Si no tienes una imagen de Marte, puedes crear un archivo
+binario de prueba de la siguiente manera:
+
+```bash
+$ head --bytes 1024 /dev/urandom > mars.jpg
+$ ls -lh mars.jpg
+```
+
+```output
+-rw-r--r-- 1 vlad 57095 1.0K Mar 8 20:24 mars.jpg
+```
+
+`ls` nos muestra que se creó un archivo de 1-kilobyte. Está lleno de bytes al azar
+leídos a partir del archivo especial, `/dev/urandom`.
+
+Ahora, supón que **Dracula** agrega `mars.jpg` a su repositorio:
+
+```bash
+$ git add mars.jpg
+$ git commit -m "Add picture of Martian surface"
+```
+
+```output
+[master 8e4115c] Add picture of Martian surface
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ create mode 100644 mars.jpg
+```
+
+Supón que Wolfman agregó una imagen similar al mismo tiempo.
+La suya es una imagen del cielo de Marte, pero *también* se llama `mars.jpg`.
+Cuando **Dracula** intenta hacer push, recibe un mensaje familiar:
+
+```bash
+$ git push origin master
+```
+
+```output
+To https://github.com/vlad/planets.git
+ ! [rejected] master -> master (fetch first)
+error: failed to push some refs to 'https://github.com/vlad/planets.git'
+hint: Updates were rejected because the remote contains work that you do
+hint: not have locally. This is usually caused by another repository pushing
+hint: to the same ref. You may want to first integrate the remote changes
+hint: (e.g., 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+```
+
+Hemos aprendido que primero debemos hacer **pull** y resolver conflictos:
+
+```bash
+$ git pull origin master
+```
+
+Cuando hay un conflicto en una imagen u otro archivo binario, git imprime
+un mensaje así:
+
+```output
+$ git pull origin master
+remote: Counting objects: 3, done.
+remote: Compressing objects: 100% (3/3), done.
+remote: Total 3 (delta 0), reused 0 (delta 0)
+Unpacking objects: 100% (3/3), done.
+From https://github.com/vlad/planets.git
+ * branch master -> FETCH_HEAD
+ 6a67967..439dc8c master -> origin/master
+warning: Cannot merge binary files: mars.jpg (HEAD vs. 439dc8c08869c342438f6dc4a2b615b05b93c76e)
+Auto-merging mars.jpg
+CONFLICT (add/add): Merge conflict in mars.jpg
+Automatic merge failed; fix conflicts and then commit the result.
+```
+
+El mensaje informando el conflicto es básicamente el mismo que se imprimió para `mars.txt`, pero
+hay una línea adicional:
+
+```output
+warning: Cannot merge binary files: mars.jpg (HEAD vs. 439dc8c08869c342438f6dc4a2b615b05b93c76e)
+```
+
+Git no puede insertar indicadores de conflicto en una imagen como lo hace en los
+archivos de texto. Por lo tanto, en vez de editar la imagen, debemos revisar la versión que
+queremos mantener. Luego podemos agregar y hacer **commit** a esta versión.
+
+En la línea agregada de arriba, Git convenientemente nos dio identificadores de **commit**
+para las dos versiones de `mars.jpg`. Nuestra versión es `HEAD`, y la de Wolfman
+es `439dc8c0...`. Si queremos usar nuestra versión, podemos usar
+`git checkout`:
+
+```bash
+$ git checkout HEAD mars.jpg
+$ git add mars.jpg
+$ git commit -m "Use image of surface instead of sky"
+```
+
+```output
+[master 21032c3] Use image of surface instead of sky
+```
+
+En cambio si queremos usar la versión de Wolfman, podemos usar `git checkout` con
+el identificador de **commit** de Wolfman, `439dc8c0`:
+
+```bash
+$ git checkout 439dc8c0 mars.jpg
+$ git add mars.jpg
+$ git commit -m "Use image of sky instead of surface"
+```
+
+```output
+[master da21b34] Use image of sky instead of surface
+```
+
+También podemos mantener *ambas* imágenes. La clave es que no podemos mantenerlas con el mismo
+nombre. Pero podemos verificar cada versión de forma sucesiva y *renombrarla*, y luego agregar las versiones renombradas.
+Primero, revisa cada imagen y renómbrala:
+
+```bash
+$ git checkout HEAD mars.jpg
+$ git mv mars.jpg mars-surface.jpg
+$ git checkout 439dc8c0 mars.jpg
+$ mv mars.jpg mars-sky.jpg
+```
+
+Luego, elimina la vieja imagen `mars.jpg` y agrega los dos archivos nuevos:
+
+```bash
+$ git rm mars.jpg
+$ git add mars-surface.jpg
+$ git add mars-sky.jpg
+$ git commit -m "Use two images: surface and sky"
+```
+
+```output
+[master 94ae08c] Use two images: surface and sky
+ 2 files changed, 0 insertions(+), 0 deletions(-)
+ create mode 100644 mars-sky.jpg
+ rename mars.jpg => mars-surface.jpg (100%)
+```
+
+Ahora ambas imágenes de Marte estan ingresadas en el repositorio, y `mars.jpg`
+ya no existe.
+
+
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Una típica sesión de trabajo
+
+Te sientas en tu computadora para trabajar en un proyecto compartido que es mantenido en un
+repositorio Git remoto. Durante tu sesión de trabajo, realizas las siguientes acciones,
+pero no en éste orden:
+
+- *Hacer cambios* agregando el número `100` al archivo de texto `numbers.txt`
+- *Actualizar repositorio remoto* para actualizar el repositorio local
+- *Celebrar* tu éxito con cerveza(s)
+- *Actualizar repositorio local* para actualizar el repositorio remoto
+- *Realizar cambios* con los cuales voy a hacer commit
+- *Hacer commit a los cambios* al repositorio local
+
+¿En qué orden deberías hacer estas acciones para minimizar la posibilidad de conflictos?
+Pon los comandos de arriba en orden en la columna *acción* de la tabla de abajo.
+Cuando tengas el orden correcto, ve si puedes escribir los comandos correspondientes en la columna
+*comando*. Algunos campos ya están completados para ayudarte a
+comenzar.
+
+| orden | acción . . . . . . . . . . | comando . . . . . . . . . . |
+| ----- | ----------------------------- | --------------------------- |
+| 1 | | |
+| 2 | | `echo 100 >> numbers.txt` |
+| 3 | | |
+| 4 | | |
+| 5 | | |
+| 6 | ¡Celebrar! | `AFK` |
+
+::::::::::::::: solution
+
+## Solución
+
+| orden | acción . . . . . . . . . . | comando . . . . . . . . . . |
+| ----- | ----------------------------- | --------------------------- |
+| 1 | Actualizar repositorio local | `git pull origin master` |
+| 2 | Hacer cambios | `echo 100 >> numbers.txt` |
+| 3 | Realizar cambios | `git add numbers.txt` |
+| 4 | Hacer commit a los cambios | `git commit -m "Agregar 100 a numbers.txt"` |
+| 5 | Actualizar repositorio remoto | `git push origin master` |
+| 6 | ¡Celebrar! | `AFK` |
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- Los conflictos ocurren cuando dos o más personas cambian el mismo archivo(s) al mism/o tiempo.
+- El sistema de control de versiones no permite a las personas sobreescribir ciegamente los cambios del otro, pero resalta los conflictos para poder resolverlos.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/episodes/10-open.md b/episodes/10-open.md
index cf9b38d5..3fc59ce7 100644
--- a/episodes/10-open.md
+++ b/episodes/10-open.md
@@ -2,72 +2,102 @@
title: La ciencia abierta
teaching: 5
exercises: 5
-questions:
-- "¿Cómo un control de versiones me puede ayudar a tener mi trabajo más abierto?"
-objectives:
-- "Explica como el control de versiones nos ayuda a tener un cuaderno electrónico para todo nuestro trabajo computacional."
-keypoints:
-- "Trabajo científico abierto es más útil y puede ser citado más que si no lo es."
---
-> Lo opuesto a "abierto" no es "cerrado".
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Explica como el control de versiones nos ayuda a tener un cuaderno electrónico para todo nuestro trabajo computacional.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Cómo un control de versiones me puede ayudar a tener mi trabajo más abierto?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+> Lo opuesto a "abierto" no es "cerrado".
> Lo opuesto a "abierto" es "quebrado".
->
-> --- John Wilbanks
+>
+> \--- John Wilbanks
El libre intercambio de información podría ser el ideal en Ciencia. Pero la realidad, a menudo, es mucho más complicada.
-En la práctica cotidiana vemos situaciones como la siguiente:
-
-* Una científica recoge algunos datos y los almacena en una máquina que seguramente tiene en su oficina.
-* Luego ella escribe y modifica unos pocos programas para analizar los datos (los cuales residen en su computadora).
-* Una vez que tiene algunos resultados, ella escribe y presenta su artículo. Podría incluir sus datos -en varias revistas que los requieran- pero probablemente no incluya su código.
-* El tiempo pasa.
-* La revista envía las revisiones de un puñado de personas anónimas que trabajan en su campo de actividad.
- Ella revisa su artículo para satisfacer las revisiones propuestas. Durante ese tiempo ella también podría modificar los **scripts** que escribió anteriormente, y vuelve a enviar.
-* Pasa más tiempo.
-* El artículo finalmente se publica.
-* Se podría incluir un enlace a una copia online de sus datos, pero el mismo artículo está detrás de un sitio web de pago: sólo las personas que tienen acceso personal o institucional serán capaces de leerlo.
+En la práctica cotidiana vemos situaciones como la siguiente:
+
+- Una científica recoge algunos datos y los almacena en una máquina que seguramente tiene en su oficina.
+- Luego ella escribe y modifica unos pocos programas para analizar los datos (los cuales residen en su computadora).
+- Una vez que tiene algunos resultados, ella escribe y presenta su artículo. Podría incluir sus datos -en varias revistas que los requieran- pero probablemente no incluya su código.
+- El tiempo pasa.
+- La revista envía las revisiones de un puñado de personas anónimas que trabajan en su campo de actividad.
+ Ella revisa su artículo para satisfacer las revisiones propuestas. Durante ese tiempo ella también podría modificar los **scripts** que escribió anteriormente, y vuelve a enviar.
+- Pasa más tiempo.
+- El artículo finalmente se publica.
+- Se podría incluir un enlace a una copia online de sus datos, pero el mismo artículo está detrás de un sitio web de pago: sólo las personas que tienen acceso personal o institucional serán capaces de leerlo.
Para muchos otros científicos, el proceso abierto se ve así:
-* Los datos que obtiene son almacenados, tan pronto como los colecta, en un repositorio de acceso abierto, como puede ser [figshare](http://figshare.com/) o [Zenodo](http://zenodo.org), obteniendo su propio [Digital Object Identifier] (https://en.wikipedia.org/wiki/Digital_object_identifier) (DOI). O los datos que han sido recientemente publicados, son almacenados en [Dryad](http://datadryad.org/).
-* La científica crea un nuevo repositorio en GitHub para guardar su trabajo.
-* Al hacer su análisis de los datos, guarda los cambios de sus **scripts** (y posiblemente algunos archivos de salida) en ese repositorio. También utiliza el repositorio para su artículo. Entonces ese repositorio es el centro de colaboración con sus colegas.
-* Cuando está satisfecha con el estado de su artículo, publica una versión en [arXiv](http://arxiv.org/) o en algún otro servidor de preimpresión para invitar a sus compañeros a una retroalimentación.
-* Basado en esa retroalimentación, puede escribir varias revisiones antes de enviar finalmente su artículo a la revista.
-* El artículo publicado incluye enlaces a su preimpresión y a sus repositorios de código y datos, lo que hace mucho más fácil para otros científicos utilizar este trabajo como punto de partida para su propia investigación.
+- Los datos que obtiene son almacenados, tan pronto como los colecta, en un repositorio de acceso abierto, como puede ser [figshare](https://figshare.com/) o [Zenodo](https://zenodo.org), obteniendo su propio [Digital Object Identifier] ([https://en.wikipedia.org/wiki/Digital\_object\_identifier](https://en.wikipedia.org/wiki/Digital_object_identifier)) (DOI). O los datos que han sido recientemente publicados, son almacenados en [Dryad](https://datadryad.org/).
+- La científica crea un nuevo repositorio en GitHub para guardar su trabajo.
+- Al hacer su análisis de los datos, guarda los cambios de sus **scripts** (y posiblemente algunos archivos de salida) en ese repositorio. También utiliza el repositorio para su artículo. Entonces ese repositorio es el centro de colaboración con sus colegas.
+- Cuando está satisfecha con el estado de su artículo, publica una versión en [arXiv](https://arxiv.org/) o en algún otro servidor de preimpresión para invitar a sus compañeros a una retroalimentación.
+- Basado en esa retroalimentación, puede escribir varias revisiones antes de enviar finalmente su artículo a la revista.
+- El artículo publicado incluye enlaces a su preimpresión y a sus repositorios de código y datos, lo que hace mucho más fácil para otros científicos utilizar este trabajo como punto de partida para su propia investigación.
-Este modelo abierto acelera la investigación: el trabajo abierto [se cita y se reutiliza](http://dx.doi.org/10.1371/journal.pone.0000308). Sin embargo, las personas que quieren trabajar de esta manera necesitan tomar algunas decisiones sobre qué significa exactamente "abierto" y cómo hacerlo. Puedes encontrar más información sobre los diferentes aspectos de la Ciencia Abierta en [el libro](http://link.springer.com/book/10.1007/978-3-319-00026-8).
+Este modelo abierto acelera la investigación: el trabajo abierto [se cita y se reutiliza](https://dx.doi.org/10.1371/journal.pone.0000308). Sin embargo, las personas que quieren trabajar de esta manera necesitan tomar algunas decisiones sobre qué significa exactamente "abierto" y cómo hacerlo. Puedes encontrar más información sobre los diferentes aspectos de la Ciencia Abierta en [el libro](https://link.springer.com/book/10.1007/978-3-319-00026-8).
Ésta es una de las muchas razones por las que enseñamos el control de versiones. Cuando se utiliza con diligencia, responde a "cómo" actúa un cuaderno electrónico compartible:
-* Las etapas conceptuales del trabajo están documentadas, incluyendo quién hizo qué y cuándo se hizo. Cada paso está marcado con un identificador (el ID de confirmación) de cada uno de los intentos y propósitos.
-* Puedes vincular tu documentación de ideas y otros trabajos intelectuales directamente con los cambios que surgen de ellos.
-* Puedes referirte a lo que utilizaste en tu investigación para obtener tus resultados computacionales de manera única y recuperable.
-* Con un sistema de control de versiones como Git, todo el historial del repositorio es fácil de archivar para siempre.
-
-> ## Haciendo código citable
->
-> [Esta breve guía](https://guides.github.com/activities/citable-code/) de GitHub
-> explica cómo crear un "Digital Object Identifier (DOI)" para tu código, tus artículos, o cualquier cosa alojada en un repositorio de control de versiones.
-{: .callout}
-
-> ## ¿Cuán reproducible es mi trabajo?
->
-> Pide a un compañero de laboratorio que reproduzca un resultado que obtuviste
-> utilizando sólo lo que está disponible en un documento publicado o en la web.
-> Luego, trata de hacer lo mismo con los resultados de tu labmate.
-> Finalmente, reproducir los resultados de otro laboratorio.
-{: .challenge}
-
-> ## ¿Cómo encontrar un repositorio de datos adecuado?
->
-> Navega por Internet durante un par de minutos y echa un vistazo a los repositorios de datos mencionado anteriormente: [Figshare](http://figshare.com/), [Zenodo](http://zenodo.org), [Dryad](http://datadryad.org/). Dependiendo de tu campo de investigación, encuentra repositorios reconocidos por la comunidad en tu campo. También puede ser útil [estos repositorios de datos recomendados por Nature](http://www.nature.com/sdata/data-policies/repositories). Discute con tu vecino qué repositorio de datos deseas abordar para tu proyecto actual y explicale por qué.
-{: .challenge}
-
-> ## ¿Puedo publicar código también?
->
-> Hay nuevas maneras de publicar código y hacer que sea citable. Uno de ellos se describe [en la página principal del mismo GitHub](https://guides.github.com/activities/citable-code/). Básicamente es una combinación de GitHub (donde está el código) y Zenodo (el repositorio que crea el DOI). Lee esta página mientras sabes que ésta es sólo una de las muchas maneras de hacer tu código citable.
-{: .challenge}
-
-{% include links.md %}
+- Las etapas conceptuales del trabajo están documentadas, incluyendo quién hizo qué y cuándo se hizo. Cada paso está marcado con un identificador (el ID de confirmación) de cada uno de los intentos y propósitos.
+- Puedes vincular tu documentación de ideas y otros trabajos intelectuales directamente con los cambios que surgen de ellos.
+- Puedes referirte a lo que utilizaste en tu investigación para obtener tus resultados computacionales de manera única y recuperable.
+- Con un sistema de control de versiones como Git, todo el historial del repositorio es fácil de archivar para siempre.
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Haciendo código citable
+
+[Esta breve guía](https://guides.github.com/activities/citable-code/) de GitHub
+explica cómo crear un "Digital Object Identifier (DOI)" para tu código, tus artículos, o cualquier cosa alojada en un repositorio de control de versiones.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## ¿Cuán reproducible es mi trabajo?
+
+Pide a un compañero de laboratorio que reproduzca un resultado que obtuviste
+utilizando sólo lo que está disponible en un documento publicado o en la web.
+Luego, trata de hacer lo mismo con los resultados de tu labmate.
+Finalmente, reproducir los resultados de otro laboratorio.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## ¿Cómo encontrar un repositorio de datos adecuado?
+
+Navega por Internet durante un par de minutos y echa un vistazo a los repositorios de datos mencionado anteriormente: [Figshare](https://figshare.com/), [Zenodo](https://zenodo.org), [Dryad](https://datadryad.org/). Dependiendo de tu campo de investigación, encuentra repositorios reconocidos por la comunidad en tu campo. También puede ser útil [estos repositorios de datos recomendados por Nature](https://www.nature.com/sdata/data-policies/repositories). Discute con tu vecino qué repositorio de datos deseas abordar para tu proyecto actual y explicale por qué.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## ¿Puedo publicar código también?
+
+Hay nuevas maneras de publicar código y hacer que sea citable. Uno de ellos se describe [en la página principal del mismo GitHub](https://guides.github.com/activities/citable-code/). Básicamente es una combinación de GitHub (donde está el código) y Zenodo (el repositorio que crea el DOI). Lee esta página mientras sabes que ésta es sólo una de las muchas maneras de hacer tu código citable.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- Trabajo científico abierto es más útil y puede ser citado más que si no lo es.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/episodes/11-licensing.md b/episodes/11-licensing.md
index a63faf84..ec7808d2 100644
--- a/episodes/11-licensing.md
+++ b/episodes/11-licensing.md
@@ -2,48 +2,70 @@
title: Licencia
teaching: 5
exercises: 0
-questions:
-- "¿Qué información sobre licencias debería incluir en mi trabajo?"
-objectives:
-- "Explicar la importancia de agregar información de licencias a nuestro repositorio de código."
-- "Escoger la licencia apropiada."
-- "Explicar las diferencias en licencias y algunas expectativas sociales."
-keypoints:
-- "Las personas que usan la licencia **GPL** en su software tienen que asegurarse de que toda la estructura esté bajo ésta licencia; muchas otras licencias no requieren esto."
-- "La familia de licencias **Creative Commons** permite a las personas adaptarse a varios requerimientos y restricciones de atribución, la creación de trabajo derivado, compartir el trabajo, y comercialización."
-- "Personas sin conocimientos de leyes no deberían tratar de escribir nuevas licencias desde cero."
---
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Explicar la importancia de agregar información de licencias a nuestro repositorio de código.
+- Escoger la licencia apropiada.
+- Explicar las diferencias en licencias y algunas expectativas sociales.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Qué información sobre licencias debería incluir en mi trabajo?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
Cuando un repositorio público contiene código fuente, un manuscrito u otro trabajo creativo, éste debe incluir un archivo con el nombre `LICENCIA` o `LICENCIA.txt` en el directorio base del repositorio, que indique claramente bajo qué licencia se pone a disposición el contenido. Esto se debe a que la protección de propiedad intelectual (y por lo tanto derechos de autor) se aplica automáticamente a las obras creativas. La reutilización de trabajos creativos sin licencia es peligrosa, ya que los titulares de los derechos de autor podrían realizar una demanda por infringir la misma.
-Una licencia resuelve el problema otorgando derechos a otros (los licenciatarios) que de otro modo no tendrían. Los derechos que se otorgan y bajo qué condiciones difieren, a menudo de forma leve, de una licencia a otra. En la práctica, algunas licencias son las más populares, y el sitio [choosealicense.com](http://choosealicense.com/) te ayudará a encontrar una licencia que se adapte a tus necesidades. Las cosas importantes a considerar son:
+Una licencia resuelve el problema otorgando derechos a otros (los licenciatarios) que de otro modo no tendrían. Los derechos que se otorgan y bajo qué condiciones difieren, a menudo de forma leve, de una licencia a otra. En la práctica, algunas licencias son las más populares, y el sitio [choosealicense.com](https://choosealicense.com/) te ayudará a encontrar una licencia que se adapte a tus necesidades. Las cosas importantes a considerar son:
-* Si deseas abordar los derechos de patente.
-* Si necesitas personas que distribuyan los trabajos derivados de tu código fuente.
-* Si el contenido al que estás otorgando la licencia es código fuente.
-* Si realmente deseas licenciar el código.
+- Si deseas abordar los derechos de patente.
+- Si necesitas personas que distribuyan los trabajos derivados de tu código fuente.
+- Si el contenido al que estás otorgando la licencia es código fuente.
+- Si realmente deseas licenciar el código.
Elegir una licencia que sea de uso común hace la vida más fácil para los contribuyentes y los usuarios, porque es probable que ya estén familiarizados con la licencia y no tengan que sortear una jerga específica para decidir si están de acuerdo con la licencia.
-La [Iniciativa Open Source](http://opensource.org/licenses) y [Free Software Foundation](http://www.gnu.org/licenses/license-list.html) mantienen listas de licencias que pueden son buenas opciones a considerar.
+La [Iniciativa Open Source](https://opensource.org/licenses) y [Free Software Foundation](https://www.gnu.org/licenses/license-list.html) mantienen listas de licencias que pueden son buenas opciones a considerar.
Este artículo sobre [licencias de software](https://doi.org/10.1371/journal.pcbi.1002598) proporciona una excelente descripción de licencias y de opciones de licencias desde la perspectiva de los científicos que también escriben código.
Al fin de cuentas, lo que importa es que haya información clara sobre cuál es la licencia. Además, es mejor elegir la licencia desde el principio, incluso si se trata de un repositorio que no es público. Retrasar la decisión de sobre qué licencia elegir sólo complica las cosas más adelante, porque cada vez que un nuevo colaborador comienza a contribuir, ellos también tienen derechos de autor y, por lo tanto, se les debe pedir aprobación una vez que se elige una licencia.
-> ## ¿Puedo usar una **Open License**?
->
-> Investiga si puedes usar una **Open license** o "Licencia Abierta" en tu **software**. ¿Puedes hacer eso por tí mismo?, ¿o necesitas permiso de alguien dentro de tu institución? Si necesitas permiso, ¿de quién?
-{: .challenge}
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## ¿Puedo usar una **Open License**?
+
+Investiga si puedes usar una **Open license** o "Licencia Abierta" en tu **software**. ¿Puedes hacer eso por tí mismo?, ¿o necesitas permiso de alguien dentro de tu institución? Si necesitas permiso, ¿de quién?
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## ¿Qué licencias ya he aceptado?
+
+Muchas herramientas de **software** que usamos día a día (incluyendo las herramientas en este **workshop**) son
+**open-source software**. Escoge uno de los proyectos de GitHub de la lista de abajo, o algún otro que te interese. Encuentra la licencia (usualmente es un archivo que se llama `LICENSE` o `COPYING`) y luego habla con tus compañeros sobre como ésta licencia te permite o te restringe el uso del **software**. ¿Es una de las licencias que hemos visto en esta sesión? ¿Qué tan diferente es ésta licencia?
+
+- [Git](https://github.com/git/git), herramientas para el manejo de código fuente.
+- [CPython](https://github.com/python/cpython), implementación estándar del lenguaje Python.
+- [Jupyter](https://github.com/jupyter), el proyecto que implementa **notebooks** para correr Python en la **web** que usaremos en este **workshop**.
+- [EtherPad](https://github.com/ether/etherpad-lite), un editor colaborativo en tiempo real.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- Las personas que usan la licencia **GPL** en su software tienen que asegurarse de que toda la estructura esté bajo ésta licencia; muchas otras licencias no requieren esto.
+- La familia de licencias **Creative Commons** permite a las personas adaptarse a varios requerimientos y restricciones de atribución, la creación de trabajo derivado, compartir el trabajo, y comercialización.
+- Personas sin conocimientos de leyes no deberían tratar de escribir nuevas licencias desde cero.
-> ## ¿Qué licencias ya he aceptado?
->
-> Muchas herramientas de **software** que usamos día a día (incluyendo las herramientas en este **workshop**) son
-> **open-source software**. Escoge uno de los proyectos de GitHub de la lista de abajo, o algún otro que te interese. Encuentra la licencia (usualmente es un archivo que se llama `LICENSE` o `COPYING`) y luego habla con tus compañeros sobre como ésta licencia te permite o te restringe el uso del **software**. ¿Es una de las licencias que hemos visto en esta sesión? ¿Qué tan diferente es ésta licencia?
-> - [Git](https://github.com/git/git), herramientas para el manejo de código fuente.
-> - [CPython](https://github.com/python/cpython), implementación estándar del lenguaje Python.
-> - [Jupyter](https://github.com/jupyter), el proyecto que implementa **notebooks** para correr Python en la **web** que usaremos en este **workshop**.
-> - [EtherPad](https://github.com/ether/etherpad-lite), un editor colaborativo en tiempo real.
-{: .challenge}
+::::::::::::::::::::::::::::::::::::::::::::::::::
-{% include links.md %}
diff --git a/episodes/12-citation.md b/episodes/12-citation.md
index 5995eabf..75308176 100644
--- a/episodes/12-citation.md
+++ b/episodes/12-citation.md
@@ -2,20 +2,26 @@
title: Ejemplo de Referencia o cita
teaching: 2
exercises: 0
-questions:
-- "¿Cómo puedo hacer que mi trabajo sea más fácil de citar?"
-objectives:
-- "Haz que tu trabajo sea más fácil de citar"
-keypoints:
-- "Agrega un archivo CITATION al repositorio y explica cómo quieres que tu trabajo sea citado."
---
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Haz que tu trabajo sea más fácil de citar
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Cómo puedo hacer que mi trabajo sea más fácil de citar?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
Te recomendamos que incluyas un archivo llamado `CITATION` o `CITATION.txt`
que describa cómo citar o referenciar tu proyecto.
-La siguiente cita es de
+La siguiente cita es de
[Software Carpentry](https://github.com/swcarpentry/website/blob/gh-pages/CITATION):
-~~~
+```source
To reference Software Carpentry in publications, please cite both of the following:
Greg Wilson: "Software Carpentry: Getting Scientists to Write Better
@@ -41,8 +47,14 @@ July 2013.
eprinttype = {arxiv},
eprint = {1307.5448}
}
-~~~
-{: .source}
+```
+
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- Agrega un archivo CITATION al repositorio y explica cómo quieres que tu trabajo sea citado.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
-{% include links.md %}
diff --git a/episodes/13-hosting.md b/episodes/13-hosting.md
index 68ef9a0e..d44f128e 100644
--- a/episodes/13-hosting.md
+++ b/episodes/13-hosting.md
@@ -2,15 +2,20 @@
title: Hospedaje
teaching: 10
exercises: 0
-questions:
-- "¿Dónde debería alojar mis repositorios de control de versiones?"
-objectives:
-- "Explicar diferentes opciones para realizar trabajos científicos."
-keypoints:
-- "Los proyectos pueden alojarse en servidores de la universidad, en dominios personales o públicas."
-- "Las reglas con respecto a la propiedad intelectual y el almacenamiento de información confidencial se aplican sin importar dónde se alojan el código y los datos."
---
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Explicar diferentes opciones para realizar trabajos científicos.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Dónde debería alojar mis repositorios de control de versiones?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
La segunda gran pregunta para los grupos que quieren liberar su trabajo es dónde
hospedar su código y datos. Una opción es que el laboratorio, departamento o la
universidad provean un servidor, gestionen cuentas y respaldos, etc. El principal
@@ -19,69 +24,90 @@ importante si algún material es sensible (es decir, se relaciona a experimentos
que involucran sujetos humanos o pueden ser usados en una patente). Las principales
desventajas son el costo de proveer el servicio y su longevidad: un científico
que ha pasado diez años colectando datos quisiera asegurarse de que estos estarán
-disponibles en diez años más, pero eso está más allá del tiempo de vida de muchos
+disponibles en diez años más, pero eso está más allá del tiempo de vida de muchos
de los subsidios que financian la infraestructura académica.
Otra opción es comprar un dominio y pagar a un Proveedor de Servicios de Internet
(ISP por sus siglas en inglés) para hospedarlo. Esto da al individuo o grupo mayor
-control, y le da la vuelta a problemas que pueden surgir cuando se cambien de una
+control, y le da la vuelta a problemas que pueden surgir cuando se cambien de una
institución a otra, pero requiere más tiempo y esfuerzo para configurar que la
opción anterior o siguiente.
La tercera opción es utilizar un servicio de hospedaje público como
-[GitHub](http://github.com), [GitLab](http://gitlab.com),
-[BitBucket](http://bitbucket.org) o [SourceForge](http://sourceforge.net).
+[GitHub](https://github.com), [GitLab](https://gitlab.com),
+[BitBucket](https://bitbucket.org) o [SourceForge](https://sourceforge.net).
Cada uno de estos servicios provee una interfaz web que permite a las personas
-crear, ver y editar sus repositorios de código. Estos servicios también proveen
+crear, ver y editar sus repositorios de código. Estos servicios también proveen
herramientas de comunicación y gestión de proyectos que incluyen `seguimiento de problemas`,
páginas wiki, notificaciones de correo electrónico y revisiones de código. Estos
servicios se benefician de economías de escalamiento y efectos de redes: es más
fácil correr un servicio grande bien que correr varios pequeños servicios al
-mismo estándar. También es más fácil para la gente colaborar. Usando un servicio
+mismo estándar. También es más fácil para la gente colaborar. Usando un servicio
popular puede ayudar a conectar tu proyecto con una comunidad que ya está usando el
mismo servicio.
-Como un ejemplo, Software Carpentry [está en
+Como un ejemplo, Software Carpentry [está en
GitHub]({{ swc_github }}), donde puedes encontrar el [código fuente para esta
página](https://github.com/swcarpentry/git-novice-es/blob/gh-pages/_episodes/13-hosting.md).
Cualquiera con una cuenta de GitHub puede sugerir cambios a este texto.
Usando servicios grandes y bien establecidos puede también ayudarte a tomar
-ventaja rápidamente de herramientas poderosas tales como la Integración
-Continua (CI por sus siglas en inglés). CI puede automaticamente construir el ejecutable a partir del codigo fuente y probar el
-software automáticamente cada vez que se hace un `commit` o se somete un
-`pull request`. La integración directa de CI con un servicio de hospedaje en
+ventaja rápidamente de herramientas poderosas tales como la Integración
+Continua (CI por sus siglas en inglés). CI puede automaticamente construir el ejecutable a partir del codigo fuente y probar el
+software automáticamente cada vez que se hace un `commit` o se somete un
+`pull request`. La integración directa de CI con un servicio de hospedaje en
línea significa que esta información está presente en cualquier `pull request`
y ayudar a mantener la integridad y estándares de calidad del código. Si bien
CI está disponible en situaciones de auto-hospedaje, hay menos configuración y
-mantenimiento al usar un servicio en línea. Más aún, estas herramientas son
+mantenimiento al usar un servicio en línea. Más aún, estas herramientas son
proporcionadas sin costo alguno para proyectos de código abierto y están también
disponibles para repositorios privados por una cuota.
-> ## Barreras Institucionales
->
-> Compartir es el ideal de la ciencia,
-> pero muchas instituciones imponen restricciones al compartir,
-> por ejemplo para proteger propiedad intelectual potencialmente patentable.
-> Si encuentras tales restricciones,
-> pudiera ser productivo indagar acerca de las motivaciones
-> ya sea para solicitar una excepción para un proyecto específico o dominio,
-> o para impulsar una reforma institucional más amplia para el apoyo de la ciencia abierta.
-{: .callout}
-
-> ## ¿Mi Trabajo Puede Ser Público?
->
-> Averigua si tienes permitido hospedar tu trabajo abiertamente en un repositorio público.
-> ¿Puedes hacer esto unilateralmente,
-> o necesitas permiso de alguien en tu institución?
-> Si ese es el caso, ¿de quién?
-{: .challenge}
-
-> ## ¿Dónde Puedo Compartir Mi Trabajo?
->
-> ¿Tu institución tiene un repositorio(s) donde puedas compartir tus
-> artículos, datos y software? ¿Cómo los repositorios institucionales
-> difieren de servicios como [arXiV](http://arxiv.org/), [figshare](http://figshare.com/) y [GitHub](http://github.com/)?
-{: .challenge}
-
-{% include links.md %}
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Barreras Institucionales
+
+Compartir es el ideal de la ciencia,
+pero muchas instituciones imponen restricciones al compartir,
+por ejemplo para proteger propiedad intelectual potencialmente patentable.
+Si encuentras tales restricciones,
+pudiera ser productivo indagar acerca de las motivaciones
+ya sea para solicitar una excepción para un proyecto específico o dominio,
+o para impulsar una reforma institucional más amplia para el apoyo de la ciencia abierta.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## ¿Mi Trabajo Puede Ser Público?
+
+Averigua si tienes permitido hospedar tu trabajo abiertamente en un repositorio público.
+¿Puedes hacer esto unilateralmente,
+o necesitas permiso de alguien en tu institución?
+Si ese es el caso, ¿de quién?
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## ¿Dónde Puedo Compartir Mi Trabajo?
+
+¿Tu institución tiene un repositorio(s) donde puedas compartir tus
+artículos, datos y software? ¿Cómo los repositorios institucionales
+difieren de servicios como [arXiV](https://arxiv.org/), [figshare](https://figshare.com/) y [GitHub](https://github.com/)?
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- Los proyectos pueden alojarse en servidores de la universidad, en dominios personales o públicas.
+- Las reglas con respecto a la propiedad intelectual y el almacenamiento de información confidencial se aplican sin importar dónde se alojan el código y los datos.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/episodes/14-supplemental-rstudio.md b/episodes/14-supplemental-rstudio.md
index e88f051c..0c307645 100644
--- a/episodes/14-supplemental-rstudio.md
+++ b/episodes/14-supplemental-rstudio.md
@@ -2,56 +2,66 @@
title: Usando Git desde RStudio
teaching: 10
exercises: 0
-questions:
-- "¿Cómo puedo usar Git desde RStudio?"
-objectives:
-- "Entender cómo usar Git desde RStudio."
-keypoints:
-- "Crear un proyecto en RStudio"
---
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Entender cómo usar Git desde RStudio.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- ¿Cómo puedo usar Git desde RStudio?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
Ya que el uso de control de versiones es muy útil cuando escribimos **scripts**, entonces RStudio esta integrado con Git. Hay algunas otras mas complejas funcionalidades de Git que solamente se pueden usar desde la terminal, pero RStudio tiene una buena interfaz de trabajo para realizar las operaciones más comunes de control de versiones.
RStudio te permite crear un proyecto [project][rstudio-projects] asociado a un directorio determinado. Esta es una manera de hacer un seguimiento de los archivos asociados al proyecto. Una manera de tener control de archivos es mediante el uso de un programa de control de versiones. Para empezar a usar RStudio para el control de versiones, comencemos por crear un nuevo proyecto:
-
+
Una nueva ventana se abrirá y preguntará cómo queremos crear el proyecto. Tenemos
aquí varias opciones. Supongamos que queremos usar RStudio con el repositorio de planetas
que ya hemos creado. Como ese repositorio ya está en una carpeta en tu computadora,
podemos escoger la opción "Existing Directory":
-
+
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## ¿Puedes ver la opción de "Version Control"?
+
+Aunque no vamos a usar ésta opción aquí, deberías poder ver una opción en el menú que diga
+"Version Control". Esta es la opción que debes escoger cuando quieras crear
+un proyecto en tu computadora mediante una clonación de un repositorio de GitHub.
+Si esta opción no es visible, probablemente significa que RStudio no sabe
+donde está tu ejecutable de Git. Revisa
+[esta página](https://stat545-ubc.github.io/git03_rstudio-meet-git.html)
+para encontrar algunos consejos. Incluso después de instalar Git, si estás usando MacOSX
+algunas veces puede ser necesario que tengas que aceptar la licencia de XCode
-> ## ¿Puedes ver la opción de "Version Control"?
->
-> Aunque no vamos a usar ésta opción aquí, deberías poder ver una opción en el menú que diga
-> "Version Control". Esta es la opción que debes escoger cuando quieras crear
-> un proyecto en tu computadora mediante una clonación de un repositorio de GitHub.
-> Si esta opción no es visible, probablemente significa que RStudio no sabe
-> donde está tu ejecutable de Git. Revisa
-> [esta página](https://stat545-ubc.github.io/git03_rstudio-meet-git.html)
-> para encontrar algunos consejos. Incluso después de instalar Git, si estás usando MacOSX
-> algunas veces puede ser necesario que tengas que aceptar la licencia de XCode
-{: .callout}
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
En el siguiente paso, RStudio va a preguntar cuál es la carpeta existente que queremos usar. Haremos
click en el navegador de archivos para navegar a la carpeta correcta en tu computadora, y luego haremos click en
"Create Project":
-
+
¡Y ya está! Ahora tenemos un proyecto en R que contiene tu propio repositorio. Fíjate que ahora en el menú aparece un botón con "Git" en letras verticales. Esto significa que RStudio ha reconocido que ésta carpeta es un repositorio de Git, así que te proporcionará las herramientas para usar Git:
-
+
Para editar los archivos en tu repositorio, puedes hacer click en el archivo desde el panel inferior izquierdo. Ahora vamos a añadir más información sobre Plutón:
-
+
Una vez que hemos guardado nuestros archivos editados, ahora podemos usar RStudio para hacer permanentes los cambios. Usa el botón y haz clik a "Commit":
-
+
Esto abrirá una ventana donde puedes seleccionar qué archivos quieres hacer **commit** (marca
las casillas en la columna "Staged") y luego escribe un mensaje para el **commit** (en el panel
@@ -59,60 +69,83 @@ superior derecho). Los iconos en la columna "Status" indican el estado actual de
archivo. También puedes ver los cambios de cada archivo haciendo click en su nombre. Una vez
que todo esté de la forma que quieres, haz click en "Commit":
-
+
Puedes subir los cambios seleccionando "Push" en el menú de Git. Allí hay también
opciones para traer los cambios (hacer **pull**) desde una versión remota de este repositorio, y ver
el historial de cambios realizados:
-
+
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+¿Están los comandos **Push** y **Pull** en gris?
+
+Si este es el caso, generalmente significa que RStudio no sabe dónde están las
+otras versiones de tu repositorio (por ejemplo, en GitHub).
+Para solucionar esto, abre una terminal, sitúate en el repositorio y luego lanza el siguiente comando:
+`git push -u origin master`. Luego reinicia RStudio.
+
-> ¿Están los comandos **Push** y **Pull** en gris?
->
-> Si este es el caso, generalmente significa que RStudio no sabe dónde están las
-> otras versiones de tu repositorio (por ejemplo, en GitHub).
-> Para solucionar esto, abre una terminal, sitúate en el repositorio y luego lanza el siguiente comando:
-> `git push -u origin master`. Luego reinicia RStudio.
-{: .callout}
+::::::::::::::::::::::::::::::::::::::::::::::::::
Si hacemos click en el historial de cambios "History", podemos ver una versión gráfica de lo
que obtendríamos con el comando `git log`:
-
+
RStudio crea algunos archivos que le ayudan a mantener un control de los cambios en el proyecto. Normalmente no deseamos que Git los incluya en el control de versiones, así que es una buena idea agregar sus nombres al `.gitignore`:
-
-
-> ## Tip: Control de versiones del output desechable (versioning disposable output)
->
-> Generalmente tu no quieres hacer control de cambios o versiones de tus output desechables (o solo datos de lectura).
-> Entonces, tu debes modificar el archivo `.gitignore` para decirle a Git que ignore estos archivos
-> y directorios.
-{: .callout}
-
-> ## Challenge
->
-> 1. Crear un directorio dentro de tu proyecto llamado `graphs`.
-> 2. Modificar el archivo `.gitignore` para que contenga `graphs/`
-> entonces este output desechable no estara **versioned**.
->
-> Agrega el folder recien creado al control de versiones usando la interface de Git.
->
-> > ## Solucion del Challenge
-> >
-> > Esto puede ser realizado con los comandos de linea:
-> > ```
-> > $ mkdir graphs
-> > $ echo "graphs/" >> .gitignore
-> > ```
-> > {: . shell}
-> {: .solution}
-{: .challenge}
+
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Tip: Control de versiones del output desechable (versioning disposable output)
+
+Generalmente tu no quieres hacer control de cambios o versiones de tus output desechables (o solo datos de lectura).
+Entonces, tu debes modificar el archivo `.gitignore` para decirle a Git que ignore estos archivos
+y directorios.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::: challenge
+
+## Challenge
+
+1. Crear un directorio dentro de tu proyecto llamado `graphs`.
+2. Modificar el archivo `.gitignore` para que contenga `graphs/`
+ entonces este output desechable no estara **versioned**.
+
+Agrega el folder recien creado al control de versiones usando la interface de Git.
+
+::::::::::::::: solution
+
+## Solucion del Challenge
+
+Esto puede ser realizado con los comandos de linea:
+
+``` shell
+$ mkdir graphs
+$ echo "graphs/" >> .gitignore
+```
+
+:::::::::::::::::::::::::
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
Hay muchas más opciones que se pueden encontrar en la interfaz de RStudio,
pero las que hemos visto son suficientes para comenzar.
+
+
[rstudio-projects]: https://support.rstudio.com/hc/en-us/articles/200526207-Using-Projects
-{% include links.md %}
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- Crear un proyecto en RStudio
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+
diff --git a/fig/RStudio_screenshot_afterclone.png b/episodes/fig/RStudio_screenshot_afterclone.png
similarity index 100%
rename from fig/RStudio_screenshot_afterclone.png
rename to episodes/fig/RStudio_screenshot_afterclone.png
diff --git a/fig/RStudio_screenshot_commit.png b/episodes/fig/RStudio_screenshot_commit.png
similarity index 100%
rename from fig/RStudio_screenshot_commit.png
rename to episodes/fig/RStudio_screenshot_commit.png
diff --git a/fig/RStudio_screenshot_editfiles.png b/episodes/fig/RStudio_screenshot_editfiles.png
similarity index 100%
rename from fig/RStudio_screenshot_editfiles.png
rename to episodes/fig/RStudio_screenshot_editfiles.png
diff --git a/fig/RStudio_screenshot_existingdirectory.png b/episodes/fig/RStudio_screenshot_existingdirectory.png
similarity index 100%
rename from fig/RStudio_screenshot_existingdirectory.png
rename to episodes/fig/RStudio_screenshot_existingdirectory.png
diff --git a/fig/RStudio_screenshot_gitignore.png b/episodes/fig/RStudio_screenshot_gitignore.png
similarity index 100%
rename from fig/RStudio_screenshot_gitignore.png
rename to episodes/fig/RStudio_screenshot_gitignore.png
diff --git a/fig/RStudio_screenshot_history.png b/episodes/fig/RStudio_screenshot_history.png
similarity index 100%
rename from fig/RStudio_screenshot_history.png
rename to episodes/fig/RStudio_screenshot_history.png
diff --git a/fig/RStudio_screenshot_navigateexisting.png b/episodes/fig/RStudio_screenshot_navigateexisting.png
similarity index 100%
rename from fig/RStudio_screenshot_navigateexisting.png
rename to episodes/fig/RStudio_screenshot_navigateexisting.png
diff --git a/fig/RStudio_screenshot_newproject.png b/episodes/fig/RStudio_screenshot_newproject.png
similarity index 100%
rename from fig/RStudio_screenshot_newproject.png
rename to episodes/fig/RStudio_screenshot_newproject.png
diff --git a/fig/RStudio_screenshot_review.png b/episodes/fig/RStudio_screenshot_review.png
similarity index 100%
rename from fig/RStudio_screenshot_review.png
rename to episodes/fig/RStudio_screenshot_review.png
diff --git a/fig/RStudio_screenshot_viewhistory.png b/episodes/fig/RStudio_screenshot_viewhistory.png
similarity index 100%
rename from fig/RStudio_screenshot_viewhistory.png
rename to episodes/fig/RStudio_screenshot_viewhistory.png
diff --git a/fig/conflict.svg b/episodes/fig/conflict.svg
similarity index 100%
rename from fig/conflict.svg
rename to episodes/fig/conflict.svg
diff --git a/fig/git-checkout.svg b/episodes/fig/git-checkout.svg
similarity index 100%
rename from fig/git-checkout.svg
rename to episodes/fig/git-checkout.svg
diff --git a/fig/git-committing.svg b/episodes/fig/git-committing.svg
similarity index 100%
rename from fig/git-committing.svg
rename to episodes/fig/git-committing.svg
diff --git a/fig/git-freshly-made-github-repo.svg b/episodes/fig/git-freshly-made-github-repo.svg
similarity index 100%
rename from fig/git-freshly-made-github-repo.svg
rename to episodes/fig/git-freshly-made-github-repo.svg
diff --git a/fig/git-staging-area.svg b/episodes/fig/git-staging-area.svg
similarity index 100%
rename from fig/git-staging-area.svg
rename to episodes/fig/git-staging-area.svg
diff --git a/fig/git_staging.svg b/episodes/fig/git_staging.svg
similarity index 100%
rename from fig/git_staging.svg
rename to episodes/fig/git_staging.svg
diff --git a/fig/github-add-collaborators.png b/episodes/fig/github-add-collaborators.png
similarity index 100%
rename from fig/github-add-collaborators.png
rename to episodes/fig/github-add-collaborators.png
diff --git a/fig/github-change-repo-string.png b/episodes/fig/github-change-repo-string.png
similarity index 100%
rename from fig/github-change-repo-string.png
rename to episodes/fig/github-change-repo-string.png
diff --git a/fig/github-collaboration.svg b/episodes/fig/github-collaboration.svg
similarity index 100%
rename from fig/github-collaboration.svg
rename to episodes/fig/github-collaboration.svg
diff --git a/fig/github-create-repo-01.png b/episodes/fig/github-create-repo-01.png
similarity index 100%
rename from fig/github-create-repo-01.png
rename to episodes/fig/github-create-repo-01.png
diff --git a/fig/github-create-repo-02.png b/episodes/fig/github-create-repo-02.png
similarity index 100%
rename from fig/github-create-repo-02.png
rename to episodes/fig/github-create-repo-02.png
diff --git a/fig/github-create-repo-03.png b/episodes/fig/github-create-repo-03.png
similarity index 100%
rename from fig/github-create-repo-03.png
rename to episodes/fig/github-create-repo-03.png
diff --git a/fig/github-find-repo-string.png b/episodes/fig/github-find-repo-string.png
similarity index 100%
rename from fig/github-find-repo-string.png
rename to episodes/fig/github-find-repo-string.png
diff --git a/fig/github-repo-after-first-push.svg b/episodes/fig/github-repo-after-first-push.svg
similarity index 100%
rename from fig/github-repo-after-first-push.svg
rename to episodes/fig/github-repo-after-first-push.svg
diff --git a/fig/merge.svg b/episodes/fig/merge.svg
similarity index 100%
rename from fig/merge.svg
rename to episodes/fig/merge.svg
diff --git a/fig/phd101212s.png b/episodes/fig/phd101212s.png
similarity index 100%
rename from fig/phd101212s.png
rename to episodes/fig/phd101212s.png
diff --git a/fig/play-changes.svg b/episodes/fig/play-changes.svg
similarity index 100%
rename from fig/play-changes.svg
rename to episodes/fig/play-changes.svg
diff --git a/fig/versions.svg b/episodes/fig/versions.svg
similarity index 100%
rename from fig/versions.svg
rename to episodes/fig/versions.svg
diff --git a/index.md b/index.md
index f520fdf0..c193081d 100644
--- a/index.md
+++ b/index.md
@@ -1,9 +1,8 @@
---
-layout: lesson
-root: .
+site: sandpaper::sandpaper_site
---
-Para ilustrar el poder de Git y GitHub, usaremos la siguiente historia
+Para ilustrar el poder de Git y GitHub, usaremos la siguiente historia
como un ejemplo motivador a través de esta lección.
El Hombre Lobo y Drácula han sido contratados por Universal Missions para investigar si es
@@ -14,27 +13,27 @@ turnos entonces cada uno gastará mucho tiempo esperando a que el otro
termine, pero si trabajan en sus propias copias e intercambian los cambios
por email, las cosas se perderán, se sobreescribirán o se duplicarán.
-Un colega sugiere utilizar [control de versiones]({{ page.root }}/reference#control-de-versiones)
+Un colega sugiere utilizar [control de versiones](learners/reference.md#control-de-versiones)
para lidiar con el trabajo. El control de versiones es mejor que el intercambio de ficheros por email:
-* Nada se pierde una vez que se incluye bajo control de versiones,
- a no ser que se haga un esfuerzo sustancial. Como se van guardando
- todas las versiones precedentes de los ficheros, siempre es posible
- volver atrás en el tiempo y ver exactamente quién escribió qué en
- un día en particular, o qué versión de un programa fue utilizada
- para generar un conjunto de resultados en particular.
-
-* Como se tienen estos registros de quién hizo qué y en qué momento,
- es posible saber a quién preguntar si se tiene una pregunta en un
- momento posterior y, si es necesario, revertir el contenido a una
- versión anterior, de forma similar a como funciona el comando "deshacer"
- de los editores de texto.
-
-* Cuando varias personas colaboran en el mismo proyecto, es posible
- pasar por alto o sobreescribir de manera accidental los cambios
- hechos por otra persona. El sistema de control de versiones
- notifica automáticamente a los usuarios cada vez que hay un
- conflicto entre el trabajo de una persona y la otra.
+- Nada se pierde una vez que se incluye bajo control de versiones,
+ a no ser que se haga un esfuerzo sustancial. Como se van guardando
+ todas las versiones precedentes de los ficheros, siempre es posible
+ volver atrás en el tiempo y ver exactamente quién escribió qué en
+ un día en particular, o qué versión de un programa fue utilizada
+ para generar un conjunto de resultados en particular.
+
+- Como se tienen estos registros de quién hizo qué y en qué momento,
+ es posible saber a quién preguntar si se tiene una pregunta en un
+ momento posterior y, si es necesario, revertir el contenido a una
+ versión anterior, de forma similar a como funciona el comando "deshacer"
+ de los editores de texto.
+
+- Cuando varias personas colaboran en el mismo proyecto, es posible
+ pasar por alto o sobreescribir de manera accidental los cambios
+ hechos por otra persona. El sistema de control de versiones
+ notifica automáticamente a los usuarios cada vez que hay un
+ conflicto entre el trabajo de una persona y la otra.
Los equipos no son los únicos que se benefician del control de
versiones: los investigadores independientes se pueden beneficiar
@@ -44,10 +43,15 @@ si alguna vez necesitan retomar el proyecto en un momento
posterior (e.g. un año después, cuando se ha desvanecido el
recuerdo de los detalles).
-> ## Pre-requisitos
->
-> En esta lección utilizamos Git desde el terminal de Unix.
-> Se espera de los participantes alguna experiencia previa,
-> *pero esto no es requisito indispensable*.
-{: .prereq}
+:::::::::::::::::::::::::::::::::::::::::: prereq
+
+## Pre-requisitos
+
+En esta lección utilizamos Git desde el terminal de Unix.
+Se espera de los participantes alguna experiencia previa,
+*pero esto no es requisito indispensable*.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
diff --git a/_extras/guide.md b/instructors/instructor-notes.md
similarity index 58%
rename from _extras/guide.md
rename to instructors/instructor-notes.md
index 95a30ca7..4b15162f 100644
--- a/_extras/guide.md
+++ b/instructors/instructor-notes.md
@@ -1,21 +1,21 @@
---
-title: "Instructor Notes"
+title: Instructor Notes
---
Usar una herramienta de software para manejar las versiones de tus archivos de proyecto
le permite enfocarse en los aspectos más interesantes / innovadores de su proyecto.
-* Ventajas del control de versiones
- * Es fácil de configurar
- * Cada copia de un repositorio de Git es una copia de seguridad completa de un proyecto y su historial
- * Unos pocos comandos fáciles de recordar son todo lo que necesita para la mayoría de las tareas cotidianas de control de versiones
- * El servicio de alojamiento [GitHub][github] proporciona un servicio de colaboración basado en la web
-* Dos conceptos principales
- * *commit*: un conjunto de cambios registrados en los archivos de su proyecto
- * *repositorio*: el historial de todas las confirmaciones de su proyecto
-* ¿Por qué usar GitHub?
- * No es necesario un servidor: fácil de configurar
- * Comunidad fuerte de GitHub: tus colegas probablemente ya estén allí
+- Ventajas del control de versiones
+ - Es fácil de configurar
+ - Cada copia de un repositorio de Git es una copia de seguridad completa de un proyecto y su historial
+ - Unos pocos comandos fáciles de recordar son todo lo que necesita para la mayoría de las tareas cotidianas de control de versiones
+ - El servicio de alojamiento [GitHub][github] proporciona un servicio de colaboración basado en la web
+- Dos conceptos principales
+ - *commit*: un conjunto de cambios registrados en los archivos de su proyecto
+ - *repositorio*: el historial de todas las confirmaciones de su proyecto
+- ¿Por qué usar GitHub?
+ - No es necesario un servidor: fácil de configurar
+ - Comunidad fuerte de GitHub: tus colegas probablemente ya estén allí
## En general
@@ -30,167 +30,171 @@ temas interesantes, como ramificación, hash y commit de objetos.
En cambio, tratamos de convencerlos de que el control de versiones es útil para los investigadores
trabajando en equipo o no, porque es
-* una mejor forma de "deshacer" cambios,
-* una mejor manera de colaborar que enviar y recibir archivos por correo, y
-* una mejor manera de compartir tu código y otro trabajo científico con el mundo.
+- una mejor forma de "deshacer" cambios,
+- una mejor manera de colaborar que enviar y recibir archivos por correo, y
+- una mejor manera de compartir tu código y otro trabajo científico con el mundo.
## Notas de enseñanza
-* Recursos para "dividir" su caparazón para que los comandos recientes permanezcan a la vista: https://github.com/rgaiacs/swc-shell-split-window.
+- Recursos para "dividir" su caparazón para que los comandos recientes permanezcan a la vista: [https://github.com/rgaiacs/swc-shell-split-window](https://github.com/rgaiacs/swc-shell-split-window).
-* Asegúrese de que la red esté funcionando *antes* de comenzar esta lección.
+- Asegúrese de que la red esté funcionando *antes* de comenzar esta lección.
-* Los dibujos son particularmente útiles en esta lección: si tiene una pizarra blanca, [usarlo][dibujos]!
+- Los dibujos son particularmente útiles en esta lección: si tiene una pizarra blanca, [usarlo][dibujos]!
-* El control de versiones generalmente no es el primer tema en un taller, así que haga que los alumnos creen una cuenta de GitHub después de la sesión anterior. Recuerde a los alumnos que el nombre de usuario y el correo electrónico que usan para GitHub (y configuración durante la configuración de Git) será visible para el público de manera predeterminada. Sin embargo, hay muchas razones por las cuales un alumno puede no querer su personal información visible, y GitHub tiene [recursos para mantener una dirección de correo electrónico privado][github-privacy].
+- El control de versiones generalmente no es el primer tema en un taller, así que haga que los alumnos creen una cuenta de GitHub después de la sesión anterior. Recuerde a los alumnos que el nombre de usuario y el correo electrónico que usan para GitHub (y configuración durante la configuración de Git) será visible para el público de manera predeterminada. Sin embargo, hay muchas razones por las cuales un alumno puede no querer su personal información visible, y GitHub tiene [recursos para mantener una dirección de correo electrónico privado][github-privacy].
-* Si algunos estudiantes usan Windows, inevitablemente habrá problemas fusionando archivos con diferentes finales de línea. (Incluso si todos están encendidos un poco de sabor de Unix, diferentes editores pueden o no agregar una nueva línea a la última línea de un archivo.) Tómese un momento para explicar estos problemas, ya que los estudiantes seguramente tropezarán con ellos de nuevo. Si los estudiantes se están encontrando con problemas para terminar la línea, GitHub tiene una [página][github-line-endings] que ayuda a solucionar problemas.
+- Si algunos estudiantes usan Windows, inevitablemente habrá problemas fusionando archivos con diferentes finales de línea. (Incluso si todos están encendidos un poco de sabor de Unix, diferentes editores pueden o no agregar una nueva línea a la última línea de un archivo.) Tómese un momento para explicar estos problemas, ya que los estudiantes seguramente tropezarán con ellos de nuevo. Si los estudiantes se están encontrando con problemas para terminar la línea, GitHub tiene una [página][github-line-endings] que ayuda a solucionar problemas.
-* No usamos una GUI de Git en estas notas porque no hemos encontrado una que se instala fácilmente y funciona confiablemente en los tres principales sistemas operativos, y porque queremos que los alumnos entiendan qué comandos se están ejecutando. Ese dijo, los instructores deberían demo una GUI en su escritorio en algún momento durante esta lección y apunte a los alumnos en [esta página][github-gui].
+- No usamos una GUI de Git en estas notas porque no hemos encontrado una que se instala fácilmente y funciona confiablemente en los tres principales sistemas operativos, y porque queremos que los alumnos entiendan qué comandos se están ejecutando. Ese dijo, los instructores deberían demo una GUI en su escritorio en algún momento durante esta lección y apunte a los alumnos en [esta página][github-gui].
-* Los instructores deben mostrar a los alumnos herramientas gráficas de fusión / fusión como [DiffMerge][diffmerge].
+- Los instructores deben mostrar a los alumnos herramientas gráficas de fusión / fusión como [DiffMerge][diffmerge].
-* Cuando sea apropiado, explique que enseñamos a Git en lugar de CVS, Subversion, o Mercurial principalmente debido a la creciente popularidad de GitHub: CVS y Subversion ahora se ve como sistemas heredados, y Mercurial no es tan ampliamente utilizado en las ciencias en este momento.
+- Cuando sea apropiado, explique que enseñamos a Git en lugar de CVS, Subversion, o Mercurial principalmente debido a la creciente popularidad de GitHub: CVS y Subversion ahora se ve como sistemas heredados, y Mercurial no es tan ampliamente utilizado en las ciencias en este momento.
-* Recursos adicionales:
- * [git-it][git-it] es una demostración de Git de línea de comandos a tu propio ritmo, con [git-it-electron][git-it-electron] su sucesor de GitHub Desktop.
- * [Code School][code-school] tiene un curso interactivo gratuito, [Try Git][try-git].
- * para instructores, [la parábola de Git][git-parábola] es una lectura de fondo útil
+- Recursos adicionales:
+
+ - [git-it] es una demostración de Git de línea de comandos a tu propio ritmo, con [git-it-electron] su sucesor de GitHub Desktop.
+ - [Code School][code-school] tiene un curso interactivo gratuito, [Try Git][try-git].
+ - para instructores, [la parábola de Git][git-parábola] es una lectura de fondo útil
-## [Control automatizado de versiones]({{page.root}}/01-basics/)
+## [Control automatizado de versiones](../episodes/01-basics.md)
-* Pregunte, "¿Quién usa 'deshacer' en su editor?" Todos dicen "Yo". 'Deshacer' es el más simple forma de control de versiones.
+- Pregunte, "¿Quién usa 'deshacer' en su editor?" Todos dicen "Yo". 'Deshacer' es el más simple forma de control de versiones.
-* Ofrezca a los alumnos una visión general de cinco minutos de lo que el control de versión les hace antes de zambullirte en las prácticas de vigilancia. La mayoría de ellos tendrá intentó coautar documentos enviando archivos por correo electrónico, o tendrá en bicicleta en la oficina solo para darse cuenta de que la llave USB con la última noche el trabajo todavía está en la mesa de la cocina. Los instructores también pueden hacer bromas sobre directorios con nombres como "versión final", "versión final revisada", "versión final con las correcciones del revisor tres", "versión realmente final", y, "vamos, realmente tiene que ser la última versión" para motivar la versión control como una mejor manera de colaborar y como una mejor manera de respaldar el trabajo.
+- Ofrezca a los alumnos una visión general de cinco minutos de lo que el control de versión les hace antes de zambullirte en las prácticas de vigilancia. La mayoría de ellos tendrá intentó coautar documentos enviando archivos por correo electrónico, o tendrá en bicicleta en la oficina solo para darse cuenta de que la llave USB con la última noche el trabajo todavía está en la mesa de la cocina. Los instructores también pueden hacer bromas sobre directorios con nombres como "versión final", "versión final revisada", "versión final con las correcciones del revisor tres", "versión realmente final", y, "vamos, realmente tiene que ser la última versión" para motivar la versión control como una mejor manera de colaborar y como una mejor manera de respaldar el trabajo.
-## [Configuración de Git]({{page.root}}/02-setup/)
+## [Configuración de Git](../episodes/02-setup.md)
-* Sugerimos que los instructores y los estudiantes usen `nano` como editor de texto para este lecciones porque
- * se ejecuta en los tres principales sistemas operativos,
- * se ejecuta dentro del caparazón (las ventanas de conmutación pueden ser confusas para los estudiantes), y
- * tiene ayuda contextual en la parte inferior de la ventana.
+- Sugerimos que los instructores y los estudiantes usen `nano` como editor de texto para este lecciones porque
+ - se ejecuta en los tres principales sistemas operativos,
+ - se ejecuta dentro del caparazón (las ventanas de conmutación pueden ser confusas para los estudiantes), y
+ - tiene ayuda contextual en la parte inferior de la ventana.
Señale a los alumnos durante la configuración que pueden y deben usar
otro editor de texto si ya están familiarizados con él.
-* Al configurar Git, tenga muy claro lo que los alumnos deben ingresar: es común que editen los detalles del instructor (por ejemplo, correo electrónico). Verifique en el final usando `git config --list`.
+- Al configurar Git, tenga muy claro lo que los alumnos deben ingresar: es común que editen los detalles del instructor (por ejemplo, correo electrónico). Verifique en el final usando `git config --list`.
-## [Creación de un repositorio]({{page.root}}/03-create/)
+## [Creación de un repositorio](../episodes/03-create.md)
-* Cuando haces `git status`, los usuarios de Mac pueden ver un archivo` .DS_Store` mostrando como sin seguimiento. Este es un archivo que Mac OS crea en cada directorio.
+- Cuando haces `git status`, los usuarios de Mac pueden ver un archivo` .DS_Store` mostrando como sin seguimiento. Este es un archivo que Mac OS crea en cada directorio.
-* El desafío "Lugares para crear repositorios" intenta reforzar la idea que la carpeta `.git` contiene todo el repositorio de Git y eliminando esta carpeta deshace un `git init`. También le da al alumno la manera de solucionar el problema común error de poner carpetas no deseadas (como `Escritorio`) bajo control de versión.
+- El desafío "Lugares para crear repositorios" intenta reforzar la idea que la carpeta `.git` contiene todo el repositorio de Git y eliminando esta carpeta deshace un `git init`. También le da al alumno la manera de solucionar el problema común error de poner carpetas no deseadas (como `Escritorio`) bajo control de versión.
En lugar de eliminar la carpeta `.git` directamente, puede elegir moverla primero en un directorio más seguro y eliminarlo de allí:
-~~~
+```bash
$ mv .git temp_git
$ rm -rf temp_git
-~~~
-{: .language-bash}
+```
El desafío sugiere que es una mala idea crear un repositorio de Git dentro de otro repositorio.
Para obtener más información sobre este tema, consulte [este número][repos-in-repos].
-## [Cambios de seguimiento]({{page.root}}/04-changes/)
+## [Cambios de seguimiento](../episodes/04-changes.md)
-* Es importante que los alumnos realicen un ciclo completo de compromiso por sí mismos (hacer cambios, `git diff`,` git add`, y `git commit`). El "repositorio de `bio`" desafío hace eso.
+- Es importante que los alumnos realicen un ciclo completo de compromiso por sí mismos (hacer cambios, `git diff`,` git add`, y `git commit`). El "repositorio de `bio`" desafío hace eso.
-* Este es un buen momento para mostrar una diferencia con una herramienta gráfica de diferencia. Si tu omítalo porque tiene poco tiempo, muéstrelo una vez en GitHub.
+- Este es un buen momento para mostrar una diferencia con una herramienta gráfica de diferencia. Si tu omítalo porque tiene poco tiempo, muéstrelo una vez en GitHub.
-* Una cosa puede causar confusión es la recuperación de versiones antiguas. Si, en lugar de haciendo `$ git checkout f22b25e mars.txt`, alguien hace `$ git checkout f22b25e`, terminan en el estado "HEAD separado" y la confusión abunda. Entonces es posible seguir cometiendo, pero cosas como `git push origen master` un poco más tarde no dará resultados fácilmente comprensibles. También hace que parezca que los commits se pueden perder. Para "arreglar" una "CABEZA separada", simplemente `git checkout master`.
+- Una cosa puede causar confusión es la recuperación de versiones antiguas. Si, en lugar de haciendo `$ git checkout f22b25e mars.txt`, alguien hace `$ git checkout f22b25e`, terminan en el estado "HEAD separado" y la confusión abunda. Entonces es posible seguir cometiendo, pero cosas como `git push origen master` un poco más tarde no dará resultados fácilmente comprensibles. También hace que parezca que los commits se pueden perder. Para "arreglar" una "CABEZA separada", simplemente `git checkout master`.
-* Este es un buen momento para mostrar un registro dentro de una GUI de Git. Si te lo saltas porque tienes poco tiempo, muéstralo una vez en GitHub.
+- Este es un buen momento para mostrar un registro dentro de una GUI de Git. Si te lo saltas porque tienes poco tiempo, muéstralo una vez en GitHub.
-## [Ignorando cosas]({{page.root}}/06-ignore/)
+## [Ignorando cosas](../episodes/06-ignore.md)
Solo recuerda que puedes usar comodines y expresiones regulares para ignorar un un conjunto particular de archivos en `.gitignore`.
-## [Controles remotos en GitHub]({{page.root}}/07-github/)
+## [Controles remotos en GitHub](../episodes/07-github.md)
-* Deje en claro que Git y GitHub no son lo mismo: Git es una persona abierta herramienta de control de versión fuente, GitHub es una compañía que aloja Git repositorios en la web y proporciona una interfaz web para interactuar con repositorios ellos hospedan
+- Deje en claro que Git y GitHub no son lo mismo: Git es una persona abierta herramienta de control de versión fuente, GitHub es una compañía que aloja Git repositorios en la web y proporciona una interfaz web para interactuar con repositorios ellos hospedan
-* Si tus alumnos están lo suficientemente avanzados como para sentirse cómodos con SSH, cuéntales pueden usar claves para autenticarse en GitHub en lugar de contraseñas, pero no intente configurar esto durante la clase: lleva demasiado tiempo y es una distracción de las ideas centrales de la lección.
+- Si tus alumnos están lo suficientemente avanzados como para sentirse cómodos con SSH, cuéntales pueden usar claves para autenticarse en GitHub en lugar de contraseñas, pero no intente configurar esto durante la clase: lleva demasiado tiempo y es una distracción de las ideas centrales de la lección.
-* Es muy útil dibujar un diagrama que muestre los diferentes repositorios involucrado.
+- Es muy útil dibujar un diagrama que muestre los diferentes repositorios involucrado.
-## [Collaborating]({{page.root}}/08-collab/)
+## [Collaborating](../episodes/08-collab.md)
-* Decidir por adelantado si todos los alumnos trabajarán en una compartida repositorio, o si van a trabajar en parejas (u otros grupos pequeños) en repositorios separados. El primero es más fácil de configurar; el último corre más suave.
+- Decidir por adelantado si todos los alumnos trabajarán en una compartida repositorio, o si van a trabajar en parejas (u otros grupos pequeños) en repositorios separados. El primero es más fácil de configurar; el último corre más suave.
-* El juego de roles entre dos instructores puede ser efectivo cuando se enseña secciones de colaboración y conflicto de la lección. Un instructor puede jugar el papel del propietario del repositorio, mientras que el segundo instructor puede jugar el papel del colaborador. Si es posible, intente usar dos proyectores para que se pueden ver las pantallas de los dos instructores. Esto hace para una ilustración muy clara para los estudiantes sobre quién hace qué.
+- El juego de roles entre dos instructores puede ser efectivo cuando se enseña secciones de colaboración y conflicto de la lección. Un instructor puede jugar el papel del propietario del repositorio, mientras que el segundo instructor puede jugar el papel del colaborador. Si es posible, intente usar dos proyectores para que se pueden ver las pantallas de los dos instructores. Esto hace para una ilustración muy clara para los estudiantes sobre quién hace qué.
-* También es efectivo emparejar a los estudiantes durante esta lección y asignar uno miembro de la pareja para tomar el papel del propietario y el otro el papel de el colaborador En esta configuración, los desafíos pueden incluir preguntar al
- colaborador para hacer un cambio, comprometerlo y enviar el cambio al control remoto repositorio para que el propietario pueda recuperarlo y viceversa. los el juego de roles entre los instructores puede ser un poco "dramático" en el conflictos parte de la lección si los instructores quieren inyectar un poco de humor en la habitación.
+- También es efectivo emparejar a los estudiantes durante esta lección y asignar uno miembro de la pareja para tomar el papel del propietario y el otro el papel de el colaborador En esta configuración, los desafíos pueden incluir preguntar al
+ colaborador para hacer un cambio, comprometerlo y enviar el cambio al control remoto repositorio para que el propietario pueda recuperarlo y viceversa. los el juego de roles entre los instructores puede ser un poco "dramático" en el conflictos parte de la lección si los instructores quieren inyectar un poco de humor en la habitación.
-* Si no tiene dos proyectores, tenga dos instructores al frente del
- habitación. Cada instructor hace su parte de la demostración de colaboración en su propia computadora y luego pasa el cable del proyector de un lado a otro con el otro instructor cuando es hora de que hagan la otra parte de el flujo de trabajo colaborativo. Toma menos de 10 segundos para cada cambio, por lo que no interrumpe el flujo de la lección. Y, por supuesto, ayuda a dar a cada uno de los instructores un color diferente sombrero, o poner notas adhesivas de diferentes colores en sus frentes.
+- Si no tiene dos proyectores, tenga dos instructores al frente del
+ habitación. Cada instructor hace su parte de la demostración de colaboración en su propia computadora y luego pasa el cable del proyector de un lado a otro con el otro instructor cuando es hora de que hagan la otra parte de el flujo de trabajo colaborativo. Toma menos de 10 segundos para cada cambio, por lo que no interrumpe el flujo de la lección. Y, por supuesto, ayuda a dar a cada uno de los instructores un color diferente sombrero, o poner notas adhesivas de diferentes colores en sus frentes.
-* Si eres el único instructor, la mejor manera de crear es clonar los dos repositorios en su escritorio, pero con diferentes nombres, por ejemplo, pretender uno es su computadora en el trabajo:
+- Si eres el único instructor, la mejor manera de crear es clonar los dos repositorios en su escritorio, pero con diferentes nombres, por ejemplo, pretender uno es su computadora en el trabajo:
-~~~
+```bash
$ git clone https://github.com/vlad/planets.git planets-at-work
-~~~
-{: .language-bash}
+```
-* Es muy común que los alumnos escriban mal el alias remoto o la URL remota cuando se agrega un control remoto, entonces no pueden 'presionar'. Puedes diagnosticar esto con `git remote -v` y comprobando cuidadosamente si hay errores tipográficos.
- - Para arreglar un alias incorrecto, puedes hacer `git remote rename `.
- - Para arreglar una URL incorrecta, puedes hacer `git remote set-url `.
+- Es muy común que los alumnos escriban mal el alias remoto o la URL remota cuando se agrega un control remoto, entonces no pueden 'presionar'. Puedes diagnosticar esto con `git remote -v` y comprobando cuidadosamente si hay errores tipográficos.
+
+ - Para arreglar un alias incorrecto, puedes hacer `git remote rename `.
+ - Para arreglar una URL incorrecta, puedes hacer `git remote set-url `.
-* Antes de clonar el repositorio, asegúrese de que nadie esté dentro de otro repositorio. los La mejor forma de lograr esto es pasar al `Escritorio` antes de la clonación: `cd && cd Desktop`.
+- Antes de clonar el repositorio, asegúrese de que nadie esté dentro de otro repositorio. los La mejor forma de lograr esto es pasar al `Escritorio` antes de la clonación: `cd && cd Desktop`.
-* Si ambos repos están en `Desktop`, pídales que clonen a su colaborador repo bajo un directorio dado usando un segundo argumento:
+- Si ambos repos están en `Desktop`, pídales que clonen a su colaborador repo bajo un directorio dado usando un segundo argumento:
-~~~
+```bash
$ git clone https://github.com/vlad/planets.git vlad-planet
-~~~
-{: .language-bash}
+```
-* El error más común es que los estudiantes "empujan" antes de "tirar". Si ellos `pull` después, pueden tener un conflicto.
+- El error más común es que los estudiantes "empujan" antes de "tirar". Si ellos `pull` después, pueden tener un conflicto.
-* Conflictos, a veces extraños, comenzarán a surgir. Mantente apretado: los conflictos son siguiente.
+- Conflictos, a veces extraños, comenzarán a surgir. Mantente apretado: los conflictos son siguiente.
-## [Conflicts]({{page.root}}/09-conflict/)
+## [Conflicts](../episodes/09-conflict.md)
-* Espere que los alumnos cometan errores. Espere *usted mismo* para cometer errores. Esta sucede porque es tarde en la lección y todos están cansados.
+- Espere que los alumnos cometan errores. Espere *usted mismo* para cometer errores. Esta sucede porque es tarde en la lección y todos están cansados.
-* Si eres el único instructor, la mejor forma de crear un conflicto es:
- * Clona tu repositorio en un directorio diferente, pretendiendo que es tu computadora en
- trabajo: `git clone https://github.com/vlad/planets.git planets-at-work`.
- * En la oficina, usted hace un cambio, se compromete y empuja.
- * En su repositorio de la computadora portátil, usted (olvide tirar y) hacer un cambio, comprometerse y
- intenta empujar.
- * `git pull` ahora y muestra el conflicto.
+- Si eres el único instructor, la mejor forma de crear un conflicto es:
+
+ - Clona tu repositorio en un directorio diferente, pretendiendo que es tu computadora en
+ trabajo: `git clone https://github.com/vlad/planets.git planets-at-work`.
+ - En la oficina, usted hace un cambio, se compromete y empuja.
+ - En su repositorio de la computadora portátil, usted (olvide tirar y) hacer un cambio, comprometerse y
+ intenta empujar.
+ - `git pull` ahora y muestra el conflicto.
-* Los estudiantes generalmente se olvidan de 'agregar' el archivo después de arreglar el conflicto y solo (intenta) comprometer. Puedes diagnosticar esto con `git status`.
+- Los estudiantes generalmente se olvidan de 'agregar' el archivo después de arreglar el conflicto y solo (intenta) comprometer. Puedes diagnosticar esto con `git status`.
-* Recuerde que puede descartar uno de los dos padres de la combinación:
- * descartar el archivo remoto, `git checkout --ours conflicted_file.txt`
- * descartar el archivo local, `git checkout --the conflictigned_file.txt`
+- Recuerde que puede descartar uno de los dos padres de la combinación:
+
+ - descartar el archivo remoto, `git checkout --ours conflicted_file.txt`
+ - descartar el archivo local, `git checkout --the conflictigned_file.txt`
Aún debe `git add` y` git commit` después de esto. Esto esparticularmente útil cuando se trabaja con archivos binarios.
-## [Ciencia abierta]({{page.root}}/10-open/)
+## [Ciencia abierta](../episodes/10-open.md)
-## [Licencias]({{page.root}}/11-licensing/)
+## [Licencias](../episodes/11-licensing.md)
Enseñamos sobre licencias porque preguntas sobre quién posee qué o qué puede usar qué, surgen naturalmente una vez que comenzamos a hablar sobre el uso de servicios públicos como GitHub para almacenar archivos. Además, la discusión les da a los estudiantes la oportunidad de atrapar su aliento después de lo que a menudo es un par de horas frustrantes.
-## [Citation]({{page.root}}/12-citation/)
+## [Citation](../episodes/12-citation.md)
-## [Alojamiento]({{page.root}}/13-hosting/)
+## [Alojamiento](../episodes/13-hosting.md)
Una preocupación común para los estudiantes es tener su trabajo a disposición del público en GitHub. Si bien fomentamos la ciencia abierta, a veces los repos privados son única opción. Siempre es interesante mencionar las opciones para tener repositorios privados alojados en la web.
-[code-school]: https://www.codeschool.com/
-[diffmerge]: https://sourcegear.com/diffmerge/
+[github]: https://github.com/
[dibujos]: https://marklodato.github.io/visual-git-guide/index-en.html
+[github-privacy]: https://help.github.com/articles/keeping-your-email-address-private/
+[github-line-endings]: https://help.github.com/articles/dealing-with-line-endings/#platform-all
+[github-gui]: https://git-scm.com/downloads/guis
+[diffmerge]: https://sourcegear.com/diffmerge/
[git-it]: https://github.com/jlord/git-it
[git-it-electron]: https://github.com/jlord/git-it-electron
-[git-parábola]: http://tom.preston-werner.com/2009/05/19/the-git-parable.html
-[github]: https://github.com/
-[github-gui]: http://git-scm.com/downloads/guis
-[github-line-endings]: https://help.github.com/articles/dealing-with-line-endings/#platform-all
-[github-privacy]: https://help.github.com/articles/keeping-your-email-address-private/
-[repos-in-repos]: https://github.com/swcarpentry/git-novice/issues/272
+[code-school]: https://www.codeschool.com/
[try-git]: https://try.github.io
+[git-parábola]: https://tom.preston-werner.com/2009/05/19/the-git-parable.html
+[repos-in-repos]: https://github.com/swcarpentry/git-novice/issues/272
+
+
+
diff --git a/_extras/discuss.md b/learners/discuss.md
similarity index 85%
rename from _extras/discuss.md
rename to learners/discuss.md
index 6c5fdb42..0b5aeb86 100644
--- a/_extras/discuss.md
+++ b/learners/discuss.md
@@ -11,17 +11,16 @@ Tenga en cuenta que dado que este material no es esencial para el uso básico de
## Más configuración avanzada de Git
-En [Configuración de Git]({{page.root}}/02-setup/),
+En [Configuración de Git](../episodes/02-setup.md),
usamos `git config --global` para establecer algunas opciones predeterminadas para Git.
Resulta que estas opciones de configuración se almacenan en su directorio de inicio
en un archivo de texto sin formato llamado `.gitconfig`.
-~~~
+```bash
$ cat ~/.gitconfig
-~~~
-{: .language-bash}
+```
-~~~
+```output
[user]
name = Vlad Dracula
email = vlad@tran.sylvan.ia
@@ -29,8 +28,7 @@ $ cat ~/.gitconfig
ui = true
[core]
editor = nano
-~~~
-{: .output}
+```
Este archivo se puede abrir en su editor de texto preferido.
(Tenga en cuenta que se recomienda continuar usando el comando `git config`,
@@ -40,34 +38,30 @@ Eventualmente, querrás comenzar a personalizar el comportamiento de Git.
Esto se puede hacer agregando más entradas a su `.gitconfig`.
Las opciones disponibles se describen en el manual:
-~~~
+```bash
$ git config --help
-~~~
-{: .language-bash}
+```
En particular, puede resultarle útil agregar alias.
Estos son como accesos directos para comandos de git más largos.
Por ejemplo, si te cansas de escribir `git checkout` todo el tiempo,
podrías ejecutar el comando:
-~~~
+```bash
$ git config --global alias.co checkout
-~~~
-{: .language-bash}
+```
-Ahora, si volvemos al ejemplo de [Explorando el historial]({{ page.root }}/05-history/) where we ran:
+Ahora, si volvemos al ejemplo de [Explorando el historial](../episodes/05-history.md) where we ran:
-~~~
+```bash
$ git checkout f22b25e mars.txt
-~~~
-{: .language-bash}
+```
ahora podríamos escribir:
-~~~
+```bash
$ git co f22b25e mars.txt
-~~~
-{: .language-bash}
+```
## Diseñando el registro de Git
@@ -80,41 +74,43 @@ Puede usar `git log --help` y` git config --help` para buscar diferentes formas
la salida de registro.
Pruebe los siguientes comandos y vea qué efecto tienen:
-~~~
+```bash
$ git config --global alias.lg "log --graph"
$ git config --global log.abbrevCommit true
$ git config --global format.pretty oneline
$ git lg
-~~~
-{: .language-bash}
+```
Si no te gustan los efectos,
puedes deshacerlos con:
-~~~
+```bash
$ git config --global --unset alias.lg
$ git config --global --unset log.abbrevCommit
$ git config --global --unset format.pretty
-~~~
-{: .language-bash}
-
-> ## Deshacer cambios en la configuración de Git
->
-> Puede usar el indicador `--unset` para eliminar las opciones no deseadas de` .gitconfig`.
-> Otra forma de deshacer los cambios es almacenar su `.gitconfig` usando Git.
->
-> Para sugerencias sobre lo que puede querer configurar,
-> vaya a GitHub y busque "gitconfig".
-> Encontrará cientos de repositorios en los que las personas han almacenado
-> sus propios archivos de configuración de Git.
-> Ordenarlos por el número de estrellas y echar un vistazo a los mejores.
-> Si encuentras alguno que te guste,
-> compruebe que estén cubiertos por una licencia de código abierto antes de clonarlos.
-{: .callout}
+```
+
+::::::::::::::::::::::::::::::::::::::::: callout
+
+## Deshacer cambios en la configuración de Git
+
+Puede usar el indicador `--unset` para eliminar las opciones no deseadas de` .gitconfig`.
+Otra forma de deshacer los cambios es almacenar su `.gitconfig` usando Git.
+
+Para sugerencias sobre lo que puede querer configurar,
+vaya a GitHub y busque "gitconfig".
+Encontrará cientos de repositorios en los que las personas han almacenado
+sus propios archivos de configuración de Git.
+Ordenarlos por el número de estrellas y echar un vistazo a los mejores.
+Si encuentras alguno que te guste,
+compruebe que estén cubiertos por una licencia de código abierto antes de clonarlos.
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
## Archivos sin texto
-Recordar cuando discutimos [Conflictos]({{page.root}}/09-conflict/)
+Recordar cuando discutimos [Conflictos](../episodes/09-conflict.md)
hubo un desafío que preguntó,
"¿Qué hace Git?
cuando hay un conflicto en una imagen o algún otro archivo no textual
@@ -140,56 +136,50 @@ utilizando salidas de un procesador de texto en lugar de texto sin formato.
Crea un nuevo directorio y entra en él:
-~~~
+```bash
$ mkdir planets-nontext
$ cd planets-nontext
-~~~
-{: .language-bash}
+```
Use un programa como Microsoft Word o LibreOffice Writer para crear un documento nuevo.
Ingrese el mismo texto con el que comenzamos antes:
-~~~
+```output
Cold and dry, but everything is my favorite color
-~~~
-{: .output}
+```
Guarde el documento en el directorio `planets-nontext` con el nombre de `mars.doc`.
De vuelta en la terminal, ejecute los comandos habituales para configurar un nuevo repositorio de Git:
-~~~
+```bash
$ git init
$ git add mars.doc
$ git commit -m "Starting to think about Mars"
-~~~
-{: .language-bash}
+```
Luego haga los mismos cambios a `mars.doc` que nosotros (o Vlad) previamente hicimos a `mars.txt`.
-~~~
+```output
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
-~~~
-{: .output}
+```
Guarde y cierre el procesador de texto.
Ahora mira lo que Git piensa de tus cambios:
-~~~
+```bash
$ git diff
-~~~
-{: .language-bash}
+```
-~~~
+```output
diff --git a/mars.doc b/mars.doc
index 53a66fd..6e988e9 100644
Binary files a/mars.doc and b/mars.doc differ
-~~~
-{: .output}
+```
Compare esto con el anterior `git diff` obtenido al usar archivos de texto:
-~~~
+```output
diff --git a/mars.txt b/mars.txt
index df0654a..315bf3a 100644
--- a/mars.txt
@@ -197,8 +187,7 @@ index df0654a..315bf3a 100644
@@ -1 +1,2 @@
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
-~~~
-{: .output}
+```
Observe cómo los archivos de texto plano dan una diferencia mucho más informativa.
Puede ver exactamente qué líneas cambiaron y cuáles fueron los cambios.
@@ -225,54 +214,48 @@ del repositorio.
Crea un nuevo archivo para el planeta Nibiru:
-~~~
+```bash
$ echo "This is another name for fake planet X" > nibiru.txt
-~~~
-{: .language-bash}
+```
Ahora agregue al repositorio como lo aprendió anteriormente:
-~~~
+```bash
$ git add nibiru.txt
$ git commit -m 'adding info on nibiru'
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
nothing to commit, working directory clean
-~~~
-{: .output}
+```
Nibiru no es un planeta real. Esa fue una idea tonta. Vamos a eliminar
desde el disco y deja que Git lo sepa:
-~~~
+```bash
$ git rm nibiru.txt
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
deleted: nibiru.txt
-~~~
-{: .output}
+```
El cambio ha sido organizado. Ahora comprometa la eliminación y elimine
archivo del propio repositorio. Tenga en cuenta que el archivo se eliminará
en el nuevo compromiso La confirmación anterior seguirá
tener el archivo, si fueras a recuperar esa confirmación específica.
-~~~
+```bash
$ git commit -m 'Removing info on Nibiru. It is not a real planet!'
-~~~
-{: .language-bash}
+```
## Eliminar un archivo con Unix
@@ -281,22 +264,20 @@ archivo con Unix `rm` en lugar de usar` git rm`, sin preocupaciones,
Git es lo suficientemente inteligente como para notar el archivo perdido. Vamos a recrear el archivo y
cometerlo de nuevo.
-~~~
+```bash
$ echo "This is another name for fake planet X" > nibiru.txt
$ git add nibiru.txt
$ git commit -m 'adding nibiru again'
-~~~
-{: .language-bash}
+```
Ahora eliminamos el archivo con Unix `rm`:
-~~~
+```bash
$ rm nibiru.txt
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Changes not staged for commit:
(use "git add/rm ..." to update what will be committed)
@@ -305,37 +286,33 @@ Changes not staged for commit:
deleted: nibiru.txt
no changes added to commit (use "git add" and/or "git commit -a")
-~~~
-{: .output}
+```
Vea cómo Git ha notado que el archivo `nibiru.txt` ha sido eliminado
del disco. El siguiente paso es "escenificar" la eliminación del archivo
del repositorio. Esto se hace con el comando `git rm` igual que
antes de.
-~~~
+```bash
$ git rm nibiru.txt
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
deleted: nibiru.txt
-~~~
-{: .output}
+```
El cambio que se hizo en Unix ahora se ha organizado y debe ser
comprometido.
-~~~
+```bash
$ git commit -m 'Removing info on Nibiru, again!'
-~~~
-{: .language-bash}
+```
## Renombrar un archivo
@@ -343,46 +320,41 @@ Otro cambio común cuando se trabaja en un proyecto es cambiar el nombre de un a
Crea un archivo para el planeta Krypton:
-~~~
+```bash
$ echo "Superman's home planet" > krypton.txt
-~~~
-{: .language-bash}
+```
Añádalo al repositorio:
-~~~
+```bash
$ git add krypton.txt
$ git commit -m 'Adding planet Krypton'
-~~~
-{: .language-bash}
+```
Todos sabemos que Superman se mudó a la Tierra. No es que tuviera mucho
elección. Ahora su planeta de origen es la Tierra.
Cambie el nombre del archivo `krypton.txt` a` earth.txt` con Git:
-~~~
+```bash
$ git mv krypton.txt earth.txt
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# renamed: krypton.txt -> earth.txt
#
-~~~
-{: .output}
+```
El último paso es comprometer nuestro cambio al repositorio:
-~~~
+```bash
$ git commit -m 'Superman's home is now Earth'
-~~~
-{: .language-bash}
+```
## Renombrar un archivo con Unix
@@ -392,21 +364,20 @@ ser capaz de lidiar con eso. Intentemos nuevamente cambiar el nombre del archivo
esta vez con Unix `mv`. Primero, necesitamos recrear el
archivo `krypton.txt`:
-~~~
+```bash
$ echo "Superman's home planet" > krypton.txt
$ git add krypton.txt
$ git commit -m 'Adding planet Krypton again.'
-~~~
-{: .language-bash}
+```
Vamos a renombrar el archivo y ver lo que Git puede descifrar por sí mismo:
-~~~
+
+```bash
$ mv krypton.txt earth.txt
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Changes not staged for commit:
(use "git add/rm ..." to update what will be committed)
@@ -420,36 +391,34 @@ Untracked files:
earth.txt
no changes added to commit (use "git add" and/or "git commit -a")
-~~~
-{: .output}
+```
Git notó que el archivo `krypton.txt` ha desaparecido del
sistema de archivos y un nuevo archivo `earth.txt` ha aparecido.
Agregue esos cambios al área de ensayo:
-~~~
+```bash
$ git add krypton.txt earth.txt
$ git status
-~~~
-{: .language-bash}
+```
-~~~
+```output
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
renamed: krypton.txt -> earth.txt
-~~~
-{: .output}
+```
Observe cómo Git ahora ha descubierto que el `krypton.txt` no tiene
desapareció simplemente ha sido renombrado.
El último paso, como antes, es comprometer nuestro cambio al repositorio:
-~~~
+```bash
$ git commit -m 'Superman's home is Earth, told you before.'
-~~~
-{: .language-bash}
+```
+
+
diff --git a/learners/reference.md b/learners/reference.md
new file mode 100644
index 00000000..180daa2a
--- /dev/null
+++ b/learners/reference.md
@@ -0,0 +1,81 @@
+---
+title: 'Cheatsheets de Git para Referencia Rápida'
+---
+
+## Cheatsheets de Git para Referencia Rápida
+
+- Un excelente [cheatsheet de git listo para impresión](https://services.github.com/on-demand/downloads/github-git-cheat-sheet.pdf) está disponible en formato PDF desde
+ [el sitio de preparación de GitHub](https://services.github.com/resources/).
+- Una [visualización interactiva](https://ndpsoftware.com/git-cheatsheet.html)
+ sobre las relaciones entre entorno de trabajo, área de staging, repositorio local y remoto, así los comandos asociados con cada caso (y sus explicaciones)
+- Ambos recursos están disponibles en varios lenguajes e.g. español, francés, y muchos más.
+
+## Glosario
+
+{:auto\_ids}
+changeset
+: Un grupo de cambios a uno o más ficheros que son o serán añadidos
+en un solo [commit](#commit) en un [repositorio](#repositorio)
+de [control de versiones](#control-de-versiones).
+
+commit
+: Como verbo *hacer un commit* es la acción de registrar el estado
+de un conjunto de ficheros en un momento determinado (un [changeset](#changeset))
+en un [repositorio](#repositorio) de [control de versiones](#control-de-versiones). Como sustantivo,
+*un commit* es el resultado de esta acción, i.e. un changeset almacenado en un repositorio.
+Si un commit contiene cambios hechos a múltiples ficheros,
+todos los cambios son almacenados juntos.
+
+conflicto
+: Un cambio hecho por un usuario de un [sistema de control de versiones](#control-de-versiones)
+que es incompatible con cambios hechos por otros usuarios.
+Asistir a los usuarios a [resolver](#resolver) conflictos
+es una de las funciones más importantes del control de versiones.
+
+HTTP
+: Siglas de Hypertext Transfer Protocol, el [protocolo](#protocolo) utilizado para compartir páginas web y otros datos
+en la World Wide Web.
+
+mezclar
+: (un repositorio): Reconciliar dos conjuntos de cambios en un
+[repositorio](#repositorio).
+
+protocolo
+: Un conjunto de reglas que definen cómo una computadora se comunica con otra.
+Entre los protocolos más utilizados en la Internet se encuentran [HTTP](#http) y [SSH](#ssh).
+
+remote
+: (de un repositorio) Un [repositorio](#repositorio) de [control de versiones](#control-de-versiones) conectado con otro
+de forma tal que ambos pueden ser actualizados intercambiando [commits](#commit).
+
+repositorio
+: Un área de almacenamiento donde un sistema de [control de versiones](#control-de-versiones)
+almacena la historia completa de [commits](#commit) de un proyecto, así como información
+sobre quién cambio qué, cuándo.
+
+resolver
+: Eliminar los [conflictos](#conflicto) entre dos o más cambios incompatibles sobre un fichero o un conjunto de ficheros
+administrados por un sistema de [control de versiones](#control-de-versiones).
+
+revisión
+: Un sinónimo de [commit](#commit).
+
+SHA-1
+: [SHA-1 hashes](https://en.wikipedia.org/wiki/SHA-1) es lo que Git utiliza para generar identificadores, incluyendo los de los commits.
+Para calcularlos, Git no solamente utiliza los cambios que forman parte de un commit, sino también sus metadatos (tales como fecha, autor,
+mensaje), incluyendo los identificadores de todos los commits hechos para cambios anteriores. Esto hace que los ID de commits de Git san virtualmente únicos.
+I.e., es ínfima la probabilidad de que un mismo ID se refiera a dos commits hechos de forma independiente, incluso si tuvieran los mismos cambios.
+
+SSH
+: Abreviatura de Secure Shell, un [protocolo](#protocolo) utilizado para la comunicación de forma segura entre computadoras.
+
+timestamp
+: Un registro de cuando ocurrió un evento específico.
+
+control de versiones
+: Una herramienta para administrar los cambios hechos a un conjunto de ficheros.
+Cada conjunto de cambios crea un nuevo[commit](#commit) de los ficheros;
+el sistema de control de versiones permite a los usuarios recibir de manera fiable los commits precedentes,
+y ayuda a solventar cambios conflictivos hechos por diferentes usuarios.
+
+
diff --git a/setup.md b/learners/setup.md
similarity index 90%
rename from setup.md
rename to learners/setup.md
index 7febf634..7666ff5d 100644
--- a/setup.md
+++ b/learners/setup.md
@@ -1,5 +1,4 @@
---
-layout: page
title: Setup
---
@@ -8,10 +7,12 @@ para conocer más instrucciones de instalación de Git.
Haremos nuestro trabajo en la carpeta `Desktop`. Por favor asegúrese de cambiar su directorio de trabajo con:
-~~~
+```bash
$ cd
$ cd Desktop
-~~~
-{: .language-bash}
+```
[workshop-setup]: https://carpentries.github.io/workshop-template/#git
+
+
+
diff --git a/profiles/learner-profiles.md b/profiles/learner-profiles.md
new file mode 100644
index 00000000..434e335a
--- /dev/null
+++ b/profiles/learner-profiles.md
@@ -0,0 +1,5 @@
+---
+title: FIXME
+---
+
+This is a placeholder file. Please add content here.
diff --git a/reference.md b/reference.md
deleted file mode 100644
index f442b9f1..00000000
--- a/reference.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-layout: reference
----
-
-## Cheatsheets de Git para Referencia Rápida
-
-* Un excelente [cheatsheet de git listo para impresión](https://services.github.com/on-demand/downloads/github-git-cheat-sheet.pdf) está disponible en formato PDF desde
-[el sitio de preparación de GitHub](https://services.github.com/resources/).
-* Una [visualización interactiva](http://ndpsoftware.com/git-cheatsheet.html)
- sobre las relaciones entre entorno de trabajo, área de staging, repositorio local y remoto, así los comandos asociados con cada caso (y sus explicaciones)
-* Ambos recursos están disponibles en varios lenguajes e.g. español, francés, y muchos más.
-
-## Glosario
-
-{:auto_ids}
-changeset
-: Un grupo de cambios a uno o más ficheros que son o serán añadidos
- en un solo [commit](#commit) en un [repositorio](#repositorio)
- de [control de versiones](#control-de-versiones).
-
-commit
-: Como verbo *hacer un commit* es la acción de registrar el estado
- de un conjunto de ficheros en un momento determinado (un [changeset](#changeset))
- en un [repositorio](#repositorio) de [control de versiones](#control-de-versiones). Como sustantivo,
- *un commit* es el resultado de esta acción, i.e. un changeset almacenado en un repositorio.
- Si un commit contiene cambios hechos a múltiples ficheros,
- todos los cambios son almacenados juntos.
-
-conflicto
-: Un cambio hecho por un usuario de un [sistema de control de versiones](#control-de-versiones)
- que es incompatible con cambios hechos por otros usuarios.
- Asistir a los usuarios a [resolver](#resolver) conflictos
- es una de las funciones más importantes del control de versiones.
-
-HTTP
-: Siglas de Hypertext Transfer Protocol, el [protocolo](#protocolo) utilizado para compartir páginas web y otros datos
- en la World Wide Web.
-
-mezclar
-: (un repositorio): Reconciliar dos conjuntos de cambios en un
- [repositorio](#repositorio).
-
-protocolo
-: Un conjunto de reglas que definen cómo una computadora se comunica con otra.
- Entre los protocolos más utilizados en la Internet se encuentran [HTTP](#http) y [SSH](#ssh).
-
-remote
-: (de un repositorio) Un [repositorio](#repositorio) de [control de versiones](#control-de-versiones) conectado con otro
- de forma tal que ambos pueden ser actualizados intercambiando [commits](#commit).
-
-repositorio
-: Un área de almacenamiento donde un sistema de [control de versiones](#control-de-versiones)
- almacena la historia completa de [commits](#commit) de un proyecto, así como información
- sobre quién cambio qué, cuándo.
-
-resolver
-: Eliminar los [conflictos](#conflicto) entre dos o más cambios incompatibles sobre un fichero o un conjunto de ficheros
- administrados por un sistema de [control de versiones](#control-de-versiones).
-
-revisión
-: Un sinónimo de [commit](#commit).
-
-SHA-1
-: [SHA-1 hashes](http://en.wikipedia.org/wiki/SHA-1) es lo que Git utiliza para generar identificadores, incluyendo los de los commits.
- Para calcularlos, Git no solamente utiliza los cambios que forman parte de un commit, sino también sus metadatos (tales como fecha, autor,
- mensaje), incluyendo los identificadores de todos los commits hechos para cambios anteriores. Esto hace que los ID de commits de Git san virtualmente únicos.
- I.e., es ínfima la probabilidad de que un mismo ID se refiera a dos commits hechos de forma independiente, incluso si tuvieran los mismos cambios.
-
-SSH
-: Abreviatura de Secure Shell, un [protocolo](#protocolo) utilizado para la comunicación de forma segura entre computadoras.
-
-timestamp
-: Un registro de cuando ocurrió un evento específico.
-
-control de versiones
-: Una herramienta para administrar los cambios hechos a un conjunto de ficheros.
- Cada conjunto de cambios crea un nuevo[commit](#commit) de los ficheros;
- el sistema de control de versiones permite a los usuarios recibir de manera fiable los commits precedentes,
- y ayuda a solventar cambios conflictivos hechos por diferentes usuarios.
diff --git a/site/README.md b/site/README.md
new file mode 100644
index 00000000..42997e3d
--- /dev/null
+++ b/site/README.md
@@ -0,0 +1,2 @@
+This directory contains rendered lesson materials. Please do not edit files
+here.