[
  {
    "path": "CODEOWNERS",
    "content": "* @RomuloOliveira\nREADME_de-DE.md @Ana06\nREADME_ua-UA.md @CODER591\n"
  },
  {
    "path": "CONTRIBUTING.md",
    "content": "# Contributing\n\nFirst of all, thanks for the taking time to contribute and help people!\n\nThis document contains a set of guidelines for contributing to the repository. These guidelines are intended to provide a clear and concise to help you to know where help is needed and how you can contribute to improve the guide.\n\n## Where can I help?\n\nThere are several ways to contribute. A contribution could happen both in the form of changes to the repository itself or through pull request reviews. Any kind of help would be appreciated.\n\nIn special, I'd like to highlight and bring attention to help in the form of:\n\n- Fix of inconsistencies across languages\n- Grammar and spelling corrections\n- Improvement of source referencing (images, references, etc.)\n- Incorrect, inconsistent or incomplete information fixes\n- Pull request reviews\n- Translation to other languages\n\n## Principles\n\n- **Consistency across languages over 100% correct grammar/spelling**: It's better to have some grammar and spelling errors than having outdated or specialized content for a single language. Use Google Translate or similar tools when needed.\n- **Best practices in this guide should aim to help, not to set rule-following blindly standards**: It's intended to provide resourceful guidelines to help people communicate in a better, concise and clear way. It's a mean to an end, not the end itself.\n- **One size does not fit all**: A project, team or company standards and agreements may override common practices. People may not agree 100% with all practices and it's ok. These things should not led to add or remove a guideline. Helping people should.\n- **Native speakers are owners, but two heads are better than one**: Pull request authors do the best they can, but this doesn't replaces a good review by another native speaker.\n\nFeel free to propose improvements if you have.\n\n## Guidelines\n\nTry to follow these guidelines when contributing. They're not rules and I'll not strictly enforce them, although I may ask you to adapt your contribution according to it.\n\nFeel free to propose changes to the guidelines and use your best judgment.\n\n### General guidelines\n\n- You may fork the project to make changes to the repository. See [this Github guide](https://guides.github.com/activities/forking/) explaining how to do it.\n- Use English for commit messages, issues and pull requests (both description and discussions).\n- Use the [best practices](https://github.com/RomuloOliveira/commit-messages-guide#good-practices) described in the guide.\n- Add `[PROPOSAL]` prefix to PR title when doing additions other than translations or corrections (e.g., [#31](https://github.com/RomuloOliveira/commit-messages-guide/pull/31))\n- Github editor usually suggests a commit message like \"Update file\", add a description of your change in the commit body or change the title.\n    - A good example: [7747659](https://github.com/RomuloOliveira/commit-messages-guide/commit/7747659824b83f6d07589daa66a67ee29fa60ddb)\n\nIt worth noting again that the best practices described in this guide are _guidelines_ and not rules. I won't refuse your contribution nor nitpick your commit messages if you're not following them strictly. It aims to help.\n\n### New translation checklist\n\n- Make sure you're working in the most updated branch. Rebase your code and fix conflicts when needed.\n- Make sure you've updated the [Available languages section](https://github.com/RomuloOliveira/commit-messages-guide#available-languages) section in (and only in) README.md.\n- Make sure you haven't included `Available languages` section in your translation (See [#31](https://github.com/RomuloOliveira/commit-messages-guide/pull/31)).\n\n### Pull Request review process\n\nPreferably, there should be at least 1 review from a native speaker. All pull requests will stay open for a few days waiting for a review help. Translations that didn't had a thorough review by a native speakers should be merged in a couple days, though.\n\nAll discussions should be resolved before a merge. Only [code owners](https://github.com/RomuloOliveira/commit-messages-guide/blob/master/CODEOWNERS) can do a merge. Native speakers have the authority to request changes in any pull request.\n\nEverything that applies to a native speaker also applies to a fluent writer.\n\n## Author notes\n\n_by @RomuloOliveira_\n\nI'm a Brazilian Portuguese native speaker still working on my English. I'll try to review all translations using Google Translate but a native speaker review is way more valuable.\n\nI'll open pull requests for significant changes and proposals, but I may commit directly to the master branch for minor fixes or changes that do not affect translations' content.\n\nOpinions and contents are my own and don't necessarily represent those of my current or former employers.\n\n## Thanks\n\nHelping people is priceless and I thank every and each of you that contributed to this guide.\n"
  },
  {
    "path": "LICENSE",
    "content": "Attribution 4.0 International\n\n=======================================================================\n\nCreative Commons Corporation (\"Creative Commons\") is not a law firm and\ndoes not provide legal services or legal advice. Distribution of\nCreative Commons public licenses does not create a lawyer-client or\nother relationship. Creative Commons makes its licenses and related\ninformation available on an \"as-is\" basis. Creative Commons gives no\nwarranties regarding its licenses, any material licensed under their\nterms and conditions, or any related information. Creative Commons\ndisclaims all liability for damages resulting from their use to the\nfullest extent possible.\n\nUsing Creative Commons Public Licenses\n\nCreative Commons public licenses provide a standard set of terms and\nconditions that creators and other rights holders may use to share\noriginal works of authorship and other material subject to copyright\nand certain other rights specified in the public license below. The\nfollowing considerations are for informational purposes only, are not\nexhaustive, and do not form part of our licenses.\n\n     Considerations for licensors: Our public licenses are\n     intended for use by those authorized to give the public\n     permission to use material in ways otherwise restricted by\n     copyright and certain other rights. Our licenses are\n     irrevocable. Licensors should read and understand the terms\n     and conditions of the license they choose before applying it.\n     Licensors should also secure all rights necessary before\n     applying our licenses so that the public can reuse the\n     material as expected. Licensors should clearly mark any\n     material not subject to the license. This includes other CC-\n     licensed material, or material used under an exception or\n     limitation to copyright. More considerations for licensors:\n\twiki.creativecommons.org/Considerations_for_licensors\n\n     Considerations for the public: By using one of our public\n     licenses, a licensor grants the public permission to use the\n     licensed material under specified terms and conditions. If\n     the licensor's permission is not necessary for any reason--for\n     example, because of any applicable exception or limitation to\n     copyright--then that use is not regulated by the license. Our\n     licenses grant only permissions under copyright and certain\n     other rights that a licensor has authority to grant. Use of\n     the licensed material may still be restricted for other\n     reasons, including because others have copyright or other\n     rights in the material. A licensor may make special requests,\n     such as asking that all changes be marked or described.\n     Although not required by our licenses, you are encouraged to\n     respect those requests where reasonable. More_considerations\n     for the public:\n\twiki.creativecommons.org/Considerations_for_licensees\n\n=======================================================================\n\nCreative Commons Attribution 4.0 International Public License\n\nBy exercising the Licensed Rights (defined below), You accept and agree\nto be bound by the terms and conditions of this Creative Commons\nAttribution 4.0 International Public License (\"Public License\"). To the\nextent this Public License may be interpreted as a contract, You are\ngranted the Licensed Rights in consideration of Your acceptance of\nthese terms and conditions, and the Licensor grants You such rights in\nconsideration of benefits the Licensor receives from making the\nLicensed Material available under these terms and conditions.\n\n\nSection 1 -- Definitions.\n\n  a. Adapted Material means material subject to Copyright and Similar\n     Rights that is derived from or based upon the Licensed Material\n     and in which the Licensed Material is translated, altered,\n     arranged, transformed, or otherwise modified in a manner requiring\n     permission under the Copyright and Similar Rights held by the\n     Licensor. For purposes of this Public License, where the Licensed\n     Material is a musical work, performance, or sound recording,\n     Adapted Material is always produced where the Licensed Material is\n     synched in timed relation with a moving image.\n\n  b. Adapter's License means the license You apply to Your Copyright\n     and Similar Rights in Your contributions to Adapted Material in\n     accordance with the terms and conditions of this Public License.\n\n  c. Copyright and Similar Rights means copyright and/or similar rights\n     closely related to copyright including, without limitation,\n     performance, broadcast, sound recording, and Sui Generis Database\n     Rights, without regard to how the rights are labeled or\n     categorized. For purposes of this Public License, the rights\n     specified in Section 2(b)(1)-(2) are not Copyright and Similar\n     Rights.\n\n  d. Effective Technological Measures means those measures that, in the\n     absence of proper authority, may not be circumvented under laws\n     fulfilling obligations under Article 11 of the WIPO Copyright\n     Treaty adopted on December 20, 1996, and/or similar international\n     agreements.\n\n  e. Exceptions and Limitations means fair use, fair dealing, and/or\n     any other exception or limitation to Copyright and Similar Rights\n     that applies to Your use of the Licensed Material.\n\n  f. Licensed Material means the artistic or literary work, database,\n     or other material to which the Licensor applied this Public\n     License.\n\n  g. Licensed Rights means the rights granted to You subject to the\n     terms and conditions of this Public License, which are limited to\n     all Copyright and Similar Rights that apply to Your use of the\n     Licensed Material and that the Licensor has authority to license.\n\n  h. Licensor means the individual(s) or entity(ies) granting rights\n     under this Public License.\n\n  i. Share means to provide material to the public by any means or\n     process that requires permission under the Licensed Rights, such\n     as reproduction, public display, public performance, distribution,\n     dissemination, communication, or importation, and to make material\n     available to the public including in ways that members of the\n     public may access the material from a place and at a time\n     individually chosen by them.\n\n  j. Sui Generis Database Rights means rights other than copyright\n     resulting from Directive 96/9/EC of the European Parliament and of\n     the Council of 11 March 1996 on the legal protection of databases,\n     as amended and/or succeeded, as well as other essentially\n     equivalent rights anywhere in the world.\n\n  k. You means the individual or entity exercising the Licensed Rights\n     under this Public License. Your has a corresponding meaning.\n\n\nSection 2 -- Scope.\n\n  a. License grant.\n\n       1. Subject to the terms and conditions of this Public License,\n          the Licensor hereby grants You a worldwide, royalty-free,\n          non-sublicensable, non-exclusive, irrevocable license to\n          exercise the Licensed Rights in the Licensed Material to:\n\n            a. reproduce and Share the Licensed Material, in whole or\n               in part; and\n\n            b. produce, reproduce, and Share Adapted Material.\n\n       2. Exceptions and Limitations. For the avoidance of doubt, where\n          Exceptions and Limitations apply to Your use, this Public\n          License does not apply, and You do not need to comply with\n          its terms and conditions.\n\n       3. Term. The term of this Public License is specified in Section\n          6(a).\n\n       4. Media and formats; technical modifications allowed. The\n          Licensor authorizes You to exercise the Licensed Rights in\n          all media and formats whether now known or hereafter created,\n          and to make technical modifications necessary to do so. The\n          Licensor waives and/or agrees not to assert any right or\n          authority to forbid You from making technical modifications\n          necessary to exercise the Licensed Rights, including\n          technical modifications necessary to circumvent Effective\n          Technological Measures. For purposes of this Public License,\n          simply making modifications authorized by this Section 2(a)\n          (4) never produces Adapted Material.\n\n       5. Downstream recipients.\n\n            a. Offer from the Licensor -- Licensed Material. Every\n               recipient of the Licensed Material automatically\n               receives an offer from the Licensor to exercise the\n               Licensed Rights under the terms and conditions of this\n               Public License.\n\n            b. No downstream restrictions. You may not offer or impose\n               any additional or different terms or conditions on, or\n               apply any Effective Technological Measures to, the\n               Licensed Material if doing so restricts exercise of the\n               Licensed Rights by any recipient of the Licensed\n               Material.\n\n       6. No endorsement. Nothing in this Public License constitutes or\n          may be construed as permission to assert or imply that You\n          are, or that Your use of the Licensed Material is, connected\n          with, or sponsored, endorsed, or granted official status by,\n          the Licensor or others designated to receive attribution as\n          provided in Section 3(a)(1)(A)(i).\n\n  b. Other rights.\n\n       1. Moral rights, such as the right of integrity, are not\n          licensed under this Public License, nor are publicity,\n          privacy, and/or other similar personality rights; however, to\n          the extent possible, the Licensor waives and/or agrees not to\n          assert any such rights held by the Licensor to the limited\n          extent necessary to allow You to exercise the Licensed\n          Rights, but not otherwise.\n\n       2. Patent and trademark rights are not licensed under this\n          Public License.\n\n       3. To the extent possible, the Licensor waives any right to\n          collect royalties from You for the exercise of the Licensed\n          Rights, whether directly or through a collecting society\n          under any voluntary or waivable statutory or compulsory\n          licensing scheme. In all other cases the Licensor expressly\n          reserves any right to collect such royalties.\n\n\nSection 3 -- License Conditions.\n\nYour exercise of the Licensed Rights is expressly made subject to the\nfollowing conditions.\n\n  a. Attribution.\n\n       1. If You Share the Licensed Material (including in modified\n          form), You must:\n\n            a. retain the following if it is supplied by the Licensor\n               with the Licensed Material:\n\n                 i. identification of the creator(s) of the Licensed\n                    Material and any others designated to receive\n                    attribution, in any reasonable manner requested by\n                    the Licensor (including by pseudonym if\n                    designated);\n\n                ii. a copyright notice;\n\n               iii. a notice that refers to this Public License;\n\n                iv. a notice that refers to the disclaimer of\n                    warranties;\n\n                 v. a URI or hyperlink to the Licensed Material to the\n                    extent reasonably practicable;\n\n            b. indicate if You modified the Licensed Material and\n               retain an indication of any previous modifications; and\n\n            c. indicate the Licensed Material is licensed under this\n               Public License, and include the text of, or the URI or\n               hyperlink to, this Public License.\n\n       2. You may satisfy the conditions in Section 3(a)(1) in any\n          reasonable manner based on the medium, means, and context in\n          which You Share the Licensed Material. For example, it may be\n          reasonable to satisfy the conditions by providing a URI or\n          hyperlink to a resource that includes the required\n          information.\n\n       3. If requested by the Licensor, You must remove any of the\n          information required by Section 3(a)(1)(A) to the extent\n          reasonably practicable.\n\n       4. If You Share Adapted Material You produce, the Adapter's\n          License You apply must not prevent recipients of the Adapted\n          Material from complying with this Public License.\n\n\nSection 4 -- Sui Generis Database Rights.\n\nWhere the Licensed Rights include Sui Generis Database Rights that\napply to Your use of the Licensed Material:\n\n  a. for the avoidance of doubt, Section 2(a)(1) grants You the right\n     to extract, reuse, reproduce, and Share all or a substantial\n     portion of the contents of the database;\n\n  b. if You include all or a substantial portion of the database\n     contents in a database in which You have Sui Generis Database\n     Rights, then the database in which You have Sui Generis Database\n     Rights (but not its individual contents) is Adapted Material; and\n\n  c. You must comply with the conditions in Section 3(a) if You Share\n     all or a substantial portion of the contents of the database.\n\nFor the avoidance of doubt, this Section 4 supplements and does not\nreplace Your obligations under this Public License where the Licensed\nRights include other Copyright and Similar Rights.\n\n\nSection 5 -- Disclaimer of Warranties and Limitation of Liability.\n\n  a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE\n     EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS\n     AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF\n     ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,\n     IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,\n     WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR\n     PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,\n     ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT\n     KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT\n     ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.\n\n  b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE\n     TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,\n     NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,\n     INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,\n     COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR\n     USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN\n     ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR\n     DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR\n     IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.\n\n  c. The disclaimer of warranties and limitation of liability provided\n     above shall be interpreted in a manner that, to the extent\n     possible, most closely approximates an absolute disclaimer and\n     waiver of all liability.\n\n\nSection 6 -- Term and Termination.\n\n  a. This Public License applies for the term of the Copyright and\n     Similar Rights licensed here. However, if You fail to comply with\n     this Public License, then Your rights under this Public License\n     terminate automatically.\n\n  b. Where Your right to use the Licensed Material has terminated under\n     Section 6(a), it reinstates:\n\n       1. automatically as of the date the violation is cured, provided\n          it is cured within 30 days of Your discovery of the\n          violation; or\n\n       2. upon express reinstatement by the Licensor.\n\n     For the avoidance of doubt, this Section 6(b) does not affect any\n     right the Licensor may have to seek remedies for Your violations\n     of this Public License.\n\n  c. For the avoidance of doubt, the Licensor may also offer the\n     Licensed Material under separate terms or conditions or stop\n     distributing the Licensed Material at any time; however, doing so\n     will not terminate this Public License.\n\n  d. Sections 1, 5, 6, 7, and 8 survive termination of this Public\n     License.\n\n\nSection 7 -- Other Terms and Conditions.\n\n  a. The Licensor shall not be bound by any additional or different\n     terms or conditions communicated by You unless expressly agreed.\n\n  b. Any arrangements, understandings, or agreements regarding the\n     Licensed Material not stated herein are separate from and\n     independent of the terms and conditions of this Public License.\n\n\nSection 8 -- Interpretation.\n\n  a. For the avoidance of doubt, this Public License does not, and\n     shall not be interpreted to, reduce, limit, restrict, or impose\n     conditions on any use of the Licensed Material that could lawfully\n     be made without permission under this Public License.\n\n  b. To the extent possible, if any provision of this Public License is\n     deemed unenforceable, it shall be automatically reformed to the\n     minimum extent necessary to make it enforceable. If the provision\n     cannot be reformed, it shall be severed from this Public License\n     without affecting the enforceability of the remaining terms and\n     conditions.\n\n  c. No term or condition of this Public License will be waived and no\n     failure to comply consented to unless expressly agreed to by the\n     Licensor.\n\n  d. Nothing in this Public License constitutes or may be interpreted\n     as a limitation upon, or waiver of, any privileges and immunities\n     that apply to the Licensor or You, including from the legal\n     processes of any jurisdiction or authority.\n\n\n=======================================================================\n\nCreative Commons is not a party to its public\nlicenses. Notwithstanding, Creative Commons may elect to apply one of\nits public licenses to material it publishes and in those instances\nwill be considered the “Licensor.” The text of the Creative Commons\npublic licenses is dedicated to the public domain under the CC0 Public\nDomain Dedication. Except for the limited purpose of indicating that\nmaterial is shared under a Creative Commons public license or as\notherwise permitted by the Creative Commons policies published at\ncreativecommons.org/policies, Creative Commons does not authorize the\nuse of the trademark \"Creative Commons\" or any other trademark or logo\nof Creative Commons without its prior written consent including,\nwithout limitation, in connection with any unauthorized modifications\nto any of its public licenses or any other arrangements,\nunderstandings, or agreements concerning use of licensed material. For\nthe avoidance of doubt, this paragraph does not form part of the\npublic licenses.\n\nCreative Commons may be contacted at creativecommons.org.\n"
  },
  {
    "path": "README.md",
    "content": "# Commit messages guide\n\n[![Say Thanks!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nA guide to understanding the importance of commit messages and how to write them well.\n\nIt may help you to learn what a commit is, why it is important to write good messages, best practices and some tips to plan and (re)write a good commit history.\n\n## Available languages\n\n- [English](README.md)\n- [Português](README_pt-BR.md)\n- [Deutsch](README_de-DE.md)\n- [Español](README_es-AR.md)\n- [Italiano](README_it-IT.md)\n- [한국어](README_ko-KR.md)\n- [Русский](README_ru-RU.md)\n- [简体中文](README_zh-CN.md)\n- [日本語](README_ja-JP.md)\n- [Українська](README_ua-UA.md)\n- [Türkçe](README_tr-TR.md)\n- [ngôn ngữ tiếng Việt](README_vi-VN.md)\n- [繁體中文](README_zh-TW.md)\n- [ελληνικά](README_gr-GR.md)\n- [Française](README_fr-FR.md)\n- [پارسی](README_fa-IR.md)\n- [Polish](README_pl-PL.md)\n- [Azərbaycanca](README_az-AZ.md)\n\n## What is a \"commit\"?\n\nIn simple terms, a commit is a _snapshot_ of your local files, written in your local repository.\nContrary to what some people think, [git doesn't store only the difference between the files, it stores a full version of all files](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences).\nFor files that didn't change from one commit to another, git stores just a link to the previous identical file that is already stored.\n\nThe image below shows how git stores data over time, in which each \"Version\" is a commit:\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Why are commit messages important?\n\n- To speed up and streamline code reviews\n- To help in the understanding of a change\n- To explain \"the whys\" that cannot be described only with code\n- To help future maintainers figure out why and how changes were made, making troubleshooting and debugging easier\n\nTo maximize those outcomes, we can use some good practices and standards described in the next section.\n\n## Good practices\n\nThese are some practices collected from my experiences, internet articles, and other guides. If you have others (or disagree with some) feel free to open a Pull Request and contribute.\n\n### Use imperative form\n\n```\n# Good\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Bad\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_But why use the imperative form?_\n\nA commit message describes what the referenced change actually **does**, its effects, not what was done.\n\n\n### Capitalize the first letter\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nadd `use` method to Credit model\n```\n\nThe reason that the first letter should be capitalized is to follow the grammar rule of using capital letters at the beginning of sentences.\n\nThe use of this practice may vary from person to person, team to team, or even from language to language.\nCapitalized or not, an important point is to stick to a single standard and follow it.\n\n### Try to communicate what the change does without having to look at the source code\n\n```\n# Good\nAdd `use` method to Credit model\n\n```\n\n```\n# Bad\nAdd `use` method\n```\n\n```\n# Good\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Bad\nAdjust css\n```\n\nIt is useful in many scenarios (e.g. multiple commits, several changes and refactors) to help reviewers understand what the committer was thinking.\n\n### Use the message body to explain \"why\", \"for what\", \"how\" and additional details\n\nFocus on the \"why\" instead of \"what\" (although \"what\" and \"how\" are still important).\nIf, for example, your commit message is a restatement of the diff, it may be important to\nrethink it.\n\n```\n# Good\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Good\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# Good\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nThe subject and the body of the messages are separated by a blank line.\nAdditional blank lines are considered as a part of the message body.\n\nCharacters like `-`, `*` and \\` are elements that improve readability.\n\n### Avoid generic messages or messages without any context\n\n```\n# Bad\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### Avoid language such as \"this PR\", \"this commit\", \"this patch\"\n\nYou don't have to refer to the commit by itself. We **know** that this is a patch, commit or PR.\n\n```\n# Bad\nThis commit does x and y...\n\nThis PR does x and y...\n\nThis Patch x and y...\n\n# Good\n\nX and y are done...\n```\n\n### Avoid personal language (e.g. pronouns)\n\nA thing that can be learned from academic writing and brought to commit messages is to avoid using personal\nlanguage.\n\n```\n# Bad\nI fixed the problem.\n\n# Good\nThe problem has been fixed by doing x and y...\n```\n\n### Limit the number of characters\n\n[It's recommended](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) to use a maximum of 50 characters for the subject and 72 for the body.\n\n### Keep language consistency\n\nFor project owners: Choose a language and write all commit messages using that language. Ideally, it should match the code comments, default translation locale (for localized projects), etc.\n\nFor contributors: Write your commit messages using the same language as the existing commit history.\n\n```\n# Good\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Good (Portuguese example)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Bad (mixes English and Portuguese)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### Template\n\nThis is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## Notes on PR messages and cover letters\n\nMost developers open Pull Requests (PR) on a Git repo through a platform (Github, Gitlab),\nwhile kernel developers  and people who send patches through email ([yes, that's a\nthing](https://git-scm.com/docs/git-send-email/2.45.0) refer to it as \"cover letter\".\n\nA good cover letter, or PR message, will summarize, give background and context to a series of\ncommits that are related. Good writing on this part will help to \"sell\" your commit series to\nthe maintainers of a project, as they'll be able to understand why you are presenting such changes\ntogether.\n\nIf you're writing a smaller (single or a few commits) change, treat the first commit as a cover letter.\nGithub, for example, uses this first commit as the default PR message.\n\nHere's an [example](https://lore.kernel.org/lkml/20230414225551.858160935@linutronix.de/) of a good cover\nletter sent on the Linux kernel mailing list. It contains:\n\n- A description of the overall changes and why they were made;\n\n- Background, or any important information that is needed to understand these changes;\n\n- A breakdown of the solution and the approach taken to reach such solution;\n\n- Caveats, or things that could go wrong and must be considered before applying such changes;\n\n- Possible enhancements, a section describing opportunities for future changes that are out of the scope\n  for the current commit set;\n\n## Signing off your commits and following guidelines\n\nOpen source projects often require you to sign your code and follow some guidelines. One such example is\nthe Developer Certificate of Origin (DCO)[https://developercertificate.org/], which you have to abide to\nwhen contributing to projects by The Linux Foundation, the Cloud Native Computing Foundation and many\nothers.\n\nThis means that you have to use your **real name** (i.e. a name that identifies you, _not necessarily your\nlegal name_) and to sign off your commits. Avoid pseudonyms or false names. Further reading about real names\n[here](https://www.mail-archive.com/kernelnewbies@kernelnewbies.org/msg22178.html).\n\nUse `git config` to set your name and email.\n\n``` sh\n# You can apply these changes locally, to a single repo\ngit config --local user.name \"Jane Doe\"\ngit config --local user.email \"janedoe@janedoe.com\"\n\n# Or globally\ngit config --global user.name \"Jane Doe\"\ngit config --global user.email \"janedoe@janedoe.com\"\n```\n\nWhen doing a commit, add the `-s` flag to `git commit` and that will add a `Signed-off-by: ` line to your\ncommit.\n\nAside from adding this line to the commit, it's also important to use GPG for signing your commits.\n\nGPG, or GNU Privacy Guard, is a tool that allows you to encrypt and tamperproof documents. You can use it,\nfor example, to sign emails and ensure that they haven't been modified without your consent. In the git\nworld, this is how you tell that a commit has been made by you and has not been tampered before reaching\nother people.\n\nGithub has more [information](https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account)\nabout how to generate and add a GPG key to your account. [This documentation](https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key)\nteaches how to use gpgsign for commits.\n\nMore information about working with GPG [here](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work).\n\nFor even more security, you can setup [pinentry](https://www.gnupg.org/related_software/pinentry/index.html)\nto add physical layers of security to GPG, such as signing your commits with Yubikey of Touch ID.\n\n## Rebase vs. Merge\n\nThis section is a **TL;DR** of Atlassian's excellent tutorial, [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\n**TL;DR:** Applies your branch commits, one by one, upon the base branch, generating a new tree.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge\n\n**TL;DR:** Creates a new commit, called (appropriately) a _merge commit_, with the differences between the two branches.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Why do some people prefer to rebase over merge?\n\nI particularly prefer to rebase over merge. The reasons include:\n\n- It generates a \"clean\" history, without unnecessary merge commits\n- _What you see is what you get_, i.e., in a code review all changes come from a specific and entitled commit, avoiding changes hidden in merge commits\n- More merges are resolved by the committer, and every merge change is in a commit with a proper message\n  - It's unusual to dig in and review merge commits, so avoiding them ensures all changes have a commit where they belong\n\n### When to squash\n\n\"Squashing\" is the process of taking a series of commits and condensing them into a single commit.\n\nIt's useful in several situations, e.g.:\n\n- Reducing commits with little or no context (typo corrections, formatting, forgotten stuff)\n- Joining separate changes that make more sense when applied together\n- Rewriting _work in progress_ commits\n\n### When to avoid rebase or squash?\n\nAvoid rebase and squash in public commits or in shared branches where multiple people work on.\nRebase and squash rewrite history and overwrite existing commits, doing it on commits that are on shared branches (i.e., commits pushed to a remote repository or that comes from others branches) can cause confusion and people may lose their changes (both locally and remotely) because of divergent trees and conflicts.\n\n## Useful git commands\n\n### rebase -i\n\nUse it to squash commits, edit messages, rewrite/delete/reorder commits, etc.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nUse it to clean up commits easily and without needing a more complex rebase.\n[This article](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) has very good examples of how and when to do it.\n\n### cherry-pick\n\nIt is very useful to apply that commit you made on the wrong branch, without the need to code it again.\n\nExample:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nLet's say we have the following diff:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nWe can use `git add -p` to add only the patches we want to, without the need to change the code that is already written.\nIt's useful to split a big change into smaller commits or to reset/checkout specific changes.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Other interesting stuff\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Like it?\n\n[Say thanks!](https://saythanks.io/to/RomuloOliveira)\n\n## Contributing\n\nAny kind of help would be appreciated. Example of topics that you can help me with:\n\n- Grammar and spelling corrections\n- Translation to other languages\n- Improvement of source referencing\n- Incorrect or incomplete information\n\n## Inspirations, sources and further reading\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n- [Philosophy of Linux kernel patches](https://kernelnewbies.org/PatchPhilosophy)\n- [The perfect patch](https://www.ozlabs.org/~akpm/stuff/tpp.txt)\n"
  },
  {
    "path": "README_az-AZ.MD",
    "content": "# Commit mesajları təlimatı\n\n[![Say Thanks!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nBu təlimat commit mesajlarının əhəmiyyətini və onların daha yaxşı necə yazılacağını izah edir.\n\nBu, \"commit\"-in nə olduğunu, yaxşı commit mesajları yazmağın nə üçün vacib olduğunu, yaxşı commit tarixçəsini planlaşdırmaq və (yenidən) yazmaq üçün bəzi nümunələr və məsləhətləri anlamağa kömək edə bilər.\n\n## \"commit\" nədir?\n\nSadə dillə desək, commit sizin yerli reponuza yazılmış fayllarınızın *anlıq* görüntüsüdür.\nBəzi insanların düşündüyündən fərqli olaraq, [git yalnız fayllar arasındakı fərqləri saxlamır, bütün faylların tam versiyasını saxlayır](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences).\nİki commit arasında dəyişməmiş fayllar üçün git, sadəcə olaraq, artıq saxlanmış əvvəlki eyni fayla keçid yaradacaq.\n\nAşağıdakı şəkil, git-in hər bir \"versiya\"ya uyğun olaraq məlumatları necə saxladığını göstərir:\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Commit mesajları niyə vacibdir?\n\n- Kod baxışını (code review) daha sürətli və asan edir\n- Dəyişikliyi anlamağa kömək edir\n- Təkcə kodla izah edilə bilməyən \"niyə\"ni izah edir\n- Sonrakı tərtibatçılara dəyişikliklərin niyə və necə edildiyini anlamağa kömək edir, problemlərin aradan qaldırılmasını və xətaların düzəldilməsini asanlaşdırır.\n\nBu faydaları maksimum dərəcədə artırmaq üçün biz növbəti bölmədə təsvir olunan bəzi ən yaxşı təcrübə və standartlardan istifadə edə bilərik.\n## Ən yaxşı təcrübələr\n\nBunlar təcrübələrimdən, internetdəki məqalələrdən və digər təlimatlardan topladığım bəzi təcrübələrdir. Əlavə etmək istədiyiniz bir şey varsa (və ya razı deyilsinizsə), Pull Request açın və töhfə verin.\n\n### Əmr formasından istifadə edin\n\n```\n# Good\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Bad\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_Bəs nə üçün əmr forması?_\n\nCommit mesajı göstərilən dəyişiklikdə nə edildiyini deyil, əslində, nə etdiyini və onun təsirlərini təsvir edir.\n\n### Böyük hərf ilə başlayın\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nadd `use` method to Credit model\n```\n\nBöyük hərflə başlamağın səbəbi, qrammatik qaydalardan biri olan cümlələrin əvvəlində böyük hərflərdən istifadəyə riayət etməkdir.\n\nBunun istifadəsi insandan insana, komandadan komandaya və hətta dildən dilə dəyişə bilər. Böyük hərflə yazın və ya yazmayın, əsas məsələ bir standarta bağlı qalmaq və ona əməl etməkdir.\n\n### Mənbə koduna baxmadan dəyişikliyin nə etdiyini bildirməyə çalışın\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nAdd `use` method\n```\n\n```\n# Good\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Bad\nAdjust css\n```\n\nBu təcrübə bir çox ssenarilərdə (məsələn, çoxlu commitlər, çoxsaylı dəyişikliklər və refaktorinqlər zamanı) mesaj oxuyanlara xəbər verənin nə düşündüyünü anlamağa kömək etmək üçün faydalıdır.\n\n### \"Niyə?\", \"Nə məqsədlə?\", \"Necə?\" suallarını və əlavə detalları izah etmək üçün mesaj mətnindən istifadə edin\n\n“Nə” əvəzinə “niyə”yə diqqət yetirin (baxmayaraq ki, “nə” və “necə” hələ də vacibdir).\nMəsələn, commit mesajınız diff-in yenidən ifadəsidirsə, onu yenidən nəzərdən keçirmək vacib ola bilər.\n\n```\n# Good\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Good\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# Good\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nMesajların mövzusu və mətni boş sətirlə ayrılır.\nƏlavə boş sətirlər mesajın əsas hissəsi hesab olunur.\n\n`-`, `*` və \\` kimi simvollar oxunaqlılığı artıran elementlərdir.\n\n###  Ümumi və ya hərhansı konteksti olmayan mesajlardan çəkinin\n\n```\n# Bad\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n\n### \"this PR\", \"this commit\", \"this patch\" kimi yazı dilindən çəkinin\n\nBir commitin özünə müraciət etmək lazım deyil. Biz **bilirik** ki, bu, yol, commit və ya PR-dır.\n\n```\n# Bad\nThis commit does x and y...\n\nThis PR does x and y...\n\nThis Patch x and y...\n\n# Good\n\nX and y are done...\n```\n\n### Şəxsi dildən çəkinin (məsələn, əvəzliklər)\n\nAkademik yazılardan öyrənib, mesajların göndərilməsinə də tətbiq edə biləcəyimiz bir şey, şəxsi dildən istifadə etməməkdir.\n\n```\n# Bad\nI fixed the problem.\n\n# Good\nThe problem has been fixed by doing x and y...\n```\n\n### Simvolların sayını məhdudlaşdırın\n\nMövzu üçün 50 simvoldan, mətn üçün isə 72 simvoldan çox olmamaq [tövsiyə olunur](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines).\n### Dil ardıcıllığını qoruyun\n\nLayihə sahibləri üçün: Bir dil seçin və bütün commit mesajlarını həmin dildə yazın. İdeal olaraq, kod şərhləri, standart yerli tərcümə parametrləri (lokallaşdırılmış layihələr üçün) və s. ilə uyğun gəlməlidir.\n\nTöhfə verənlər üçün: Mövcud commit tarixçəsi ilə eyni dildən istifadə edərək commit mesajı yazın.\n\n```\n# Good\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Good (Portuqalca nümunə)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Bad (İngiliscə və Portuqalca qarışıq)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### Şablon\n\nBu şablonun orijinalı [Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) tərəfindən yazılıb: [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n\n## PR mesajları və müşayiət məktubları haqqında qeydlər\n\nƏksər tərtibatçılar Git reposunda Pull Request (PR) yaratmaq üçün bir platformadan (GitHub, GitLab) istifadə edirlər, lakin nüvə (kernel) tərtibatçıları və dəyişiklikləri e-poçt vasitəsilə göndərən şəxslər ([bəli, belə bir şey var](https://git-scm.com/docs/git-send-email/2.45.0) ) bunu \"cover letter\" (müşayiət məktubu) adlandırırlar.\n\nYaxşı bir müşayiət məktubu və ya PR mesajı bir-biri ilə əlaqəli olan commit seriyasını ümumiləşdirir, onların mənşəyi və konteksti haqqında məlumat verir. Bu hissənin yaxşı yazılması commit seriyanızı layihənin saxlayıcılarına \"satmağa\" kömək edəcək, çünki onlar təqdim etdiyiniz dəyişikliklərin niyə birlikdə göndərildiyini asanlıqla anlaya biləcəklər.\n\nƏgər daha kiçik (bir və ya bir neçə commit-lik) dəyişiklik edirsinizsə, ilk commit-i müşayiət məktubu kimi qəbul edin. Məsələn, GitHub ilk commit-i standart PR mesajı kimi istifadə edir.\n\nLinux nüvəsi (kernel) e-poçt siyahısına göndərilmiş yaxşı bir müşayiət məktubunun [nümunəsi budur](https://lore.kernel.org/lkml/20230414225551.858160935@linutronix.de/). O, aşağıdakıları ehtiva edir:\n\n- Ümumi dəyişikliklərin təsviri və onların hansı səbəblə edildiyi;\n- Bu dəyişiklikləri anlamaq üçün vacib olan arxa plan və digər mühüm məlumatlar;\n- Həllin detallı izahı və bu həllə çatmaq üçün tətbiq edilən yanaşma;\n- Çətinliklər və ya tətbiq etməzdən əvvəl nəzərə alınmalı potensial problemlər;\n- Mümkün təkmilləşdirmələr – cari commit dəstinin əhatə dairəsindən kənarda qalan gələcək dəyişikliklər üçün imkanları təsvir edən bölmə.\n\n## Commit-ləri imzalamaq və qaydalara riayət etmək\n\nAçıq mənbə (open-source) layihələr tez-tez kodunuzu imzalamağı və müəyyən qaydalara əməl etməyi tələb edir. Bunun bir nümunəsi **Developer Certificate of Origin (DCO)**-dur ([DCO saytı](https://developercertificate.org/)), hansı ki, **The Linux Foundation**, **Cloud Native Computing Foundation** və digər təşkilatların layihələrinə töhfə verərkən riayət etməli olduğunuz bir qaydadır.\n\nBu o deməkdir ki, siz **həqiqi adınızdan** istifadə etməlisiniz (yəni, sizi müəyyən edən bir ad, _mütləq hüquqi adınız olmalı deyil_) və commit-lərinizi imzalamalısınız. Təxəllüslərdən və ya saxta adlardan istifadə etməyin. **Həqiqi adlardan istifadə haqqında daha ətraflı** [buradan oxuya bilərsiniz](https://www.mail-archive.com/kernelnewbies@kernelnewbies.org/msg22178.html).\n\nAdınızı və e-poçtunuzu təyin etmək üçün aşağıdakı `git config` əmrlərindən istifadə edin:\n\n``` sh\n# Bu dəyişiklikləri yerli olaraq tək repoya tətbiq edə bilərsiniz\ngit config --local user.name \"Jane Doe\"\ngit config --local user.email \"janedoe@janedoe.com\"\n\n# Və ya qlobal olaraq\ngit config --global user.name \"Jane Doe\"\ngit config --global user.email \"janedoe@janedoe.com\"\n```\n\nCommit edərkən `git commit` əmrinə `-s` bayrağını əlavə edin. Bu, commit-inizə **\"Signed-off-by: \"** sətrini əlavə edəcək.\n\nBu sətrin commit-ə əlavə olunmasından başqa, commit-lərinizi imzalamaq üçün **GPG (GNU Privacy Guard)** istifadə etmək də vacibdir.\n\nGPG (və ya GNU Privacy Guard) sənədləri şifrələməyə və onların dəyişdirilməsinin qarşısını almağa imkan verən bir alətdir. Məsələn, e-poçtları imzalamaq və onların sizin razılığınız olmadan dəyişdirilmədiyini təmin etmək üçün istifadə edilə bilər. **Git dünyasında isə GPG commit-in həqiqətən sizin tərəfinizdən edildiyini və başqaları tərəfindən dəyişdirilmədiyini təsdiqləmək üçün istifadə olunur.**\n\nGitHub-da **GPG açarını yaratmaq və hesabınıza əlavə etmək** haqqında daha ətraflı [məlumat](https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account) əldə edə bilərsiniz. **Commit-lər üçün gpgsign istifadəsi** ilə bağlı təlimatı [buradan](https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key) oxuya bilərsiniz.\n\n**GPG ilə işləmək haqqında daha çox məlumatı** [buradan](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) əldə edə bilərsiniz.\n\nDaha yüksək təhlükəsizlik üçün [pinentry](https://www.gnupg.org/related_software/pinentry/index.html) konfiqurasiya edə bilərsiniz. Bu, GPG üçün fiziki təhlükəsizlik qatlarını əlavə etməyə, məsələn, commit-lərinizi **Yubikey və ya Touch ID** ilə imzalamağa imkan verir.\n\n## Rebase (yenidən baza) və Merge (birləşmə)\n\nBu hissə, Atlassian-ın [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) adlı möhtəşəm dərsliyinin TL;DR (Too long; didn't read/çox uzun idi; oxumadım) xülasəsidir.\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\n**TL;DR:** Bu, branch commitlərini əsas branch-dan sonra yeni ağac yaratmaq üçün bir-bir tətbiq edir.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge\n\n**TL;DR:** İki branch arasındakı fərqləri ehtiva edən _merge commit_ adlı yeni commit yaradır.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Niyə bəzi insanlar merge (birləşmə) əvəzinə rebase-ə (yenidən baza) üstünlük verirlər?\n\nŞəxsən mən merge yerinə rebase-ə üstünlük verirəm. Səbəblər aşağıdakılardır:\n\n* Gereksiz bir _merge commit_'i olmadan \"temiz\" bir geçmiş oluşturur.\n* _Gördüğünüz şey, elde ettiğiniz şeydir_, yani bir kod incelemesinde, merge commit'inin ardında gizlenen değişikliklerden kaçınarak, tüm değişiklikler belirli ve başlıklı bir commit'ten gelir.\n* Daha fazla merge, commit eden tarafından çözümlenir ve her bir merge işlemi uygun bir mesajla bir commit içindedir.\n    * Bir birleştirme commit'ini detaylı incelemek ve gözden geçirmek olağandışı bir durumdur, bu nedenle bunlardan kaçınmak tüm değişikliklerin ait oldukları bir commit'e sahip olmasını garanti eder.\n\n- Lazımsız bir _merge commit_'i olmadan \"təmiz\" bir tarix yaradır.\n- _Gördüyün şey, əldə etdiyin şeydir_, yəni kod icmalında merge commit-inin arxasında gizlənmiş dəyişikliklərdən qaçaraq, bütün dəyişikliklər müəyyən və başlıqlı bir commit-dən gəlir.\n- Daha çox merge commit edən tərəfindən həll edilir və hər bir merge əməliyyatı uyğun bir mesajla commit içərisində olur.\n    - Bir merge commit-inin detallı incələnməsi və nəzərdən keçirilməsi qeyri-adi bir vəziyyətdir, buna görə də bunlardan qaçmaq bütün dəyişikliklərin aid olduqları bir commit-ə sahib olmasını təmin edir.\n\n### Squash (əzmə/birləşdirmə) nə zaman edilməlidir?\n\n\"Squashing\" bir sıra commit-i götürüb tək bir commit-ə sıxlaşdırmaq prosesidir.\n\nBəzi hallarda faydalıdır, məsələn:\n- Çox az və ya heç bir konteksti olmayan commit-ləri azaltmaq (orfoqrafiya səhvlərinin düzəldilməsi, formatlama, unudulmuş şeylər)\n- Birlikdə tətbiq edildikdə daha məntiqli olan ayrıca dəyişiklikləri birləşdirmək\n- Üzərində işlənməyə davam edilən commit-ləri yenidən yazmaq\n\n### Rebase və ya squash-dən nə zaman çəkinməlisiniz?\n\n_Public commit_-lərdə və ya bir neçə nəfərin birlikdə işlədiyi paylaşılan branch-lərdə rebase və squash-dən çəkinin. Rebase və squash tarixçəni yenidən yazır və mövcud commit-lərin üzərinə yazır. Bunu paylaşılan branch-lərdə etmək qarışıqlığa səbəb ola bilər (məsələn, uzaq repo-ya push edilən commit-lər və ya digər branch-lərdən gələn commit-lər). Bu, insanların fərqli branch-lər və konfliktlər səbəbindən dəyişikliklərini (həm yerli, həm də uzaq) itirməsinə səbəb ola bilər.\n\n## Faydalı git əmrləri\n\n### rebase -i\n\nCommitləri squash/sıxışdırmaq, mesajları redaktə etmək, commitləri yenidən yazmaq/silmək/sıralarını düzəltmək vs s. üçün istifadə olunur.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nCommitləri asanlıqla və daha mürəkkəb bir rebase-ə ehtiyac olmadan təmizləmək üçün istifadə olunur.\n[Bu yazıda](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html), necə və nə vaxt ediləcəyinə dair gözəl nümunələr var.\n\n### cherry-pick\n\nSəhv branch-da etdiyiniz commiti yenidən kodlaşdırma etmədən tətbiq etmək lazım olduqda bu çox faydalıdır.\n\nNümunə:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nDeyək ki, aşağıdakı kimi bir _diff_'imiz var:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Credit modeline `use` metodu ekle\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nArtıq yazılmış kodu dəyişdirmədən yalnız istədiyimiz yolları əlavə etmək üçün `git add-p` istifadə edə bilərik.\nBöyük dəyişikliyi daha kiçik commitlərə bölmək və ya xüsusi dəyişiklikləri sıfırlamaq/kontrol etmək üçün faydalıdır.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Credit modeline `use` metodu ekle\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Digər maraqlı şeylər\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Bəyəndin?\n\n[Təşəkkür et!](https://saythanks.io/to/RomuloOliveira)\n\n## Töhfə vermək\n\nHər hansı bir yardım təqdirəlayiqdir. Mənə kömək edə biləcəyiniz mövzuların nümunələri:\n\n- Qrammatika və orfoqrafiya düzəlişləri\n- Digər dillərə tərcümə\n- Mənbə/istinadın təkmilləşdirilməsi\n- Yanlış və ya natamam məlumatların düzəldilməsi\n\n## İlham alınanlar, mənbələr və əlavə oxu\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_de-DE.md",
    "content": "# Commit Messages Guide\n\n[![Sag danke!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nEin Leitfaden, um die Wichtigkeit von Commit-Messages zu verstehen und diese richtig zu formulieren.\n\nVerstehe was ein Commit ist, warum es wichtig ist, eine gute Commit-Message zu schreiben, gute Praxis und ein paar Tipps, um eine saubere Commit-Historie zu planen oder vielleicht sogar nachträglich noch anzupassen.\n\n#### Hinweis des Übersetzers\n\nAuch wenn dies eine Übersetzung darstellen soll, empfiehlt es sich, alle Commit-Messages auf Englisch zu schreiben, deshalb sind die Beispiele nicht übersetzt.\n\n## Was ist ein \"Commit\"?\n\nGanz einfach beschrieben ist ein Commit eine Art _Schnappschuss_ deiner lokalen Dateien in deinem Repository (dein Projektordner).\nIm Gegensatz zur geläufigen Annahme [speichert Git nicht nur die Unterschiede in den Dateien, sondern immer die gesamte Datei (Quelle auf Englisch)](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences).\nFür Dateien, die sich von einem auf den anderen Commit nicht geändert haben, speichert Git lediglich einen Link zur einer bereits gespeicherten Version in einem vorangegangenen Commit.\n\nDie folgende Grafik zeigt wie Git die Daten mit der Zeit speichert. Jede \"Version\" meint hier einen Commit.\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Warum sind Commit-Messages wichtig?\n\n- Um Code-Reviews zu beschleunigen und zu vereinfachen\n- Um die erzielte Änderung besser verstehen zu können\n- Um _die_ Gründe zu erläutern, die so nicht aus dem Code hervorgehen (Grundsatzentscheidungen)\n- Um zukünftigen Entwicklern zu helfen, zu verstehen, wie und warum Änderungen gemacht wurden – was die Fehlersuche und -behebung vereinfacht\n\nUm diese und noch mehr Vorteile möglichst effizient nutzen zu können, sollten wir uns an die folgenden Praktiken und Standards halten.\n\n## Praktiken\n\nDies sind Praktiken aus meiner eigenen Erfahrung, sowie aus anderen Artikeln/Anleitungen aus dem Internet. Wenn du noch mehr Tipps hast oder manche dieser Praktiken für nicht sinnvoll hältst, beantrage gerne eine Änderung via Pull Request.\n\n### Imperativ verwenden\n\n```\n# Good\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Bad\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_Warum soll ich den Imperativ benutzen?_\n\nEine Commit-Message beschreibt was die Änderung tatsächlich **tut** – ihre Auswirkungen – nicht was vorher war.\n\n### Große Anfangsbuchstaben\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nadd `use` method to Credit model\n```\n\nDiese Regelung ergibt grammatikalisch schlichtweg Sinn, da man den grammatikalischen Regeln bzgl. Großbuchstaben am Satzanfang gerecht wird.\n\nDiese Regelung kann von Entwickler zu Entwickler, Team zu Team oder auch Sprache zu Sprache unterschiedlich sein.\n\nGroßschreiben oder nicht, wichtig ist nur, dass man bei einer Variante bleibt.\n\n### Versuche _genau_ zu beschreiben, was die Änderung macht, auch ohne dass man in den Code gucken muss.\n\n```\n# Good\nAdd `use` method to Credit model\n\n```\n\n```\n# Bad\nAdd `use` method\n```\n\n```\n# Good\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Bad\nAdjust css\n```\n\nDies ist in vielen Situationen (z.B.: mehrere kleine Commits, Refactoring) sinnvoll, um besser zu verstehen, was sich der Entwickler gedacht hat.\n\n### \"Warum\", \"Wozu\", \"Wie\" und andere Details gehören in die Beschreibung der Commit-Message\n\n```\n# Good\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Good\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are picklable by default\n```\n\n```\n# Good\nAdd `use` method to Credit model\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nTitel bzw. Betreff der Commit-Message und die Beschreibung müssen mit einer Leerzeile getrennt werden. Alle weiteren Leerzeilen oder Absätze werden als Teil der Beschreibung gewertet.\n\nTrenn- oder Aufzählungszeichen, wie z.B.: `-`, `*` oder `\\` verbessern die Lesbarkeit der Beschreibung.\n\n### Vermeide allgemeingültige oder kontextfreie Beschreibungen\n\n```\n# Bad\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### Limitiere die Länge der Commit-Message\n\n[Es wird empfohlen (Quelle in ENG)](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) maximal 50 Zeichen für den Titel/Betreff und 72 Zeichen für die Nachricht zu verwenden.\n\n### Bleibe in einer Sprache\n\nDies gilt vor allem für Entwickler, für die Englisch nicht die Muttersprache ist. Logischerweise sollte man sich immer dem etablierten Standard anpassen – ganz besonders bei Repositories mit Entwicklern aus vielen verschiedenen Ländern.\n\nEntscheide dich für eine Sprache und bleibe dabei.\n\n```\n# Good\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Good (German example)\nababab Fügt die `use` Funktion dem Credit Model hinzu\nefefef Nutzt den InventoryBackendPool um aufs Bestands-BackEnd zuzugreifen\nbebebe Korrigiert den Methodennamen der InventoryBackend Kind-Klassen\n```\n\n```\n# Bad (mixes English and German)\nababab Fügt die `use` Funktion dem Credit Model hinzu\nefefef Add `use` method to Credit model\ncdcdcd Fix method name of InventoryBackend child classes\n```\n\n### Template\n\nDas folgende Template, [im Original von Tim Pope (Quelle auf Englisch)](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), erschienen so auch in dem Buch [Pro Git Book (Quelle auf Englisch)](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## Rebase vs _Merge_\n\nDieser Abschnitt ist ein **TL;DR** des lesenswerten Artikels [Atlassian's article Merging vs. Rebasing (Quelle auf Englisch)](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\n**TL;DR:** Wendet die Änderungen des aktuellen Branches auf den Stand des Basis-Branches an.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### _Merge_\n\n**TL;DR:** Erstellt einen neuen Commit, auch _Merge-Commit_, dieser führt die Änderungen beider Branches zusammen.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Warum bevorzugen manche Entwickler rebase?\n\nIch persönlich bevorzuge rebase. Gründe dafür sind unter anderem:\n\n* Es entsteht eine \"saubere\" Historie, ohne unnötige Merge-Commits.\n\n* _What you see is what you get_, z.B.: in eine Code-Review sieht man wirklich jeden Commit. Es sind keine Änderungen in Merge-Commits versteckt.\n* Jedes Zusammenführen von Code geschieht einzeln durch den Entwickler, so hat jeder Merge einen eigenen Commit mit einer entsprechenen Commit-Message.\n    * Im Normalfall werden Merge-Commits in einer Code-Review nicht betrachtet. Hat jede Änderung/Zusammenführung einen eigenen Commit, kann man sicher sein, dass alles an der richtigen Stelle ist und betrachtet werden kann.\n\n### Wann benutzt man squash\n\nSquash beschreibt eine Methode in der eine Reihe von Commits in einem einzelnen Commit zusammengefasst werden.\n\nHilfreich bei z.B.:\n\n- dem Reduzieren von kleinen/kontextlosen Commits (Rechtschreibfehler, Formatierung, vergessene Änderungen)\n- dem Zusammenführen mehrerer Commits, die als Ganzes mehr Sinn ergeben\n- dem Neu-Verpacken von _work in progress_ Commits\n\n### Wann sollte man rebase bzw. squash vermeiden\n\nVermeiden Sie die Verwendung von Rebase und Squash in öffentlichen Commits oder in Branches, in denen mehrere Personen arbeiten.\n\nRebase und Squash verändern die Historie der Commits und überschreiben bestehende Commits. Verwendet man rebase und squash auf Commits, die sich auf einen gemeinsam genutzten Branch befinden (d.h. Commits, die in ein Remote-Repository verschoben wurden oder von anderen Branches stammen), erzeugt man unötige Verwirrung. Darüber hinaus besteht die Gefahr, dass Andere ihre Änderungen (sowohl lokal als auch auf dem Remote) verlieren, aufgrund von unterschiedlichen Trees und anderen Konflikten.\n\n## Hilfreiche Git Kommandos\n\n### rebase -i\n\nWird verwendet, um Commits zu squashen, Commit-Messages zu bearbeiten, Neuschreiben/Löschen/Neuordnen von Commits, usw.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n### fixup\n\nWird verwendet, um Commits einfach anzupassen ohne ein komplexes Rebase durchzuführen.\n[Dieser Artikel (Quelle auf Englisch)](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) beschreibt mit Beispielen wie und wann man einen fixup durchführt.\n\n### cherry-pick\n\nSehr hilfreich, wenn man einen Commit der z.B. versehentlich im falschen Branch gepusht wurde, auf den richtigen Branch anwenden will, ohne diesen neuschreiben zu müssen.\n\nBeispiel:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### git add/checkout/reset [--patch | -p]\n\nAngenommen wir haben die folgenden offenen Änderungen:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in [Pro Git Book](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nMit `git add -p` können wir nun ausschließlich die gewünschten Abschnitte zum Commit hinzufügen, ganz ohne dass wir bestehenden Code ändern müssen. Das ist hilfreich, um größere Änderungen in mehrere kleine Commits aufzuteilen oder um ungewollte Änderungen gezielt rückgängig zu machen.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in [Pro Git Book](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Sonstiges Interessantes\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Hat es dir gefallen?\n\n[Sag danke!](https://saythanks.io/to/RomuloOliveira)\n\n## Mitwirken\n\nJede Art von Hilfe ist willkommen. Zum Beispiel zu den Themen:\n\n- Grammatik und Rechtschreibung\n- Übersetzung in andere Sprachen\n- Verbesserung der Quell-Referenzen\n- Falsche oder unvollständige Information\n\n## Inspiration, Quellen und Lesenswertes\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_es-AR.md",
    "content": "# Guía de mensajes de commit\n\n[![Say Thanks!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nUna guía para entender la importancia de los mensajes de commit y cómo escribirlos correctamente.\n\nAquí vas a aprender qué es un commit, por qué es importente escribir buenos mensajes, buenas prácticas y algunos tips para planear y (re)escribir una buena historia de commits.\n\n## ¿Qué es un \"commit\"?\n\nEn una frase, un commit es una copia instantánea de los archivos escritos de tu repositorio local.\nEn contra de lo que mucha gente cree, [git no guarda solo la diferencia entre los archivos, sino que guarda cada versión completa](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Fundamentos-de-Git#_copias_instant%C3%A1neas_no_diferencias)\nPara los archivos que no cambian de un commit a otro, git guarda un enlace a la versión previa, idéntica al archivo guardado.\n\nLa imagen a continuación muestra como git guarda datos a través del tiempo, entendiendo que cada \"versión\" es un commit:\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## ¿Por qué los mensajes de commit son importantes?\n\n- Para acelerar y dinamizar las revisiones de código\n- Para ayudar a entender los cambios\n- Para explicar los \"por qué\" que no pueden ser descritos solo con código\n- Para ayudar a los mantenedores futuros a entender por qué o cómo se hizo un cambio, facilitando la resolución de problemas y la depuración\n\nPara maximizar estos resultados se pueden usar las buenas prácticas y estándares descritos en la sección siguiente.\n\n## Buenas prácticas\n\nEstas son algunas prácticas recolectadas desde mi experiencia, artículos de internet y otras guías. Si tienes otras (o estás en contra de alguna) siéntete libre de abrir un Pull Request y contribuir.\n\n### Usa forma imperativa\n\n```\n# Good\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Bad\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_¿Pero por qué usar forma imperativa?_\n\nUn mensaje de commit describe qué **hace** el cambio referenciado, su efecto, no qué se hizo.\n\n\n### Primera letra en mayúscula\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nadd `use` method to Credit model\n```\n\nEl motivo detrás de esto es para seguir la regla gramatical que las oraciones deben comenzar en mayúsculas.\n\nEl uso de esta práctica puede variar de persona a persona, de equipo a equipo, o incluso de idioma a idioma.\nMayúsculas o no, es importante adherir a un solo estándar y respetarlo.\n\n### Comunica qué hace el cambio sin necesidad de mirar al código fuente\n\n```\n# Good\nAdd `use` method to Credit model\n\n```\n\n```\n# Bad\nAdd `use` method\n```\n\n```\n# Good\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Bad\nAdjust css\n```\n\nEs muy útil para ayudar a los revisores a entender el razonamiento del autor de los cambios (por ejemplo, cuando hay muchos commits, muchos cambios y refactors)\n\n### Usa el cuerpo del mensaje para explicar \"por qué\", \"para qué\", \"cómo\" y detalles adicionales\n\n```\n# Good\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Good\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are picklable by default\n```\n\n```\n# Good\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nEl asunto y el cuerpo del mensaje se separan por una línea en blanco.\nLas líneas en blanco adicionales pasan a ser consideradas parte del cuerpo del mensaje.\n\nCaracteres como `-`, `*` y \\` pueden aportar legibilidad.\n\n### Evita mensajes genéricos o sin contexto\n\n```\n# Bad\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### Limita el número de columnas\n\n[Se recomienda](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Contribuyendo-a-un-Proyecto#r_commit_guidelines) usar un máximo de 50 caracteres para el asunto y 72 para el cuerpo.\n\n### Mantén idioma consistente\n\nPara dueños de proyectos: elijan un idioma y escriban todos los mensajes de commit usando ese idioma. Idealmente debería coincidir con los comentarios del código, la localización por defecto (para proyectos que apliquen), etc.\n\nPara contribuidores: escriban sus mensajes de commits usando el mismo idioma que los que ya existen en el historial de commits.\n\n```\n# Good\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Good (Spanish example)\nababab Agrega el método `use` a la clase Credit\nefefef Usa el InventoryBackendPool para recuperar el backend de stock\nbebebe Corrige el nombre de un método de la clase InventoryBackend\n```\n\n```\n# Bad (mixes English and Spanish)\nababab Use InventoryBackendPool to retrieve inventory backend\nefefef Add `use` method to Credit model\ncdcdcd Listo\n```\n\n### Plantilla\n\nEsta es una plantilla, [escrita originalmente por Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), que aparece en el [_Libro Pro Git_](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Contribuyendo-a-un-Proyecto).\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## Rebase vs. Merge\n\nEsta sección es un **TL;DR** del excelente tutorial de Atlassian, [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\n**TL;DR:** aplica los commits de tu rama, uno a uno, sobre la rama base, generando un nuevo árbol.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge\n\n**TL;DR:** crea un nuevo commit, llamado (adecuadamente) un _commit de merge_, con la diferencia entre las dos ramas.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### ¿Por qué algunas personas prefieren rebase en lugar de merge?\n\nYo particularmente prefiero rebase por sobre merge. Entre otros, los motivos son:\n\n* Genera una historia más \"limpia\", sin commits de merge innecesarios\n* _Lo que ves es lo que hay_, por ejemplo, en una revisión de código los cambios vendrán de commits específicos y rotulados, evitando cambios ocultos en commits de merge\n* Más merges son resueltos por el autor y cada cambio producto de un merge es un commit separado con un mensaje acorde.\n    * No es una práctica usual indagar y revisar un commit de merge, así que al evitarlos nos aseguramos que los cambios provengan de un commit particular\n\n### ¿Cuándo hacer squash?\n\n\"Squashing\" es el proceso de tomar una serie de commits y condensarlos en uno solo.\n\nEs útil en varias situaciones, por ejemplo:\n\n- Reducir commits muy pequeños o sin contexto (typos, formateos, olvidos)\n- Unir cambios separados que cobran más sentido cuando se aplican juntos\n- Reescribir commits de trabajo en progreso (WIP)\n\n### ¿Cuándo evitar el rebase o squash?\n\nEvita el uso de rebase y squash en commits que sean públicos o compartidos por varias personas que trabajan en simultáneo.\nRebase y squash reescriben la historia y sobreescriben commits existentes, al hacerlo en commits que pertenecen a ramas compartidas (por ejemplo que fueron publicados en un repositorio remoto) puede causar confusión y pérdida del trabajo de alguien (tanto de manera local como remota) por encontrarnos frente a árboles divergentes y conflictos.\n\n## Comandos git útiles\n\n### rebase -i\n\nÚsalo para hacer squash de commits, editar mensajes, reescribir/eliminar/reordenar commits, etc.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nÚsalo para limpiar commits fácilmente y sin necesidad de un rebase más complejo.\n[Este artículo](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) tiene muy buenos ejemplos de cómo y cuándo usarlo.\n\n### cherry-pick\n\nEs útil para aplicar un commit que se hizo en una rama equivocada, sin necesidad de volver a escribirlo.\n\nEjemplo:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nSupongamos que tenemos la siguiente diferencia:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nPodemos usar `git add -p` para agregar solo los parches que querramos, sin necesidad de cambiar el código que ya fue escrito.\nEs útil también para separar un cambio grande en commits pequeños o hacer reset/checkout de cambios específicos.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Otros enlaces interesantes\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## ¿Te gustó?\n\n[¡Di gracias!](https://saythanks.io/to/RomuloOliveira)\n\n## Contribuciones\n\nToda ayuda es bienvenida. Ejemplo de temas sobre los que puedes colaborar:\n\n- Correcciones de gramática y ortografía\n- Traducción a otros idiomas\n- Mejoras en el código de referencia\n- Información incorrecta o incompleta\n\n## Fuentes de inspiración, referencias y lecturas adicionales\n\n- [Cómo escribir un mensaje de commit de git](https://chris.beams.io/posts/git-commit/)\n- [Libro Pro Git - Guía de commits](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Contribuyendo-a-un-Proyecto#r_commit_guidelines)\n- [Una nota sobre mensajes de commit de git](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Libro Pro Git - Reescribiendo la Historia](https://git-scm.com/book/es/v2/Herramientas-de-Git-Reescribiendo-la-Historia)\n"
  },
  {
    "path": "README_fa-IR.md",
    "content": "#  راهنمای Commit-Message\n\n[![Say Thanks!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\n‫\nراهنمایی برای درک اهمیت Commit-Message و نحوه نوشتن صحیح آن.\n\n‫\n این راهنما سعی دارد به شما کمک کند یادبگیرید کامیت چیست، چرا نوشتن Commit-Message مناسب مهم است،\nتمرین های خوب و نکاتی که می تواند منجرب به بازنگری و داشتن تاریخچه کامیت بهتری شود\n\n## دیگر زبان ها\n\n- [English](README.md)\n- [Português](README_pt-BR.md)\n- [Deutsch](README_de-DE.md)\n- [Español](README_es-AR.md)\n- [Italiano](README_it-IT.md)\n- [한국어](README_ko-KR.md)\n- [Русский](README_ru-RU.md)\n- [简体中文](README_zh-CN.md)\n- [日本語](README_ja-JP.md)\n- [Українська](README_ua-UA.md)\n- [پارسی](README_fa-IR.md)\n\n## \"Commit\" چیست ?\n\n‫\nبه زبان ساده، یک کامیت اسنپ شات ی از فایل های محلی شما هست که در مخزن محلی نوشته میشود\nبرخلاف تصور افراد، [گیت تنها تغییرات فایل هارا نگهداری نمی کند بلکه نسخه کاملی از آنها را نگهداری میکند](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences).\nو برای فایل هایی که تغییری در آنها داده نشده تنها لینک منطبق با فایل موجود را نگهداری میکند.\n\nتصویر زیر نحوه ذخیره اطلاعات درطول زمان را نمایش میدهد، در اینجا هر نسخه یک کامیت محسوب میگردد\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## چرا Commit-Messages اهمیت دارند؟\n\n- سرعت بخشیدن و ساده سازی کدریویو\n- کمک به فهم تغییرات\n- توضیح \"دلیل\"، که تنها با کد قابل توضیح نیست\n- کمک به نگهداری درآینده و فهم چرا و چگونه تغیرات داده شده اند، عیب یابی و اشکال زدایی سریعتر\n\nبرای درک بهتر، چند تمرین و استاندارد در قسمت بعدی توضیح داده خواهد شد\n\n## تمرین خوب\n\nاینها چند تمرین خوب گردآوری شده از تجارب شخصی، اینترنت و سایر راهنماها می باشند، اگه شما با آنها مخالفید یا میتوانید تمرین های بهتر دیگری ارائه دهید میتوانید در توسعه این مخزن مشارکت نمایید\n\n### استفاده از فرم دستوری\n\n```\n# Good\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Bad\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_اما چرا ما شکل دستوری را استفاده میکنیم?_\n\n‫\nیک Commit-Message درواقع آن چیزی راکه تغییرات انجام میدهد یا تاثیر آن را توضیح میدهد نه چیزی که انجام شده است\n\n\n### حرف اول با حروف بزرگ\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nadd `use` method to Credit model\n```\n\nدلیل اینکه اولین حرف باید با حروف بزرگ باشد پیروی از قانون گرامر و استفاده از حروف بزرگ در ابتدای جمله می باشد\n\nاستفاده از این تمرین از شخصی به شخص دیگر، یا از تیمی به تیمی دیگر یا حتی از زبانی به زبان دیگر متفاوت خواهد بود.\nاستفاده از حروف بزرگ یا کوچک اهمیتی ندارد، نکته مهم پیروی از یک قانون واحد است\n\n### سعی در رساندن اینکه تغیر چه کاری انجام میدهد بدون نیاز به مشاهده کد \n\n```\n# Good\nAdd `use` method to Credit model\n\n```\n\n```\n# Bad\nAdd `use` method\n```\n\n```\n# Good\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Bad\nAdjust css\n```\n\nدر بسیاری از سناریوها مانند کامیت های متعدد، تغییرات مختلف و بازنویسی به بازبینی کننده کمک خواهد کرد که بفهمد کامیت کننده درچه فکری بوده است \n\n### استفاده از بدنه Commit-Message برای توضیح \"چرا\"، \"به چه علت\"، \"چطور\" و جزئیات بیشتر\n\n```\n# Good\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Good\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# Good\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\n‫\nموضوع و بدنه پیام کامیت با یک خط خالی جدا می شوند.\nخط های خالی اضافی جزئی از بدنه Commit-Message محسوب خواهند شد\n\n‫\nکارکتر هایی همچون `-`, `*` و `\\` باعث تقویت خوانایی Commit-Message خواهند شد\n\n### از متن های کلی یا بی محتوا دوری کنید\n\n```\n# Bad\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### تعداد کارکتر های مورد استفاده را محدود کنید\n\n‫\n[توصیه شده](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) برای موضوع Commit-Message حداکثر 50 کارکتر و برای بدنه آن کداکثر 72 کارکتر استفاده شود.\n\n### در استفاده از زبان نوشتن متن ثابت قدم باشید\n\n‫\nبرای مالک پروژه: انتخاب یک زبان و نوشتن همه Commit-Message ها بوسیله آن، که باید همان زبان مورد استفاده برای کامنت ها و زبان پیش فرض برای پروژه های چند زبانه باشد\n\n‫\nبرای مشارکت کنندگان: نوشتن Commit-Message با زبان مشابه متن های کامیت قبلی\n\n```\n# Good\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Good (Portuguese example)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Bad (mixes English and Portuguese)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### قالب\n\n‫\n این یک قالب [نوشته شده توسط Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) که در [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) قابل دسترسی می باشد\n\n```\nتغیرات را در حدود ۵۰ کاراکتر یا کمتر خلاصه کنید\n\nمتن توضیحات دقیقتر را در ۷۲ کاراکتر بگنجانید،\n.اولین خط بعنوان موضوع و مابقی بعنوان بدنه تلقی خواهد شد\n\nیک خط خالی برای جدا کردن موضوع از بدنه ضرروی خواهد بود\nدر غیراینصورت ابزارهای مختلف مثل `log`, `shortlog`و `rebase` سردرگم خواهند شد\n\nمشکلی که کامیت فوق رفع خواهد کرد را توضیح دهید\nبرخلاف اینکه چطور تغییرات انجام شده برروی چرا تغییرات رو انجام داده اید\nفوکوس کنید.\nاینکه تغییرات چطور انجام شده در کد مشخص هست\n\nاینجا مکانی هست که باید توضیح دهید آبا تغیرات تاثیری بر قسمت های مختلف یا عواقب ناخواسته ای خواهند داشت\n\n\nاگر از ابزاری برای مدیریت ایژوهااستفاده می کنید شماره ارجاع مربوط را در انتهای متن قرار بدید\nمثال\n\nResolves: #123\nSee also: #456, #789\n```\nاینجا میتوانید متن اصلی را مشاهده نمایید\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## Rebase vs. Merge\n\n‫\nاین قسمت خلاصه ای از آموزش عالی اطلسین می باشد، [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\nبطور خلاصه قرار دادن کامیت های برنچ شما برروی کامیت های مستر وتولید درخت جدید\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge\n\n‫\nبطور خلاصه ایجاد یک کامیت جدید بنام _merge commit_ شامل اختلاف دو برنچ\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### چرا افراد Rebase را به Merge ترجیح میدهند؟\n\nمن شخصا ریبیس را به مرج ترجیح میدهم به دلایل زیر\n\n* توسط آن یک تاریخچه کامیت تمیز و بدون کامیت مرج غیرضروری خواهید داشت\n* چیزی که شما می بینید چیزی هست که بدست میاورید به این معنی که در بازنگری همه تغییرات در کامیت مربوطه قابل مشاهده هستند وتغییراتی در کامیت مرج مخفی نشده است\n* مرجج های بیشتری توسط کامیت کننده برطرف خواهد شد و هر تغییر مرج در کامیتی با متن مناسب خواهد بود\n  * در حالت عادی کامیت های مرج بررسی نمیشوند بنابراین اجتناب از آنها این اطمینان به ما خواهد داد که همه تغییرات در کامیت مربوطه خواهند بود\n  \n\n### چه وقت از squash استفاده کنیم\n\n‫\n\"Squashing\" پروسه ای می باشد که یک سری ازکامیت ها به یک کامیت تبدیل خواهند شد\nو در وضعیت های مختلفی مفید می باشد مانند\n\n- کاهش تعداد کامیت های بدون محتوا یا کم محتوا مانند اصلاحات تایپی، فرمت کد، چیزهای فراموش شده\n- اضافه کردن تغییراتی که درصورت یکی شدن معنی دار خواهند بود\n- بازنویسی  کامیت های _work in progress_  \n\n### چه زمانی از rebase یا squash استفاده نکنیم?\n\nدر زمانی که برروی برنچ های مشترک یا کامیت های عمومی با سایر افراد کار میکنید  باید از استفاده از آنها اجتناب کنید\n\n\nاین دستورات تاریخچه کامیت ها را بازنویسی همچنین کامیت های موجود رااز بین خواهد برد\nدر نتیجه انجام آن برروی برنچ های مشترک می تواند باعث ابهام و یا ازدست رفتن تغییرات بدلیل کانفلیک یا انشعابات در درخت کامیت ها گردد \n\n## دستورات مفید Git\n\n### rebase -i\n\nاز این دستور برای ویرایش کامیت، ریبیس، بازنویسی، حذف یا تغییر ترتیب کامیت ها بطور مثال میتوانید استفاده کنید\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\n‫\nاز این دستور برای پاک سازی آسان بدون نیاز به پیچیدگی های زیاد rebase می توانید استفاده کنید\n[این مقاله](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) در بردارنده مثال هایی مفیدی از نحوه و زمان انجام آن می باشد\n\n\n### cherry-pick\nدستور مفیدی برای اضافه کردن کامیتی که در برنچی اشتباهی انجام شده بدون نیاز به کدنویسی مجدد\n\nExample:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\nبطور مثال ما تفاوت زیر را داریم:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n‫\nتوسط `git add -p` ما میتوانید تنها پچ هایی که میخواهیم اضافه کنیم، \nبدون احتیاج به تغیر کدی که نوشته شده است\nهمچنین این امکان میسر خواهند بود تغییرات بزرگ به کامیت های کوچکتر شکسته شود یا تغیرات reset/checkout شوند \n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## سایت های جالب دیگر\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## مفید بود?\n\n[تشکر !](https://saythanks.io/to/RomuloOliveira)\n\n## مشارکت\nاز هر نوع کمکی قدردانی خواهد شد بطور مثال در موارد زیر شما میتوانید به بنده کمک کنید\n\n- گرامر و تصحیح املا\n- ترجمه به زبان های دیگر\n- تقویت منابع و مراجع\n- اصلاعات ناقص و نادرست\n\n## منابع الهام گرفته شده و اطلاعات بیشتر\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_fr-FR.md",
    "content": "# Guide sur les messages de commit\n\n[![Dites merci!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nUn guide pour comprendre l'importance des messages de commit et comment bien les écrire.\n\nCela pourrait vous aider à comprendre ce qu'un commit est, pourquoi c'est important de bien écrire ses messages, les meilleurs techniques et quelques astuces, pour mieux (ré)écrire une bonne \"commit history\"\n\n## Qu'est-ce qu'un \"commit\" ?\n\nDans des termes simples, un commit est une _sauvegarde_ de vos fichiers locaux, écrits dans votre dépôt local.\nContrairement à ce que certaines personnes pensent, [git ne stocke pas seulement la différence entre ces fichiers, il stocke une version complète de tous les fichiers](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences).\nPour les fichiers qui ne changent pas d'un commit à l'autre, git stocke juste un lien vers la version précédente identique qui est déjà stockée.\n\nL'image ci-dessous montre comment git stocke les fichiers à travers le temps, dans quelle \"Version\" est un commit.\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Pourquoi les messages de commit sont importants ?\n\n- Pour raccourcir et faciliter les revues de code.\n- Pour aider dans la compréhension d'un changement.\n- Pour expliquer les \"pourquoi\", qui ne sauraient être décris en code\n- Pour aider les futurs personnes qui vont devoir maintenir le code à comprendre les différents changements, et l'évolution du code.\n\nPour maximiser ces résultats, nous pouvons utiliser certaines bonnes pratiques et des standards, décrits dans la prochaine section.\n\n## Bons usages\n\nIl y a quelques bons usages recueillit par l'experience, des articles sur internet, et d'autres guides. Si vous en avez d'autres (ou n'êtes pas d'accord avec certains), soyez libres d'ouvrir une demande de Pull et de contribuer à l'amélioration du guide.\n\n### Utilisez l'impératif\n\n```\n# Bon\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Mauvais\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_Pourquoi l'impératif ?_\n\nUn message de commit décrit ce que le changement **fait**, ces effets, pas ce qui à été fait.\n\n### Mettre une majuscule au début de la phrase\n\n```\n# Bon\nAdd `use` method to Credit model\n```\n\n```\n# Mauvais\nadd `use` method to Credit model\n```\n\nOn met la première lettre en majuscule pour suivre la règle de grammaire selon laquelle on doit utiliser une majuscule au début d'une phrase.\n\nCette pratique peut être ou non appliquée en fonction des personnes, des équipes ou même des languages. Dans tous les cas, l'important est de définir une règle et de s'y tenir.\n\n### Essayer de décrire les changements sans avoir à lire le code\n\n```\n# Bon\nAdd `use` method to Credit model\n\n```\n\n```\n# Mauvais\nAdd `use` method\n```\n\n```\n# Bon\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Mauvais\nAdjust css\n```\n\nCela est utile dans de nombreux scenarios (commits multiples, beaucoup changements et refactorisations) pour aider les reviewers à comprendre ce à quoi la personne qui a fait le commit pensait.\n\n### Use the message body to explain \"why\", \"for what\", \"how\" and additional details\n### Utiliser le corps du message pour expliquer \"pourquoi\", pour \"quoi\", \"comment\" et autres détails\n\n```\n# Bon\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Bon\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are picklable by default\n```\n\n```\n# Bon\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nL'objet et le corps du message sont séparés par un saut de ligne.\nDes sauts de ligne additionels sont considérés comme faisant partie du corps.\nEviter les caractères tels que `-`, `*` et `\\` améliore la lisiblité.\n\n### Eviter les messages génériques ou sans aucun contexte\n\n```\n# Mauvais\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### Limiter le nombre de colonnes\n\n[Il est recommandé](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) d'utiliser un maximum de 50 caractères pour le sujet, et 72 pour le corps.\n\n### Garder la cohérence linguistique\n\nPour les propriétaires de projet: Choisissez une langue et écrivez tous les messages de validation en utilisant cette langue. Idéalement, il devrait correspondre aux commentaires de code, aux paramètres régionaux de traduction par défaut (pour les projets localisés), etc.\n\nPour les contributeurs: Écrivez vos messages de validation en utilisant la même langue que l'historique de validation existant.\n\n\n```\n# Bon\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Bon (Exemple Portugais)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Bad (mix Anglais et Portugais)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### Modèle\n\nC'est un modèle, [écrit par Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), qui apparait dans le  [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n\n```\nRésumer les changements en 50 caractères ou moins.\n\nTexte explicatif plus détaillé, si nécessaire. Mettez un retour à la ligne à environ 72 caractères. Dans certains contextes, la première ligne est traitée\nen tant que sujet du commit et le reste en tant que corps. La ligne\nvide séparant le sommaire du corps est critique (sauf si vous omettez complètement le corps); certains outils tels que `log`, `shortlog` et\n`rebase` peuvent être confus si vous les fusionnez ensemble.\n\nExpliquez le problème que ce commit est en train de résoudre. Concentrez-vous sur\nles raisons pour lesquelles vous apportez ce changement, par opposition à la\nfaçon dont (le code explique cela).\nEst-ce qu'il y at-il des effets secondaires ou d’autres conséquences non intuitives de ce changement? Voici l'endroit pour les expliquer.\n\nLes autres paragraphes viennent après les lignes vides.\n\n - Les puces sont ok.\n\n - Généralement, un tiret ou un astérisque est utilisé pour la puce, précédé d'un espace, avec des lignes vides entre les deux, mais les conventions varient ici.\n\nSi vous utilisez un outil de suivi des problèmes,\nmettez les références à la fin comme ceci:\n\nRésout: #123\nVoir aussi: #456, #789\n```\n\n## Rebase vs. Merge\n\nCette section est un **TL;DR** de l'excellent tutoriel d'Atlassian, [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\n**TL;DR:** Applique vos commits de branche, un par un, sur la branche principale, générant un nouvel \"arbre\"\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge\n\n**TL;DR:** Créé un nouveau commit, appelé un _merge commit_, avec les différences entre ces deux branches.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Pourquoi certaines personnes préfères rebase plutôt que merge ?\n\nJe préfère particulièrement rebase plutôt que merge. Les raisons sont:\n\n* Cela génère un historique \"propre\", sans merge commits inutiles.\n* Ce que vous voyez est ce que vous obtenez, c’est-à-dire que dans une revue de code, toutes les modifications proviennent d’un commit spécifique, évitant les changements masqués dans les commits de merge.\n* Plus de merges sont résolus par la personne qui commit, et chaque modification de merge est dans un commit avec un message propre à celui-ci.\n* Il est inhabituel de chercher et d'examiner les commits de merge. Evitez-les donc pour vous assurer que tous les changements ont un commit auquel ils appartiennent.\n\n### Quand \"squash\"\n\n\"Squashing\" est le processus consistant à prendre une série de commits et à les condenser en un seul commit.\n\nC'est utile dans plusieurs situations, e.g.:\n\n- Réduire le nombre de commit avec peu ou pas de contexte (correction de fautes d'orthographe, formatage, choses oubliées)\n- Joindre des modifications distinctes qui ont plus de sens lorsqu'elles sont appliquées ensemble\n- Réécrire les commits de _travail en cours_\n\n### Quand éviter rebase ou squash ?\n\nIl faut éviter rebase et squash dans les commits publiques ou dans les branches partagées où plusieurs personnes travaillent dessus.\nRebase et squash réécrivent l'historique et écrasent les commits existants, le faire sur des commits qui sont dans des branches partagées (i.e., les commits push sur le dépôt distant ou qui viennent d'autres branches) peut entrainer de la confusion, et les gens risquent de perdre leurs changements (autant localement que à distance) car les arbres et les conflicts divergent.\n\n## Commandes git pratiques\n\n### rebase -i\n\nUtilisez-la pour squash les commits, modifier les messages, réécrire/supprimer/réorganiser les commits, etc.\n\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nUtilisez-la pour nettoyer les commits facilement et sans nécessiter de rebase plus complexe.\n[Cet article](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) a de bons exemples de comment et quand le faire.\n\n### cherry-pick\n\nC'est très utile pour appliquer le commit que vous avez fait sur la mauvaise branche, sans qu'il soit nécessaire de le coder à nouveau.\n\nExemple:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nImaginons que nous avons le diff suivant:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Modèle\n+\n+C'est un modèle, [Ecrit par Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), qui apparait dans [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contribuer\n\n Toute sorte d'aide est apréciée. Voici quelques exemples de sujets où vous pouvez m'aider.\n\n@@ -202,3 +205,4 @@ Toute sorte d'aide est apréciée. Voici quelques exemples de sujets où vous pouvez m'aider.\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nOn peut utiliser git add -p pour ajouter uniquement les correctifs que nous voulons, sans qu'il soit nécessaire de modifier le code déjà écrit.\nIl est utile de scinder un gros changement en de plus petits commits ou de réinitialiser/extraire des modifications spécifiques.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## D'autres choses intéréssantes\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Vous aimez ?\n\n[Dites merci!](https://saythanks.io/to/RomuloOliveira)\n\n## Contribuer\n\nToute sorte d'aide est appréciée. Voici quelques exemples de sujets où vous pouvez m'aider :\n\n- Corrections grammaticales et orthographiques\n- Traduction dans d'autres langues\n- Meilleures référencement des sources\n- Informations incorrectes ou incompletes\n\n## Inspirations, sources et lectures complémentaires:\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_gr-GR.md",
    "content": "# Οδηγός για τα \"Μηνύματα Commit\"\n\n[![Πείτε ευχαριστώ!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nΑυτό το κείμενο αποτελεί έναν οδηγό που θα συντελέσει στο να κατανοήσετε την σημασία των μηνυμάτων commit και πώς να τα γράψετε σωστά.\n\nΕνδεχομένως να σας βοηθήσει να μάθετε τι ακριβώς είναι ένα commit, γιατί θεωρείται σημαντικό το να γράφετε καλά μηνύματα, βέλτιστες πρακτικές και κάποιες συμβουλές για το πώς να προσχεδιάσετε και (ξανά)συντάξετε ένα καλό ιστορικό commit.\n\n## Τι είναι ένα \"commit\"?\n\nΜε απλά λόγια, ένα commit είναι ένα _στιγμιότυπο_ των τοπικών σας αρχείων, γραμμένο στο τοπικό σας απωθητήριο(repository).\nΑντίθετα με την γνώμη μερικών, [το git δεν αποθηκεύει μόνο την εκάστοτε διαφορά μεταξύ των αρχείων, αποθηκεύει μία πλήρη έκδοση όλων των αρχείων](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences).\nΌσον αφορά τα αρχεία τα οποία δεν άλλαξαν από το ένα commit στο άλλο, το git αποθηκεύει μόνο έναν σύνδεσμο που παραπέμπει στο προηγούμενο, πανομοιότυπο αρχείο που είναι ήδη αποθηκευμένο.\n\nΗ παρακάτω εικόνα αναπαριστά τον τρόπο σύμφωνα με τον οποίο το git αποθηκεύει δεδομένα με την πάροδο του χρόνου, όπου κάθε \"Εκδοχή\" είναι ένα commit:\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Γιατί είναι τα μηνύματα commit σημαντικά?\n\n- Για να επιταχυνθούν και βελτιστοποιηθούν οι κριτικές κώδικα\n- Για να συνδράμουν στην καλύτερη κατανόηση μιας αλλαγής\n- Για να εξηγήσουν \"τα γιατί (αίτια)\" που δεν μπορούν να περιγραφτούν μόνο με την χρήση κώδικα\n- Για να βοηθήσουν μελλοντικούς διατηρητές του απωθητηρίου να καταλάβουν γιατί και πώς υλοποιήθηκαν ορισμένες αλλαγές, κάτι που καθιστά την επίλυση προβλημάτων και τον εντοπισμό \"bugs\" ευκολότερα\n\nΓια να επιτύχουμε αυτά τα αποτελέσματα στον μέγιστο βαθμό, μπορούμε να χρησιμοποιήσουμε ορισμένες καλές πρακτικές και πρότυπα που αναλύονται στο επόμενο τμήμα.\n\n## Καλές πρακτικές\n\nΑυτές είναι μερικές πρακτικές που συνέλεξα από τις εμπειρίες μου, άρθρα στο διαδίκτυο, και άλλους οδηγούς. Εάν έχετε άλλες (ή διαφωνείτε με μερικές) νιώστε ευπρόσδεκτοι να ανοίξετε ένα \"Pull Request\" και να συνεισφέρετε.\n\n### Χρησιμοποιήστε υποτακτική\n\n```\n# Καλό\nΧρησιμοποιώ InventoryBackendPool για να επανακτήσω inventory backend\n```\n\n```\n# Κακό\nΧρησιμοποίησα InventoryBackendPool για να επανακτήσω inventory backend\n```\n\n_Αλλά γιατί να χρησιμοποιήσω υποτακτική;_\n\nΈνα μήνυμα commit περιγράφει τι η αναφερθείσα αλλαγή **κάνει** στην πραγματικότητα, τις επιδράσεις της, όχι τι συνέβη.\n\n### Κάντε το πρώτο γράμμα κεφαλαίο\n\n```\n# Καλό\nΠροσθέσει την `use` μέθοδο στο Credit μοντέλο\n```\n\n```\n# Κακό\nπροσθέσει την `use` μέθοδο στο Credit μοντέλο\n```\n\nΟ λόγος για τον οποίο πρέπει να είναι το πρώτο γράμμα κεφαλαίο είναι για να ακολουθηθεί ο κανόνας της γραμματικής που δηλώνει ότι πρέπει να χρησιμοποιούνται κεφαλαία γράμματα στην αρχή των προτάσεων.\n\nΗ χρήση αυτής της πρακτικής ενδέχεται να ποικίλλει από άτομο σε άτομο, ομάδα σε ομάδα, ή ακόμα από γλώσσα σε γλώσσα.\nΜε κεφαλαίο πρώτο γράμμα ή όχι, το σημαντικό είναι να παραμείνετε στο να χρησιμοποιείτε ένα μόνο πρότυπο και να το ακολουθήσετε.\n\n### Προσπαθήστε να επικοινωνήσετε τι κάνει η εκάστοτε αλλαγή χωρίς να απαιτείται αναδρομή στον πηγαίο κώδικα\n\n```\n# Καλό\nΠροσθέσει την `use` μέθοδο στο Credit μοντέλο\n```\n\n```\n# Κακό\nΠροσθέσει την `use` μέθοδο\n```\n\n```\n# Καλό\nΑυξήσει το αριστερό κενό μεταξύ του textbox και layout frame\n```\n\n```\n# Κακό\nΠροσαρμόσει το css\n```\n\nΕίναι λυσιτελές σε πολλές εκδοχές (π.χ. πολλαπλά commits, διάφορες αλλαγές και refactors) το να βοηθήσετε τους κριτικούς κώδικα να καταλάβουν τι σκεφτόταν αυτός που διέπραξε τα commits.\n\n### Χρησιμοποιήστε το σώμα κειμένου για να εξηγήσετε \"γιατί\", \"για ποιον σκοπό\", \"πώς\" και επιπρόσθετες λεπτομέρειες\n\n```\n# Καλό\nΦτιάξει όνομα μεθόδου των παιδιών κλάσεων του InventoryBackend\n\nΟι κλάσεις που εξήγοντο από το InventoryBackend δεν\nσέβοταν το βασικό interface της κλάσης.\n\nΔούλεψε επειδή το cart καλούσε την υλοποίηση\nbackend με λάθος τρόπο.\n```\n\n```\n# Καλό\nΜετατρέψει τα credits σε σειριακά και αντίστροφα ως json στο Cart\n\nΜετατροπή των Credit instances σε dict για δύο κύριους λόγους:\n\n  - Το Pickle στηρίζεται στο file path για τις κλάσεις και δεν θέλουμε να\n    χαλάσουμε τα πάντα εφ' όσον χρειαστεί ένα refactor\n  - Το dict και οι ενσωματομένοι τύποι είναι δυνατόν να γίνουν\n    pickled από μόνοι τους\n```\n\n```\n# Καλό\nΠροσθέσει την `use` μέθοδο στο Credit\n\nΑλλαγή από namedtuple σε κλάση γιατί χρειαζόμαστε να\nεγκατασταστήσουμε ένα καινούργιο attribute (in_use_amount)\nμε μία νέα τιμή\n```\n\nΤο θέμα και το σώμα των κειμένων διαχωρίζονται μέσω μίας κενής γραμμής.\nΠεραιτέρω κενές γραμμές εκλαμβάνονται ως μέρος του σώματος κειμένου.\n\nΧαρακτήρες όπως `-`, `*` και \\` είναι στοιχεία που βελτιώνουν την αναγνωσιμότητα.\n\n### Αποφύγετε γενικού ύφους μηνύματα ή μηνύματα χωρίς κάποιο γενικό πλαίσιο\n\n```\n# Κακό\nΦτιάξει αυτό\n\nΦτιάξει πράγματα\n\nΤώρα πρέπει να δουλέψει\n\nΑλλάξει πράγματα\n\nΤροποποιήσει το css\n```\n\n### Περιορίστε τον αριθμό των χαρακτήρων\n\n[Προτείνεται](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) να χρησιμοποιείτε ένα μέγιστο 50 χαρακτήρων για το θέμα και 72 για το σώμα του κειμένου\n\n### Διατηρήστε συνοχή στην γλώσσα\n\nΓια τους ιδιοκτήτες project: Διαλέξτε μία γλώσσα και γράψτε όλα τα μηνύματα commit χρησιμοποιώντας αυτήν την γλώσσα. Ιδανικά, θα πρέπει να ταιριάζει με τα σχόλια στον κώδικα, το προκαθορισμένο locale μετάφρασης (για projects τοπικού χαρακτήρα), κτλ.\n\nΓια όσους συνεισφέρουν: Γράψτε τα μηνύματα commit σας χρησιμοποιώντας την ίδια γλώσσα που χρησιμοποιείται στο ήδη υπάρχον ιστορικό commit.\n\n```\n# Καλό\nababab Προσθέσει την `use` μέθοδο στο μοντέλο Credit\nefefef Χρησιμοποιήσει το InventoryBackendPool για να επανακτήσει το inventory backend\nbebebe Διορθώσει το όνομα των μεθόδων των InventoryBackend παιδιών κλάσεων\n```\n\n```\n# Καλό (Παράδειγμα στα Πορτογαλικά)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Κακό (Μπλέκει Αγγλικά και Πορτογαλικά)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### Πρότυπο\n\nΑυτό είναι ένα πρότυπο, [που αρχικά έγραψε ο Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), το οποίο εμφανίζεται στο [_Pro Git Βιβλίο_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n\n```\nΑναφέρετε περιληπτικά τις αλλαγές σε περίπου 50 χαρακτήρες ή λιγότερους\n\nΠιο λεπτομερές επεξηγηματικό κείμενο, εάν κρίνεται απαραίτητο.\nΣυμπυκνώστε το σε περίπου 72 χαρακτήρες. Εντός κάποιων πλαισίων,\nη πρώτη γραμμή αντιμετωπίζεται ως το θέμα του commit και το υπόλοιπο\nτου κειμένου ως το σώμα του. Η κενή γραμμή που διαχωρίζει την\nπερίληψη από το σώμα είναι ζωτικής σημασίας (εκτός και αν παραλείψετε\nτο σώμα εντελώς); ποικίλια εργαλεία όπως τα `log`, `shortlog` και `rebase`\nμπορεί να μπερδευτούν αν τρέξετε τα δύο μαζί.\n\nΕξηγήστε το πρόβλημα που επιλύει αυτό το commit. Εστιάστε στο γιατί\nκάνετε αυτήν την αλλαγή αντί στο πώς (ο κώδικας το εξηγεί αυτό).\nΥπάρχουν έμμεσες επιδράσεις ή άλλες μη διαισθητικές συνέπειες αυτής\nτης αλλαγής; Εδώ είναι το μέρος για να τις εξηγήσετε.\n\nΠεραιτέρω παράγραφοι έρχονται μετά από κενές γραμμές.\n\n  - Τα bullet points είναι, και αυτά, εντάξει\n\n  - Συνήθως για το bullet χρησιμοποιείται μία παύλα ή ένας αστερίσκος,\n    μετά από ένα μόνο κενό, με κενές γραμμές ανάμεσα, αλλά οι συμβάσεις\n    σχετικά με αυτό το θέμα ποικίλουν.\n\nΆμα χρησιμοποιείτε έναν issue tracker, τοποθετήστε αναφορές σε αυτούς\nστο κάτω μέρος, όπως έτσι:\n\nΕπιλύει: #123\nΔείτε επίσης: #456, #789\n```\n\n## Rebase εναντίον Merge\n\nΑυτό το τμήμα είναι ένα **TL;DR** του εξαιρετικού tutorial του Atlassian, [\"Merging εναντίον Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\n**TL;DR:** Εφαρμόζει τα commits στο κλαδί που είστε, ένα ένα, στο κλαδί βάση, παράγοντας ένα καινούργιο δέντρο.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge\n\n**TL;DR:** Δημιουργεί ένα νέο commit, το επονομαζόμενο (δικαίως) _merge commit_, με τις διαφορές μεταξύ των δύο κλαδιών.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Γιατί μερικοί προτιμούν να κάνουν rebase αντί για merge;\n\nΕγώ προσωπικά προτιμώ να κάνω rebase αντί για merge. Οι λόγοι περιλαμβάνουν:\n\n* Παράγει ένα \"καθαρό\" ιστορικό, χωρίς αχρείαστα merge commits\n* _Ότι δείτε είναι ότι παίρνετε_, δηλαδή, σε μια κριτική κώδικα όλες οι αλλαγές προέρχονται από ένα συγκεκριμένο και ονοματιζμένο commit, αποφεύγοντας αλλαγές κρυμμένες μέσα σε merge commits\n* Περισσότερα merges επιλύονται από αυτόν που κάνει commit, και κάθε αλλαγή merge είναι σε ένα commit με ένα κατάλληλο μήνυμα\n    * Είναι ασηνύθιστο να ψάχνεις και να κάνεις κριτική κώδικα σε merge commits, οπότε το να τα αποφεύγεις διασφαλίζει το ότι όλες οι αλλαγές έχουν ένα commit στο οποίο ανήκουν\nI particularly prefer to rebase over merge. The reasons include:\n\n### Πότε να κάνετε squash\n\n\"Squashing\" είναι η διαδικασία του να παίρνεις μια ακολουθία από commits και μετά να τις συμπυκνώνεις σε ένα μόνο commit.\n\nΕίναι χρήσιμο σε πληθώρα περιστάσεων, π.χ:\n\n- Ελλάτωση commits με λίγο ή καθόλου πλαίσιο (διορθώσεις τυπογραφικών λαθών, formatting, ξεχασμένα πράγματα)\n- Σύντμηση διαφορετικών αλλαγών που βγάζουν περισσότερο νόημα όταν εφαρμοστούν μαζί\n- Γράψιμο έτη μία φορά _work in progress_ commits\n\n### Πότε να αποφύγετε το rebase ή το squash;\n\nΑποφύγετε τα rebase και squash σε δημόσια commits ή σε κοινόχρηστα κλαδιά όπου δουλεύουν πολλοί άνθρωποι.\nΤο rebase και το squash ξανά γράφουν το ιστορικό και γράφονται επί των ήδη υπαρχόντων commits, το να τα κάνετε σε commits που είναι σε κοινόχρηστα κλαδιά (δηλαδή, commits που έχετε κάνει push σε remote απωθητήριο ή που προέρχονται από κλαδιά άλλων) μπορεί να προκαλέσει σύγχηση και ενδέχεται άνθρωποι να χάσουν τις αλλαγές τους (και τοπικά και remotely) λόγω των αποκλίνοντων δέντρων και conflicts.\n\n## Χρήσιμες εντολές git\n\n### rebase -i\n\nΧρησιμοποιήστε την για να κάνετε squash commits, να επεξεργαστείτε μηνύματα, να ξαναγράψετε/διαγράψετε/αναταξινομήσετε commits, κλπ.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nΧρησιμοποιήστε την για να καθαρίσετε commits εύκολα και χωρίς να χρειαστεί ένα πιο πολύπλοκο rebase.\n[Αυτό το άρθρο](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) περιέχει πολύ καλά παραδείγματα σχετικλα με το πώς και πότε να το κάνετε.\n\n### cherry-pick\n\nΕίναι πολύ χρήσιμη για να εφαρμόσετε το commit που κάνατε στο λάθος κλαδί, χωρίς την ανάγκη να ξαναγράψετε τον κώδικα.\n\nΠαράδειγμα:\n```\n$ git cherry-pick 790ab21\n[master 094d820] Φτιάξει ελληνική γραμματική στο \"Συνεισφορά\"\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nΑς υποθέσουμε ότι έχουμε το ακόλουθο diff:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nΜπορούμε να χρησιμοποιήσουμε `git add -p` για να προσθέσουμε μόνο τα patches που θέλουμε, χωρίς να χρειάζεται να αλλάξουμε τον κώδικα που έχει ήδη γραφτεί.\nΕίναι χρήσιμο να διαιρούμε μια μεγάλη αλλαγή σε μικρότερα commits ή να επαναφέρουμε/κάνουμε checkout συγκεκριμένες αλλαγές.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Άλλα ενδιαφέροντα πράγματα\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Σας άρεσε;\n\n[Πείτε ευχαριστώ!](https://saythanks.io/to/RomuloOliveira)\n\n## Συνεισφορά\n\nΚάθε είδους βοήθειας θα ήταν καλοδεχούμενη. Παράδειγμα από θέματα με τα οποία μπορείτε να με βοηθήσετε:\n\n- Διορθώσεις στην γραμματική και την ορθογραφία\n- Μετάφραση σε άλλες γλώσσες\n- Βελτίωση της αναφοράς πηγών\n- Λανθασμένη ή ατελής πληροφορία\n\n## Εμπνεύσεις, πηγές, και τι να διαβάσετε περαιτέρω\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_it-IT.md",
    "content": "# Guida per i messaggi di commit\n\n[![Ringrazia!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nUna guida per capire l'importanza dei messaggi di commit e come scriverli bene.\n\nPotrebbe aiutarti a capire cos'è un commit, perché è importante scrivere buoni messaggi, buone pratiche e alcuni consigli per pianificare e (ri)scrivere una buona storia per i commit.\n\n## Cos'è un \"commit\"?\n\nIn termini semplici, un commit è una _fotografia_ dei file locali, scritti nel repository locale.\nContrariamente a cosa pensano alcune persone, [git non memorizza solo le differenze tra i file, ma la versione completa di tutti i file](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences).\nPer i file che non cambiano tra un commit e l'altro, git memorizza solo un link al file identico precedente che è già memorizzato.\n\nL'immagine qui sotto mostra come git memorizza i dati nel tempo, nella quale ogni \"Version\" è un commit:\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Perché i messaggi di commit sono importanti??\n\n- Per velocizzare e snellire la _code review_ (revisione del codice)\n- Per aiutare la comprensione di un cambiamento\n- Per spiegare i motivi del cambiamento, che non possono essere spiegati con il solo codice\n- Per aiutare i _maintainers_ futuri a capire perché e come i cambiamenti sono stati fatti, rendendo la futura individuazione e risoluzione di problemi più facile\n\nPer massimizzare questi risultati, possiamo usare alcune buone pratiche e standard descritti nella prossima sezione.\n\n## Buone pratiche\n\nQueste sono alcune (buone) pratiche collezionate dalla mia esperienza, da articoli su internet, e altre guide. Se ne avete altre (o non siete d'accordo su alcune) sentitevi liberi di aprire una Pull Request e contribuire.\n\n### Uso della forma imperativa\n\n```\n# Corretto\nUsa InventoryBackendPool per recuperare il backend dell'inventario\n```\n\n```\n# Errato\nUsato InventoryBackendPool per recuperare il backend dell'inventario\n```\n\n_Ma perché usare la forma imperativa?_\n\nUn messaggio di commit descrive cosa fa il cambiamento (a cui fa riferimento), i suoi effetti,, non cosa è stato fatto.\n\n### La prima lettera in maiuscolo\n\n```\n# Corretto\nAggiunge il metodo `use` al modello Credit\n```\n\n```\n# Errato\naggiunge il metodo `use` al modello Credit\n```\n\nIl motivo per mettere la prima lettera iniziale è per seguire le regole grammaticali che impongono la lettera maiuscola ad inizio di una frase.\n\nL'uso di questa pratica può variare da persona a persona, gruppo a gruppo, o anche da lingua a lingua. In maiuscolo o no, l'importante è usare un solo standard e seguirlo.\n\n### Tenta di comunicare cosa il cambiamento fa senza la necessità di guardare il codice\n\n```\n# Corretto\nAggiunge il metodo `use` al modello Credit\n\n```\n\n```\n# Errato\nAggiunge il metodo `use`\n```\n\n```\n# Corretto\nIncrementa il padding sinistro tra il textbox e\nlayout frame\n```\n\n```\n# Errato\nSistema il CSS\n```\n\nE' utile in tanti scenari (esempio: commit multipli, parecchi cambiamenti e ristrutturazioni) per aiutare i revisori a capire cosa il _committer_ (ovvero chi ha fatto il commit) stava pensando.\n\n### Usa il corpo del messaggio per spiegare \"perché\", \"per cosa\", \"come\" e dettagli aggiuntivi\n\n```\n# Corretto\nCorregge il nome del metodo delle classi figlie\ndi InventoryBackend\n\nClassi derivate da InventoryBackend non rispettavano la classe base.\n\nFunzionava perché il carrello chiamava l'implementazione di backend non\ncorretta.\n```\n\n```\n# Corretto\nSerializza e deserializza i crediti in JSON in\nCart\n\nConverte le istanze di Credit in dizionario per due motivi:\n\n  - Pickle si basa sul percorso del file per le classi e non vogliamo\n    rompere tutto se ci sarà una ristrutturazione\n  - Dizionari e tipi built-in sono pickleable by default\n```\n\n```\n# Corretto\nAggiunge il metodo `use` a Credit\n\nCambia da namedtuple a classe perché abbiamo bisogno di preparare un\nnuovo attributo (in_use_amount) con un nuovo valore\n```\n\nL'oggetto ed il corpo del commit sono separati da una linea vuota.\nLinee vuote aggiuntive sono considerate parte del messaggio.\n\nCaratteri come `-`, `*` e \\` sono elementi che aiutano la leggibilità.\n\n### Evita messaggi di errore generici o messaggi senza contesto\n\n```\n# Errati\nCorreggi questo\n\nCorrette delle cose\n\nOra dovrebbe funzionare\n\nCambia delle cose\n\nAggiusta il css\n```\n\n### Limita il numero di colonne\n\n[E' consigliato](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) usare al massimo 50 caratteri per l'oggetto e 72 per il corpo di ogni commit.\n\n### Mantieni la lingua in modo consistente\n\nPer i proprietari dei progetti: scegli una lingua e scrivi tutti i messaggi di commit in quella lingua. Sarebbe l'ideale se fosse la stessa lingua con cui si scrivono i commenti nel codice, la stessa predefinita per l'applicazione, ecc.\n\nPer chi collabora: scrivi i messaggi dei tuoi commit rispettando la stessa lingua della history dei commit.\n\n```\n# Corretto\nababab Aggiunge il metodo `use` al modello Credit\nefefef Usa InventoryBackendPool per recuperare il backend dell'inventario\nbebebe Correggi il nome del metodo delle classi figlio di InventoryBackend\n```\n\n```\n# Corretto (esempio in Portuguese)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Errato (mischia English e Portuguese)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### Modelli\n\nQuesto è un modello, [scritto originariamente da Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), che appare in [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n\n```\nRaccogli i cambiamenti in 50 caratteri o meno\n\nUna spiegazione più dettagliata se necessario. Vai a capo a circa 72\ncaratteri. In alcuni contesti, la prima linea è trattata come oggetto\ndel commit, ed il resto come il corpo. La linea vuota che separa\nl'oggetto dal corpo è necessaria (amenoché il corpo non sia vuoto);\nvari strumenti come `log`, `shortlog` e `rebase` possono confondersi se\nli metti insieme.\n\nSpiega il problema che questo commit risolve. Focalizzati sul perché\nstai facendo questo cambiamento al contrario di come (il codice lo\nspiega già di suo). Ci sono side-effects o altre conseguenze non\nintuitive a seguito di questo cambiamento? Questo è il posto per\nspiegarle.\n\nAltri paragrafi vengono dopo linee vuote.\n\n - Elenchi puntati vanno bene\n\n - Di solito un trattino o un asterisco son usati per il punto,\n   preceduti da un singolo spazio, con linee vuote nel mezzo, ma qui le\n   convenzioni variano\n\nSe hai un sistema di tracciamento delle issues, puoi mettere i\nriferimenti alla fine, così:\n\nRisolve: #123\nVedi anche: #456, #789\n```\n\n## Rebase vs. Merge\n\nQuesta sezione è un **TL;DR** degli eccellenti tutorial di Atlassian, [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\n**TL;DR:** Applica i commit del tuo branch, uno a uno, al branch di base, generato un nuovo albero.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge\n\n**TL;DR:** Crea un nuovo commit, chiamato (propriamente) _merge commit_, con le differenze tra i due branches.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Perché qualcuno preferisce \"rebase\" a \"merge\"?\n\nAnche io, tra i tanti, preferisco \"rebase\" a \"merge\". Le motivazioni sono, tra le altre:\n\n* Genera una history \"pulita\", senza _merge commits_ non necessari\n* _What you see is what you get_, ovvero in una revisione del codice tutti i cambiamenti arrivano da uno specifico commit, evitando cambiamenti nascosti nei _merge commits_\n* Più merges sono risolti da chi crea il commit, e ogni cambiamento in un merge è un commit con un proprio messaggio\n    * E' poco comune guardare e revisionare i commit di merge, quindi evitarli del tutto assicura che tutti i cambiamenti sono sotto il commit dove dovrebbero essere\n\n### Quando fare lo \"squash\"\n\n\"Squashing\" (o _fare squash_) è il processo di prendere diversi commit e condensarli all'interno di un singolo unico commmit.\n\nE' utile quando, ad esempio, si vuole:\n\n- Ridurre i commit con poco o nulla (correzioni di errori ortografici o simili, formattazione, cose dimenticate)\n- Unire cambiamenti sperati che hanno più senso applicati insieme\n- Riscrivere un commit che era _work in progress_\n\n### Quando evitare \"rebase\" o \"squash\"?\n\nEvita \"rebase\" e \"squash\" in commit pubblici, oppure in branch condivisi dove più persone stanno lavorando.\n\"Rebase\" e \"squash\" riscrivono la storia e sovrascrivono i commit esistenti: fare questo in commit che sono in branch condivisi (ovvero, sincronizzati con repository remoti) può causare confusione, e le persone potrebbero perdere il proprio lavoro (locale o remoto) a causa di alberature divergenti e conflitti.\n\n## Comandi git utili\n\n### rebase -i\n\nUsa per fare uno \"squash\", modificare messaggi, riscrivere/eliminare/riordinare i commit, etc.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nUsa per pulire i commit in modo semplice e senza un rebase \"complesso\".\n[Questo articolo](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) ha dei buoni esempi su come e quando fare ciò.\n\n### cherry-pick\n\nE' utile per applicare un commit fatto in un altro branch (anche per errore), senza aver bisogno di riscriverlo.\n\nEsempio:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nFacciamo il caso di avere il seguente _diff_:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nPossiamo usare `git add -p` per aggiungere solo le patch che vogliamo, senza aver bisogno di cambiare il codice che è già scritto.\nE' utile per spezzare grandi cambiamenti in piccoli commit, o per fare il reset/checkout di cambiamenti specifici.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Altre cose interessanti\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Ti piace?\n\n[Ringrazia!](https://saythanks.io/to/RomuloOliveira)\n\n## Contribuire\n\nQualsiasi tipo di aiuto è apprezzato. Un esempio di cose per cui potete aiutarmi sono:\n\n- Correzioni grammaticali e ortografiche\n- Traduzione in altre lingue\n- Miglioramento nei riferimenti alle sorgenti\n- Informazioni parziali o incomplete\n\n## Fonti d'ispirazione, sorgenti e altre letture\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_ja-JP.md",
    "content": "# コミットメッセージガイド\n\n[![ありがとう!を言う!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nコミットメッセージの重要性と良いコミットメッセージの書き方を理解するためのガイドです\n(訳注: 本日本語訳では、英語でコミットメッセージを書くことを想定します)\n\nコミットとは何か、良いコミットメッセージを書くことが重要であるのはなぜか、良いコミット履歴を計画し書く(書き直す)ための最良の方法とコツを学ぶのを手助けできるかもしれません。\n\n## 「コミット」とは何か?\n\n簡単に言うと、コミットとはあなたのローカルリポジトリーに書かれたローカルファイルの _スナップショット_ です。\n人々が考えているのとは異なり、[gitはファイルの差分のみを保持しているのではなく全てのファイルの全てのバージョンのファイルそのものを保持しています](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences)。\n1つのコミットで以前と変更がないファイルについては、gitは既に保持している以前のバージョンの同一ファイルへのリンクを保持します。\n\n下図は、gitが経時的にデータをどのように保持しているかを示しています。個々の「version」をコミットだと考えてください。\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## なぜコミットメッセージは重要なのか?\n\n- 素早く効率的にコードレビューをするため\n- 変更を理解するのを助けるため\n- コードのみでは説明できない「なぜ」を説明するため\n- 未来のメンテナーが、なぜどのように変更がされたのかを理解し、トラブル解決とデバッグを容易にできるようにするため\n\nこれらの成果を最大化するために、次のセクションで説明する良い事例と標準を使うことができます。\n\n## 良い事例\n\n私の経験やインターネット上の記事、他のガイドから集めた良い事例があります。\n他に良い事例を知っていたり、賛成できないものがある場合には、気軽にプルリクエストを送って貢献してください。\n\n### 命令形を使う\n\n```\n# 良い例\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# 悪い例\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_しかし、なぜ命令法を使うべきなのでしょうか?_\n\nコミットメッセージは、関連付けられる変更が実際に何を*する*のか、どんな効果を持つのかを説明するものであり、何がされたのかを説明するものではありません。\n\n### 最初の文字を大文字にする\n\n```\n# 良い例\nAdd `use` method to Credit model\n```\n\n```\n# 悪い例\nadd `use` method to Credit model\n```\n\n最初の文字を大文字にするのは、文の初めの文字は大文字にするという文法規則に従っています。\n\nこれは人によりチームにより言語により異なります。\n大文字にするにしてもしないにしても、重要なのは1つの標準にこだわり従うことです。\n\n### ソースコードを見ることなく変更を伝えられるようにする\n\n```\n# 良い例\nAdd `use` method to Credit model\n\n```\n\n```\n# 悪い例\nAdd `use` method\n```\n\n```\n# 良い例\nIncrease left padding between textbox and layout frame\n```\n\n```\n# 悪い例\nAdjust css\n```\n\nこのことは、多くのシナリオ(例えば、複数のコミットやいくつかの変更、リファクタリング)で、コミッターが考えていたことをレビュアーが理解するのを助けます。\n\n### 「なぜ」「何のために」「どのように」その他の詳細を説明するためにメッセージの本文を使う。\n\n```\n# 良い例\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# 良い例\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# 良い例\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nメッセージの件名と本文は空行で区切ります。それ以上の空行はメッセージの本文の一部とみなされます。\n\n`-`や`*`、\\`といった文字は読みやすくするために使えます。\n\n### 一般的なメッセージや文脈の分からないメッセージを避ける\n\n```\n# 悪い例\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### 文字数を制限する\n\n件名は50文字、本文は1行につき72文字を上限とするのが[推奨されています](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)。\n\n### 言語の一貫性を保つ\n\nプロジェクトのオーナーへ: 言語を1つ選び、全てのコミットメッセージにその言語を使ってください。\nその言語がコード中のコメントやデフォルトの翻訳ロケール(ローカライズされたプロジェクトの場合)などとも一致している方が良いです。\n\n貢献者へ: 既に存在するコミット履歴の言語を使ってあなたのコミットメッセージを書いてください。\n\n```\n# 良い例\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# 良い例 (ポルトガル語の例)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# 悪い例 (英語とポルトガル語が混在している)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### テンプレート\n\nこれは[元々Tim Popeによって書かれた](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)テンプレートで、[_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project)に収録されています。\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## リベース対マージ\n\nこのセクションは、Atlassianの優れたチュートリアルである[\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)をまとめたものです。\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### リベース\n\n**まとめ**: あなたのブランチのコミットを1つ1つベースのブランチに追加して、新しいツリーを生成します。\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### マージ\n\n**まとめ**: 適切には _マージコミット_ と呼ばれる、2つのブランチの間の差分である新しいコミットを作成します。\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### なぜマージよりリベースを好む人々がいるのか?\n\n私は特にマージよりリベースの方が良いと考えています。理由は以下の通りです。\n\n* リベースは「クリーン」な履歴を生成し、不必要なマージコミットを生成しない\n* 見たままが得られる、つまり、コードレビューで全ての変更が特定のコミットと関連付けられ、マージコミットに変更が隠れるのを防げる\n* コミッターによりマージがされるにつれて、それぞれのマージの変更は適切なメッセージを持った1つのコミットにまとまってしまう\n    * マージコミットを掘り起こしたり、レビューしたりすることは通常やるべきことではない。それを避けるために、全ての変更はそれぞれのコミットを持つようにする\n\n### スカッシュすべき時\n\n「スカッシュ」とは、一連のコミットを1つのコミットまとめるプロセスです。\n\nこれは、以下の例のような状況では一般的です。\n\n- 文脈が乏しいまたはないコミットをなくす (誤字を訂正する、フォーマットを整える、忘れていたものを含める)\n- 一緒に適用された方がより意味が明確になる分かれた変更をまとめる\n- _作業中_ のコミットを書き直す\n\n### リベースやスカッシュを避けるべき時は?\n\nリベースやスカッシュは、公開されたコミットまたは複数の人が作業している共有されたブランチでは避けてください。\nリベースやスカッシュは履歴を書き換え、既存のコミットを上書きします。\nこれを共有されたブランチで行うと混乱をまねき(つまり、コミットはリモートリポジトリーにプッシュされるし、リモートリポジトリーは他の人のブランチから生成される)、ツリーの状態が一貫性を失い競合が発生することで、他の人が自分の変更を(ローカルとリモートの両方で)失うかもしれません。\n\n## 有用なgitコマンド\n\n### rebase -i\n\nコミットをスカッシュしたり、メッセージを編集したり、コミットを書き換えたり、削除したり、並べ替えたりするために使います。\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nもっと複雑なリベースを必要とせず、簡単にコミットを綺麗にするために使います。\n[この記事](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html)はどのように、どういう時に使うべきかのとても良い例を示しています。\n\n### cherry-pick\n\n間違って別のブランチでしてしまったコミットをコードを書き直すことなく適用させるのにとても便利です。\n\n例:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\n以下のような差分があるとします。\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n`git add -p`を使うことで、必要なパッチのみ追加することができ、既に書かれたコードを変更する必要はありません。\nこれは大きな変更をより小さなコミットに分割するのに役立ちますし、特定の変更をreset/checkoutするのにも役立ちます。\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### 部分1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### 部分2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### 部分3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## その他の有用なこと\n\nhttps://whatthecommit.com/\n\n## 気に入りましたか?\n\n[ありがとう!を言う](https://saythanks.io/to/RomuloOliveira)\n\n## 貢献する\n\nどんな種類の手助けも歓迎します。例えば以下の事項で手助けしてください。\n\n- 文法と綴りの訂正\n- 他の言語への翻訳\n- 他の情報源への参照の改善\n- 間違っていたり不完全であったりする情報の訂正\n\n## インスピレーションや情報源、次に読むべきもの\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_ko-KR.md",
    "content": "# 커밋 메시지 가이드\n\n[![감사 인사하기!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\n커밋 메시지의 중요성을 이해하고 어떻게 하면 잘 작성할 수 있는지에 대해 설명하는 안내서입니다.\n\n커밋 메시지가 무엇이며, 왜 잘 작성하는 것이 중요한지 알아보고 좋은 커밋 히스토리를 유지하고 싶을 때 적용할 수 있는 최고의 접근법과 몇 가지 유용한 팁을 배워봅시다.\n\n## \"commit\" 이 무엇인가요?\n\n간단히 말해서, \"커밋 (commit)\" 은 로컬 저장소에 쓰여지는 로컬 파일들의 단편본입니다.\n일반적으로 사람들이 생각하는 것과는 다르게, [git은 파일의 변경된 내용만을 기록하지 않고 모든 파일의 버전을 모두 기록합니다](https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-Git-%EA%B8%B0%EC%B4%88#_%EC%B0%A8%EC%9D%B4%EA%B0%80_%EC%95%84%EB%8B%88%EB%9D%BC_%EC%8A%A4%EB%83%85%EC%83%B7).\n어떤 한 커밋과 다른 커밋 사이에 변경된 내용이 없다면, git은 이미 동일한 파일에 대해 링크만 생성합니다.\n\n아래의 이미지는 시간이 지남에 따라 git이 어떻게 데이터를 저장하는지 보여줍니다. 각 \"Version\" 은 커밋을 뜻합니다.\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## 왜 커밋 메시지가 중요한가요?\n\n- 코드 리뷰 시간을 단축하고 능률적으로 처리하기 위해서\n- 변경 사항을 이해하는데 도움을 주기 위해서\n- 코드만으론 설명이 어려운 \"왜 이렇게 했을까\" 를 설명하기 위해서\n- 추후 작업할 사람이 왜/어떻게 변경 사항이 만들어졌는지 이해하는데 도움을 주고 문제 해결과 디버깅을 쉽게 만들기 위해서\n\n이로부터 얻는 이로운 효과를 극대화 하기 위해, 활용할 수 있는 좋은 습관과 표준을 다음 섹션에서 설명합니다.\n\n## 좋은 습관\n\n다음 설명할 습관들은 제 개인적인 경험, 인터넷 글, 다른 가이드에서 얻어온 것입니다. 더 추가할 내용(또는 뺄 내용)이 있다면 Pull Request 를 열고 기여해주세요.\n\n### 명령조 사용하기\n\n```\n# 좋음\nInventoryBackendPool을 사용하여 재고 백엔드를 검색합니다\n---\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# 나쁨\nInventoryBackendPool을 사용하여 재고 백엔드를 검색했습니다\n---\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_근데 왜 명령조를 쓰나요?_\n\n커밋 메시지는 무엇이 변경되었는지가 아니라 실제로 그 변경 사항이 미치는 영향, 즉 변경 사항이 실질적으로 무엇을 하는지 설명합니다.\n\n### 첫 번째 문자를 대문자로 시작하기\n\n```\n# 좋음\nAdd `use` method to Credit model\n```\n\n```\n# 나쁨\nadd `use` method to Credit model\n```\n\n첫 문자를 대문자로 작성해야 하는 이유는 문장의 시작 부분에 대문자를 사용하는 문법 규칙을 따르기 위함입니다.\n\n이런 실질적인 규칙의 사용상은 사람, 팀, 언어마다 다를 수 있습니다.\n대문자로 시작하건 아니건, 중요한 것은 하나의 표준을 만들어 계속 따르는 것입니다.\n\n_역주:_ 한국어는 크게 영향이 없을 듯 합니다.\n\n### 소스코드를 보지 않고도 변경 사항이 무엇을 하는지 알 수 있도록 하기\n\n```\n# 좋음\nCredit 모델에 `use` 메소드 추가\n---\nAdd `use` method to Credit model\n```\n\n```\n# 나쁨\n`use` 메소드 추가\n---\nAdd `use` method\n```\n\n```\n# 좋음\n텍스트 상자와 레이아웃 프레임 사이 왼쪽 간격 늘림\n---\nIncrease left padding between textbox and layout frame\n```\n\n```\n# 나쁨\nCSS 조정\n---\nAdjust css\n```\n\n이는 다양한 상황 (e.g. 다중 커밋, 서로 다른 변경 사항, 리팩토링)에서 코드 리뷰를 진행하는 사람이 커밋 작성자가 무슨 생각을 하고 있었는지 쉽게 이해할 수 있도록 도움을 줄 수 있습니다.\n\n### 커밋 메시지 본문으로 \"왜\", \"무엇을 위해\", \"어떻게\" 변경했는지와 상세 내용 추가 설명하기\n\n```\n# 좋음\nInventoryBackend 자식 클래스의 메소드 이름 수정\n\nInventoryBackend를 상속받는 클래스가 기반 클래스의 인터페이스를 따르지 않음.\n\nCart가 잘못된 방식으로 백엔드 구현을 호출하고 있었기 때문에 문제가 없었음.\n---\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# 좋음\nCredits을 cart의 json에 직렬화 및 역직렬화합니다\n\nCredit 객체를 딕셔너리로 전환하는데 두 가지 이유가 있습니다:\n\n  - Pickle이 클래스의 파일 경로에 의존하기 때문에 리팩토링시 로직이 망가질 수 있습니다\n  - 딕셔너리와 빌트인 타입은 기본적으로 pickle 모듈에 의해 직렬화가 가능합니다\n---\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# 좋음\nCredit에 `use` 메소드 추가\n\n새 속성(in_use_amount)값이 필요하기 때문에 namedtuple에서 클래스로 전환했습니다\n---\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\n제목과 메시지 본문은 공백 행 하나로 분리합니다.\n이후 추가되는 공백은 메시지 본문의 일부로 취급합니다.\n\n`-`, `*`, \\` 와 같은 문자를 사용하면 가독성을 향상시킬 수 있습니다.\n\n### 맥락 없는 총칭적 메시지 사용 자제하기\n\n```\n# 나쁨\n이거 고침\n\n뭔가 고침\n\n이제 잘 작동할거임\n\n뭔가 변경함\n\nCSS 조정\n---\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### 행 글자 수 제한하기\n\n제목은 50자, 본문은 72자로 한 줄에 들어갈 수 있는 글자 수를 제한하는 것이 [권장됩니다](https://git-scm.com/book/ko/v2/%EB%B6%84%EC%82%B0-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C%EC%9D%98-Git-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EC%97%90-%EA%B8%B0%EC%97%AC%ED%95%98%EA%B8%B0#_commit_guidelines).\n\n### 일정한 언어 사용하기\n\n프로젝트 소유자인 경우: 언어 하나를 선택해서 모든 커밋을 그 언어만 사용해서 작성합니다. 궁극적으로, 이 규칙은 코드 주석과 기본 언어 파일 (다국어 지원 프로젝트의 경우) 등 모두 일치해야 합니다.\n\n기여자의 경우: 이미 커밋 히스토리에서 사용되고 있는 언어를 사용하여 커밋 메시지를 작성합니다.\n\n```\n# 좋음\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# 좋음 (한국어 예시)\nababab Credit 모델에 `use` 메소드 추가\nefefef InventoryBackendPool을 사용하여 재고 백엔드를 검색합니다\nbebebe InventoryBackend 자식 클래스의 메소드 이름 수정\n```\n\n```\n# 나쁨 (영어와 한국어 혼용)\nababab Credit 모델에 `use` 메소드 추가\nefefef Use InventoryBackendPool to retrieve inventory backend\ncdcdcd 이제 잘 작동할거임\n```\n\n### 템플릿\n\n이 템플릿은 [_Pro Git Book_](https://git-scm.com/book/ko/v2/%EB%B6%84%EC%82%B0-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C%EC%9D%98-Git-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EC%97%90-%EA%B8%B0%EC%97%AC%ED%95%98%EA%B8%B0)에 나와있는 [Tim Pope의 커밋 메시지](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)를 발췌한 것입니다.\n\n```\n여기에 최대 50자까지 변경 사항에 대해 설명하세요\n\n필요하다면 여기에 좀 더 상세하게 설명하세요. 한 줄당 대략 72자까지 맞출 수 있도록\n합니다. 일부 상황에서 첫 줄은 커밋의 제목이 되고, 그 후에 작성되는 텍스트는 본문으로\n취급됩니다. 제목과 본문을 나누는 중간에 삽입되는 공백 행은 매우 중요합니다 (본문을\n완전히 생략하지 않는 이상); `log` 와 `shortlog`, `rebase` 와 같이 다양한\n도구들은 공백에 의존하므로 두 부분을 합쳐버릴 경우 도구가 혼동할 수 있습니다.\n\n이 커밋이 해결하고자하는 문제를 설명합니다. 어떻게 했는지보단(코드가 설명할 것이기 때문),\n왜 변경 사항을 적용했는지에 대해 집중합니다. 이 변경 사항으로 인해 생기는 부수 효과가\n있거나 다른 직관적이지 않은 영향이 있을 수 있다면 여기에 설명하세요.\n\n앞으로 추가되는 문단은 공백 행 뒤에 옵니다.\n\n - 필요하다면 강조점을 써도 됩니다\n\n - 하이픈(-) 또는 별(*)이 주로 강조점으로 사용되고 이후 단일 공백(space)을 삽입합니다\n   강조점 사이에는 공백 행을 넣지만 규칙은 언제든지 바꿀 수 있습니다\n\n이슈 트래커를 사용한다면 다음과 같이 레퍼런스를 메시지 하단에 삽입하세요:\n\n이슈: #123\n같이보기: #456, #789\n---\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## 재정렬 (Rebase) vs. 병합 (Merge)\n\n이 섹션은 Atlassian의 멋진 튜토리얼 [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) 의 **길어서 안 읽음 요약 좀 (TL;DR)** 버전입니다.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### 재정렬 (Rebase)\n\n**한 줄 요약:** 기반 브랜치부터 작업 브랜치의 커밋을 하나씩 차곡차곡 이어붙여 새로운 트리를 만듭니다.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### 병합 (Merge)\n\n**한 줄 요약:** 두 브랜치의 변경 사항을 하나로 합쳐 (적절히) _병합된 커밋_ 이라 적힌 하나의 새 커밋을 만듭니다.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### 왜 사람들은 병합(merge)보다 재정렬(rebase)을 선호하나요?\n\n다음과 같은 이유 때문에 저도 병합보단 재정렬을 선호합니다:\n\n- 불필요한 병합된 커밋 없이 \"깔끔한\" 기록을 생성합니다\n- _보이는 그대로 알 수 있습니다_, 특히, 코드 리뷰에서 커밋의 변경 사항을 병합된 커밋으로 인해 감춰지지 않고 모두 볼 수 있습니다\n- 커미터(committer)가 더 직접적으로 병합에 관여하게 되고, 모든 병합 변경 사항이 적절한 커밋 메시지로 대체됩니다\n  - 병합 커밋을 리뷰하고 파고드는 일은 드묾으로, 병합을 피하면 모든 변경 사항이 각자 적절한 커밋에 연관되도록 할 수 있습니다.\n\n### 스쿼시(squash)가 필요할 때\n\n\"스쿼싱 (Squashing)\" 은 일련의 커밋을 받아서 하나의 커밋으로 간략화시키는 작업입니다.\n\n다음과 같은 상황에 유용할 수 있습니다:\n\n- 맥락이 없거나 너무 작은 커밋들 줄이기 (오타 교정, 코드 정리, 잊어버린 부분 추가)\n- 하나로 합쳤을 때 더 의미가 있는 변경 사항들\n- _현재 작업 중 (work in progress)_ 커밋 재작성\n\n### 어떨 때 재정렬(rebase), 스쿼시(squash)의 사용을 피해야 하나요?\n\n재정렬과 스쿼시 모두 공개된 커밋이나 많은 사람들이 같이 작업하는 공유된 브랜치에선 사용하지 않는 것이 좋습니다.\n재정렬과 스쿼시는 기존 커밋 기록을 다시 작성해서 덮어씌우기 때문에 위에서 언급한 공유된 브랜치(주로, remote로 푸시 된 커밋 또는 다른 브랜치로부터 받은 커밋)에 적용하게 되면 혼란을 빛게되고 분기 트리와 충돌로 인해 다른 사람들이 작업한 변경 사항을 잃을 수도 있습니다(local과 remote 모두).\n\n## 유용한 git 커맨드\n\n### rebase -i\n\n커밋을 스쿼시가 필요할때, 메시지를 변경하거나, 커밋 재작성/삭제/순서 변경이 필요할 때 사용하세요.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\n복잡한 재정렬을 할 필요 없이 쉽게 커밋을 정리할 때 사용하세요. [이 글](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html)에서 언제 어떻게 사용해야 하는지 좋은 예시로 설명하고 있습니다.\n\n### cherry-pick\n\n실수로 엉뚱한 브랜치에 커밋을 했을 때 다시 작업할 필요 없이 해당 커밋을 다른 브랜치에 적용시키고 싶을 때 사용하세요.\n\n사용 예시:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\n다음과 같은 diff가 있다고 가정해 봅시다:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n`git add -p` 를 사용하면 코드를 건드리지 않고 원하는 부분만 선택하여 스테이지에 추가할 수 있습니다.\n큰 변경 사항을 작은 커밋으로 쪼개거나 특정 변경 사항을 reset/checkout 할 때 유용하게 사용할 수 있습니다.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## 다른 흥미로운 것들\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## 맘에 들어요?\n\n[고마웡!](https://saythanks.io/to/RomuloOliveira)\n\n## 기여하기\n\n형식에 상관없이 도움을 주시면 감사하겠습니다. 다음과 같은 주제가 있습니다:\n\n- 문법 또는 철자 교정\n- 다른 언어로 번역\n- 출처 참조 개선\n- 잘못되었거나 완전하지 않은 정보 개선\n\n## 영감, 출처, 더 읽어보기\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_pl-PL.md",
    "content": "# Przewodnik po commitach\n\n[![Podziękuj twórcy!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nPrzewodnik ten, pomoże Ci zrozumieć jak ważne są wiadomości zawierane w commitach i jak je dobrze pisać.\n\nDodatkowo pomoże Ci zrozumieć czym są same commity, jak ważne jest pisanie dobrych wiadomości, jakie są najlepsze praktyki i wskazówki, do pisania (i poprawienia) naprawdę dobrej historii commitów.\n\nNa potrzeby przewodnika, będziemy używać słowa \"commit\" - zamiast polskich odpowiedników \"popełnić, angażować, oddać, zatwierdzić\"\nA na wiadomości do commitów (strasznie to brzmi po Polsku) będziemy pisać \"commit message\"\n\n## Dostępne języki\n\n- [English](README.md)\n- [Português](README_pt-BR.md)\n- [Deutsch](README_de-DE.md)\n- [Español](README_es-AR.md)\n- [Italiano](README_it-IT.md)\n- [한국어](README_ko-KR.md)\n- [Русский](README_ru-RU.md)\n- [简体中文](README_zh-CN.md)\n- [日本語](README_ja-JP.md)\n- [Українська](README_ua-UA.md)\n- [Türkçe](README_tr-TR.md)\n- [ngôn ngữ tiếng Việt](README_vi-VN.md)\n- [繁體中文](README_zh-TW.md)\n- [ελληνικά](README_gr-GR.md)\n- [Française](README_fr-FR.md)\n- [پارسی](README_fa-IR.md)\n- [Polish](README_pl-PL.md)\n\n## Co to jest \"commit\"?\n\nW krótkich słowach, commit to _snapshot_ _(migawka)_ Twoich lokalnych plików, zapisana w Twoim lokalnym repozytorium. Czyli ich dokładna kopia.\nW przeciwieństwie do tego, co myślą niektórzy, [git nie przechowuje tylko i wyłącznie róznic między plikami, przechowuje pełną warsj wszystkich plików](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences).\nJeżeli któryś plik nie zmienił się między commitami, to git \"linkuje\" go, po to, by oszczędzić miejsce.\n\nObrazek poniżej, pokazuje jak git przechowuje dane, każda wersja, to commit:\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Dlaczego commit messages są ważne?\n\n- Aby przyspieszyć i usprawnić code-reviews (analize i ocenianie kodu przez innych programistów)\n- Aby pomóc w zrozumieniu zmiany danego commita\n- Aby wyjaśnić „dlaczego” zrobiliśmy coś, ponieważ nie zawsze da się to opisać kodem\n- Aby pomóc przyszłym programistom dowiedzieć się, dlaczego i jak dokonano zmian, ułatwiając rozwiązywanie problemów i debugowanie.\n\nAby zmaksymalizować te punkty, możemy skorzystać z dobrych praktyk i standardów opisanych w następnym rozdziale.\n\n## Dobre praktyki\n\nOto niektóre praktyki zebrane z moich doświadczeń, artykułów internetowych i innych przewodników. Jeśli masz inne (lub nie zgadzasz się z niektórymi), możesz otworzyć Pull Request i wnieść swój wkład.\n\nJako że commit messages, piszemy w języku angielskim, nie będą one tłumaczone.\n\n### Użyj trybu rozkazującego\n\n```\n# Dobrze\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Żle\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_Ale po co używać trybu rozkazującego?_\n\ncommit message opisuje co zmiana aktualnie **robi**. Chodzi o zmiany w kodzie, a nie o to co zostało zrobione.\n\n### Zacznij z dużej litery\n\n```\n# Dobrze\nAdd `use` method to Credit model\n```\n\n```\n# Żle\nadd `use` method to Credit model\n```\n\nPowodem, dla którego pierwsza litera powinna być wielka, jest przestrzeganie prostej zasady gramatycznej, polegającej na używaniu wielkich liter na początku zdania.\n\nStosowanie tej praktyki może różnić się w zależności od zespołu.\n\n### Staraj się komunikować, co robi zmiana, bez konieczności patrzenia na kod źródłowy\n\n```\n# Dobrze\nAdd `use` method to Credit model\n\n```\n\n```\n# Żle\nAdd `use` method\n```\n\n```\n# Dobrze\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Żle\nAdjust css\n```\n\nPomoże Ci to w wielu przypadkach (np. wyszukiwanie danej zmiany w kilku commitach). Nie ma nic gorszego, niż szukanie odpowiedniego commita, wsród kilkunastu z opisem \"visual fixes\".\n\n### Użyj ciała wiadomości, aby wyjaśnić „dlaczego”, „po co” i „jak”\n\n```\n# Dobrze\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Dobrze\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# Dobrze\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nGłowa i ciało wiadomości są oddzielone pustą linią.\n\nZnaki takie jak `-`, `*` i \\` znacznie zwiększają czytelność.\n\n### Unikaj ogólnych wiadomości lub wiadomości bez kontekstu\n\n```\n# Źle\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### Ogranicz liczbę znaków\n\n[Zalecane jest](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) używać tylko 50 znaków w temacie (głowie) i 72 w ciele.\n\n### Zachowaj spójność językową\n\nDo właścicieli projektów: wybierz język i pisz wszystkie commit messages w tym języku. Najlepiej by był to ten sam język, w którym znajdują się nazwy zmiennych, metod czy obiektów.\n(Najczęściej jest to angielski, chyba że przyjdzie Wam pracować dla PKP)\n\nDla współtwórców: Pisz commit messages, używając tego samego języka, którego używali poprzedni commitujący.\n\n```\n# Dobrze\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Dobrze (Portuguese example)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Źle (mixes English and Portuguese)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### Szablon\n\nOto cytat, [napisany przez Tima Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), Ktory pojawia się w [_Wspaniałej książce o gicie_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\nPL:\n\n```\nPodsumuj zmiany w około 50 znakach lub mniej\n\nW razie potrzeby bardziej szczegółowy tekst objaśniający zmieść w 72 znakach.\nW niektórych commitach pierwsza linia jest traktowana jako\ntemat commitu, a reszta tekstu jako jego treść.\npusta linia oddzielająca głowę od ciała jest bardzo ważna (chyba że całkowicie pomijasz ciało);\n\nWyjaśnij problem, który rozwiązuje commit. Skoncentruj się na tym, dlaczego\nwprowadzasz tę zmianę, a nie na tym jak (kod to wyjaśni).\nCzy są jakieś błędy i problemy które tworzy ten commit?\nW ciele commitu możesz je wyjaśnić.\n\nKolejne akapity pojawiają się po pustych wierszach.\n\n - punktory też są w porządku\n\n - Zazwyczaj przed punktorem stosuje się myślnik lub gwiazdkę, poprzedzone spacją.\n\nJeśli korzystasz z narzędzia do śledzenia zgłoszeń, umieść odniesienia do nich na dole,\nNa przykład:\n\nRozwiązuje: #123\nZobacz też: #456, #789\n```\n\n## Rebase vs. Merge (Zmiana bazy vs scalanie)\n\nTa sekcja to **TL;DR** (za długie do czytania) z wspaniałego samouczka Atlassian, [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase (Zmiana bazy)\n\n**TL;DR:** Układa Twoje gałęzie (branch) commitów, jeden po drugim, na gałęzi bazowej, generując nowe drzewo.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge (Scalanie)\n\n**TL;DR:** Tworzy nowy commit, nazwany (odpowiednio) _merge commit_, z informacjami o róznicach między gałęziami.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Dlaczego niektórzy wolą zmienić bazę, zamiast scalić?\n\nJa wolę zmianę bazy. Powodami są:\n\n- Generowanie „czystej” historii, bez zbędnych commitów scalających.\n- _What you see is what you get_, (otrzymujesz to co widzisz), to znaczy wszystkie zmiany pochodzą z konkretnych i nazwanych commitów, unikamy zmian wprowadznych w merge commitach.\n- Każdy commit jest z odpowiednią wiadomością, a my nie musimy potem kopać w zmianach, które wystąpiły przy scalaniu.\n\n### Kiedy squashować\n\n\"Squashing\" to proces zbierania serii commitów i kondensowaniu ich w jednym commicie. Czyli polega na \"zgnieceniu\" kilku commitów w jeden.\n\nPrzydaje się to w kilku sytuacjach, np.:\n\n- Redukcja commitów z małą ilością zmian (formatowanie, literówki)\n- Łączenie commitów, wprowadzających zmiany, które mają sens tylko jeżeli są razem.\n- Nadpisywaniu niedokonczonych commitów.\n\n### Kiedy unikać zmiany bazy lub squasha?\n\nUnikaj zmiany bazy i squasha w publicznych zatwierdzeniach lub w gałęziach współdzielonych, nad którymi pracuje wiele osób.\nZmiana bazy i squash nadpisuję historię i istniejące commity, robienie tego na commitach, które znajdują się we współdzielonych gałęziach (tj. zatwierdzeń wypchniętych do zdalnego repozytorium lub pochodzących z innych gałęzi) może powodować zamieszanie i ludzie mogą utracić swoje zmiany (zarówno lokalnie, jak i zdalnie) z powodu rozbieżnych drzew i konfliktów.\n\n## Przydatne komendy git\n\n### rebase -i\n\nUżyj go do squashowania commitów, edytowania wiadomości, przepisywania/usuwania/zmieniania kolejności zatwierdzeń itp.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nUżyj go do łatwego czyszczenia commitówm bez potrzeby bardziej złożonej zmiany bazy.\n[Ten artykuł](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) zawiera bardzo dobre przykłady, jak i kiedy to zrobić.\n\n### cherry-pick\n\nBardzo przydatne jest zastosowanie tego commita, który wykonałeś w złej gałęzi, bez konieczności ponownego kodowania.\n\nPrzykładowo:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nPowiedzmy, że mamy następującą różnicę:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nMożemy użyć `git add -p` aby dodawać tylko te poprawki, które chcemy, bez konieczności zmiany kodu, który jest już napisany.\nPrzydatne jest podzielenie dużej zmiany na mniejsze commity, lub zresetowanie/pobranie określonych zmian.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Więcej interesujących linków\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Spodobało Ci się?\n\n[Say thanks!](https://saythanks.io/to/RomuloOliveira)\n\n## Contributing\n\nWszelka pomoc jest mile widziana. Przykładowe tematy, w których możesz mi pomóc:\n\n- Poprawki gramatyczne i ortograficzne\n- Tłumaczenie na inne języki\n- Poprawa odwoływania się do źródła\n- Nieprawidłowe lub niepełne informacje\n\n## Inspiracje, źródła i dalsze lektury\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_pt-BR.md",
    "content": "# Guia de mensagens de commit\n\n[![Diga obrigado!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nUm guia para entender a importância das mensagens de commit e como escrevê-las bem.\n\nPode te ajudar a aprender o que é um _commit_, entender porque é importante escrever boas mensagens usando boas práticas e conhecer dicas para planejar e (re)escrever o seu histórico de _commits_.\n\n**Observações:** Apesar da versão em português ter sido escrita antes da versão em inglês, a versão inglês contém alguns textos que estão mais detalhados, assim como melhor referenciamento de fontes.\n\n## O que é um \"_commit_\"?\n\nEm termos simples, o **_commit_** é uma espécie de _snapshot_ dos seus arquivos locais gravado localmente no seu repositório. Ao contrário do que se pensa, o git *não* armazena apenas as diferenças e sim a cópia completa dos arquivos.\nNo caso de arquivos que não mudaram de um _commit_ para o outro, é gravada uma referência ao arquivo gerado no último snapshot.\n\nA imagem abaixo mostra como o git armazena dados ao longo do tempo com uma versão para cada _commit_:\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Por que as mensagens são importantes?\n\n- Facilita e agiliza o _code review_\n- Ajuda no entendimento do que está acontecendo\n- Explica os porquês ocultos que não podem ser explicados somente em código\n- Facilita a solução de problemas e a depuração garantindo que futuros codificadores entendam por que e como as mudanças foram feitas\n\n## Boas práticas\n\n### Use o imperativo\n\n```\n# Good\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Bad\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\nPor que!?\n\nA mensagem de _commit_ diz o que ele **faz**, não o que foi feito.\n\n### Primeira letra em maiúsculo\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nadd `use` method to Credit model\n```\n\nÉ uma regra bem discutível e a menos importante pra mim.\nO motivo de escolher começar com letra maiúscula é simplesmente porque é assim\nque se começa uma frase em qualquer texto.\n\n### Tente comunicar o que o _commit_ faz sem que seja necessário olhar o conteúdo do _commit_\n\n```\n# Good\nAdd `use` method to Credit model\n\n```\n\n```\n# Bad\nAdd `use` method\n```\n\n```\n# Good\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Bad\nAdjust css\n```\n\n### Use o corpo da mensagem para explicar \"porquê\", \"para quê\", \"como\" e detalhes adicionais\n\n```\n# Good\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Good\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are picklable by default\n```\n\n```\n# Good\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nO título e o corpo da mensagem são separados por uma linha em branco.\nLinhas em branco adicionais são consideradas como parte do corpo.\n\nCaracteres como `-` e `*` e \\` são elementos comuns para melhorar a leitura.\n\n### Evite _commits_ com mensagens genéricas ou sem contexto algum\n\n```\n# Bad\nFix this\n\nFix stuff\n\nAgora vai\n\nChange stuff\n\nAdjust css\n```\n\n### Tente limitar o nº de colunas das mensagens\n\n[Recomenda-se](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) 50 caracteres para o título e por volta de 72 para o corpo.\n\n### Mantenha consistência de idioma\n\n```\n# Good\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Good\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Bad\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### Exemplo de formato\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## Rebase vs. Merge\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\n**TL;DR:** Aplica os _commits_ do seu _branch_, um a um, sobre o _branch_ de base, gerando uma nova árvore\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge\n\n**TL;DR:** Cria um novo _commit_, chamado de _Merge commit_, com as diferenças entre a sua árvore e a árvore de base\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Por que algumas pessoas preferem rebase?\n\nEu particularmente prefiro o rebase, alguns motivos incluem:\n\n* Deixa o histórico mais \"limpo\", sem _commits_ de _merge_ desnecessários espalhados nele\n* _What you see is what you get_, i.e., em um code review você está vendo o diff real entre o _master_ e o _branch_\n* Os conflitos mais complexos são resolvidos pelo _commiter_ e ficam dentro de um _commit_, que tem mensagem e propósito\n    * Ninguém olha o conteúdo dos _commits_ de _merge_ e nisso que mora o perigo\n\n### Quando fazer squash\n\nSquash é o processo de pegar uma série de commits e juntá-los em um commit só.\n\nÉ útil em diversas situações, como por exemplo:\n\n- Muitos _commits_ adicionais sem contexto (correção de _typos_, formatação, coisas esquecidas)\n- Mudanças que estão em _commits_ separados que fariam mais sentido parte de um só\n- _Commits WIP_\n\n### Quando evitar rebase ou squash?\n\nEvite _rebase_ e _squash_ em _commits_ públicos ou em _branches_ compartilhadas que outras pessoas possam ter trabalhado.\n_Rebase_ e _squash_ reescrevem a história sobrescrevendo commits existentes, fazendo isso em commits que existam em _branches_ compartilhadas (i.e., _commits_ enviados para repositórios remotos ou originados de outras branches) podem causar confusão e as pessoas podem perder suas modificações (tanto locais quanto remotas) por causa de divergências e conflitos.\n\n## Comandos úteis\n\n### rebase -i\n\nUsado para fazer _squash_, editar mensagens, editar/apagar/reordenar _commits_, etc.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nÚtil para facilitar a limpeza sem perder tempo/trabalho com um rebase.\n[Exemplos](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html).\n\n### cherry-pick\n\nBastante útil quando você precisa pegar aquele _commit_ que você fez no branch errado sem precisar reescrever novamente.\n\nExemplo:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nExemplo de diff:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nPodemos usar `git add -p` para adicionar apenas os patches que queremos, sem a necessidade de alterar o código que já está escrito.\nÉ útil para dividir uma grande mudança em commits menores ou para fazer reset/checkout de mudanças específicas.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Links interessantes\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Gostou?\n\n[Mandar um obrigado!](https://saythanks.io/to/RomuloOliveira)\n\n## Contribuindo\n\nTodo tipo de ajuda é bem-vinda. Exemplos de tópicos em que você pode contribuir:\n\n- Correcões gramaticais e ortográficas\n- Tradução para novas línguas\n- Melhoras nas referências e fontes\n\n## Inspirações, fontes e leitura adicional\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_ru-RU.md",
    "content": "# Руководство по написанию коммитов\n\n[![Скажи спасибо!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nЭто руководство поможет понять, почему важно писать хорошие сообщения коммитов и как это делать.\n\nТакже это руководство может помочь прояснить, что такое коммит, почему важно писать хорошие сообщения, узнать лучшие практики и советы по созданию и (пере)написанию истории коммитов.\n\n## Что такое \"коммит\"?\n\nПростыми словами, коммит — это _снимок_ ваших локальных файлов, записанный в локальный репозиторий.\nВопреки распространённому мнению, [git хранит не только изменения между файлами, но и в целом полную версию всех файлов](https://git-scm.com/book/ru/v2/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git).\nДля файлов, которые не менялись от одного коммита к другому, git хранит только ссылку на предыдущий идентичный файл, который уже был сохранен.\n\nНа изображении ниже показано, как git хранит данные с течением времени. Каждая \"версия\" является коммитом:\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Почему сообщения коммитов важны?\n\n- Чтобы ускорить и упростить проверку кода\n- Чтобы помочь в понимании изменений\n- Чтобы объяснить вопросы, которые не могут быть описаны только кодом\n- Чтобы помочь будущим разработчикам разобраться, почему и как были сделаны изменения, облегчив поиск и устранение ошибок\n\nЧтобы добиться максимального результата, мы можем использовать некоторые полезные практики и стандарты, описанные в следующем разделе.\n\n## Полезные практики\n\nЭто некоторые практики, собранные из моего опыта, статей и других руководств. Если у вас есть предложение (или вы не согласны с некоторым) не стесняйтесь открыть пулреквест и внести свой вклад.\n\n### Используйте повелительное наклонение\n\n```\n# Хорошо\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Плохо\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_Но зачем использовать повелительное наклонение?_\n\nСообщение коммита описывает, что конкретно **делают** зафиксированные изменения, его конечный результат, а не что было сделано.\n\n### Начинайте сообщение коммита с заглавной буквы\n\n```\n# Хорошо\nAdd `use` method to Credit model\n```\n\n```\n# Плохо\nadd `use` method to Credit model\n```\n\nСмысл этой рекомендации простой: в соответствии с правилами грамматики первое слово предложения начинается с заглавной буквы.\n\nИспользование этой практики может варьироваться от человека к человеку, от команды к команде или даже от языка к языку.\nЗаглавная или нет, важно придерживаться единого стандарта и следовать ему.\n\n### Старайтесь описывать изменения так, чтобы указывать на исходный код\n\n```\n# Хорошо\nAdd `use` method to Credit model\n\n```\n\n```\n# Плохо\nAdd `use` method\n```\n\n```\n# Хорошо\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Плохо\nAdjust css\n```\n\nЭто полезно во многих случаях (пр. несколько коммитов, различные изменения и рефакторинг), чтобы помочь проверяющим понять о чём думал автор коммита.\n\n### Используйте тело сообщения для объяснения \"почему\", \"для чего\", \"как\" и дополнительные детали\n\n```\n# Хорошо\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Хорошо\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# Хорошо\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nТема и описание сообщения разделены пустой строкой.\n\nДополнительные пустые строки считаются частью описания.\n\nТакие символы как `-`, `*` и ` улучшают общую читаемость.\n\n### Избегайте общих сообщений или сообщений без какого-либо контекста\n\n```\n# Плохо\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### Ограничьте длину строк\n\n[Рекомендуется](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) использовать максимум 50 символов для темы и 72 символа для описания.\n\n### Сохраняйте согласованность языка\n\nДля владельцев проектов: Выберите язык и пишите все сообщения коммитов используя этот язык. В идеале, он должен совпадать с комментариями в коде, стандартным переводом (для переведенных проектов), и т.д.\n\nДля участников проекта: Пишите сообщения коммитов на том языке, который используется в истории коммитов.\n\n```\n# Хорошо\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Хорошо (Португальский пример)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Плохо (смесь Английского и Португальского)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### Шаблон\n\nЭтот шаблон, [который изначально описан Тимом Поупом (Tim Pope)](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), также упоминается в [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## Перебазировка vs. Слияние\n\nЭтот раздел является кратким пересказом превосходного руководства [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) от Atlassian.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Перебазирование\n\n**Кратко:** Применяет ваши коммиты в ветке, один за другим, к базовой ветки (например, master), генерируя новое дерево.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Слияние\n\n**Кратко:** Создаёт новый коммит, называемый (соответственно) _коммит слияния_ (_merge commit_), с различиями между двумя ветками.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Почему некоторые люди предпочитают перебазирование вместо слияния?\n\nЯ, в частности, предпочитаю перебазирование вместо слияния. По следующим причинам:\n\n* Это создает \"чистую\" историю, без ненужных коммитов-слияний\n* _Что видишь, то и имеешь,_, т.е. при ревью кода все изменения идут от определенного коммита, без скрытых изменений в коммитах при слиянии\n* Больше слияний решаются автором коммита, поэтому каждое слитое изменение находится в коммите с соответствующим сообщением\n    * Обычно не смотрят коммиты-слияния, так что таким образом все изменения зафиксированы в коммите, к которому они непосредственно относятся\n\n### Когда нужно делать объединение коммитов?\n\nОбъединение (Squashing) — это процесс объединения множества коммитов в один-единственный коммит.\n\nЭто может пригодиться в ряде ситуаций, например:\n\n- Уменьшение количества коммитов с небольшим контекстом или без контекста (исправление опечаток, форматирование, дополнения)\n- Объединение независимых изменений, которые лучше всего применять вместе\n- Переписывание коммитов в стадии _WIP_ (черновика)\n\n### Когда избегать перебазирования или сжатия?\n\nИзбегайте этого в публичных коммитах или в общих ветках, в которых работают несколько человек.\nПеребазирование и слияние также перезаписывает историю коммитов и существующие коммиты, делая это с коммитами, которые находятся в разных ветках (например, коммиты, отправленные в удаленный репозиторий или коммиты из других веток) могут вызвать путаницу и поэтому можно потерять изменения (как локальные, так и удаленные) из-за различающегося дерева и конфликтов.\n\n## Полезные команды git\n\n### rebase -i\n\nИспользуйте их, чтобы объединить коммиты, изменить сообщения, переписать/удалить/изменить порядок коммитов и т.д.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nИспользуйте эту команду, чтобы привести в порядок коммиты, не прибегая к перебазированию.\nВ [этой статье](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) есть хорошие примеры того, как и когда это делать.\n\n\n### cherry-pick\n\nЭта команда может быть очень полезной для применения коммита, который был сделан в неверной ветке, чтобы не писать код заново.\n\nПример:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nДавайте представим, что у нас есть следующий список различий:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Участие в проекте\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nМы можем выполнить `git add -p` чтобы добавить только те патчи, которые нам нужны, без необходимости изменять уже существующий код.\nЭто очень полезно при разделении больших изменений в маленькие коммиты или для отмены/проверки конкретных изменений.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### часть 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### часть 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### часть 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Кое-что интересное\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Нравится это руководство?\n\n[Скажи спасибо!](https://saythanks.io/to/RomuloOliveira)\n\n## Помощь\n\nЛюбая помощь приветствуется. Вот, например, что вы можете сделать:\n\n- Исправить ошибки в грамматике и правописании\n- Перевод на другие языки\n- Улучшение списка связанных источников\n- Изменить неверную или неполную информацию\n\n## Источники вдохновения и список для дальнейшего чтения\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_tr-TR.md",
    "content": "# Commit mesajları kılavuzu\n\n[![Say Thanks!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nCommit mesajlarının önemini ve onların nasıl daha iyi yazılacağını anlatan bu kılavuz; commitin ne olduğunu, iyi commit mesajları yazmanın neden önemli olduğunu, iyi bir commit geçmişi planlamaya ve (yeniden) yazmaya yönelik bir takım örnekleri ve ipuçlarını anlamanıza yardımcı olabilir.\n\n## \"commit\" nedir?\n\nBasitçe, commit yerel deponuza yazılan dosyalarınızın anlık görüntüsüdür.\nBazı insanların düşündüğünün aksine, [git sadece dosyalar arasındaki farkı saklamaz, tüm dosyaların tam sürümünü saklar](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences).\nİki commit arasında değişmemiş dosyalar için, git zaten saklanan önceki özdeş dosyaya yalnızca bir bağlantı oluşturur.\n\nAşağıdaki resimde git'in, her \"versiyon\"da commit edildiği durumda, verileri nasıl sakladığı gösterilmektedir:\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Commit mesajları neden önemlidir?\n\n- Kod incelemelerini hızlandırır ve kolaylaştırır\n- Değişimin anlaşılmasına yardımcı olur\n- Sadece kodla açıklanamayan \"neden\"leri açıklar\n- Sonraki yazılımcıların, değişikliklerin neden ve nasıl yapıldığını anlamalarına yardımcı olur, sorun giderme ve hata ayıklamayı kolaylaştırır\n\nBu faydaları en üst düzeye çıkarmak için, bir sonraki bölümde açıklanan bazı faydalı uygulamaları ve standartları kullanabiliriz.\n\n## Faydalı uygulamalar\n\nBunlar; deneyimlerimden, internetteki makalelerden ve diğer kılavuzlardan toplanan bazı uygulamalardır. Eklemek istedikleriniz varsa (veya bazılarına katılmıyorsanız) bir Pull Request açmaktan ve katkıda bulunmaktan çekinmeyin.\n\n### Emir kipi kullanın\n\n```\n# Good\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Bad\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_Ama neden emir kipi?_\n\nBir commit mesajı belirtilen değişikliğin gerçekte ne yaptığını ve etkilerini açıklar, ne yapıldığını değil.\n\n### Büyük harfle başlayın\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nadd `use` method to Credit model\n```\n\nBüyük harfle başlanmasının nedeni, dil bilgisi kurallarından biri olan cümlelerin başında büyük harf kullanılması kuralına uymaktır.\n\nBu uygulamanın kullanımı kişiden kişiye, takımdan takıma, hatta dilden dile değişebilir. Büyük harfle veya değil, önemli olan nokta tek bir standarda sadık kalmak ve onu takip etmektir.\n\n### Kaynak koda bakmak zorunda kalmadan değişikliğin ne yaptığını bildirmeye çalışın\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nAdd `use` method\n```\n\n```\n# Good\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Bad\nAdjust css\n```\n\nBu uygulama mesajı okuyanların, commit edenin ne düşündüğünü anlamalarına yardımcı olmak adına birçok senaryoda (_örneğin çoklu commit'ler, çeşitli değişiklikler ve yeniden düzenlemeler_) faydalıdır.\n\n### \"Neden?\", \"Ne amaçla?\", \"Nasıl?\"ı ve ek detayları açıklamak için mesaj gövdesini kullanın\n\n```\n# Good\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Good\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# Good\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nMesajların konusu ve gövdesi boş bir satırla ayrılır.\nEk boş satırlar mesaj gövdesinin bir parçası olarak kabul edilir.\n\n`-`, `*` ve  \\` gibi karakterler okunabilirliği artıran öğelerdir.\n\n### Herhangi bir bağlamı olmayan mesajlardan ve genel mesajlardan kaçının\n\n```\n# Bad\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### Karakter sayısını sınırlayın\n\nKonu için en fazla 50 karakter ve gövde için 72 karakter kullanılması [önerilir](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines).\n\n### Dil tutarlılığını koruyun\n\nProje sahipleri için: Bir dil seçin ve tüm commit mesajlarını bu dili kullanarak yazın. İdeal olarak, kod yorumları, varsayılan yerel çeviri ayarları (yerelleştirilmiş projeler için) vb. ile eşleşmelidir.\n\nKatkıda bulunanlar için: Var olan commit geçmişiyle aynı dili kullanarak commit mesajı yazın.\n\n```\n# Good\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Good (Portekizce örneği)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Bad (İngilizce ve Portekizce karışık)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### Şablon\n\nBu şablonun orjinali [Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) tarafından yazıldı; [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## Rebase vs. Merge\n\nBu kısım Atlassian'ın [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) başlıklı harika eğitiminin bir TL;DR'si(Too long; didn't read/Çok uzundu; okumadım), özetidir.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\n**TL;DR:** Branch commitlerinizi ana branchin devamına yeni bir ağaç oluşturacak şekilde tek tek uygular.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Birleştirme\n\n**TL;DR:** _merge commit_ olarak adlandırılan ve iki branch arasında farklardan oluşan yeni bir commit oluşturur.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Neden bazı kişiler merge yerine rebase tercih eder?\n\nBen şahsen merge yerine rebase'i tercih ediyorum. Sebepleri ise şu şekilde:\n\n* Gereksiz bir _merge commit_'i olmadan \"temiz\" bir geçmiş oluşturur.\n* _Gördüğünüz şey, elde ettiğiniz şeydir_, yani bir kod incelemesinde, merge commit'inin ardında gizlenen değişikliklerden kaçınarak, tüm değişiklikler belirli ve başlıklı bir commit'ten gelir.\n* Daha fazla merge, commit eden tarafından çözümlenir ve her bir merge işlemi uygun bir mesajla bir commit içindedir.\n    * Bir birleştirme commit'ini detaylı incelemek ve gözden geçirmek olağandışı bir durumdur, bu nedenle bunlardan kaçınmak tüm değişikliklerin ait oldukları bir commit'e sahip olmasını garanti eder.\n\n### Ne zaman squash (ezme/birleştirme) yapılmalı?\n\n\"Squashing\" bir dizi commit'i alıp tek bir commit'e yoğunlaştırma işlemidir.\n\nBazı durumlarda faydalıdır, örneğin:\n\n- Çok az ya da hiç bağlam olmadan commit'i azaltmak (yazım hatası düzeltmeleri, biçimlendirme, unutulmuş şeyler)\n- Birlikte uygulandığında daha anlamlı hale gelen ayrı değişiklikleri birleştirme\n- Üzerinde çalışılmaya devam edilen commit'leri yeniden yazma\n\n### Rebase veya squash'dan ne zaman kaçınmalı?\n\n_Public commit_'te veya birden fazla kişinin çalıştığı, paylaşılan branchlerde rebase ve squash'den kaçının. Rebase ve squash geçmişi yeniden yazar ve var olan commit'lerin üzerine yazar, bunu paylaşılan branchlerde yapmak karşıklığa (örn., uzaktaki bir depoya push edilen/gönderilen commitler veya diğer branch/dallardan gelen commitler) neden olabilir ve insanlar farklı branchler ve çakışmalar nedeniyle değişikliklerini (hem yerel hem de uzaktan) kaybedebilir.\n\n## Kullanışlı git komutları\n\n### rebase -i\n\nCommitleri squash/sıkıştırmak, mesajları düzenlemek, commitleri yeniden yazmak/silmek/sıralarını düzenlemek vb. için kullanın.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nCommitleri kolayca ve daha karmaşık bir rebase'e ihtiyaç duymadan temizlemek için kullanın.\n[Bu yazıda](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html), nasıl ve ne zaman yapılacağına dair güzel örnekler mevcut.\n\n### cherry-pick\n\nYanlış bir branch üzerinde yaptığınız commit'i tekrar kodlamaya gerek kalmadan uygulamak gerektiğinde çok kullanışlıdır.\n\nÖrnek:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nDiyelim ki aşağıdaki gibi bir _diff_'imiz var:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Credit modeline `use` metodu ekle\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nZaten yazılmış olan kodu değiştirmeye gerek kalmadan, yalnızca istediğimiz yamaları eklemek için `git add-p`'yi kullanabiliriz.\nBüyük bir değişikliği daha küçük commitlere bölmek veya belirli değişiklikleri sıfırlamak/kontrol etmek açısından yararlıdır.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Credit modeline `use` metodu ekle\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Diğer ilginç bağlantılar\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Beğendin mi?\n\n[Teşekkür Et!](https://saythanks.io/to/RomuloOliveira)\n\n## Katkıda bulunma\n\nHer türlü yardım makbule geçecektir. Bana yardımcı olabileceğiniz örnek konular:\n\n- Dil bilgisi ve imlâ düzeltmeleri\n- Diğer dillere çeviri\n- Kaynak/referans iyileştirme\n- Yanlış veya eksik bilgiyi düzeltme\n\n## İlham alınanlar, kaynaklar ve ileri okuma\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_ua-UA.md",
    "content": "# Керівництво по написанню комітів\n\n[![Скажи дякую!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nКерівництво для розуміння важливості повідомлень комітів і того, як правильно їх писати.\n\nЦе може допомогти вам зрозуміти, що таке коміт, чому важливо писати хороші повідомлення, кращі практики і деякі поради по плануванню і (пере)написанню хорошої історії комітів.\n\n## Що таке \"коміт\"?\n\nПростими словами, коміт - це _знімок(зліпок)_ ваших локальних файлів, записаний в локальний репозиторій.\nНасправді, [git зберігає не тільки зміни між файлами, але і в цілому повну версію всіх файлів](https://git-scm.com/book/ru/v2/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git).\nДля файлів, які не змінювались від одного коміта до іншого, git зберігає тільки посилання на попередній ідентичний файл, котрий вже був збережений.\n\nЗображення нижче показує, як git зберігає дані з плином часу, тоді як кожна \"версія\" являється комітом:\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Чому повідомлення комітів важливі?\n\n- Щоб прискорити і спростити перевірку коду\n- Щоб допомогти в розумінні змін\n- Щоб прояснити речі, які не можуть бути описані тільки кодом\n- Щоб допомогти майбутнім розробникам розібратись, чому і як були зроблені зміни, полегшивши пошук і ліквідацію помилок\n\nЩоб досягнути максимального результату, ми можем використовувати деякі корисні практики та стандарти, описанні в наступному розділі.\n\n## Корисні практики\n\nЦе деякі практики, зібрані з мого досвіду, статей та решти керівництв. Якщо у вас є пропозиція (або ви не згідні з деякими речами) не соромтесь відкрити пулреквест і внести свій внесок.\n\n### Використовуйте наказовий спосіб\n\n```\n# Добре\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Погано\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_Але навіщо використовувати наказовий спосіб?_\n\nПовідомлення коміту описує, що конкретно **роблять** зафіксовані зміни, його кінцевий результат, а не що було зроблено.\n\n### Починайте повідомлення коміту з Великої букви\n\n```\n# Добре\nAdd `use` method to Credit model\n```\n\n```\n# Погано\nadd `use` method to Credit model\n```\n\nЗміст цієї рекомендації простий: відповідно до правил граматики перше слово у реченні починається з великої букви.\n\nВикористання цієї практики може варіюватись від людини до людини, від команди до команди або рідше від мови до мови.\nВелика чи ні, важливо дотримуватись єдиного стандарту і слідувати йому.\n\n### Старайтесь описувати зміни так, щоб вказувати на сирцевий код, тобто місце де сталася зміна\n\n```\n# Добре\nAdd `use` method to Credit model\n\n```\n\n```\n# Погано\nAdd `use` method\n```\n\n```\n# Добре\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Погано\nAdjust css\n```\n\nЦе корисно в багатьох випадках (пр. декілька комітів, різноманітні зміни і рефакторинг), щоб допомогти рев'юверам зрозуміти про що думав автор коміту, та що мав на увазі, коли писав повідомлення.\n\n### Використовуйте тіло повідомлення для пояснення \"чому\", \"для чого\", \"як\" та додаткові деталі\n\n```\n# Добре\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Добре\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# Добре\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nТема і опис повідомлення розділені пустою стрічкою.\n\nДодаткові пусті стрічки рахуються частиною опису.\n\nТакі символи як `-`, `*` і ` покращують загальну читаємість.\n\n### Запобігайте появі загальних повідомлень або повідомлень без будь-якого контексту\n\n```\n# Погано\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### Обмежте довжину стрічок\n\n[Рекомендуеться](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) використовувати максимум 50 символів для теми і 72 символа для опису.\n\n### Зберігайте узгодженість мовлення\n\nДля власників проектів: Оберіть мову та пишіть всі повідомлення комітів використовуючи цю мову. В ідеалі, він має співпадати з коментарями в коді, стандартним перекладом (для перекладених проектів), і т.д.\n\nДля учасників проекту: Пишіть повідомлення комітів тією мовою, котра використовується в історії комітів.\n\n```\n# Добре\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Добре (Португальський приклад)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Погано (суміш Англійської та Португальської)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### Шаблон\n\nЦей шаблон, [ був з самого початку описаний Тімом Поупом (Tim Pope)](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), також згадується в [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## Перебазування (Rebase) vs. Злиття (Merging)\n\nЦей розділ є коротким переказом чудового керівництва [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) від Atlassian.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Перебазування(Rebase)\n\n**Коротко:** Застосовує ваші коміти в гілці, один за другим, до базової гілки (наприклад, master), генеруючи нове дерево.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Злиття (Merging)\n\n**Коротко:** Створює новий коміт, названий (відповідним чином) _коміт злиття_ (_merge commit_), з різницею між двома гілками.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Чому деякі люди надають перевагу перебазуванню замість злиття?\n\nЯ, особисто, надаю перевагу перебазуванню замість злиття. З наступних причин:\n\n* Це створює \"чисту\" історію, без непотрібних комітів-злиттів\n* _Що бачиш, те і маєш,_, т.е. при рев'ю коду всі зміни йдуть від певного коміту, без прихованих змін в комітах при злитті\n* Всі конфлікти при злитті вирішуються автором коміту, тому кожна злита зміна знаходиться в коміті з відповідним повідомленням\n    * Зазвичай не дивляться на коміти-злиття, так що таким образом всі зміни зафіксовані в коміті, до якого вони безпосередньо відносяться\n\n### Коли необхідно робити об'єднання комітів?\n\nОб'єднання (Squashing) — це процес об'єднання декількох комітів в один-єдиний коміт.\n\nЦе може знадобитися в ряді ситуацій, наприклад:\n\n- Зменшення кількості комітів з невеликим контекстом або без контексту (виправлення опечатків, форматування, доповнення)\n- Об'єднання незалежних змін, котрі краще за все застосовувати разом\n- Переписування комітів в стадії _WIP_ (чорновика)\n\n### Коли уникати перебазування або об'єднання (squash)?\n\nУникайте цього в публічних комітах або в загальних гілках, в яких працюють кілька людей.\nПеребазування і об'єднання також перезаписує історію комітів і існуючі коміти, роблячи це з комітів, які знаходяться в різних гілках (наприклад, комітів, що відправлені в віддалений репозиторій або комітів з інших гілок) що може викликати плутанину і тому можна втратити зміни (як локальні, так і віддалені) через різницю дерева і конфліктів.\n\n## Корисні команди git\n\n### rebase -i\n\nВикористовуйте їх, щоб об'єднати коміти, змінити повідомлення, переписати / видалити / змінити порядок комітів і т.д.\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nВикористовуйте цю команду, щоб привести в порядок коміти, не використовуючи перебазування.\nВ [цій статті](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) є гарні приклади того, як і коли це робити.\n\n\n### cherry-pick\n\nЦя команда може бути дуже корисною для зміни коміту, який був зроблений в неправильній гілці, щоб не писати код заново.\n\nПриклад:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nДавайте уявимо, що у нас є наступний список відмінностей:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Участь у проекті\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nМи можемо виконати `git add -p` щоб додати тільки ті патчі, які нам потрібні, без необхідності змінювати вже існуючий код.\nЦе дуже корисно при розділенні великих змін в маленькі коміти або для відміни/перевірки конкретних змін.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### частина 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### частина 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### частина 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Дещо цікаве\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Подобається це керівництво?\n\n[Скажи Дякую!](https://saythanks.io/to/RomuloOliveira)\n\n## Допомога\n\nЛюба допомога вітається. Ось, наприклад, Що ви можете зробити:\n\n- Виправити помилки в граматиці та правописі\n- Переклад на інші мови\n- Покращення списку пов'язаних джерел\n- Змінити неправильну або неповну інформацію\n\n## Джерела натхнення та список для подальшого читання\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_vi-VN.md",
    "content": "# Hướng dẫn viết commit\n\n[![Say Thanks!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\nĐây là một bài hướng dấn giúp hiểu được tầm quan trọng của các commit messages và biết cách làm sao để viết chúng cho thật tốt.\n\nỞ bài hướng dẫn này, bạn sẽ hiểu commit là gì, tầm quan trọng của việc viết message tốt cho commit của bạn, những cách thực hành tốt nhất, một số mẹo để lên kế hoạch viết commit và viết/viết lại một lịch sử commit cho tốt.\n\n## \"Commit\" là gì?\n\nHãy nghĩ đơn giản, một commit là một _ảnh_ (hoặc bản sao) của những file cục bộ trên kho lưu trữ cá nhân của bạn.\nKhác với suy nghĩ của nhiều người, [git không chỉ lưu những khác biệt giữa các phiên bản của file mà lưu trữ toàn bộ các phiên bản](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences).\nĐối với những file không có sự thay đổi so với phiên commit trước, thay vì lưu một file mới, việc git làm đơn giản sẽ là lưu trữ một link trỏ tới file đã được lưu trước đó.\n\nHình sau mô tả cách mà git lưu trữ dữ liệu theo thời gian, trong đó mỗi một \"phiên bản\" là một commit:\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## Tại sao những commit message lại quan trọng?\n\n- Làm cho việc đánh giá code trở nên nhanh chóng và hiệu quả hơn.  \n- Để giúp người khác hiểu về những sự thay đổi.  \n- Để giải thích lý do \"tại sao\" chỉ giải thích bằng code là chưa đủ mà còn phải thêm bằng message.  \n- Để sau này, những người bảo trì project có thể tìm ra lý do tại sao lại có những thay đổi và chúng được thực hiện như thế nào, điều này làm cho việc khắc phục sự cố cũng như gở lỗi trở nên dễ dàng hơn.\n\nĐể hiểu thêm về những điểm trên, chúng ta có thể sử dụng các good practices(tạm hiểu là những cách làm tốt, được rút ra từ kinh nghiệm, Tiếng Việt không có từ ngữ tương ứng nên người dịch sẽ giữ nguyên từ này) và những tiêu chuẩn được mô tả bên dưới.\n\n## Good Practices\n\nĐây là những cách làm tốt mà tác giả thu thập từ kinh nghiệp thực tế, bài báo trên internet cũng như như một số bài hướng dẫn khác. Nếu thấy có sai sót hoặc muốn thêm ví dụ vui lòng mở một Pull Request và tham gia đóng góp.  \n\n### Dùng thể mệnh lệnh(imperative form)\n\n```\n# Good\nUse InventoryBackendPool to retrieve inventory backend\n```\n\n```\n# Bad\nUsed InventoryBackendPool to retrieve inventory backend\n```\n\n_Nhưng tại sao phải dùng thể mệnh lệnh?_\n\nMột commit message mô tả các thay đổi này thực sự **làm** những gì, tác động của nó, chứ không phải nói về những việc đã được thực hiện.\n\n### Viết hoa chữ cái đầu\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nadd `use` method to Credit model\n```\n\nLý do là chúng ta phải tuân theo luật ngữ pháp về việc viết hoa chữ cái đầu tiên của câu.\n\nViệc sử dụng practice này có thể khác nhau tùy từng người, từng team, hoặc giữa các ngôn ngữ.\nViết hoa hay không thì điều quan trọng là phải tuân theo một tiêu chuẩn duy nhất, không được đan xen tùy lúc.  \n\n### Cố gắng truyền đạt những gì thay đổi gây ra mà không cần phải xem mã nguồn.\n\n```\n# Good\nAdd `use` method to Credit model\n\n```\n\n```\n# Bad\nAdd `use` method\n```\n\n```\n# Good\nIncrease left padding between textbox and layout frame\n```\n\n```\n# Bad\nAdjust css\n```\n\nViệc này rất hữu ích trong nhiều tình huống (Ví dụ: Nhiều commit, có một vài thay đổi và cấu trúc lại) để giúp những người đánh giá có thể hiểu người commit đã nghĩ gì.\n\n### Sử dụng phần thân của message để giải thích \"tại sao\", \"để làm gì\", \"như thế nào\" và một số chi tiết bổ sung\n\n```\n# Good\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Good\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# Good\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\nPhần tiêu đề và phần thân của message phải được ngăn ra bởi một dòng trống. Những dòng trống phía dưới dòng trống đó(nếu có) sẽ được xem như thuộc phần thân của message.  \n\nNhững kí tự như `-`, `*` và \\` là những yếu tố message dễ đọc hơn.\n\n### Tránh những message có nội dung chung chung hoặc những message mà không hề có bối cảnh  \n\n```\n# Bad\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### Giới hạn số lượng chữ cái.\n\n[Bạn nên](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) sử dụng tối đa 50 ký tự cho phần chủ đề và 72 ký tự mỗi dòng cho phần thân message.  \n\n### Có sự nhất quán trong việc sử dụng ngôn ngữ\n\nĐối với chủ dự dán: Chọn một ngôn ngữ và viết mọi commit message bằng ngôn ngữ đó. Choose a language and write all commit messages using that language. Lý tưởng nhất là ngôn ngữ dùng cho commit message phải khớp với các code comment, ngôn ngữ dịch mặc định (đối với những dự án được bản địa hóa), v.v...\n\nĐối với những người tham gia đóng góp: Viết commit message bằng ngôn ngữ tương tự ngôn ngữ của các commit message trước đó.  \n\n```\n# Good\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Good (Portuguese example)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Bad (mixes English and Portuguese)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### Commit message mẫu\n\nĐây là mẫu commit message, [được viết ban đầu bởi Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) và xuất hiện trong cuốn [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n\n```\nSummarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\nViệc dịch nội dung này theo người dịch là không cần thiết, tuy nhiên để những bạn mới tập làm quen hiểu rõ hơn thì người dịch sẽ cung cấp thêm bản dịch của mẫu trên:\n\n```\nTóm tắt những thay đổi trong 50 ký tự hoặc ít hơn\n\nThêm những giải thích nếu cần thiết, khoảng 72 chữ một dòng. Trong một \nsố bối cảnh, dòng đầu tiên được xem là tiêu đề và phần còn lại chính là\nnội dung. Dòng trống phân tách giữa tiêu đề và phần thân rất quan trọng\n, trừ khi bạn không viết phần thân; nhiều công cụ như `log`, `shortlog`\nvà `rebase` có thể bối rối nếu bạn không để dòng trống ở giữa.\n\nGiải thích vấn đề mà phiên commit này giải quyết. Tập trung vào lý do \ntại sao lại thay đổi thay vì giải thích cách thức thay đổi - How (code \ncủa ta sẽ giải thích how). Có tác dụng phụ hay hậu quả (có chứng cứ) \ncủa những những thay đổi này không?  Đây là nơi chúng ta giải thích \nchúng.\n\nCác đoạn tiếp theo cũng sẽ đúng sau một dòng trống.\n\n - Các bullet point được chấp nhận.\n\n - Các bullet point thường thấy là các dấu gạch đầu dòng và các dấu hoa\n  thị. Trước các bullet point là một khoảng trắng, giữa các ý là một \n  dòng trống. Tuy nhiên chỗ này sẽ có một số quy ước khác nhau.\n\nNếu bạn sử dụng trình theo dõi vấn đề (issue tracker), Đặt tham chiếu \nđến chúng ở dưới cùng, như thế này:\n\nGiải quyết: #123\nXem thêm: #456, #789\n```\n\n## Rebase vs. Merge\n\nChương này là một [**TL;DR**](https://en.wikipedia.org/wiki/Wikipedia:Too_long;_didn%27t_read)(bản tóm tắt ngắn gọn) của bài hướng dẫn tuyệt vời của Atlassian, [\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\nỞ đây người dịch sẽ không dịch từ rebase và merge sang Tiếng Việt để tránh gây bối rối cũng như tiện cho người đọc tìm hiểu keyword sau này.\n\n### Rebase\n\n**TL;DR:** Gắn các commit trên nhánh của bạn, từng cái một, lên branch gốc, tạo ra một cây mới.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge\n\n**TL;DR:** tạo một commit mới, gọi là(một cách thích hợp) một _merge commit_, chứa tất cả những sự khác nhau giữa 2 branch.\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### Tại sao một số người thích rebase hơn merge?\n\nTác giả đặc biệt thích rebase hơn merge. Có những lý do sau:\n\n* Nó sinh ra một lịch sử \"sạch\", không có những merge commit không cần thiết.  \n* _Bạn thấy gì bạn sẽ nhận cái đó_, i.e., trong lúc đánh giá code,ta sẽ thấy được mọi thay đổi từ các commit cụ thể và có tên, tránh những thay đổi ẩn nằm trong các merge commits.  \n* Nhiều merges được giải quyết bởi người commit hơn, và mỗi một sự thay đổi do merge gây ra sẽ nằm commit với message phù hợp.  \n * Thông thường ta sẽ không khai thác cũng như đánh giá những merge commit, vì thế tránh chúng để đảm bảo mọi thay đổi điều có commit chứa thay đổi đó.\n\n### Khi nào cần squash\n\n\"Squashing\" là quá trình lấy một dãy commit và ép lại thành một commit duy nhất.\n\nSẽ rất hữu ích trong một vài tình huống, ví dụ:\n\n- Giảm những commits ít hoặc không có ngữ cảnh (sửa lỗi chính tả, định dạng, nội dung bị quên)\n- Kết hợp những sự thay đổi riêng biệt, những thay đổi này có ý nghĩa hơn khi áp dụng cùng nhau.\n- Viết lại những commit kiểu _công việc đang tiếng hành_.\n\n### Khi nào nên tránh rebase hoặc squash?\n\nTránh rebase và squash ở những commit công khai hoặc những nhánh đồng sở hữu nơi nhiều người cùng làm việc trên nhánh đó.\nRebase và squashy viết lại history và ghi đè lên các commit hiện có, thực hiện nó trên những commit trên những nhánh đồng sở hữu (ví dụ, commit được đẩy đến một kho lưu trữ từ xa hoặc đến từ những nhánh khác) có thể gây bối rối và mọi người có thể mất những thay đổi của họ (cục bộ lẫn từ xa) bởi những cây phân nhánh và xung đột(divergent trees and conflicts).  \n\n## Những git command hữu ích\n\n### rebase -i\n\nSử dụng để squash những commit, sửa messages, viết lại/xóa/sắp xếp lại những commit, v,v...\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\nSử dụng để dọn dẹp các commit một cách dễ dàng và không cần rebase phức tạp.\n[Bài báo này](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) có những ví dục tốt về cách thức cũng như khi nào thì nên sử dụng fixup.\n\n### cherry-pick\n\n`cherry-pick` Khi bạn commit sai nhánh, sử dụng cherry-pick để lấy một commit trên nhánh sai và áp dụng vào nhánh mình muốn, thay vì phải code lại từ đầu.\n\nVí dụ:\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\nTưởng tượng chúng ta có những sự khác biệt sau:\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\nChúng ta có thể dùng `git add -p` để thêm duy nhất chỗ mà ta muốn, không cần phải thay đổi code đã được viết.\nSẽ hữu ích khi chia một thay đổi lớn thành những commit nhỏ hơn hoặc reset/checkout một thay đổi cụ thể.\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## Những thứ thú vị khác có thể tham khảo:\n\n- https://whatthecommit.com/\n- https://gitmoji.carloscuesta.me/\n\n## Thích tài liệu này?\n\n[Gởi lời cảm ơn tới RomuloOliveira!](https://saythanks.io/to/RomuloOliveira)\n\n## Đóng góp\n\nMọi sự đóng góp nào điều được đánh giá cao. Ví dụ về những chủ đề mà bạn có thể giúp:\n\n- Sửa lỗi ngữ pháp và lỗi chính tả  \n- Dịch sang ngôn ngữ khác  \n- Cải thiện nguồn tham khảo  \n- Sửa các thông tin không chính xác hoặc không đầy đủ  \n\n## Nguồn cảm hứng, nguồn và đọc thêm:\n\n- [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_zh-CN.md",
    "content": "# Commit messages guide\n\n[![Say Thanks!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\n一个了解 commit 信息重要性和如何更好地编写它的指南。\n\n它可以帮助你了解什么是 commit、为什么编写好的信息很重要、最好的实践案例以及一些技巧来计划和（重新）编写良好的 commit 历史。\n\n## 什么是“commit”？\n\n简单来讲，commit 就是在本地存储库中编写的文件的 _快照_。与印象中不同的是，[git 不仅存储不同版本文件之间的差异，还存储了所有文件的完整版本](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences)。对于两个 commit 之间没有被修改的文件，git 只存储指向前一个完全相同的文件的链接。\n\n下面的图片展示了 git 如何随着时间存储数据，其中每个 “Version” 都是一个 commit：\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## 为什么 commit 信息很重要？\n\n- 加快和简化代码审查（code reviews）\n- 帮助理解一个更改\n- 解释不能只由代码描述的“为什么”\n- 帮助未来的维护人员弄清楚为什么以及如何产生的更改，从而使故障排查和调试更容易\n\n为了最大化这些结果，我们可以使用下一节中描述的一些好的实践和标准。\n\n## 好的实践\n\n这些是从我的经验、互联网文章和其他指南中整理的一些实践经验。如果你有更多的经验（或持不同意见），请随时提交 Pull Request 提供帮助。\n\n### 使用祈使句\n\n```\n# Good\nUse InventoryBackendPool to retrieve inventory backend\n用 InventoryBackendPool 获取库存\n```\n\n```\n# Bad\nUsed InventoryBackendPool to retrieve inventory backend \nInventoryBackendPool 被用于获取库存\n```\n\n_不过为什么要使用祈使句呢？_\n\ncommit 信息描述的是引用的变更部分实际上**做**了什么，它的效果，而不是因此被做了什么。\n\n### 首字母大写\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nadd `use` method to Credit model\n```\n\n首字母大写的原因是遵守英文句子开头使用大写字母的语法规则。\n\n这种做法可能因人而异、因团队而异、甚至因语言而异。不管是否大写，重要的是要制定一个标准并遵守它。\n\n### 尽量做到只看注释便可明白而无需查看变更内容\n\n```\n# Good\nAdd `use` method to Credit model \n为 Credit 模块添加 `use` 方法\n\n```\n\n```\n# Bad\nAdd `use` method \n添加 `use` 方法\n```\n\n```\n# Good\nIncrease left padding between textbox and layout frame \n在 textbox 和 layout frame 之间添加向左对齐\n```\n\n```\n# Bad\nAdjust css \n就改了下 css\n```\n\n它在许多场景中（例如多次 commit、多个更改和重构）非常有用，可以帮助审查人员理解提交者的想法。\n\n### 使用信息本身来解释“原因”、“目的”、“手段”和其他的细节\n\n```\n# Good\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Good\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# Good\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\n信息的主题和正文之间用空行隔开。其他空行被视为信息正文的一部分。\n\n像“-”、“*”和“\\”这样的字符可以提高可读性。\n\n### 避免使用无上下文的信息\n\n```\n# Bad\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### 限制每行字数\n\n[这里建议](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)主题最多使用50个字符，正文最多使用72个字符。\n\n### 保持语言的一致性\n\n对于项目所有者而言：选择一种语言并使用该语言编写所有的 commit 信息。理想情况下，它应与代码注释、默认翻译区域（用于本地化项目）等相匹配。\n\n对于贡献者而言：使用与现有 commit 历史相同的语言编写 commit 信息。\n\n```\n# Good\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Good (Portuguese example)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Bad (mixes English and Portuguese)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### 模板\n\n下面是参考模板，最初由 [Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) 编写，出现在 [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) 中。\n\n```\n用 50 左右或更少的字符描述更改\n\n如有必要，可提供更详细的补充说明，并尽可能将其限定在每行 72 个字符左右。\n在某些情况下，第一行被视为 commit 的主题，文本其余部分被作为正文。\n因此，将主题从正文分割出来的空白行就显得至关重要(除非完全省略正文)。\n如若不然，在使用命令行，如 “log”，“shortlog” 以及 “rebase” 的时候，将会很容易混淆。\n\n解释当前 commit 所解决的问题。\n请重点描述产生此更改的原因，而非手段（代码解释了一切）。\n是否存在副作用以及其他不直观的影响？\n请在这里将其解释清楚。\n\n接下来请另起一行。\n\n - 也可以使用列举要点的格式。\n\n - 通常使用连字符(-)或星号(*)作为要点段落标记，标记与文本之间留一空格，各要点之间留一空行。但这取决于你们的约定。\n\n如果你使用问题跟踪器，请将对它们的引用放在底部，如下所示:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## Rebase vs. Merge\n\n这部分是 Atlassian 的优秀教程(TL;DR)——[\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) 的精华。\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\n**TL;DR:** 将你的分支逐个应用于基本分支，生成新树。\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge\n\n**TL;DR:** 创建一个新的 commit，称为 _merge commit_（合并提交），其具有两个分支之间的差异。\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### 为什么一些人更喜欢 rebase 而非 merge？\n\n我特别喜欢 rebase 而不是 merge。原因有以下几点：\n\n* 它的历史信息很\"干净\"，没有无用的合并 commit。\n* _所见即所得_，即在代码审查中，所有的更改都能在特定的、有标题的 commit 中找到，避免了隐藏在合并 commit 中的修改。\n* 通常 merge 是由提交者实行的，并会为每个转换成 commit 的 merge 书写准确的信息。\n    * 通常我们不会深挖和复查 merge commit，因此尽量避免使用 merge commit，并确保个变化点都有它们所属的 commit 。\n\n### 什么时候 squash\n\n“Squashing” 是将一系列 commit 压缩成一个的过程。\n\n它在某些情况下很有用，例如：\n\n- 减少那些很少甚至没有上下文（拼写错误、格式化、缺失内容）的 commit\n- 将单独的更改连接在一起使它们更通俗易懂\n- 重写 _work in progress_ 的 commit \n\n### 什么时候避免 rebase 或 squash\n\n避免在多人共同开发的公共 commit 或共享分支上使用 rebase 和 squash。rebase 和 squash 会改写历史记录并覆盖当前 commit，在共享分支的 commit（即推送到远程仓库或来自其他分支的 commit）上执行这些操作可能会引起混乱，由于分支产生分歧及冲突，合作者可能会因此失去他们（本地和远程）的更改。\n\n## 有用的 git 命令\n\n### rebase -i\n\n使用它来压缩提交（squash commits）、 编写信息、 重写/删除/重新编排 commit 等。\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\n使用它可以轻松清理 commit，而不需要复杂的 rebase。[这篇文章](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html)提供了很好的示例，说明了如何以及何时进行此操作。\n\n### cherry-pick\n\n它在你 commit 到了错误的分支而不需要重新编码时非常有用。\n\n例子：\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\n假设我们有以下冲突：\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n我们可以使用 `git add -p` 只添加我们想要的补丁，而无需更改已有代码。\n它在将一个大的更改分解为小的 commit 或 reset/checkout 特定的更改时很有用。\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## 其他有趣的内容\n\nhttps://whatthecommit.com/\n\n## 喜欢它吗？\n\n[点赞！](https://saythanks.io/to/RomuloOliveira)\n\n## 贡献\n\n感谢任何形式的帮助。例如：\n\n- 语法和拼写的纠正\n- 翻译成其他语言\n- 原引用的改进\n- 不正确或不完整的信息\n\n## 灵感、来源以及扩展阅读\n\n- [如何编写 Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit 指南](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [关于 Git Commit Messages 的说明](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [合并与变基](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - 改写历史](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  },
  {
    "path": "README_zh-TW.md",
    "content": "# Commit messages guide\n\n[![Say Thanks!](https://img.shields.io/badge/Say%20Thanks-!-1EAEDB.svg)](https://saythanks.io/to/RomuloOliveira)\n\n這是一份了解 commit 訊息的重要性和如何更好的撰寫它的指導手冊。\n\n它可以幫助你了解什麼是 commit、為什麼撰寫好的訊息很重要、最好的實踐案例以及一些技巧來計劃和 (重新) 撰寫良好的 commit 紀錄。\n\n## 什麼是“commit”？\n\n簡單來說，commit 就是在本地資料庫中撰寫的檔案的 _快照_。與印象中不同的是，[git 不僅儲存不同版本檔案之間的差異，還儲存了所有檔案的完整版本](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_snapshots_not_differences)。對於兩個 commit 之間沒有被修改的檔案，git 只儲存指向前一個完全相同的檔案的連結。\n\n下面的圖片展示了 git 如何隨著時間儲存資料，其中每個 “Version” 都是一個 commit：\n\n![](https://i.stack.imgur.com/AQ5TG.png)\n\n## 為什麼 commit 資訊很重要？\n\n- 加快和簡化 code review\n- 幫助理解一個變更\n- 解釋那些無法只透過程式碼來描述的“為什麼”\n- 幫助未來的維護人員明白為什麼以及如何產生的變更，從而使問題排查和除錯更容易\n\n為了最好的效果，我們可以使用下一節中描述的一些好的實踐方式和標準。\n\n## 好的實踐方式\n\n這些是從我的經驗、網路文章和其他指導中整理的一些實踐經驗。如果你有更多的經驗（或持不同意見），請隨時提交 Pull Request 來提供幫助。\n\n### 使用祈使句\n\n```\n# Good\nUse InventoryBackendPool to retrieve inventory backend\n用 InventoryBackendPool 取得存貨\n```\n\n```\n# Bad\nUsed InventoryBackendPool to retrieve inventory backend\nInventoryBackendPool 被用於取得存貨\n```\n\n_不過為什麼要使用祈使句呢？_\n\ncommit 訊息描述的效果是這個變更實際上**做**了什麼，而不是被做了什麼。\n\n### 第一個字母大寫\n\n```\n# Good\nAdd `use` method to Credit model\n```\n\n```\n# Bad\nadd `use` method to Credit model\n```\n\n第一個字母大寫的原因是遵守英文句子開頭使用大寫字母的語法規則。\n\n這種做法可能因人而異、因團隊而異、甚至因語言而異。不管是否大寫，重要的是要制定一個標準並遵守它。\n\n### 僅量做到只看到註釋就可以明白而無需查看變更內容\n\n```\n# Good\nAdd `use` method to Credit model\n為 Credit 模型增加 `use` 方法\n\n```\n\n```\n# Bad\nAdd `use` method\n增加 `use` 方法\n```\n\n```\n# Good\nIncrease left padding between textbox and layout frame\n在 textbox 和 layout frame 之間增加向左對齊\n```\n\n```\n# Bad\nAdjust css\n調整 css\n```\n\n它在許多場景中（例如多次 commit、多個變更和重構）非常有用，可以幫助審查者理解提交者的想法。\n\n### 使用訊息本身來解釋“原因”、“目的”、“方式”和其他的細節\n\n```\n# Good\nFix method name of InventoryBackend child classes\n\nClasses derived from InventoryBackend were not\nrespecting the base class interface.\n\nIt worked because the cart was calling the backend implementation\nincorrectly.\n```\n\n```\n# Good\nSerialize and deserialize credits to json in Cart\n\nConvert the Credit instances to dict for two main reasons:\n\n  - Pickle relies on file path for classes and we do not want to break up\n    everything if a refactor is needed\n  - Dict and built-in types are pickleable by default\n```\n\n```\n# Good\nAdd `use` method to Credit\n\nChange from namedtuple to class because we need to\nsetup a new attribute (in_use_amount) with a new value\n```\n\n訊息的標題和內容之間用空白行隔開。其他空白行被視為訊息內容的一部分。\n\n像“-”、“*”和“\\”這樣的符號可以提高可讀性。\n\n### 避免使用沒有上下文的訊息\n\n```\n# Bad\nFix this\n\nFix stuff\n\nIt should work now\n\nChange stuff\n\nAdjust css\n```\n\n### 限制每行字數\n\n[這裡建議](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)標題最多使用50個字，內容最多使用72個字。\n\n### 保持語言的一致性\n\n對於專案所有者而言：選擇一種語言並使用該語言撰寫所有的 commit 訊息。理想情況下，它應與程式碼註解、預設翻譯地區 (用於本地化專案) 等相匹配。\n\n對於貢獻者而言：使用與既有 commit 紀錄相同的語言撰寫 commit 訊息。\n\n```\n# Good\nababab Add `use` method to Credit model\nefefef Use InventoryBackendPool to retrieve inventory backend\nbebebe Fix method name of InventoryBackend child classes\n```\n\n```\n# Good (Portuguese example)\nababab Adiciona o método `use` ao model Credit\nefefef Usa o InventoryBackendPool para recuperar o backend de estoque\nbebebe Corrige nome de método na classe InventoryBackend\n```\n\n```\n# Bad (mixes English and Portuguese)\nababab Usa o InventoryBackendPool para recuperar o backend de estoque\nefefef Add `use` method to Credit model\ncdcdcd Agora vai\n```\n\n### 範本\n\n下面是參考範本，最初由 [Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) 撰寫，出現在 [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) 中。\n\n```\n用 50 個左右或更少的字來描述變更\n\n如有必要，可以提供更詳細的補充說明，並儘可能將其限定在每行 72 個字左右。\n在某些情況下，第一行被視為 commit 的標題，其餘的文字被視為內容主體。\n因此，將標題從內容分離出來的空白行就顯得非常重要(除非完全省略內容)。\n如若不然，在使用命令列，如 “log”，“shortlog” 以及 “rebase” 的時候，將會很容易混淆。\n\n解釋當前 commit 所解決的問題。\n請重點描述產生此變更的原因，而非方式（程式碼解釋了一切）。\n是否存在副作用以及其他隱含的影響？\n請在這裡將其解釋清楚。\n\n接下來請另起一行。\n\n - 也可以使用列舉的格式 (bullet point)。\n\n - 通常使用連字號(-)或星號(*)作為要點段落標記，標記與內容之間留一空格，各要點之間留一空白行。但這取決於你們的約定。\n\n如果你使用問題追蹤器，請將對它們的引用放在底部，如下所示:\n\nResolves: #123\nSee also: #456, #789\n```\n\n## Rebase vs. Merge\n\n這部分是 Atlassian 的優秀教學(TL;DR)——[\"Merging vs. Rebasing\"](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) 的精華。\n\n![](https://wac-cdn.atlassian.com/dam/jcr:01b0b04e-64f3-4659-af21-c4d86bc7cb0b/01.svg?cdnVersion=hq)\n\n### Rebase\n\n**TL;DR:** 將你的分支逐個應用於基本分支，生成新樹。\n\n![](https://wac-cdn.atlassian.com/dam/jcr:5b153a22-38be-40d0-aec8-5f2fffc771e5/03.svg?cdnVersion=hq)\n\n### Merge\n\n**TL;DR:** 建立一個新的 commit，稱為 _merge commit_（合併提交），其具有兩個分支之間的差異。\n\n![](https://wac-cdn.atlassian.com/dam/jcr:e229fef6-2c2f-4a4f-b270-e1e1baa94055/02.svg?cdnVersion=hq)\n\n### 為什麼一些人更喜歡 rebase 而非 merge？\n\n我特別喜歡 rebase 而不是 merge。原因有以下幾點：\n\n* 它的歷史紀錄很\"乾淨\"，沒有無用的合併 commit。\n* _所見即所得_，即在程式碼審查中，所有的變更都能在特定的、有標題的 commit 中找到，避免藏在合併 commit 中的修改。\n* 通常 merge 是由提交者執行的，並會為每個轉換成 commit 的 merge 寫準確的訊息。\n    * 通常我們不會深挖和複查 merge commit，因此儘量避免使用 merge commit，並確保每個變化點都有它們所屬的 commit 。\n\n### 什麼時候 squash\n\n“Squashing” 是將一系列 commit 壓縮成一個的過程。\n\n它在某些情況下很有用，例如：\n\n- 減少那些很少甚至沒有上下文（拼寫錯誤、格式化、遺失內容）的 commit\n- 將單獨的變更連結在一起使它們更通俗易懂\n- 重寫 _work in progress_ 的 commit\n\n### 什麼時候避免使用 rebase 或 squash\n\n避免在多人共同開發的共用 commit 或共享分支上使用 rebase 和 squash。rebase 和 squash 會改寫歷史紀錄並覆寫當前的 commit，在共享分支 commit（即推送到遠端倉庫或來自其他分支的 commit）上執行這些操作可能會引起混亂，由於分支產生分岐及衝突，合作者可能會因此失去它們（本地和遠端）的更改。\n\n## 有用的 git 指令\n\n### rebase -i\n\n使用它來壓縮提交（squash commits）、撰寫訊息、重寫/刪除/重新編排 commit 等。\n\n```\npick 002a7cc Improve description and update document title\npick 897f66d Add contributing section\npick e9549cf Add a section of Available languages\npick ec003aa Add \"What is a commit\" section\"\npick bbe5361 Add source referencing as a point of help wanted\npick b71115e Add a section explaining the importance of commit messages\npick 669bf2b Add \"Good practices\" section\npick d8340d7 Add capitalization of first letter practice\npick 925f42b Add a practice to encourage good descriptions\npick be05171 Add a section showing good uses of message body\npick d115bb8 Add generic messages and column limit sections\npick 1693840 Add a section about language consistency\npick 80c5f47 Add commit message template\npick 8827962 Fix triple \"m\" typo\npick 9b81c72 Add \"Rebase vs Merge\" section\n\n# Rebase 9e6dc75..9b81c72 onto 9e6dc75 (15 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into the previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\n#### fixup\n\n使用它可以輕鬆清理 commit，而不需要複雜的 rebase。[這篇文章](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html)提供了很好的範例，說明了如何以及何時進行此操作。\n\n### cherry-pick\n\n它在你 commit 到了錯誤的分支而不需要重新撰寫程式碼時非常有用。\n\n例子：\n\n```\n$ git cherry-pick 790ab21\n[master 094d820] Fix English grammar in Contributing\n Date: Sun Feb 25 23:14:23 2018 -0300\n 1 file changed, 1 insertion(+), 1 deletion(-)\n```\n\n### add/checkout/reset [--patch | -p]\n\n假設我們有以下衝突：\n\n```diff\ndiff --git a/README.md b/README.md\nindex 7b45277..6b1993c 100644\n--- a/README.md\n+++ b/README.md\n@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n我們可以使用 `git add -p` 只加入我們想要的更新，而無需更改已有的程式碼。\n它在將一個大的變更分解為小的 commit 或 reset/checkout 特定的變更時很有用。\n\n```\nStage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s\nSplit into 2 hunks.\n```\n\n#### hunk 1\n\n```diff\n@@ -186,7 +186,6 @@\n ``\n # Bad (mixes English and Portuguese)\n ababab Usa o InventoryBackendPool para recuperar o backend de estoque\n-efefef Add `use` method to Credit model\n cdcdcd Agora vai\n ``\n\nStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?\n```\n\n#### hunk 2\n\n```diff\n@@ -190,6 +189,10 @@\n ``\n cdcdcd Agora vai\n ``\n\n+### Template\n+\n+This is a template, [written originally by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the [_Pro Git Book_](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).\n+\n ## Contributing\n\n Any kind of help would be appreciated. Example of topics that you can help me with:\nStage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?\n\n```\n\n#### hunk 3\n\n```diff\n@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi\n\n - [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)\n - [Pro Git Book - Commit guidelines](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n+- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n```\n\n## 其他有趣的內容\n\nhttps://whatthecommit.com/\n\n## 喜歡它嗎？\n\n[說點感謝！](https://saythanks.io/to/RomuloOliveira)\n\n## 貢獻\n\n感謝任何形式的幫助。例如：\n\n- 語法和拼寫的糾正\n- 翻譯成其他語言\n- 原引用的改進\n- 不正確或不完整的訊息\n\n## 靈感、來源以及補充閱讀\n\n- [如何寫 Git Commit Message](https://chris.beams.io/posts/git-commit/)\n- [Pro Git Book - Commit 指導手冊](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)\n- [關於 Git Commit Messages 的說明](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)\n- [merging 與 rebase](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)\n- [Pro Git Book - 修改歷史紀錄](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n"
  }
]