{"id":13881023,"url":"https://github.com/Urigo/tortilla","last_synced_at":"2025-07-16T17:31:38.097Z","repository":{"id":43339519,"uuid":"67364764","full_name":"Urigo/tortilla","owner":"Urigo","description":"The Framework for tutorials","archived":false,"fork":false,"pushed_at":"2025-07-03T01:15:04.000Z","size":1157,"stargazers_count":52,"open_issues_count":30,"forks_count":5,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-07-03T02:26:08.870Z","etag":null,"topics":["tutorial","tutorials"],"latest_commit_sha":null,"homepage":"","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Urigo.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2016-09-04T19:42:13.000Z","updated_at":"2025-06-19T09:24:34.000Z","dependencies_parsed_at":"2024-02-24T20:22:16.783Z","dependency_job_id":"dca0aed7-ddc7-423a-a8a2-ac0d0bd515a1","html_url":"https://github.com/Urigo/tortilla","commit_stats":{"total_commits":633,"total_committers":9,"mean_commits":70.33333333333333,"dds":"0.18483412322274884","last_synced_commit":"a996c957bbe9e76aaad3c328cfde1ae6d3e829a2"},"previous_names":[],"tags_count":48,"template":false,"template_full_name":null,"purl":"pkg:github/Urigo/tortilla","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Urigo%2Ftortilla","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Urigo%2Ftortilla/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Urigo%2Ftortilla/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Urigo%2Ftortilla/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Urigo","download_url":"https://codeload.github.com/Urigo/tortilla/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Urigo%2Ftortilla/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":265527552,"owners_count":23782480,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["tutorial","tutorials"],"created_at":"2024-08-06T08:03:48.280Z","updated_at":"2025-07-16T17:31:36.399Z","avatar_url":"https://github.com/Urigo.png","language":"TypeScript","readme":"# Tortilla\n\n[![CircleCI](https://circleci.com/gh/Urigo/tortilla.svg?style=svg\u0026circle-token=12d30ba8bd17ea8294ef5430fbeb60af1474ab73)](https://circleci.com/gh/Urigo/tortilla)\n\n\u003cp align=\"center\"\u003e\u003cimg src=\"https://cloud.githubusercontent.com/assets/7648874/24250888/833ec58e-0fbf-11e7-95e5-42d5827f0dd6.png\" alt=\"tortilla\" width=\"500\"\u003e\u003c/p\u003e\n\nTortilla is a framework for building tutorials based on git and NodeJS which will help you create AWESOME tutorials and upload them to any git-host which supports markdown rendering, like GitHub. \n\nTortilla operates by simply wrapping an existing git project, thus providing you with some advanced git functions dedicated to create the most perfect and most beautiful tutorial in the world. In addition, Tortilla is easily accessible through a CLI, making it very convenient to use.\n\nWhat's the advantages of using Tortilla over writing a simple blog-post?\n- The code and the instructions will always stay correlatively updated.\n- You can reference code snippets directly from the instructions.\n- You can use template-helpers to write complex instructions with minimal efforts.\n- You can take advantages of most git features like creating commits, tags and branches.\n- You can use neat features natively provided with the git host like reporting issues and opening pull requests.\n- The tutorial is linked directly to your git host account.\n- You can enjoy the great traffic of the git host.\n- You can easily navigate through the project at any specific point of the tutorial.\n- You can historicize different versions of your tutorial.\n- You can compare different versions of the tutorial and see the differences.\n- You can render the tutorial anywhere you want - Github, your own website, Medium and more...  all at the same time\n- The list goes on and on and on...\n\nTutorials for example:\n- [Full stack Whatsapp-clone using React and GraphQL](https://github.com/urigo/whatsApp-Clone-Tutorial)\n- [How to implement a game engine in JavaScript and build a Tron-style game](https://github.com/DAB0mB/radial-snake)\n\nIf you're not familiar with Tortilla I recommend you to go through the this `README.md` file since it contains everything you have to know about Tortilla in order to use it.\n\n[![intro](https://cloud.githubusercontent.com/assets/7648874/25558853/02cbaaf4-2d0e-11e7-89db-9aff3c87cc18.png)](https://www.youtube.com/watch?v=uboqQ8B4XFk)\n\n## Tutorial Structure\n\nSee:\n- [steps](#steps)\n  - [sub-steps](#sub-step)\n  - [super-steps](#super-steps)\n- [manuals](#manuals)\n  - [translations](#translations)\n  - [template-helpers](#template-helpers)\n  - [chapter-keywords](#chapter-keywords)\n- [releases](#releases)\n  - [release-tags](#release-tags)\n  - [history-branches](#history-branches)\n- [submodules](#submodules)\n  - [submodules-setup](#submodules-setup)\n\n### Steps\n\nEach commit should represent a single step in the tutorial, using the following message template:\n\n    Step (step index): (step description)\n\nHere's a list of commits for example:\n\n    Step 2: Add todo-list\n    Step 2.3: Add todo-list controller\n    Step 2.2: Add todo-list view\n    Step 2.1: Add todo-list model\n    Step 1: Bundling\n    Step 1.3: Install the necessary packages for Webpack's build\n    Step 1.2: Add Webpack build to gulp tasks\n    Step 1.1: Create a basic Webpack config\n    How to create a todo list\n\nAs you can see, some of the commits represent a [sub-step](#sub-step) (e.g. step 1.1, 1.2) and some of them represent a [super-step](#super-step) (e.g. step 1, 2); Together they form a whole single step. Note that the only exception is the root commit whose message can be whatever you'd like (will most likely be something which describes the tutorial), but the rest of the commits **must** follow these rules, otherwise you will encounter some unexpected behaviors.\n\n\u003e Credit goes to **[@stubailo](http://www.github.com/stubailo)** who originally came up with the commit templates concept.\n\n**Related CLI:** [tortilla-step CLI](#tortilla-step-cli)\n\n#### Sub Step\n\nA sub-step is a small portion of the whole step. Each sub-step should usually represent a small change which should be followed by an explanation in the tutorial. Sub-steps should be sorted by their chronological order; Sub-steps which assemble the same step should have the same super index, and a consecutive sub index separated by a period (e.g. 1.1, 1.2).\n\n#### Super Step\n\nA super-step should **always** come at the end of each step, and should be represented with a single index (e.g. 1, 2). The super-step should add a [manual](#manuals) file which goes through the implementation of the associated step.\n\n### Manuals\n\nManuals are markdown files which should contain some handy instructions regards the implementation of each step in the tutorial. The manuals are located under the `.tortilla/manuals` directory, and are separated into 2 directories - `templates` and `views`. When writing manuals, we should never touch the `views` files, because they should be auto-generated by Tortilla's CLI. The `templates` directory, as the name suggests, should contain manual templates. Just so you can get the idea, here's an example of a `.tortilla/manuals` directory structure:\n\n    .tortilla/manuals\n    ├─ templates\n    │  ├ root.tmpl\n    │  ├ step1.tmpl\n    │  ├ step2.tmpl\n    │  └ step3.tmpl\n    └─ views\n       ├ root.md\n       ├ step1.md\n       ├ step2.md\n       └ step3.md\n\nThe main difference between a manual template and a manual view is that templates are more simplified and will be most likely used for development purposes. They contain some handy [template helpers](#template-helpers) we can be used to render complex markdown components, so our tutorial can be good-looking and easy-to-read, with minimum maintenance. As you can see in the files tree above, manual template files have an extension of `.tmpl`, unlike their belonging views which finish with an extension of `.md`. That's because the manual templates are not exactly markdown files, since they are packed with some extra syntactic abilities provided by [Handlebars'](http://handlebarsjs.com/) simple yet powerful templating engine. Indeed, you can still use markdown's templating syntax, but just know that this is not a pure markdown we're talking about. The only template-view fs correlation exception is the `root.tmpl` file which should be mapped to the `README.md` file, so we can see a nice introduction for our tutorial when entering the repository. The `root.md` file is just a symbolic link to the main `README.md` file.\n\nNote that manual templates shouldn't be written with a title, since it should be attached automatically when rendering the template's view using its belonging commit message. In addition, a navigation bar between steps should be appended at the end of the manual. For example, a root manual template which looks likes this:\n\n```\n- FOO\n- BAR\n- BAZ\n```\n\nAnd is matched with the commit message:\n\n    Les Trois Mousquetaires\n\nShould result with the following view after rendering:\n\n```md\n# Les Trois Mousquetaires\n\n- FOO\n- BAR\n- BAZ\n\n[{]: \u003chelper\u003e (navStep)\n\n| [Begin Tutorial \u003e](manuals/views/step1.md) |\n|----------------------:|\n\n[}]: #\n```\n\n**Related CLI:** [tortilla-manual CLI](#tortilla-manual-cli)\n\n#### Translations\n\nManuals don't necessarily have to be written in English, and can be also be written in whatever language you'd choose. Translated manual templates are located under the `templates/locales/your-language` path, and their belonging views are localed under `views/locales/your-language`. Here's an example of a manuals directory with manuals which are translated into Hebrew (`he`):\n\n    .tortilla/manuals\n    ├─ templates\n    │  ├ root.tmpl\n    │  ├ step1.tmpl\n    │  ├ step2.tmpl\n    │  ├ step3.tmpl\n    │  └ locales/he\n    │    ├ root.tmpl\n    │    ├ step1.tmpl\n    │    ├ step2.tmpl\n    │    └ step3.tmpl\n    └─ views\n       ├ root.md\n       ├ step1.md\n       ├ step2.md\n       ├ step3.md\n       └ locales/he\n         ├ root.md\n         ├ step1.md\n         ├ step2.md\n         └ step3.md\n\nTranslations for step messages (and potentially other stuff) can be defined under the `.tortilla/locales` directory in a `json` file with the relevant language code (e.g. `.tortilla/locales/he.json`). Here's an example of a translation file which translates step messages:\n\n```json\n{\n  \"step\": {\n    \"root\": \"כיצד ליצור רשימת מטלות\",\n    \"1.1\": \"יצירת קובץ הגדרות בסיסי ל Webpack\",\n    \"1.2\": \"הוספת משימה של בנייה בעזרת Webpack לרשימת המשימות של gulp\",\n    \"1.3\": \"התקנת החבילות הנחוצות בכדי שנוכל לבנות בעזרת Webpack\",\n    \"1\": \"צרירת הפרוייקט\",\n    \"2.1\": \"יצירת מודל למטלה יחידה\",\n    \"2.2\": \"יצירת רשימת מטלות ויזואלית\",\n    \"2.3\": \"יצירת רשימת מטלות לוגית\",\n    \"2\": \"הוספת רשימת מטלות\"\n  }\n}\n```\n\n#### Template Helpers\n\nTemplate helpers are used when writing a manual file to make our lives a bit easier when it comes to formatting complex markdown components. The templates are rendered using [Handlebars'](http://handlebarsjs.com/) templating, so I recommend you to go through its rules and syntax so you can be familiar with it, but just for the heck of demonstration, a manual template file which looks like this:\n\n```\n*Here's how we should use template-helpers*\n\n{{{diffStep 1.1}}}\n```\n\nShould be rendered to:\n\n```md\n*Here's how we should use template-helpers*\n\n[{]: \u003chelper\u003e (diffStep 1.1)\n\n#### Step 1.1: Demo commit\n\n##### Added demo-file.js\n\\`\\`\\`diff\n@@ -0,0 +1,3 @@\n+┊ ┊1┊foo\n+┊ ┊2┊bar\n+┊ ┊3┊baz🚫↵\n\\`\\`\\`\n\n[}]: #\n```\n\n**🌟 Available {{view models}} 🌟**\n\n- `step` - The number of the current step.\n\n- `commit_message` - The current commit message.\n\n**🌟 Available {{{template helpers}}} 🌟**\n\n- `navStep` - A navigation bar between step manuals. Will present two buttons - \"Previous step\" and \"Next step\". This template helper may receives the following options:\n  - `prevRef` - The reference which we will be redirected to once pressed on \"Previous step\" button.\n  - `nextRef` - The reference which we will be redirected to once pressed on \"Next step\" button.\n\n- `diffStep \u003cstep\u003e` - Will run `git diff` for the specified step's commit. This template helper may receives the following options:\n  - `files` - A list of specific file paths separated by a comma (`,`) that we would like to present in our diff. The rest of the files in the diff will be ignored.\n  - `module` - The name of the submodule which contains the step we would like to reference.\n  - `noTitle` - A flag which indicates whether we should render the step title prior to diffs or not.\n\n#### Chapter Keywords\n\nEach chapter can be specify keywords that can help with [SEO](https://en.wikipedia.org/wiki/Search_engine_optimization). By editing the `package.json` and adding a `keywords` section at the manual's step we can achieve. First run `tortilla step edit [step]` and then a your [keywords](https://docs.npmjs.com/files/package.json#keywords). [tortilla.academy] will take care of putting these keywords together under a single `meta` tag based on the generated dump file.\n\n### Releases\n\nA Tortilla project may contain [release tags](#release-tags) which represent different versions of the tutorial in different time points. Here's a list of tags for example:\n\n    master@root@0.0.1\n    master@step1@0.0.1\n    master@0.0.1\n    master@root@0.1.0\n    master@step1@0.1.0\n    master@0.1.0\n    foo@root@0.0.1\n    foo@step1@0.0.1\n    foo@0.0.1\n\nIn addition, a stack of all the releases is available through [history branches](#history-branches):\n\n    master-history\n    foo-history\n\n**Related CLI:** [tortilla-release CLI](#tortilla-release-cli)\n\n#### Release Tags\n\nA release tag should represent the tutorial at a specific state (e.g. step 2 of master branch) and time point (e.g. version 1.2.1). A release tag should contain the name of the branch, the step descriptor, if at all, and a [semver](http://semver.org/) version, separated with at (`@`) signs (e.g. `master@step1@0.0.1`, `foo@0.1.0`).\n\n#### History Branches\n\nThe history is specific for a certain branch. Its name should end with `history` preceded by the branch name (e.g. `master-history`). Each commit in that branch represents all the changes made in a specific release, making the comparison between releases much easier (even if they have different roots!). Here's an example of a commits list in a history branch named `master-history`:\n\n    master@1.0.0: Add favorites page\n    master@0.0.2: Update step 2\n    master@0.0.1: Initial tutorial creation\n\n### Submodules\n\nOften times, we would like to have a single repository where we include all the manual files, and the implementation logic would be implemented in different repositories which will be referenced from the main repository using git's submodules architecture; E.g. a single repository that includes submodules referencing the client and the server. Another advantage for that architecture is that we can implement similar applications using different stacks, or having a single back-end for multiple front-end applications, with almost identical instructions.\n\n**Related CLI:** [tortilla-submodule CLI](#tortilla-submodule-cli)\n\n#### Submodules Setup\n\nWhen rendering manuals which reference steps from submodules, the git host URL is taken from `package.json` to compose the path of the commit that contains the file. Thus, you need to define the url in `package.json` of the submodule repository like so:\n\n```json\n{\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"https://github.com/Urigo/tortilla.git\"\n  }\n}\n```\n\n## Quick Startup\n\nFirst you will need to install Tortilla's CLI tool:\n\n    $ sudo npm install tortilla -g\n\nOnce you have it installed you can go ahead and create a new Tortilla project:\n\n    $ tortilla create my-tutorial -m \"How to create my app\"\n\nThis command will initialize a new Tortilla project called `my-tutorial` with an initial commit message of `How to create my app`.\n\nTo clone the project, use the following command:\n\n    $ tortilla clone git@github.com:John/my-tutorial.git\n\nYou shouldn't be using git as Tortilla exposes all the necessary commands for it to work and contains additional logic and restrictions that will ensure that it operates as expected.\n\nA manual page for the usage of Tortilla's CLI tool can be brought any time by typing the following:\n\n    $ tortilla --help\n\nFor further information, I'd recommend you going through the [CLI](#CLI) section.\n\n## CLI\n\nSee:\n\n- [tortilla](#tortilla-cli)\n  - [tortilla-dump](#tortilla-dump-cli)\n  - [tortilla-manual](#tortilla-manual-cli)\n  - [tortilla-release](#tortilla-release-cli)\n  - [tortilla-step](#tortilla-step-cli)\n  - [tortilla-strict](#tortilla-strict-cli)\n  - [tortilla-submodule](#tortilla-submodule-cli)\n  - [tortilla-package](#tortilla-package-cli)\n\n### tortilla CLI\n\n**command:** `tortilla create [name]`\n\nCreates a new Tortilla project with the provided name.\n\n- *option:* `-o, --output [path]` - The output path of the newly created project.\n- *option:* `-m, --message [message]` - The created project's initial commit's message.\n- *option:* `--override` - Override project directory if already exists.\n\n**command:** `tortilla init [name]`\n\nInitializes Tortilla essentials in the provided project.\n\n**command:** `tortilla dispose [cwd]`\n\nRemoves tortilla from specified project. If no `cwd` is provided, the current directory will be used by default.\n\n**command:** `tortilla push \u003cremote\u003e \u003cbranch\u003e`\n\nPush a tutorial based on the provided branch. e.g. given `master` then `master-history`, `master-root`, `master@0.1.0`, etc, will be pushed. Note that everything will be pushed by FORCE and will override existing refs within the remote, **even deleted refs**.\n\n**command:** `tortilla pull \u003cremote\u003e \u003cbranch\u003e`\n\nPull a tutorial based on the provided branch. e.g. given `master` then `master-history`, `master-root`, `master@0.1.0`, etc, will be pulled.\n\n**command:** `tortilla review \u003cremote\u003e \u003cbranch\u003e`\n\nPush the necessary refs to GitHub (or any other host) and open the browser with the comparison URI. A comparison URI is one that can be used to view the diff between our changes, and the current branch in the remote. Example URI: `https://github.com/Urigo/WhatsApp-Clone-Client-React/compare/7131782c5db1be873d3c315e4f60a322aa641490..c306dbe91df195d49ae52a7630c2a2fe1a215879`. This will be useful to view the changes before we're actually gonna push them.\n\n- *option:* `-p, --print` - Don't open in the browser, only print.\n\n**command:** `tortilla status`\n\nWill print the tutorial status prior to git-status. If for example, we're editing step 1.2, this will print `Editing step 1.2`. In case there's a conflict, let's say between steps 1.2 and 1.3, this will print `Solving conflict between step 1.2 (HEAD) and step 1.3`.\n\n- *option:* `-i, --instruct` - Print additional instructions: how to continue from current state. Am I allowed to push new steps? Should I amend my changes? etc.\n\n### tortilla-dump CLI\n\n**command:** `tortilla dump create [out]`\n\nDumps tutorial data as a JSON file. The default dump file name would be `tutorial.json`, although an optional output path might be provided. Here's a brief description of the schema of the generated dump file:\n\n```json\n[\n  {\n    \"branchName\": \"Current branch\",\n    \"historyBranchName\": \"History branch matching current branch\",\n    \"releases\": [\n      {\n        \"ReleaseVersion\": \"x.x.x\",\n        \"tagName\": \"The name of the tag\",\n        \"tagRevision\": \"The revision of the tag\",\n        \"historyRevision\": \"Commit hash based on history branch\",\n        \"changesDiff\": \"Diff with most recent release\",\n        \"manuals\": [\n          {\n            \"manualTitle\": \"Step commit message\",\n            \"stepRevision\": \"Step commit revision\",\n            \"manualView\": \"Manual view content\"\n          }\n        ]\n      }\n    ]\n  }\n]\n```\n\n- *option:* `--filter [filter]` - A list of branches we would like to filter separated with spaces.\n- *option:* `--reject [reject]` - A list of branches we would like to reject separated with spaces.\n- *option:* `--override` - Override file if already exists.\n\n**command:** `tortilla dump diff-releases \u003cdumpFile\u003e \u003csrcRelease\u003e \u003cdstRelease\u003e`\n\nCreates a diff between two specified releases in a given dump file. Useful when we would like to create the diff independently from the git-project.\n\n### tortilla-manual CLI\n\nFor more information see the [manuals](#manuals) section.\n\n**command:** `tortilla manual render [step]`\n\nRenders specified manual view.\n\n- *option:* `--root` - Render root manual (`README.md`).\n- *option:* `--all` - Render all manuals.\n\n### tortilla-release CLI\n\nFor more information see the [releases](#releases) section.\n\n**command:** `tortilla release bump \u003ctype\u003e`\n\nBumps the current release of the tutorial. This will create some new release tags accordingly and will update the associated history branch. The provided type represents a [semver version type](http://semver.org/) (major, minor and patch) we would like to bump. We can also specify `next` as the release number which will then store a weak reference to the potential upcoming version; this means that by the time we release another `next` version or another stable release, the most recent `next` version should be overridden.\n\n- *option:* `-m, --message [message]` - A message describing the newly created release. If not provided, and editor will be opened instead where we can type a full document.\n\nExample: `tortilla release bump next -m \"Fixes from the community and dependency update\"`\n\n**command:** `tortilla release bump \u003ctype\u003e`\n\nReverts release to the most recent one. For example, if we have 2 releases: `master@2.0.0` and `master@1.0.0`, this command will delete `master@2.0.0`, leaving `master@1.0.0`. If no more releases are left, the `history` branch will be deleted. This is useful if we've released something by accident and we would like to fix it.\n\n**command:** `tortilla release list [branch]`\n\nPrints a list of all releases of the given `branch`. If no `branch` was provided, the active branch will be used by default.\n\n**command:** `tortilla release current`\n\nPrints the current release.\n\n**command:** `tortilla release diff \u003csourceRelease\u003e \u003cdestinationRelease\u003e`\n\nRuns `git diff` between 2 specified releases. This will also be able to run the operation between 2 different releases which are completely different from their root! You can also provide this command with some additional native [git-diff options](https://git-scm.com/docs/git-diff#_options).\n\n### tortilla-step CLI\n\nFor more information see the [steps](#steps) section.\n\n**command:** `tortilla step push`\n\nPushes a new step. Staged files will be committed along with this step.\n\n- *option:* `-m, --message [message]` - A message describing the newly created step.\n\n**command:** `tortilla step pop`\n\nPops the most recent step. This will completely discard the step's changes.\n\n**command:** `tortilla step tag`\n\nMark this step as finished and move on to the next one. This will increase the index of the [super-step](#super-steps) and zero the index of the [sub-step](#sub-steps).\n\n- *option:* `-m, --message [message]` - A message describing the newly created step.\n\n**command:** `tortilla step edit [...steps]`\n\nEdits the specified steps. A step can be specified either by index or by git-ref. This will enter rebase mode where the step's hash is at. Once finished editing, you may proceed using [git-rebase commands](https://git-scm.com/docs/git-rebase). Alternatively, you can specify a range of steps e.g. `..1.5`, `1.1..` or `1.1..1.5`.\n\n- *option:* `--root` - Edit the root step (initial commit).\n- *option:* `--udiff [path]` - Updates the `diffStep` template helpers of manuals being rebased. Note that manuals prior to the current step being edited won't be updated, since the rebasing process never looks backwards. An optional can be provided which will be a reference to another repository which contains the current repository as a submodule; This will result in updating the provided repository's manuals rather than the current one. Note that submodule's package names located in `package.json` should be distinct.\n\n**command:** `tortilla step back [targetStep]`\n\nLike `git rebase --continue`, only it will go back instead of moving forward. Checkpoints will be based on the steps we've originally provided to the command `tortilla step edit`, e.g. `tortilla step edit 1.1 1.2 1.3` will have steps `1.1`, `1.2` and `1.3` as checkpoints. If no step was provided, we will go back to the most recent step by default. `targetStep` either represents one of the provided steps we would like to go back to, or it can represent a multiplier e.g. `x3` that will go `x` times backwards in history.\n\n- *option:* `-i, --interactive` - Interactively pick a step from a menu.\n\n**command:** `tortilla step reword [step]`\n\nRename the specified step's commit message.\n\n- *option:* `-m, --message [message]` - The new message of the reworded step. If not provided, and editor will be opened instead where we can type a full document.\n\n**command:** `tortilla step show \u003cstep\u003e`\n\nRun `git-show` for given step index.\n\n### tortilla-strict CLI\n\nStrict mode determines whether Tortilla's git-hook validations are enabled or disabled. It's highly recommended to leave it on, since you might accidentally digress from Tortilla's strict project rules.\n\n**command:** `tortilla strict get`\n\nPrints whether strict mode is enabled or disabled.\n\n**command:** `tortilla strict set \u003cmode\u003e`\n\nSets strict mode. Provided mode must be either a truthy value (e.g. `1`, `true`) or a falsy value (`0`, `false`).\n\n### tortilla-submodule CLI\n\nSubmodules are useful whenever you would like to split the tutorial into different logical segments, e.g. we will have the repo with all the instructions manual referencing the backend repo and the frontend repo.\n\n**command:** `tortilla submodule add \u003cname\u003e \u003curl\u003e`\n\nLike `$ git submodule add`, this will add the specified submodule name using the provided URL, and will detach HEAD.\n\n**command:** `tortilla submodule remove \u003cname\u003e`\n\nWill remove the submodule completely, even from the git-registry. This command doesn't exist on git and it can be very useful.\n\n**command:** `tortilla submodule update \u003cname\u003e`\n\nWill run `$ git submodule update --init`, and it will remove deleted files from stage if pointed object doesn't exist in submodule's remote.\n\n**command:** `tortilla submodule fetch \u003cname\u003e`\n\nWill fetch all objects from `origin` remote of the submodule, including tags. If the submodule is not updated, an error message will be printed instead.\n\n**command:** `tortilla submodule reset \u003cname\u003e`\n\nIn other words, this will \"unclone\" the submodule, but will keep it initialized. This is reliable method to get away from messy situations with submodules, so whenever you don't know what to do, run this command.\n\n**command:** `tortilla submodule checkout \u003cname\u003e \u003cref\u003e`\n\nThis will check out the specified submodule to provided ref. It will also guide you through with some detailed instructions if you should do things beforehand, this can prevent a lot of potential issues and confusion.\n\n**example for updating submodules for WhatsApp Clone and release a new version**:\n\n```\n# Make sure to push refs to GitHub first, on WhatsApp-Clone-Client and WhatsApp-Clone-Server\ntortilla step edit --root\ntortilla submodule fetch client\ntortilla submodule fetch server\ntortilla submodule checkout client master@next\ntortilla submodule checkout server master@next\ngit commit --amend\ngit rebase --continue\ntortilla release bump next\n```\n\n**Example of reinitializing Tortilla on a repo**\n```\ngit checkout master\ngit rebase --abort\ntortilla dispose\ntortilla init\ntortilla release bump next -m \"comment\"\n```\n\n### tortilla-package CLI\n\n`package.json` related commands are useful when we wanna update our dependencies' versions all across the tutorial, without needing to deal with any conflicts across the process.\n\n**command:** `tortilla package update-deps`\n\nThis will start the dependencies updating process by creating a temporary file will contain a list of all our dependencies (merged with dev and peer) where we can specify the new versions that we would like to use in our tutorial. Once this file has been saved and closed Tortilla will handle the rebasing process.\n\n## License\n\nMIT\n","funding_links":[],"categories":["TypeScript","tutorials"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FUrigo%2Ftortilla","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FUrigo%2Ftortilla","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FUrigo%2Ftortilla/lists"}