lucasvbr/first-contributions
1
0
Fork 0
mirror of https://github.com/LucasVbr/first-contributions.git synced 2026-05-13 17:21:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

reset repo

Browse Source
This commit is contained in:
Roshanjossey
2025-01-03 22:30:04 +01:00
commit b166a1d130
314 changed files with 31890 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/CODE_OF_CONDUCT.md
+133
View File
@@ -0,0 +1,133 @@
# Contributor Covenant Code of Conduct
## Our Pledge
We as members, contributors, and leaders pledge to make participation in our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, caste, color, religion, or sexual
identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our
community include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall
community
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or advances of
any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email address,
without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.
Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at
firstcontributions@gmail.com.
All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of
actions.
**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or permanent
ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the
community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.1, available at
[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
Community Impact Guidelines were inspired by
[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
For answers to common questions about this code of conduct, see the FAQ at
[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
[https://www.contributor-covenant.org/translations][translations].
[homepage]: https://www.contributor-covenant.org
[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
[Mozilla CoC]: https://github.com/mozilla/diversity
[FAQ]: https://www.contributor-covenant.org/faq
[translations]: https://www.contributor-covenant.org/translations
.github/CONTRIBUTING.md
+86
View File
@@ -0,0 +1,86 @@
# Contribution guide
We appreciate your thought to contribute to open source. :heart:
If you'd like to suggest a change in the tutorials or the workflow, please [raise an issue](https://github.com/firstcontributions/first-contributions/issues/new). We can have a discussion to better understand the problem, get more people involved and make a collective decision.
If you're making changes to a translation, please request a review from our previous contributors who has translated to the respective translation. Our goal is for all translations to have the same content as the English one (`Readme.md`) (Except for links to other translations. We realised that it doesn't add much value)
### Our reviewers :sparkles:
| Language Name | Name in English | Reviewers|
|---|---|---|
| Afrikaans | [Afrikaans](../translations/README.afk.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/36197725?v=4" alt="@zecollokaris" />](https://github.com/zecollokaris) |
| Albanian | [Albanian](../translations/README.al.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/40631828?v=4" alt="RronKurtishi" />](https://github.com/RronKurtishi) [<img width="100" src="https://avatars.githubusercontent.com/u/98396887?s=400&v=4" alt="RronKurtishi" />](https://github.com/auronvila) |
| العربية | [Arabic](../translations/README.ar.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/83532081?v=4" alt="OsaidAlhomedy" />](https://github.com/OsaidAlhomedy) [<img width="100" src="https://avatars.githubusercontent.com/u/97640062?v=4" alt="AlaaYlula" />](https://github.com/AlaaYlula) [<img width="100" src="https://avatars.githubusercontent.com/u/60319236?v=4" alt="Laith-Alayassa" />](https://github.com/Laith-Alayassa) |
| Azerbaijani | [Azerbaijani](../translations/README.aze.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/60487349?v=4" alt="@isakurbanov744" />](https://github.com/isakurbanov744) [<img width="100" src="https://avatars.githubusercontent.com/u/58222828?v=4" alt="@Ahm3tJ4f" />](https://github.com/Ahm3tJ4f) |
| Bulgarian | [Bulgarian](../translations/README.bg.md) | []() |
| Bosnian | [Bosnian](../translations/README.bih.md) | []() |
| বাংলা | [Bengali](../translations/README.bn.md) | [<img width="100" src="https://avatars3.githubusercontent.com/u/12910423?s=460&v=4" alt="@cse031sust02" />](https://github.com/cse031sust02) |
| Belarusian | [Belarusian](../translations/README.by.md) | []() |
| Català | [Catalan](../translations/README.ca.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/16263046?s=460&v=4" alt="@Sergih28" />](https://github.com/Sergih28) |
| čeština | [Czech](../translations/README.cs.md) | []() |
| Danish | [Danish](../translations/README.da.md) | [<img width="100" src="https://avatars1.githubusercontent.com/u/15271858?s=460&v=4" alt="@7013145" />](https://github.com/7013145) |
| Deutsch | [German](../translations/README.de.md) | [<img width="100" src="https://avatars3.githubusercontent.com/u/22977266?s=460&v=4" alt="@lkreimann" />](https://github.com/lkreimann) |
| المصرية | [Egyptian](../translations/README.eg.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/12827629?s=460&v=4" alt="@MichaelKMalak" />](https://github.com/MichaelKMalak) |
| English (Pirate) | [English (Pirate)](../translations/README.en-pirate.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/956290?s=460&v=4" alt="@lukeoliff" />](https://github.com/lukeoliff) |
| Español | [Spanish](../translations/README.es.md) | [<img width="100" src="https://avatars3.githubusercontent.com/u/16923944?s=460&v=4" alt="@yirini" />](https://github.com/yirini) [<img width="100" src="https://avatars.githubusercontent.com/u/10425834?v=4" alt="@aaossa" />](https://github.com/aaossa) |
| فارسی | [Persian](../translations/README.fa.md) | [<img width="100" src="https://avatars2.githubusercontent.com/u/20030805?s=460&v=4" alt="@ThirdScript" />](https://github.com/ThirdScript) |
| Finnish | [Finnish](../translations/README.fi.md) | []() |
| Français | [French](../translations/README.fr.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/13402464?s=460&v=4" alt="@LePetitRenard" />](https://github.com/LePetitRenard) |
| ქართული | [Georgian](../translations/README.ka.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/9116447?s=460&v=4" alt="@iko1133" />](https://github.com/iko1133) |
| Galego | [Galician](../translations/README.gl.md) | [<img width="100" src="https://avatars1.githubusercontent.com/u/16878891?s=460&v=4" alt="@siderio2" />](https://github.com/siderio2) |
| Greek | [Greek](../translations/README.gr.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/63111742?v=4" alt="@adreaskar" />](https://github.com/adreaskar) [<img width="100" src="https://avatars.githubusercontent.com/u/19299306?v=4" alt="@porfanid" />](https://github.com/porfanid) |
| Gujarati | [Gujarati](../translations/README.guj.md) | [<img width="100" src="https://avatars2.githubusercontent.com/u/38134283?s=460&v=4" alt="@smitgajjar" />](https://github.com/smitgajjar) [<img width="100" src="https://avatars.githubusercontent.com/u/16669911?v=4" alt="@kaushalgosaliya5" />](https://github.com/kaushalgosaliya5/) |
| Hausa | [Hausa](../translations/README.hau.md) | []() |
| עברית | [Hebrew](../translations/README.hb.md) | [<img width="100" src="https://avatars1.githubusercontent.com/u/23402988?s=460&v=4" alt="@TomerPacific" />](https://github.com/TomerPacific) |
| हिन्दी | [Hindi](../translations/README.hi.md) | [<img width="100" src="https://avatars2.githubusercontent.com/u/4654382?s=460&v=4" alt="@arshadkazmi42" />](https://github.com/arshadkazmi42) [<img width="100" src="https://avatars2.githubusercontent.com/u/7047079?s=460&v=4" alt="@sara-02" />](https://github.com/sara-02) [<img width="100" src="https://avatars.githubusercontent.com/u/20799404?v=4" alt="shrut1996" />](https://github.com/shrut1996) |
| Chhattisgarhi | [Chhattisgarhi](../translations/README.hne.md) | [<img width="100" src="https://avatars2.githubusercontent.com/u/54806739?s=400&v=4" alt="@pradyyadav" />](https://github.com/pradyyadav) |
| Magyar | [Hungarian](../translations/README.hu.md) | []() |
| Armenian | [Armenian](../translations/README.hy.md) | []() |
| Indonesian | [Indonesian](../translations/README.id.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/315048?s=460&v=4" alt="@hahn" />](https://github.com/hahn) |
| Igbo | [Igbo](../translations/README.igb.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/36197725?v=4" alt="@zecollokaris" />](https://github.com/zecollokaris) []() |
| Italiano | [Italian](../translations/README.it.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/22260641?s=460&v=4" alt="@platipo" />](https://github.com/platipo) |
| 日本語 | [Japanese](../translations/README.ja.md) | [<img width="100" src="https://avatars3.githubusercontent.com/u/12928246?s=460&v=4" alt="@cbondurant" />](https://github.com/cbondurant) |
| ಕನ್ನಡ | [Kannada](../translations/README.ka.md) | []() |
| 한국어 | [Korean](../translations/README.ko.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/2732120?s=460&v=4" alt="@espozbob" />](https://github.com/espozbob) |
| Kiswahili | [Kiswahili](../translations/README.ksw.md) |[<img width="100" src="https://avatars.githubusercontent.com/u/36197725?v=4" alt="@zecollokaris" />](https://github.com/zecollokaris) []() |
| Kazakh | [Kazakh](../translations/README.kz.md) | [<img width="100" src="https://avatars3.githubusercontent.com/u/12928246?s=460&v=4" alt="@kurshakuz" />](https://github.com/kurshakuz) |
| Lietuvių kalba | [Lithuanian](../translations/README.lt.md) | [<img width="100" src="https://avatars1.githubusercontent.com/u/9092712?s=460&v=4" alt="@neone35" />](https://github.com/neone35) |
| Latviešu valoda | [Latvian](../translations/README.lv.md) | []() |
| | [me](../translations/README.me.md) | [<img width="100" src="https://avatars1.githubusercontent.com/u/9092712?s=460&v=4" alt="@neone35">]() |
| Македонски | [Macedonian](../translations/README.mk.md) | []() |
| മലയാളം | [Malayalam](../translations/README.ml.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/3657426?v=4" alt="@yedhukrishnan">](https://github.com/yedhukrishnan) |
| Burmese | [Burmese](../translations/README.mm_unicode.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/13135332?s=460&v=4" alt="@lwinkyawmyat" />](https://github.com/lwinkyawmyat) |
| मराठी | [Marathi](../translations/README.mr.md) | [<img width="100" src="https://avatars1.githubusercontent.com/u/16685565?s=460&v=4" alt="@bantya" />](https://github.com/bantya) |
| Español de México | [Spanish of Mexico](../translations/README.mx.md) | []() |
| Bahasa Melayu | [Malay](../translations/README.my.md) | []() |
| Nederlandse | [Dutch](../translations/README.nl.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/3897815?s=460&v=4" alt="@MJMajoor" />](https://github.com/MJMajoor) |
| Norsk | [Norwegian](../translations/README.no.md) | []() |
| नेपाली | [Nepali](../translations/README.np.md) | [<img width="100" src="https://avatars2.githubusercontent.com/u/2145263?s=460&v=4" alt="@milap-neupane" />](https://github.com/milap-neupane) |
| ਪੰਜਾਬੀ | [Punjabi](../translations/README.pa.md) | []() |
| Polski | [Polish](../translations/README.pl.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/3372341?s=460&v=4" alt="@P1X3L0V4" />](https://github.com/P1X3L0V4) [<img width="100" src="https://avatars2.githubusercontent.com/u/1311358?v=4" alt="@mikowhy" />](https://github.com/mikowhy) |
| Português | [Portugues (Portugal)](../translations/README.pt-pt.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/36346554?v=4" alt="@RamosCSV" />](https://github.com/RamosCSV) |
| Português do Brasil | [Portugues (Brazil)](../translations/README.pt-br.md) | [<img width="100" src="https://avatars2.githubusercontent.com/u/10578275?s=460&v=4" alt="@OtacilioN" />](https://github.com/OtacilioN) [<img width="100" src="https://avatars2.githubusercontent.com/u/47339825?s=460&v=4" alt="@gabrielsanttana" />](https://github.com/gabrielsanttana)|
| Română | [Romanian](../translations/README.ro.md) | [ <img width="100" src="https://avatars2.githubusercontent.com/u/20670448?s=460&v=4" alt="@dp97" />](https://github.com/dp97) |
| Русский | [Russian](../translations/README.ru.md) | [<img width="100" src="https://avatars2.githubusercontent.com/u/4745723?s=460&v=4" alt="@ayanovsk" />](https://github.com/ayanovsk) |
| Svenska | [Swedish](../translations/README.sv.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/2447741?s=460&v=4" alt="@jcer" />](https://github.com/jcer) |
| Sinhala | [Sinhala](../translations/README.si.md) | []() |
| Sindhi | [Sindhi](../translations/README.sindhi.md) | []() |
| Slovenčina | [Slovak](../translations/README.sk.md) | [<img width="100" src="https://avatars3.githubusercontent.com/u/16558136?s=460&v=4" alt="@CoderKlemen" />](https://github.com/CoderKlemen) |
| Slovenščina | [Slovenian](../translations/README.slk.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/11976353?s=460&v=4" alt="@hercegtomas" />](https://github.com/hercegtomas) |
| Serbian | [Serbian](../translations/README.sr.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/35745051?v=4" alt="@Mateja3m" />](https://github.com/Mateja3m) |
| தமிழ் | [Tamil](../translations/README.ta.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/7114806?v=4" alt="@sathishkumar-manogaran" />](https://github.com/sathishkumar-manogaran) |
| తెలుగు | [Telugu](../translations/README.te.md) | []() |
| ไทย | [Thai](../translations/README.th.md) | [<img width="100" src="https://avatars0.githubusercontent.com/u/5433758?s=460&v=4" alt="@AimeTPGM" />](https://github.com/AimeTPGM) |
| Tagalog | [Tagalog](../translations/README.tl.md) | []() |
| Türkçe | [Turkish](../translations/README.tr.md) | [<img width="100" src="https://avatars3.githubusercontent.com/u/32689837?s=460&v=4" alt="@yamac-kurtulus" />](https://github.com/yamac-kurtulus) |
| Українська | [Ukrainian](../translations/README.ua.md) | []() |
| Universal Alien | [Universal Alien](../translations/README.un-aln.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/68442560?v=4" alt="@debjit-bw" />]() |
| اردو | [Urdu](../translations/README.ur.md) | [<img width="100" src="https://avatars3.githubusercontent.com/u/4142795?s=460&v=4" alt="@Shhzdmrz" />](https://github.com/Shhzdmrz) |
| Tiếng Việt | [Vietnamese](../translations/README.vn.md) | [<img width="100" src="https://avatars3.githubusercontent.com/u/12371875?s=460&v=4" alt="@tranlyvu" />](https://github.com/tranlyvu) |
| Yorùbá | [Yorùbá](../translations/README.yor.md) | []() |
| 中文 | [Chinese (Simplified)](../translations/README.zh-cn.md) | [<img width="100" src="https://avatars2.githubusercontent.com/u/6414741?s=400&v=4" alt="@yuzhoujr" />](https://github.com/yuzhoujr) |
| 中文 | [Chinese (Traditional)](../translations/README.zh-tw.md) | [<img width="100" src="https://avatars2.githubusercontent.com/u/27748281?s=460&v=4" alt="@WeiChienHsu" />](https://github.com/WeiChienHsu) |
| Zulu | [Zulu](../translations/README.zu.md) | [<img width="100" src="https://avatars.githubusercontent.com/u/36197725?v=4" alt="@zecollokaris" />](https://github.com/zecollokaris) []() |
.github/FUNDING.yml
+12
View File
@@ -0,0 +1,12 @@
# These are supported funding model platforms
github: [firstcontributions]
open_collective: [firstcontributions]
ko_fi: # Replace with a single Ko-fi username
tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
liberapay: # Replace with a single Liberapay username
issuehunt: # Replace with a single IssueHunt username
otechie: # Replace with a single Otechie username
lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']
.github/ISSUE_TEMPLATE.md
+20
View File
@@ -0,0 +1,20 @@
<!--- Provide a general summary of the issue in the Title above -->
🐞 **Problem**
<!--- Provide a detailed description of the change or addition you are proposing -->
<!--- If it is a feature or a bug, what problem is it solving-->
🎯 **Goal**
<!--- Why is this change important to you? How would you use it? -->
<!--- How can it benefit other users? -->
💡 **Possible solutions**
<!--- Not obligatory, but suggest an idea for implementing addition or change -->
📋 **Steps to solve the problem**
* Comment below about what you've started working on.
* Add, commit, push your changes.
* Submit a pull request and add this in comments - `Addresses #<put issue number here>`
* Ask for reviews in comments section of pull request.
* Celebrate your contribution to this project. 🎉
.github/ISSUE_TEMPLATE/issue-template.md
+30
View File
@@ -0,0 +1,30 @@
---
name: Suggest changes
about: If you want to report a bug or suggest improvements, please open an issue.
title: ''
labels: discussion, question
assignees: Roshanjossey
---
<!--- Provide a general summary of the issue in the Title above -->
<!-- Make sure that you've read through https://github.com/firstcontributions/first-contributions/issues/35892 and understand the design of this project. If you have questions about it, please write a comment in that issue. -->
🐞 **Problem**
<!--- Provide a detailed description of the change or addition you are proposing -->
<!--- If it is a feature or a bug, what problem is it solving-->
🎯 **Goal**
<!--- Why is this change important to you? How would you use it? -->
<!--- How can it benefit other users? -->
💡 **Possible solutions**
<!--- Not obligatory, but suggest an idea for implementing addition or change -->
📋 **Steps to solve the problem**
* Comment below about what you've started working on.
* Add, commit, push your changes.
* Submit a pull request and add this in comments - `Addresses #<put issue number here>`
* Ask for reviews in comments section of pull request.
* Celebrate your contribution to this project. 🎉
.github/funding.json
+98
View File
@@ -0,0 +1,98 @@
{
"version": "v1.0.0",
"entity": {
"type": "organisation",
"role": "owner",
"name": "firstcontributions",
"email": "firstcontributions@gmail.com",
"phone": "",
"description": "Improve accessibility with enhanced documentation tailored for beginners and create opportunities for first-time contributors to get involved. Focus on building great software while inspiring a thriving, collaborative community around open source projects.",
"webpageUrl": {
"url": "https://github.com/firstcontributions/first-contributions"
}
},
"projects": [
{
"guid": "first-contributions",
"name": "First contributions",
"description": "Help beginners learn how to contribute to open-source projects. It provides a simple and beginner-friendly way for users to understand the contribution workflow using Git and GitHub. We've had over 90,000 users since we started in 2016",
"webpageUrl": {
"url": "https://github.com/firstcontributions/first-contributions"
},
"repositoryUrl": {
"url": "https://github.com/firstcontributions/first-contributions"
},
"licenses": [
"spdx:MIT"
],
"tags": [
"tutorial",
"beginner",
"open-source",
"contribution"
]
}
],
"funding": {
"channels": [
{
"guid": "opencollective",
"type": "payment-provider",
"address": "https://opencollective.com/firstcontributions",
"description": "Fiscal host is Open Source Collective. Payment methods can be found in https://docs.opencollective.com/help/financial-contributors/payments#select-a-payment-method"
},
{
"guid": "github-sponsors",
"type": "payment-provider",
"address": "https://github.com/sponsors/firstcontributions",
"description": "Uses open collective"
}
],
"plans": [
{
"guid": "maintainer-time",
"status": "active",
"name": "Maintainer compensation",
"description": "This will compensate the effort of one maintainer working part-time on the projects.",
"amount": 30000,
"currency": "USD",
"frequency": "yearly",
"channels": [
"opencollective",
"github-sponsors"
]
},
{
"guid": "hosting-monthly",
"status": "active",
"name": "Hosting support",
"description": "This will cover the monthly server hosting costs for the projects.",
"amount": 30,
"currency": "USD",
"frequency": "monthly",
"channels": [
"opencollective",
"github-sponsors"
]
}
],
"history": [
{
"year": 2024,
"income": 3,
"expenses": 0,
"taxes": 0,
"currency": "USD",
"description": ""
},
{
"year": 2023,
"income": 5,
"expenses": 0,
"taxes": 0,
"currency": "USD",
"description": ""
}
]
}
}
.github/workflows/auto-pr-merge.yml
+218
View File
@@ -0,0 +1,218 @@
name: Auto-merge PRs
on:
pull_request_target:
types: [opened, synchronize]
paths:
- 'Contributors.md' # <- only run if only contributors file changed
jobs:
auto-merge:
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
issues: write
steps:
# Check out the repository code
- name: Checkout code
uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
fetch-depth: 2
- name: Check if PR only modifies Contributors.md
id: is_only_contributors_file_changed
run: |
# Get a list of files changed in the pull request
PR_FILES=$(curl -s -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \
"https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files" | \
jq -r '.[].filename')
FILES_CHANGED=$(echo $PR_FILES | tr '\n' ' ')
echo "files_changed=$FILES_CHANGED" >> $GITHUB_ENV
if [[ "${FILES_CHANGED// /}" == "Contributors.md" ]]; then
echo "only_contributors=true" >> $GITHUB_ENV
else
echo "only_contributors=false" >> $GITHUB_ENV
fi
- name: Check if PR has only one line change
run: |
ADDITIONS=${{ github.event.pull_request.additions }}
DELETIONS=${{ github.event.pull_request.deletions }}
echo "additions=$ADDITIONS" >> $GITHUB_ENV
echo "deletions=$DELETIONS" >> $GITHUB_ENV
if [[ $ADDITIONS == 1 && $DELETIONS == 0 ]]; then
echo "one_line_change=true" >> $GITHUB_ENV
elif [[ $ADDITIONS == 2 && $DELETIONS == 1 ]]; then
echo "one_line_change=true" >> $GITHUB_ENV
else
echo "one_line_change=false" >> $GITHUB_ENV
fi
# Merge the pull request if it only modifies the Contributors.md file or if it fail to do then drop failure message as post
- name: Merge PR
id: merge_pr
if: env.only_contributors == 'true' && env.one_line_change == 'true'
uses: actions/github-script@v6
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
try {
// Attempt to merge the pull request using the squash method
const response = await github.rest.pulls.merge({
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: context.issue.number,
merge_method: "squash"
})
// Check if the merge was successful by checking the status code of the response
if (response.status === 200) {
const celebrationGifs = [
'https://c.tenor.com/ZCq4SwgCfxAAAAAC/snoopy-peanuts.gif',
'https://c.tenor.com/Z0ojZS2kpO0AAAAC/milk-and-mocha-happy.gif',
'https://c.tenor.com/LffD4a8ET9AAAAAC/heart-celebrate.gif',
'https://c.tenor.com/HJ0iSKwIG28AAAAC/yes-baby.gif',
'https://c.tenor.com/4blWuIh5MIYAAAAC/baby-yoda.gif',
'https://c.tenor.com/B_zYdea4l-4AAAAC/yay-minions.gif',
'https://media1.giphy.com/media/artj92V8o75VPL7AeQ/giphy.gif',
'https://media2.giphy.com/media/IwAZ6dvvvaTtdI8SD5/giphy.gif',
'https://media0.giphy.com/media/z8gtBVdZVrH20/giphy.gif',
'https://media2.giphy.com/media/26gN16cJ6gy4LzZSw/giphy.gif',
'https://media1.giphy.com/media/LZElUsjl1Bu6c/giphy.gif',
'https://media1.giphy.com/media/gHnwTttExPf4nwOWm7/giphy.gif',
]
const getRandomGif = () => celebrationGifs[Math.floor(Math.random() * celebrationGifs.length)]
// social media links
const web_url = 'https://firstcontributions.github.io';
const slack_invite_url = 'https://join.slack.com/t/firstcontributors/shared_invite/zt-2vqegkew0-ZuzGM1LO33C6Ts4nZyat1Q'
const twitter_tweet_share = 'https://twitter.com/intent/tweet?text=Yay%21%20I%20just%20made%20my%20first%20open%20source%20contribution%20with%20@1stcontribution.%20You%20can%20too%20at%20https%3A//goo.gl/66Axwe%0A&hashtags=OpenSource,CodeNewbie'
const fb_share_link = 'https://www.facebook.com/sharer/sharer.php?u=https://roshanjossey.github.io/first-contributions&quote=Yay%21%20I%20just%20made%20my%20first%20open%20source%20contribution%20with%20First%20Contributions.%20You%20can%20too,%20by%20following%20a%20simple%20tutorial%20at%20https%3A//goo.gl/66Axwe&hashtag=%23OpenSource'
const reddit_link = 'https://www.reddit.com/submit?url=https%3A%2F%2Fgithub.com%2Ffirstcontributions%2Ffirst-contributions&title=Learn%20how%20to%20contribute%20to%20open%20source%20projects%20in%205%20minutes'
const linkedin_share_link = 'https://www.linkedin.com/sharing/share-offsite/?url=https://github.com/firstcontributions/first-contributions';
const dev_share_link = "https://dev.to/new?prefill=---%0Atitle%3A%20First%20Contributions%3A%20learn%20how%20to%20contribute%20to%20open%20source%20projects%0Apublished%3A%20true%0Atags%3A%20opensource%2C%20beginners%2C%20tutorial%0A---%0A%0AI%20followed%20the%20hands-on%20tutorial%20in%20the%20Readme%20of%20first%20contributions%20and%20made%20my%20first%20pull%20request%20to%20the%20same%20repo.%0A%0A%0A%7B%25%20embed%20https%3A%2F%2Fgithub.com%2Ffirstcontributions%2Ffirst-contributions%20%25%7D";
const hackernews_share_link = 'https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fgithub.com%2Ffirstcontributions%2Ffirst-contributions&t=Show%20HN%3A%20Hands%20on%20tutorial%20for%20open%20source%20contribution'
const bluesky_share_link = 'https://bsky.app/intent/compose?text=Yay%21%20I%20just%20made%20my%20first%20open%20source%20contribution%20with%20%40FirstContributions.%20You%20can%20too%20by%20following%20a%20simple%20tutorial%20at%20https%3A%2F%2Fgoo.gl%2F66Axwe%20%23OpenSource%20%23FirstContribution%20%23Coding%20%23DevCommunity%20%23GitHub%20%23LearnToCode';
// social logo
const repo_logo = "https://avatars0.githubusercontent.com/u/65761570?s=88&u=640f39b808c75c6b86460aa907dd030bcca2f3c7&v=4"
const slack_logo = "https://edent.github.io/SuperTinyIcons/images/svg/slack.svg"
const twitter_logo = "https://edent.github.io/SuperTinyIcons/images/svg/twitter.svg"
const fb_logo = "https://edent.github.io/SuperTinyIcons/images/svg/facebook.svg"
const reddit_logo = "https://edent.github.io/SuperTinyIcons/images/svg/reddit.svg"
const linkedin_logo = "https://edent.github.io/SuperTinyIcons/images/svg/linkedin.svg";
const dev_logo = "https://edent.github.io/SuperTinyIcons/images/svg/dev_to.svg";
const hackernews_logo = "https://edent.github.io/SuperTinyIcons/images/svg/hackernews.svg";
const bluesky_logo = "https://edent.github.io/SuperTinyIcons/images/svg/bluesky.svg";
const getMergeMessage = (username) => {
const greeting = `Hello @${username}, congratulations! You've successfully submitted a pull request. 🎉`;
const starRepoMessage = `If you liked the tutorial, please star this repo by clicking the star button on the top right of this page. <img alt="star screenshot" title="star button" src="https://firstcontributions.github.io/assets/star.png">`;
const nextSteps = `# Next steps \n - Continue contributing: If you're looking for projects to contribute to, checkout our [<img src="${repo_logo}" width="22" title="web app" /> webapp](${web_url}). \n - Join our Slack group: We have a community to help/support contributors. [<img src="${slack_logo}" width="22" title="Slack" /> Join slack group](${slack_invite_url}). \n - Share on social media: You can share this content to help more people.\n - [<img alt="bluesky" title="bluesky" src="${bluesky_logo}" width="22"> Post on Bluesky](${bluesky_share_link}).\n - [ <img alt="twitter" title="twitter" src="${twitter_logo}" width="22"> tweet](${twitter_tweet_share}).\n - [<img alt="twitter" title="twitter" src="${fb_logo}" width="22"> share](${fb_share_link}).\n - [ <img alt="reddit" title="reddit" src="${reddit_logo}" width="22"> share](${reddit_link}).\n - [<img alt="linkedin" title="linkedin" src="${linkedin_logo}" width="22"> post](${linkedin_share_link}).\n - [<img alt="devio" title="devio" src="${dev_logo}" width="22"> publish](${dev_share_link}).\n - [<img src="${hackernews_logo}" width="22" title="HackerNews" /> Post on HackerNews](${hackernews_share_link}).`;
const feedbackMessage = `We'd love to hear your thoughts about this project. Let us know how we can improve by commenting or opening an issue here.`;
const gif = `![celebration gif](${getRandomGif()})`;
return `${greeting}\n\n${starRepoMessage}\n\n${nextSteps}\n\n${feedbackMessage}\n\n${gif}`;
}
// Generate the merge message using the getMergeMessage function
const message = getMergeMessage(context.payload.pull_request.user.login);
// post a comment
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
body: message
})
} else {
// Post a comment on the pull request using the createComment method
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
body: "Something went wrong while attempting to merge this pull request. Please check the GitHub Actions log for more information."
})
}
} catch (error) {
let errMsg = "";
console.error("Error merging pull request:", error.message);
// Handle specific error cases based on status code
if (error.status === 405 && error.response.data.message === "Pull Request is not mergeable") {
errMsg = `Hello @${context.payload.pull_request.user.login}, thank you for your pull request. We appreciate your contribution to the project. However, before we can merge it, there is a merge conflict with the target branch. \n\n No worries! You can follow [this guide](https://github.com/firstcontributions/first-contributions/blob/main/additional-material/git_workflow_scenarios/resolving-merge-conflicts.md) on resolving merge conflicts.
Once you've fixed the conflicts and pushed your changes, the repository will check the changes you made and proceed with the merge if everything looks good. \n\n If you have any questions or need further assistance, don't hesitate to reach out. We're here to help!`
} else if (error.status === 409) {
console.error("The pull request has conflicts with the target branch. Resolve the conflicts before merging.");
errMsg = "The pull request has conflicts with the target branch. Resolve the conflicts before merging.";
} else {
console.error("Something went wrong while merging the pull request.");
errMsg = "Something went wrong while merging the pull request.";
}
// Post a comment on the pull request using the createComment method
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
body: errMsg
})
// Set GitHub Action as failed
core.setFailed(error.message);
}
# Post a comment on the pull request if it was not merged automatically
- name: Post comment on PR if not merged automatically
# Check if the pull request only modifies the CONTRIBUTORS.md file
if: env.only_contributors != 'true'
uses: actions/github-script@v6
with:
script: |
// get the existing comments.
const {data: comments} = await github.rest.issues.listComments({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.payload.number,
})
// find any comment already made by the bot.
const botComment = comments.find(comment => comment.user.login === 'github-actions[bot]')
const body = `Thank you for your pull request. This pull request contains changes in files which requires review. The following files were changed:\n\n ${process.env.files_changed.trim() ? `\n\n${process.env.files_changed.trim().split(' ').map(file => `- ${file}`).join('\n')}` : ''}`
if (botComment) {
await github.rest.issues.updateComment({
owner: context.repo.owner,
repo: context.repo.repo,
comment_id: botComment.id,
body: body
})
} else {
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
body: body
});
}
github-token: ${{ secrets.GITHUB_TOKEN }}
.gitignore
+395
View File
@@ -0,0 +1,395 @@
.DS_Store;
.idea/
.vs
.env
# User-specific files
*.rsuser
*.suo
*.user
*.userosscache
*.sln.docstates
*.swp
# User-specific files (MonoDevelop/Xamarin Studio)
*.userprefs
# Mono auto generated files
mono_crash.*
# Build results
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
x64/
x86/
[Ww][Ii][Nn]32/
[Aa][Rr][Mm]/
[Aa][Rr][Mm]64/
bld/
[Bb]in/
[Oo]bj/
[Ll]og/
[Ll]ogs/
# Visual Studio 2015/2017 cache/options directory
.vs/
# Uncomment if you have tasks that create the project's static files in wwwroot
#wwwroot/
# Visual Studio 2017 auto generated files
Generated\ Files/
# MSTest test Results
[Tt]est[Rr]esult*/
[Bb]uild[Ll]og.*
# NUnit
*.VisualState.xml
TestResult.xml
nunit-*.xml
# Build Results of an ATL Project
[Dd]ebugPS/
[Rr]eleasePS/
dlldata.c
# Benchmark Results
BenchmarkDotNet.Artifacts/
# .NET Core
project.lock.json
project.fragment.lock.json
artifacts/
# ASP.NET Scaffolding
ScaffoldingReadMe.txt
# StyleCop
StyleCopReport.xml
# Files built by Visual Studio
*_i.c
*_p.c
*_h.h
*.ilk
*.meta
*.obj
*.iobj
*.pch
*.pdb
*.ipdb
*.pgc
*.pgd
*.rsp
*.sbr
*.tlb
*.tli
*.tlh
*.tmp
*.tmp_proj
*_wpftmp.csproj
*.log
*.tlog
*.vspscc
*.vssscc
.builds
*.pidb
*.svclog
*.scc
# Chutzpah Test files
_Chutzpah*
# Visual C++ cache files
ipch/
*.aps
*.ncb
*.opendb
*.opensdf
*.sdf
*.cachefile
*.VC.db
*.VC.VC.opendb
# Visual Studio profiler
*.psess
*.vsp
*.vspx
*.sap
# Visual Studio Trace Files
*.e2e
# TFS 2012 Local Workspace
$tf/
# Guidance Automation Toolkit
*.gpState
# ReSharper is a .NET coding add-in
_ReSharper*/
*.[Rr]e[Ss]harper
*.DotSettings.user
# TeamCity is a build add-in
_TeamCity*
# DotCover is a Code Coverage Tool
*.dotCover
# AxoCover is a Code Coverage Tool
.axoCover/*
!.axoCover/settings.json
# Coverlet is a free, cross platform Code Coverage Tool
coverage*.json
coverage*.xml
coverage*.info
# Visual Studio code coverage results
*.coverage
*.coveragexml
# NCrunch
_NCrunch_*
.*crunch*.local.xml
nCrunchTemp_*
# MightyMoose
*.mm.*
AutoTest.Net/
# Web workbench (sass)
.sass-cache/
# Installshield output folder
[Ee]xpress/
# DocProject is a documentation generator add-in
DocProject/buildhelp/
DocProject/Help/*.HxT
DocProject/Help/*.HxC
DocProject/Help/*.hhc
DocProject/Help/*.hhk
DocProject/Help/*.hhp
DocProject/Help/Html2
DocProject/Help/html
# Click-Once directory
publish/
# Publish Web Output
*.[Pp]ublish.xml
*.azurePubxml
# Note: Comment the next line if you want to checkin your web deploy settings,
# but database connection strings (with potential passwords) will be unencrypted
*.pubxml
*.publishproj
# Microsoft Azure Web App publish settings. Comment the next line if you want to
# checkin your Azure Web App publish settings, but sensitive information contained
# in these scripts will be unencrypted
PublishScripts/
# NuGet Packages
*.nupkg
# NuGet Symbol Packages
*.snupkg
# The packages folder can be ignored because of Package Restore
**/[Pp]ackages/*
# except build/, which is used as an MSBuild target.
!**/[Pp]ackages/build/
# Uncomment if necessary however generally it will be regenerated when needed
#!**/[Pp]ackages/repositories.config
# NuGet v3's project.json files produces more ignorable files
*.nuget.props
*.nuget.targets
# Nuget personal access tokens and Credentials
nuget.config
# Microsoft Azure Build Output
csx/
*.build.csdef
# Microsoft Azure Emulator
ecf/
rcf/
# Windows Store app package directories and files
AppPackages/
BundleArtifacts/
Package.StoreAssociation.xml
_pkginfo.txt
*.appx
*.appxbundle
*.appxupload
# Visual Studio cache files
# files ending in .cache can be ignored
*.[Cc]ache
# but keep track of directories ending in .cache
!?*.[Cc]ache/
# Others
ClientBin/
~$*
*~
*.dbmdl
*.dbproj.schemaview
*.jfm
*.pfx
*.publishsettings
orleans.codegen.cs
# Including strong name files can present a security risk
# (https://github.com/github/gitignore/pull/2483#issue-259490424)
#*.snk
# Since there are multiple workflows, uncomment next line to ignore bower_components
# (https://github.com/github/gitignore/pull/1529#issuecomment-104372622)
#bower_components/
# RIA/Silverlight projects
Generated_Code/
# Backup & report files from converting an old project file
# to a newer Visual Studio version. Backup files are not needed,
# because we have git ;-)
_UpgradeReport_Files/
Backup*/
UpgradeLog*.XML
UpgradeLog*.htm
ServiceFabricBackup/
*.rptproj.bak
# SQL Server files
*.mdf
*.ldf
*.ndf
# Business Intelligence projects
*.rdl.data
*.bim.layout
*.bim_*.settings
*.rptproj.rsuser
*- [Bb]ackup.rdl
*- [Bb]ackup ([0-9]).rdl
*- [Bb]ackup ([0-9][0-9]).rdl
# Microsoft Fakes
FakesAssemblies/
# GhostDoc plugin setting file
*.GhostDoc.xml
# Node.js Tools for Visual Studio
.ntvs_analysis.dat
node_modules/
# Visual Studio 6 build log
*.plg
# Visual Studio 6 workspace options file
*.opt
# Visual Studio 6 auto-generated workspace file (contains which files were open etc.)
*.vbw
# Visual Studio LightSwitch build output
**/*.HTMLClient/GeneratedArtifacts
**/*.DesktopClient/GeneratedArtifacts
**/*.DesktopClient/ModelManifest.xml
**/*.Server/GeneratedArtifacts
**/*.Server/ModelManifest.xml
_Pvt_Extensions
# Paket dependency manager
.paket/paket.exe
paket-files/
# FAKE - F# Make
.fake/
# CodeRush personal settings
.cr/personal
# Python Tools for Visual Studio (PTVS)
__pycache__/
*.pyc
# Cake - Uncomment if you are using it
# tools/**
# !tools/packages.config
# Tabs Studio
*.tss
# Telerik's JustMock configuration file
*.jmconfig
# BizTalk build output
*.btp.cs
*.btm.cs
*.odx.cs
*.xsd.cs
# OpenCover UI analysis results
OpenCover/
# Azure Stream Analytics local run output
ASALocalRun/
# MSBuild Binary and Structured Log
*.binlog
# NVidia Nsight GPU debugger configuration file
*.nvuser
# MFractors (Xamarin productivity tool) working folder
.mfractor/
# Local History for Visual Studio
.localhistory/
# BeatPulse healthcheck temp database
healthchecksdb
# Backup folder for Package Reference Convert tool in Visual Studio 2017
MigrationBackup/
# Ionide (cross platform F# VS Code tools) working folder
.ionide/
# Fody - auto-generated XML schema
FodyWeavers.xsd
# VS Code files for those working on multiple tools
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
*.code-workspace
# Local History for Visual Studio Code
.history/
# Windows Installer files from build outputs
*.cab
*.msi
*.msix
*.msm
*.msp
# JetBrains Rider
.idea/
*.sln.iml
.vscode/settings.json
.DS_Store
# Desktop.ini (Google Drive info file)
desktop.ini
.codegpt
.prettierignore
+2
View File
@@ -0,0 +1,2 @@
# Ignore Contributors.md(to prevent future merge conflicts):
Contributors.md
Contributors.md
+2089
View File
File diff suppressed because it is too large Load Diff
LICENSE
+21
View File
@@ -0,0 +1,21 @@
MIT License
Copyright (c) 2016 - present Roshan Jossey
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
README.md
+255
View File
@@ -0,0 +1,255 @@
[![Open Source Love](https://firstcontributions.github.io/open-source-badges/badges/open-source-v1/open-source.svg)](https://github.com/firstcontributions/open-source-badges)
[<img align="right" width="150" src="https://firstcontributions.github.io/assets/Readme/join-slack-team.png">](https://join.slack.com/t/firstcontributors/shared_invite/zt-2vqegkew0-ZuzGM1LO33C6Ts4nZyat1Q)
[![License: MIT](https://img.shields.io/badge/License-MIT-green.svg)](https://opensource.org/licenses/MIT)
[![Open Source Helpers](https://www.codetriage.com/roshanjossey/first-contributions/badges/users.svg)](https://www.codetriage.com/roshanjossey/first-contributions)
#### _Read this in [other languages](docs/translations/Translations.md)._
<kbd>[<img title="Shqip" alt="Shqip" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/al.svg" width="22">](docs/translations/README.al.md)</kbd>
<kbd>[<img title="Armenian" alt="Armenian" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/am.svg" width="22">](docs/translations/README.arm.md)</kbd>
<kbd>[<img title="Uzbek" alt="Uzbek language" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/uz.svg" width="22">](docs/translations/README.uz.md)</kbd>
<kbd>[<img title="Azərbaycan dili" alt="Azərbaycan dili" src="https://cdn.statically.io/flags/az.svg" width="22">](docs/translations/README.aze.md)</kbd>
<kbd>[<img title="বাংলা" alt="বাংলা" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/bd.svg" width="22">](docs/translations/README.bn.md)</kbd>
<kbd>[<img title="Bulgarian" alt="Bulgarian" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/bg.svg" width="22">](docs/translations/README.bg.md)</kbd>
<kbd>[<img title="Português (Brasil)" alt="Português (Brasil)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/br.svg" width="22">](docs/translations/README.pt_br.md)</kbd>
<kbd>[<img title="Català" alt="Català" src="https://firstcontributions.github.io/assets/Readme/catalan1.png" width="22">](docs/translations/README.ca.md)</kbd>
<kbd>[<img title="中文 (Simplified)" alt="中文 (Simplified)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/cn.svg" width="22">](docs/translations/README.zh-cn.md)</kbd>
<kbd>[<img title="Czech" alt="Czech" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/cz.svg" width="22">](docs/translations/README.cs.md)</kbd>
<kbd>[<img title="Deutsch" alt="Deutsch" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/de.svg" width="22">](docs/translations/README.de.md)</kbd>
<kbd>[<img title="Dansk" alt="Dansk" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/dk.svg" width="22">](docs/translations/README.da.md)</kbd>
<kbd>[<img title="العربية" alt="العربية" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/eg.svg" width="22">](docs/translations/README.eg.md)</kbd>
<kbd>[<img title="Dezéiriya" alt="Dezéiriya" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/dz.svg" width="22">](docs/translations/README.dz.md)</kbd>
<kbd>[<img title="Española" alt="Española" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/es.svg" width="22">](docs/translations/README.es.md)</kbd>
<kbd>[<img title="Française" alt="Française" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/fr.svg" width="22">](docs/translations/README.fr.md)</kbd>
<kbd>[<img title="Gaeilge" alt="Gaeilge" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ie.svg" width="22">](docs/translations/README.ga.md)</kbd>
<kbd>[<img title="Galego" alt="Galego" src="https://upload.wikimedia.org/wikipedia/commons/thumb/6/64/Flag_of_Galicia.svg/1200px-Flag_of_Galicia.svg.png" width="22">](docs/translations/README.gl.md)</kbd>
<kbd>[<img title="Ελληνικά" alt="Ελληνικά" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/gr.svg" width="22">](docs/translations/README.gr.md)</kbd>
<kbd>[<img title="ქართული" alt="ქართული" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ge.svg" width="22">](docs/translations/README.ge.md)</kbd>
<kbd>[<img title="Magyar" alt="Magyar" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/hu.svg" width="22">](docs/translations/README.hu.md)</kbd>
<kbd>[<img title="Bahasa Indonesia" alt="Bahasa Indonesia" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/id.svg" width="22">](docs/translations/README.id.md)</kbd>
<kbd>[<img title="עִברִית" alt="עִברִית" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/il.svg" width="22">](docs/translations/README.hb.md)</kbd>
<kbd>[<img title="हिंदी/ગુજરાતી/मराठी/മലയാളം/ಕನ್ನಡ/తెలుగు/छत्तीसगढ़ी/বাংলা/தமிழ்" alt="हिंदी/ગુજરાતી/मराठी/മലയാളം/ಕನ್ನಡ/తెలుగు/छत्तीसगढ़ी/বাংলা/தமிழ்" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/in.svg" width="22">](docs/translations/Translations.md)</kbd>
<kbd>[<img title="தமிழ்" alt="தமிழ்" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/lk.svg" width="22">](docs/translations/README.ta.md)</kbd>
<kbd>[<img title="فارسی" alt="فارسی" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ir.svg" width="22">](docs/translations/README.fa.md)</kbd>
<kbd>[<img title="پښتو" alt="پښتو" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/af.svg" width="22">](docs/translations/README.pus.md)</kbd>
<kbd>[<img title="Italiano" alt="Italiano" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/it.svg" width="22">](docs/translations/README.it.md)</kbd>
<kbd>[<img title="日本語" alt="日本語" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/jp.svg" width="22">](docs/translations/README.ja.md)</kbd>
<kbd>[<img title="සිංහල" alt="සිංහල" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/lk.svg" width="22">](docs/translations/README.si.md)</kbd>
<kbd>[<img title="Kiswahili (Kenya)" alt="Kiswahili (Kenya)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ke.svg" width="22">](docs/translations/README.kws.md)</kbd>
<kbd>[<img title="한국어" alt="한국어" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/kr.svg" width="22">](docs/translations/README.ko.md)</kbd>
<kbd>[<img title="Lietuvių kalba" alt="Lietuvių kalba" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/lt.svg" width="22">](docs/translations/README.lt.md)</kbd>
<kbd>[<img title="Limba Română" alt="Limba Română" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/md.svg" width="22"> <img title="Limba Română" alt="Limba Română" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ro.svg" width="22">](docs/translations/README.ro.md)</kbd>
<kbd>[<img title="မြန်မာ" alt="မြန်မာ" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/mm.svg" width="22">](docs/translations/README.mm_unicode.md)</kbd>
<kbd>[<img title="Македонски" alt="Македонски" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/mk.svg" width="22">](docs/translations/README.mk.md)</kbd>
<kbd>[<img title="Español de México" alt="Español de México" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/mx.svg" width="22">](docs/translations/README.mx.md)</kbd>
<kbd>[<img title="Bahasa Melayu / بهاس ملايو‎ / Malay" alt="Bahasa Melayu / بهاس ملايو‎ / Malay" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/my.svg" width="22">](docs/translations/README.my.md)</kbd>
<kbd>[<img title="Dutch" alt="Dutch" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/nl.svg" width="22">](docs/translations/README.nl.md)</kbd>
<kbd>[<img title="Norsk" alt="Norsk" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/no.svg" width="22">](docs/translations/README.no.md)</kbd>
<kbd>[<img title="नेपाली" alt="नेपाली" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/np.svg" width="15">](docs/translations/README.np.md)</kbd>
<kbd>[<img title="Wikang Filipino" alt="Wikang Filipino" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ph.svg" width="22">](docs/translations/README.fil.md)</kbd>
<kbd>[<img title="English (Pirate)" alt="English (Pirate)" src="https://firstcontributions.github.io/assets/Readme/pirate.png" width="22">](docs/translations/README.en-pirate.md)</kbd>
<kbd>[<img title="اُاردو" alt="اردو" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/pk.svg" width="22">](docs/translations/README.ur.md)</kbd>
<kbd>[<img title="Twi (Ghana)" alt="Twi (Ghana)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/gh.svg" width="22">](docs/translations/README.gh.md)</kbd>
<kbd>[<img title="Polski" alt="Polski" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/pl.svg" width="22">](docs/translations/README.pl.md)</kbd>
<kbd>[<img title="Português (Portugal)" alt="Português (Portugal)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/pt.svg" width="22">](docs/translations/README.pt-pt.md)</kbd>
<kbd>[<img title="Русский язык" alt="Русский язык" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ru.svg" width="22">](docs/translations/README.ru.md)</kbd>
<kbd>[<img title="عربى" alt="عربى" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/sa.svg" width="22">](docs/translations/README.ar.md)</kbd>
<kbd>[<img title="Svenska" alt="Svenska" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/se.svg" width="22">](docs/translations/README.se.md)</kbd>
<kbd>[<img title="Slovenčina" alt="Slovenčina" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/sk.svg" width="22">](docs/translations/README.slk.md)</kbd>
<kbd>[<img title="Slovenščina" alt="Slovenščina" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/si.svg" width="22">](docs/translations/README.sl.md)</kbd>
<kbd>[<img title="ภาษาไทย" alt="ภาษาไทย" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/th.svg" width="22">](docs/translations/README.th.md)</kbd>
<kbd>[<img title="Türkçe" alt="Türkçe" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/tr.svg" width="22">](docs/translations/README.tr.md)</kbd>
<kbd>[<img title="中文(Traditional)" alt="中文(Traditional)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/tw.svg" width="22">](docs/translations/README.zh-tw.md)</kbd>
<kbd>[<img title="Українська" alt="Українська" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ua.svg" width="22">](docs/translations/README.ua.md)</kbd>
<kbd>[<img title="Tiếng Việt" alt="Tiếng Việt" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/vn.svg" width="22">](docs/translations/README.vn.md)</kbd>
<kbd>[<img title="Tanzania" alt="Swahili language" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/tz.svg" width="22">](docs/translations/README.sw.md)</kbd>
<kbd>[<img title="Zulu (South Africa)" alt="Zulu (South Africa)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/za.svg" width="22">](docs/translations/README.zul.md)</kbd>
<kbd>[<img title="Afrikaans (South Africa)" alt="Afrikaans (South Africa)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/za.svg" width="22">](docs/translations/README.afk.md)</kbd>
<kbd>[<img title="Igbo (Nigeria)" alt="Igbo (Nigeria)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ng.svg" width="22">](docs/translations/README.igb.md)</kbd>
<kbd>[<img title="Bambara (Mali)" alt="Bambara (Mali)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ml.svg" width="22">](docs/translations/README.mli.md)</kbd>
<kbd>[<img title="Hausa (Nigeria)" alt="Hausa (Nigeria)" src="https://upload.wikimedia.org/wikipedia/commons/thumb/5/5d/Flag_of_the_Hausa_people.svg/1280px-Flag_of_the_Hausa_people.svg.png" width="22">](docs/translations/README.hau.md)</kbd>
<kbd>[<img title="Yoruba (Nigeria)" alt="Yoruba (Nigeria)" src="https://www.fotw.info/images/n/ng%7Deoyor.gif" width="22">](docs/translations/README.yor.md)</kbd>
<kbd>[<img title="Latvia" alt="Latvia" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/lv.svg" width="22">](docs/translations/README.lv.md)</kbd>
<kbd>[<img title="Suomeksi" alt="Suomeksi" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/fi.svg" width="22">](docs/translations/README.fi.md)</kbd>
<kbd>[<img title="Беларуская мова" alt="Беларуская мова" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/by.svg" width="22">](docs/translations/README.by.md)</kbd>
<kbd>[<img title="Српски" alt="Српски" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/rs.svg" width="22">](docs/translations/README.sr.md)</kbd>
<kbd>[<img title="Қазақша" alt="Қазақша" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/kz.svg" width="22">](docs/translations/README.kz.md)</kbd>
<kbd>[<img title="Bosanski" alt="Bosanski" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ba.svg" width="22">](docs/translations/README.bih.md)</kbd>
<kbd>[<img title="Bosanski" alt="Bosanski" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/et.svg" width="22">](docs/translations/README.bih.md)</kbd>
<kbd>[<img title="Hrvatski" alt="Hrvatski" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/hr.svg" width="22">](docs/translations/README.hr.md)</kbd>
<kbd>[<img title="پښتو" alt="پښتو" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/af.svg" width="22">](docs/translations/README.ps.md)</kbd>
<kbd>[<img title="Af-soomaali" alt="Somalia" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/so.svg" width="22">](docs/translations/README.so.md)</kbd>
<kbd>[<img title="Español de Ecuador" alt="Ecuador" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ec.svg" width="22">](docs/translations/README.ec.md)</kbd>
<kbd>[<img title="Luganda (Uganda)" alt="Luganda (Uganda)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ug.svg" width="22">](docs/translations/README.lug.md)</kbd>
<kbd>[<img title="Turkmen" alt="Turkmen language" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/tm.svg" width="22">](docs/translations/README.tm.md)</kbd>
<kbd>[<img title="Ewe (TOGO)" alt="Ewe (TOGO)" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/tg.svg" width="22">](docs/translations/README.ewe.md)</kbd>
<kbd>[<img title="አማርኛ" alt="አማርኛ" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/et.svg" width="22">](docs/translations/README.et.md)</kbd>
<kbd>[<img title="Kurdî" alt="Kurdî" src="https://upload.wikimedia.org/wikipedia/commons/3/35/Flag_of_Kurdistan.svg" width="22">](docs/translations/README.kr.md)</kbd>
<kbd>[<img title="Malagasy" alt="Malagasy" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/mg.svg" width="22">](docs/translations/README.mg.md)</kbd>
<kbd>[<img title="ភាសាខ្មែរ" alt="ភាសាខ្មែរ" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/kh.svg" width="22">](docs/translations/README.kh.md)</kbd>
<kbd>[<img title="Morocco" alt="Moroccan Darija" src="https://cdn.statically.io/gh/hjnilsson/country-flags/master/svg/ma.svg" width="22">](docs/translations/README.ma.md)</kbd>
# First Contributions
This project aims to simplify and guide the way beginners make their first contribution. If you are looking to make your first contribution, follow the steps below.
_If you're not comfortable with command line, [here are tutorials using GUI tools.](#tutorials-using-other-tools)_
<img align="right" width="300" src="https://firstcontributions.github.io/assets/Readme/fork.png" alt="fork this repository" />
#### If you don't have git on your machine, [install it](https://docs.github.com/en/get-started/quickstart/set-up-git).
## Fork this repository
Fork this repository by clicking on the fork button on the top of this page.
This will create a copy of this repository in your account.
## Clone the repository
<img align="right" width="300" src="https://firstcontributions.github.io/assets/Readme/clone.png" alt="clone this repository" />
Now clone the forked repository to your machine. Go to your GitHub account, open the forked repository, click on the code button, then on SSH tab and then click the _copy to clipboard_ icon.
Open a terminal and run the following git command:
```bash
git clone "url you just copied"
```
where "url you just copied" (without the quotation marks) is the url to this repository (your fork of this project). See the previous steps to obtain the url.
<img align="right" width="300" src="https://firstcontributions.github.io/assets/Readme/copy-to-clipboard.png" alt="copy URL to clipboard" />
For example:
```bash
git clone git@github.com:this-is-you/first-contributions.git
```
where `this-is-you` is your GitHub username. Here you're copying the contents of the first-contributions repository on GitHub to your computer.
## Create a branch
Change to the repository directory on your computer (if you are not already there):
```bash
cd first-contributions
```
Now create a branch using the `git switch` command:
```bash
git switch -c your-new-branch-name
```
For example:
```bash
git switch -c add-alonzo-church
```
<details>
<summary> <strong>If you get any errors using git switch, click here:</strong> </summary>
If the error message "Git: `switch` is not a git command. See `git –help`" appears, it's likely because you're using an older version of git.
In this case, try to use `git checkout` instead:
```bash
git checkout -b your-new-branch-name
```
</details>
## Make necessary changes and commit those changes
Now open `Contributors.md` file in a text editor, add your name to it. Don't add it at the beginning or end of the file. Put it anywhere in between. Now, save the file.
<img align="right" width="450" src="https://firstcontributions.github.io/assets/Readme/git-status.png" alt="git status" />
If you go to the project directory and execute the command `git status`, you'll see there are changes.
Add those changes to the branch you just created using the `git add` command:
```bash
git add Contributors.md
```
Now commit those changes using the `git commit` command:
```bash
git commit -m "Add your-name to Contributors list"
```
replacing `your-name` with your name.
## Push changes to GitHub
Push your changes using the command `git push`:
```bash
git push -u origin your-branch-name
```
replacing `your-branch-name` with the name of the branch you created earlier.
<details>
<summary> <strong>If you get any errors while pushing, click here:</strong> </summary>
- ### Authentication Error
<pre>remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
fatal: Authentication failed for 'https://github.com/<your-username>/first-contributions.git/'</pre>
Go to [GitHub's tutorial](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) on generating and configuring an SSH key to your account.
Also, you might want to run 'git remote -v' to check your remote address.
If it looks anything like this:
<pre>origin https://github.com/your-username/your_repo.git (fetch)
origin https://github.com/your-username/your_repo.git (push)</pre>
change it using this command:
```bash
git remote set-url origin git@github.com:your-username/your_repo.git
```
Otherwise you'll still get prompted for username and password and get authentication error.
</details>
## Submit your changes for review
If you go to your repository on GitHub, you'll see a `Compare & pull request` button. Click on that button.
<img style="float: right;" src="https://firstcontributions.github.io/assets/Readme/compare-and-pull.png" alt="create a pull request" />
Now submit the pull request.
<img style="float: right;" src="https://firstcontributions.github.io/assets/Readme/submit-pull-request.png" alt="submit pull request" />
Soon I'll be merging all your changes into the main branch of this project. You will get a notification email once the changes have been merged.
## Where to go from here?
Congrats! You just completed the standard _fork -> clone -> edit -> pull request_ workflow that you'll often encounter as a contributor!
Celebrate your contribution and share it with your friends and followers by going to [web app](https://firstcontributions.github.io/#social-share).
You could join our slack team if you need any help or have any questions. [Join slack team](https://join.slack.com/t/firstcontributors/shared_invite/zt-2vqegkew0-ZuzGM1LO33C6Ts4nZyat1Q).
Now let's get you started with contributing to other projects. We've compiled a list of projects with easy issues you can get started on. Check out [the list of projects in the web app](https://firstcontributions.github.io/#project-list).
### [Additional material](docs/additional-material/git_workflow_scenarios/additional-material.md)
## Tutorials Using Other Tools
| <a href="gui-tool-tutorials/github-desktop-tutorial.md"><img alt="GitHub Desktop" src="https://desktop.github.com/images/desktop-icon.svg" width="100"></a> | <a href="gui-tool-tutorials/github-windows-vs2017-tutorial.md"><img alt="Visual Studio 2017" src="https://upload.wikimedia.org/wikipedia/commons/c/cd/Visual_Studio_2017_Logo.svg" width="100"></a> | <a href="gui-tool-tutorials/gitkraken-tutorial.md"><img alt="GitKraken" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/gitkraken-tutorial/gk-icon.png" width="100"></a> | <a href="gui-tool-tutorials/github-windows-vs-code-tutorial.md"><img alt="VS Code" src="https://upload.wikimedia.org/wikipedia/commons/1/1c/Visual_Studio_Code_1.35_icon.png" width=100></a> | <a href="gui-tool-tutorials/sourcetree-macos-tutorial.md"><img alt="Sourcetree App" src="https://wac-cdn.atlassian.com/dam/jcr:81b15cde-be2e-4f4a-8af7-9436f4a1b431/Sourcetree-icon-blue.svg" width=100></a> | <a href="gui-tool-tutorials/github-windows-intellij-tutorial.md"><img alt="IntelliJ IDEA" src="https://upload.wikimedia.org/wikipedia/commons/thumb/9/9c/IntelliJ_IDEA_Icon.svg/512px-IntelliJ_IDEA_Icon.svg.png" width=100></a> |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [GitHub Desktop](docs/gui-tool-tutorials/github-desktop-tutorial.md) | [Visual Studio 2017](docs/gui-tool-tutorials/github-windows-vs2017-tutorial.md) | [GitKraken](docs/gui-tool-tutorials/gitkraken-tutorial.md) | [Visual Studio Code](docs/gui-tool-tutorials/github-windows-vs-code-tutorial.md) | [Atlassian Sourcetree](docs/gui-tool-tutorials/sourcetree-macos-tutorial.md) | [IntelliJ IDEA](docs/gui-tool-tutorials/github-windows-intellij-tutorial.md) |
<p>This project is supported by:</p>
<p>
<a href="https://www.digitalocean.com/">
<img src="https://opensource.nyc3.cdn.digitaloceanspaces.com/attribution/assets/SVG/DO_Logo_horizontal_blue.svg" width="201px">
</a>
</p>
docs/additional-material/Things a non Programmer can do.es.md
+124
View File
@@ -0,0 +1,124 @@
# Cosas que un no programador puede hacer
## Empieza a escuchar
Todo en código abierto involucra a otras personas.
Estás buscando unirte a un equipo y eso significa comprender la comunidad y cómo funciona.
Entrar en un proyecto y decir "Hola, esto es lo que creo que debería hacer este proyecto." generalmente no se considera algo bueno.
Algunos proyectos pueden acoger con agrado ese tipo de enfoque, pero si el proyecto lleva funcionando un tiempo, las posibilidades de que se adopte esa actitud son pequeñas.
**Escuchar es la mejor manera de saber qué necesita el proyecto.**
1. **Únase a una lista de correo** : para muchos proyectos, la lista de correo es el principal conducto de comunicación sobre el desarrollo del proyecto.
En proyectos grandes, hay muchas listas de correo para elegir.
Por ejemplo, el proyecto PostgreSQL tiene no menos de 12 listas orientadas a usuarios y seis listas de desarrolladores en su página de lista de correo.
Le sugiero que siga la lista principal orientada al usuario y la lista principal de desarrolladores para comenzar a escuchar.
2. **Siga un blog** : los blogs mantenidos por desarrolladores principales a menudo brindan información sobre lo que se avecina en futuras versiones.
y lo que se necesita para llegar allí. Un sitio planetario agrega noticias y entradas de blogs de muchas fuentes relacionadas con el proyecto.
Si hay un sitio planetario, como planet.gnome.org o planet.mysql.com, comience allí. Simplemente busque en Google "planeta <nombre del proyecto>".
3. **Únase a un canal IRC** : muchos proyectos de código abierto tienen canales de chat de retransmisión (IRC) de Internet dedicados donde desarrolladores y usuarios se reúnen para discutir problemas y desarrollo.
Consulte el sitio web del proyecto para obtener detalles sobre cómo se llama el canal y en qué red IRC se encuentra.
**Trabajar con tickets**
El código es el corazón de cualquier proyecto de código abierto, pero no crea que escribir código es la única forma de contribuir.
El mantenimiento del código y de los sistemas que lo rodean a menudo se descuidan en la prisa por crear nuevas funciones y corregir errores.
Considere estas áreas como una manera fácil de involucrarse en un proyecto.
La mayoría de los proyectos tienen un sistema de notificación de problemas visible públicamente, vinculado desde la página principal del sitio web del proyecto e incluido en la documentación.
Es el conducto principal de comunicación entre los usuarios y los desarrolladores. Mantenerlo actualizado es una excelente manera de ayudar al proyecto.
Es posible que necesite obtener permisos especiales en el sistema de tickets, que la mayoría de los líderes de proyecto estarán encantados de otorgarle cuando diga que quiere ayudar a limpiar los tickets.
4. **Diagnosticar un error** : los errores a menudo no se informan correctamente.
Diagnosticar y clasificar un error puede ayudar a los desarrolladores a ahorrar tiempo con el trabajo preliminar de descubrir los detalles del problema.
Si un usuario informó: "El software no funciona cuando hago X", dedique algún tiempo a descubrir los detalles de ese problema.
¿Es repetible? ¿Puedes crear un conjunto de pasos para causar el problema repetidamente? ¿Puedes limitar el problema, por ejemplo, si solo ocurre en un navegador pero no en otro, o en una distribución pero no en otra?
Incluso si no sabes qué causa el problema, el esfuerzo que pones en delimitar las circunstancias hace que sea más fácil para otra persona solucionarlo.
Cualquier cosa que descubras, agrégala al ticket en el sistema de errores para que todos lo vean.
5. **Cerrar errores solucionados** : a menudo, los errores se corrigen en el código base, pero los tickets informados sobre ellos no se actualizan en el sistema de emisión de tickets.
Limpiar este trozo de papel puede llevar mucho tiempo, pero es valioso para todo el proyecto.
Comience consultando el sistema de tickets en busca de tickets con más de un año y vea si el error aún existe.
Consulte el registro de cambios de versión del proyecto para ver si el error se solucionó y se puede cerrar.
Si se sabe que está solucionado, anote el número de versión en el ticket y ciérrelo.
Intente recrear el error con la última versión del software.
Si no se puede recrear con la última versión, anótelo en el ticket y ciérrelo.
Si todavía existe, anótelo también en el ticket y déjelo abierto.
Trabajar con código
Los programadores de todos los niveles de experiencia pueden ayudar con el código del proyecto.
No creas que tienes que ser un genio de la programación para hacer contribuciones reales a tu proyecto favorito.
Si su trabajo implica modificar el código, investigue el método que utiliza el proyecto para obtener el código de los contribuyentes.
Cada proyecto tiene su propio flujo de trabajo, así que pregunte cómo hacerlo antes de enviar el código.
Por ejemplo, el proyecto PostgreSQL es muy riguroso en su proceso: las modificaciones del código se envían en forma de parche a una lista de correo donde los desarrolladores principales examinan cada aspecto del cambio. En el otro extremo hay un proyecto como Parrot donde es fácil obtener privilegios de confirmación para el código base. Si el proyecto usa GitHub, puede haber un flujo de trabajo que use la función de solicitud de extracción de GitHub. No hay dos proyectos iguales.
Siempre que modifique el código, asegúrese de actuar como un miembro responsable de la comunidad y de mantener el estilo de su código para que coincida con el resto del código base. El código que agregue o modifique debería verse como el resto. Puede que no le guste el estilo de refuerzo o el manejo de los espacios para la sangría, pero es de mala educación enviar un cambio de código que no coincide con los estándares existentes. Es lo mismo que decir "No me gusta tu estilo y creo que el mío es mejor, así que deberías hacerlo a mi manera".
6. **Pruebe una versión beta o candidata** : cualquier proyecto diseñado para ejecutarse en múltiples plataformas puede tener todo tipo de problemas de portabilidad.
Cuando se acerca una versión y se publica una versión beta o candidata, el líder del proyecto espera que sea probada por muchas personas diferentes en muchas plataformas diferentes.
Usted puede ser una de esas personas y ayudar a garantizar que el paquete funcione en su plataforma.
Por lo general, solo necesita descargar, compilar y probar el software, pero el valor para el proyecto puede ser enorme si utiliza una distribución o hardware poco común.
Simplemente informar que la compilación y la prueba funcionan ayuda a los líderes del proyecto a saber que el lanzamiento inminente es sólido.
7. **Corregir un error** : aquí es donde generalmente comienzan los contribuyentes que desean comenzar a trabajar en el código.
Es simple: encuentre un error que parezca interesante en el sistema de tickets e intente corregirlo en el código.
Documente la solución en el código si es apropiado.
Es una buena idea agregar una prueba al conjunto de pruebas para probar el código que corrigió; algunos proyectos requieren correcciones de errores para incluir pruebas. Tome notas mientras hurga en este código base desconocido. Incluso si no puede corregir el error, documente en el ticket lo que descubrió como parte del intento de solucionarlo. Lo que encuentres ayudará a quienes te sucedan.
8. **Escribe una prueba** : la mayoría de los proyectos tienen un conjunto de pruebas que prueba el código, pero es difícil imaginar un conjunto de pruebas al que no se le puedan agregar más pruebas.
Utilice una herramienta de cobertura de pruebas como gcov para C o Devel::Cover para Perl para identificar áreas en el código fuente que no han sido probadas por el conjunto de pruebas.
Luego, agregue una prueba a la suite para cubrirlo.
9. **Silenciar una advertencia del compilador** : el proceso de compilación de muchos proyectos basados en C a menudo arroja algún que otro indicador de advertencia del compilador en la pantalla.
Estas advertencias generalmente no son indicadores de un problema, pero pueden parecerlo.
Tener demasiadas advertencias puede hacer que el compilador suene como si estuviera llorando.
Verifique si el código realmente podría estar ocultando un error. De lo contrario, modificar la fuente para silenciarla ayuda a ocultar estos falsos positivos.
10. **Agrega un comentario** :
Cuando exploras el código, es posible que encuentres algunos puntos que te resulten confusos.
Lo más probable es que si usted estaba confundido, otros también lo estarán. Documentarlos en el código y enviar un parche.
Trabajar con documentación
La documentación suele ser la parte de un proyecto que recibe poca atención.
También puede verse afectado por haber sido escrito desde el punto de vista de quienes están familiarizados con el proyecto, en lugar de desde los ojos de alguien que recién se está involucrando en él.
Si alguna vez ha leído documentos de un proyecto en el que piensa: "Es como si este manual esperara que yo ya supiera cómo utilizar el paquete", sabe de lo que estoy hablando.
A menudo, un par de ojos nuevos pueden señalar deficiencias en la documentación que quienes están cerca del proyecto no notan.
11. **Crea un ejemplo** : No hay ningún proyecto que tenga demasiados ejemplos prácticos.
Ya sea una API web, una biblioteca de rutinas, una aplicación GUI como Gimp o una herramienta de línea de comandos,
un buen ejemplo de uso adecuado puede explicar más clara y rápidamente el uso adecuado del software que las páginas de documentación.
Para una API o biblioteca, cree un programa de ejemplo que utilice la herramienta. Esto incluso podría extraerse del código que haya escrito y reducirlo a lo estrictamente necesario.
Para una herramienta, muestre ejemplos del mundo real de cómo la ha utilizado en su vida diaria. Si estás orientado visualmente,
Considere la posibilidad de crear una captura de pantalla de un proceso importante, como por ejemplo cómo instalar la aplicación.
Trabajar con la comunidad
El código abierto se trata sólo en parte de código. La comunidad hace que el código abierto funcione. A continuación le presentamos formas en las que puede ayudar a desarrollarlo.
12. **Responda una pregunta** : La mejor manera de ayudar a construir la comunidad es ayudando a los demás.
Responder una pregunta, especialmente de alguien que recién se está iniciando, es crucial para ayudar a que el proyecto crezca y prospere.
El tiempo que se toma para ayudar a un principiante, incluso si está haciendo una pregunta en la que fácilmente se podría responder con un rápido "RTFM", vale la pena en el futuro para conseguir otro miembro activo de la comunidad.
Todo el mundo empieza en alguna parte y los proyectos necesitan un flujo constante de personas para que sigan siendo vitales.
13. **Escribe una publicación de blog** :
Si tienes un blog, escribe sobre tus experiencias con el proyecto que estás utilizando.
Cuéntanos sobre un problema que enfrentaste al usar el software y qué hiciste para resolverlo.
Ayudarás de dos maneras: ayudando a mantener el proyecto en la mente de quienes te rodean,
y creando un registro para cualquier otra persona que tenga su problema en el futuro y busque la respuesta en la web.
(Un blog de sus aventuras técnicas también es una excelente manera de mostrar su experiencia en el mundo real con el software en cuestión la próxima vez que busque trabajo usándolo).
14. **Mejorar un sitio web** :
Si tiene habilidades en diseño web y puede ayudar a mejorar el sitio web y, por lo tanto, la imagen pública del proyecto, es tiempo bien invertido.
Quizás el proyecto podría necesitar una revisión gráfica o un logotipo para identificarlo.
Estas pueden ser habilidades que faltan en la comunidad. Sé que me encantaría poder obtener ayuda con el diseño gráfico de los sitios web de mis proyectos.
15. **Escribir documentación técnica**
Si puede escribir sobre cómo funciona una aplicación o software, puede escribir documentación técnica al respecto. Especialmente proyectos de código abierto que buscan actualizar, renovar, ampliar o crear documentos técnicos para que los lea el público en general. Cuanto más escribas en inglés sencillo, mejor. La mejor parte es que no es necesario ser programador para escribir documentos técnicos.
Sobre todo, escuche lo que discuten las personas que lo rodean. Vea si puede reconocer una necesidad urgente. Por ejemplo, recientemente en la lista de correo de los desarrolladores de Parrot, se decidió utilizar GitHub como sistema de notificación de problemas, abandonando la antigua instalación de Trac que tenían. Algunas personas estaban en contra de la medida porque no había forma de convertir los tickets al sistema de GitHub. Después de un día de discusiones de ida y vuelta, hablé y dije: "¿Qué tal si escribo un convertidor?" La gente estaba encantada con la idea. Dediqué tiempo a escribir un programa de conversión para más de 450 boletos, por lo que no perdimos nada de nuestro historial de boletos. Fue un gran éxito. Pude colaborar y los desarrolladores principales se mantuvieron concentrados en el negocio de trabajar en Parrot.
16. **Enseñar y ayudar a otros** :
La mejor manera de aprender más sobre un tema es intentar enseñarlo.
El mejor profesor es el que puede explicar cosas complejas con ejemplos sencillos. Por lo tanto, debes intentar ser el mejor maestro para ser el mejor alumno y el mejor en tu mundo de programación. Enseñar a otros te hará sentir mejor contigo mismo y te ayudará a adquirir mejores habilidades y conocimientos en tu profesión. Cuando reciba ayuda de alguien, no se la guarde para usted, compártala con los demás. Hacer el mundo un lugar mejor para vivir .
docs/additional-material/Things a non Programmer can do.fr.md
+52
View File
@@ -0,0 +1,52 @@
# Ce qu'un non programmeur peut faire
## Être attentive
Dans le domaine de l'open source, toute démarche, qu'il s'agisse de programmation ou d'autres aspects, requiert la contribution et l'implication d'autres personnes.
Rejoindre une équipe open source, implique de comprendre la dynamique de la communauté et son mode de fonctionnement. Plutôt que d'arriver sur un projet en affirmant immédiatement, "Voici ce que je pense que ce projet devrait faire", il est généralement plus bénéfique d'adopter une approche plus attentive.
Certains projets peuvent accueillir favorablement ce type d'approche, mais si le projet existe depuis un certain temps, les chances que cette attitude soit adoptée sont faibles. L'écoute est le meilleur moyen de savoir ce dont le projet a besoin.
1. **S'abonner à une liste de diffusion** : Pour de nombreux projets, la liste de diffusion est le principal moyen de communication sur le développement du projet. Dans les grands projets, il existe de nombreuses listes de diffusion. Par exemple, le projet PostgreSQL a pas moins de 12 listes orientées utilisateurs et six listes de développeurs sur sa page de listes de diffusion. Je vous suggère de suivre la liste principale orientée utilisateurs et la liste principale de développeurs pour commencer à écouter.
2. **Suivre un blog** : Les blogs tenus par les développeurs principaux donnent souvent des informations sur les prochaines versions et sur les étapes nécessaires pour y parvenir. Un site planet regroupe des nouvelles et des articles de blog provenant de nombreuses sources liées au projet. S'il existe un site planet, comme planet.gnome.org ou planet.mysql.com, commencez par là. Il suffit de chercher "planet" dans Google.
3. **Rejoindre un canal IRC** : De nombreux projets open source disposent de canaux IRC (Internet relay chat) dédiés où les développeurs et les utilisateurs se retrouvent pour discuter des problèmes et du développement. Consultez le site web du projet pour connaître le nom du canal et le réseau IRC sur lequel il se trouve.
4. **Travailler avec des tickets**: Le code est au cœur de tout projet open source, mais il ne faut pas croire que l'écriture de code est la seule façon de contribuer. La maintenance du code et des systèmes qui l'entourent est souvent négligée dans la course à la création de nouvelles fonctionnalités et à la correction des bogues. Ces domaines sont un moyen facile de mettre un pied dans un projet. La plupart des projets disposent d'un système de tickets de dépannage visible par tous, lié à la page d'accueil du site web du projet et inclus dans la documentation. Il s'agit du principal canal de communication entre les utilisateurs et les développeurs. Le maintenir à jour est un excellent moyen d'aider le projet. Il se peut que vous deviez obtenir des autorisations spéciales dans le système de tickets, que la plupart des chefs de projet seront heureux de vous accorder lorsque vous direz que vous voulez aider à nettoyer les tickets.
5. **Diagnostiquer un bogue** : Les bogues sont souvent mal signalés. Le diagnostic et le triage d'un bogue peuvent aider les développeurs à gagner du temps en leur permettant de comprendre les spécificités du problème. Si un utilisateur signale que "le logiciel ne fonctionne pas lorsque je fais X", prenez le temps d'analyser les détails de ce problème. Est-il reproductible ? Pouvez-vous créer une série d'étapes pour provoquer le problème de manière répétée ? Pouvez-vous circonscrire le problème, par exemple s'il ne se produit que sur un navigateur et pas sur un autre, ou sur une distribution et pas sur une autre ?
Même si vous ne savez pas ce qui cause le problème, l'effort que vous faites pour réduire les circonstances permet à quelqu'un d'autre de le résoudre plus facilement. Quoi que vous découvriez, ajoutez-le au ticket dans le système de gestion des bogues pour que tout le monde puisse le voir.
6. **Fermer les bogues corrigés** : Il arrive souvent que des bogues soient corrigés dans la base de code, mais que les tickets signalés à leur sujet ne soient pas mis à jour dans le système de gestion des tickets. Le nettoyage de ces bogues peut prendre du temps, mais il est précieux pour l'ensemble du projet.
Commencez par interroger le système de tickets pour les tickets datant de plus d'un an et voyez si le bogue existe toujours. Consultez le journal des modifications de la version du projet pour voir si le bogue a été corrigé et s'il peut être fermé. Si l'on sait qu'il a été corrigé, notez le numéro de version dans le ticket et fermez-le.
Essayez de recréer le bogue avec la dernière version du logiciel. S'il ne peut pas être recréé avec la dernière version, notez-le dans le ticket et fermez-le. S'il existe toujours, notez-le également dans le ticket et laissez-le ouvert.
Travailler avec du code Des programmeurs de tous les niveaux d'expérience peuvent aider à développer le code du projet. Ne pensez pas que vous devez être un génie du codage pour apporter une réelle contribution à votre projet favori.
Si votre travail consiste à modifier le code, renseignez-vous sur la méthode utilisée par le projet pour obtenir le code des contributeurs. Chaque projet a son propre flux de travail, alors renseignez-vous sur la façon de procéder avant de commencer à soumettre du code.
Par exemple, le projet PostgreSQL est très rigoureux dans son processus : Les modifications de code sont envoyées sous forme de correctifs à une liste de diffusion où les développeurs principaux examinent minutieusement chaque aspect du changement. À l'autre extrémité, on trouve un projet comme Parrot, où il est facile d'obtenir des privilèges de validation pour la base de code. Si le projet utilise GitHub, il peut y avoir un flux de travail qui utilise la fonction de demande d'extraction de GitHub. Il n'y a pas deux projets identiques.
Chaque fois que vous modifiez du code, veillez à agir en tant que membre responsable de la communauté et à conserver un style de code qui corresponde au reste de la base de code. Le code que vous ajoutez ou modifiez doit ressembler au reste. Vous pouvez ne pas aimer le style des accolades ou la gestion des espaces pour l'indentation, mais il est impoli de soumettre une modification de code qui ne correspond pas aux normes existantes. Cela revient à dire : "Je n'aime pas votre style, et je pense que le mien est meilleur, alors vous devriez le faire à ma façon".
7. **Tester une version bêta ou une "release candidate"** : Tout projet conçu pour fonctionner sur plusieurs plateformes peut rencontrer toutes sortes de problèmes de portabilité. Lorsqu'une version approche et qu'une version bêta ou candidate est publiée, le chef de projet espère qu'elle sera testée par de nombreuses personnes différentes sur de nombreuses plateformes différentes. Vous pouvez être l'une de ces personnes et contribuer à faire en sorte que le paquetage fonctionne sur votre plateforme.
En général, il suffit de télécharger, de compiler et de tester le logiciel, mais la valeur pour le projet peut être énorme si vous utilisez une distribution ou un matériel peu courant. Le simple fait de signaler que la compilation et le test fonctionnent permet aux chefs de projet de savoir que la version imminente est solide.
8. **Corriger un bogue** : C'est généralement par là que commencent les contributeurs désireux de travailler sur le code. C'est simple : Trouvez un bogue intéressant dans le système de tickets et essayez de le corriger dans le code. Documentez la correction dans le code si cela est approprié. C'est une bonne idée d'ajouter un test à la suite de tests pour tester la partie du code que vous avez corrigée ; certains projets exigent que les corrections de bogues incluent des tests. Prenez des notes pendant que vous fouillez dans cette base de code inconnue. Même si vous ne parvenez pas à corriger le bogue, documentez dans le ticket ce que vous avez découvert dans le cadre de la tentative de correction. Ce que vous trouvez aide ceux qui viennent après vous.
9. **Écrire un test**: La plupart des projets ont une suite de tests qui teste le code, mais il est difficile d'imaginer une suite de tests qui ne pourrait pas être complétée par d'autres tests. Utilisez un outil de couverture des tests comme gcov pour le C, ou Devel::Cover pour Perl pour identifier les zones du code source qui ne sont pas testées par la suite de tests. Ensuite, ajoutez un test à la suite pour couvrir ces zones.
10. **Faire taire un avertissement du compilateur** : Le processus de compilation de nombreux projets basés sur le langage C fait souvent apparaître à l'écran un avertissement du compilateur. Ces avertissements ne sont généralement pas des indicateurs d'un problème, mais ils peuvent y ressembler. Un trop grand nombre d'avertissements peut donner l'impression que le compilateur crie au loup. Vérifiez si le code ne cache pas un bogue. Si ce n'est pas le cas, la modification du code source pour le rendre silencieux permet de dissimuler ces faux positifs.
11. **Ajouter un commentaire** : Lorsque vous fouillez dans le code, il se peut que vous trouviez des points qui prêtent à confusion. Il y a de fortes chances que si vous avez été dérouté, d'autres le seront aussi. Documentez-les dans le code et soumettez un correctif. Travailler avec la documentation La documentation est généralement la partie d'un projet qui est la plus négligée. Elle peut aussi souffrir d'avoir été écrite du point de vue de ceux qui connaissent bien le projet, plutôt qu'à travers les yeux de quelqu'un qui vient de s'y lancer. Si vous avez déjà lu la documentation d'un projet et que vous vous êtes dit : "C'est comme si ce manuel s'attendait à ce que je sache déjà comment utiliser ce paquet", vous savez de quoi je parle. Souvent, un regard neuf peut mettre en évidence des lacunes dans la documentation que les personnes proches du projet ne remarquent pas.
12. **Create an example** : There is no project that has too many how-to examples. Whether it's a web API, a library of routines, a GUI app like Gimp or a command line tool, a good example of proper usage can more clearly and quickly explain proper usage of software than pages of documentation. For an API or library, create an example program that uses the tool. This could even be extracted from code you've written, trimmed down to the bare necessities. For a tool, show real-world examples of how you've used it in your daily life. If you’re visually oriented, consider creating a screen-capture of an important process, such as how to install the application.
Travailler avec la communauté L'open source n'est qu'une partie du code. C'est la communauté qui fait fonctionner l'open source. Voici comment vous pouvez contribuer à son développement
13. **Répondre à une question** : La meilleure façon de contribuer à la construction de la communauté est d'aider les autres. Répondre à une question, en particulier à celle d'un débutant, est essentiel pour aider le projet à se développer et à prospérer. Le temps que vous prenez pour aider un débutant, même s'il pose une question à laquelle vous pourriez facilement répondre par un rapide "RTFM", vous permet de devenir un membre actif de la communauté. Tout le monde commence quelque part, et les projets ont besoin d'un afflux constant de personnes pour rester dynamiques.
14. **Rédigez un article de blog** : Si vous avez un blog, écrivez sur vos expériences avec le projet que vous utilisez. Racontez un problème que vous avez rencontré en utilisant le logiciel et ce que vous avez fait pour le résoudre. Vous apporterez une double aide, en contribuant à maintenir le projet dans l'esprit des personnes qui vous entourent et en créant une trace pour toute personne qui, à l'avenir, sera confrontée à votre problème et cherchera la réponse sur le web. (Un blog relatant vos aventures techniques est également un excellent moyen de montrer votre expérience concrète du logiciel en question la prochaine fois que vous chercherez un emploi dans ce domaine).
15. **Améliorer un site web** : Si vous avez des compétences en conception de sites web et que vous pouvez aider à améliorer le site web, et donc l'image du projet auprès du public, c'est du temps bien utilisé. Le projet pourrait peut-être bénéficier d'une refonte graphique ou d'un logo pour l'identifier. Il s'agit peut-être de compétences qui font défaut à la communauté. Je sais que j'aimerais beaucoup avoir de l'aide en matière de conception graphique pour les sites web de mes projets.
16. **Rédiger de la documentation technique** : Si vous pouvez écrire sur le fonctionnement d'une application ou d'un logiciel, vous pouvez rédiger de la documentation technique à son sujet. En particulier pour les projets open source qui cherchent à mettre à jour, réorganiser, développer ou créer des documents techniques destinés au grand public. Plus vous écrivez en anglais simple, mieux c'est. Le plus intéressant, c'est qu'il n'est pas nécessaire d'être programmeur pour rédiger des documents techniques.
Surtout, écoutez ce que disent les gens autour de vous. Voyez si vous pouvez reconnaître un besoin pressant. Par exemple, récemment, sur la liste de diffusion des développeurs de Parrot, il a été décidé d'utiliser GitHub comme système de tickets d'incident, abandonnant l'ancienne installation de Trac qu'ils avaient. Certaines personnes se sont opposées à cette décision car il n'y avait aucun moyen de convertir les tickets au système de GitHub. Après une journée de discussions, j'ai pris la parole et j'ai dit : "Et si j'écrivais un convertisseur ?". Les gens étaient ravis de l'idée. J'ai pris le temps d'écrire un programme de conversion pour les plus de 450 tickets, de sorte que nous n'avons rien perdu de l'historique de nos tickets. Ce fut un grand succès. J'ai pu apporter ma contribution, et les développeurs principaux sont restés concentrés sur leur travail sur Parrot.
17. **Enseigner et aider les autres** : La meilleure façon d'en savoir plus sur un sujet est d'essayer de l'enseigner. Le meilleur professeur est celui qui peut expliquer des choses complexes avec des exemples simples. Vous devez donc essayer d'être le meilleur professeur pour être le meilleur apprenant et le meilleur dans votre monde de programmation. Enseigner aux autres vous permettra de vous sentir mieux dans votre peau et vous aidera à acquérir de meilleures compétences et connaissances dans votre profession. Lorsque vous recevez de l'aide de quelqu'un, ne la gardez pas pour vous, partagez-la avec les autres. Faites du monde un endroit où il fait bon vivre.
docs/additional-material/Things a non Programmer can do.md
+124
View File
@@ -0,0 +1,124 @@
# Things a non Programmer can do
## Start listening
Everything in open source involves other people.
You're looking to join a team, and that means understanding the community and how it works.
Walking in to a project and saying "Hi, here's what I think this project should be doing" is usually not taken as a good thing.
Some projects may welcome that sort of approach, but if the project has been running a while, the chances of that attitude being embraced are small.
**Listening is the best way to know what the project needs.**
1. **Join a mailing list**: For many projects, the mailing list is the main conduit of communication about the development of the project.
On large projects, there are many mailing lists to choose from.
For example, the PostgreSQL project has no fewer than 12 user-oriented lists and six developer lists on its mailing list page.
I suggest you follow the main user-oriented list and the core developer list in which to start listening.
2. **Follow a blog**: Blogs maintained by core developers often give information about what's coming up in future releases,
and what it's taken to get there. A planet site aggregates news and blog entries from many sources related to the project.
If there is a planet site, like planet.gnome.org or planet.mysql.com, start there. Just search Google for "planet <projectname>."
3. **Join an IRC channel**: Many open source projects have dedicated Internet relay chat (IRC) channels where developers and users hang out to discuss problems and development.
Check the project's website for the details of what the channel is called and what IRC network it's found on.
**Work with Tickets**
Code is the heart of any open source project, but don't think that writing code is the only way to contribute.
Maintenance of code and the systems surrounding the code often are neglected in the rush to create new features and to fix bugs.
Look to these areas as an easy way to get your foot into a project.
Most projects have a publicly visible trouble ticket system, linked from the front page of the project's website and included in the documentation.
It's the primary conduit of communication between the users and the developers. Keeping it current is a great way to help the project.
You may need to get special permissions in the ticketing system, which most project leaders will be glad to give you when you say you want to help clean up the tickets.
4. **Diagnose a bug**: Bugs are often poorly reported.
Diagnosing and triaging a bug can help save the developers time with the legwork of figuring out the specifics of the problem.
If a user reported, "The software doesn't work when I do X," spend some time to figure out the specifics of what goes into that problem.
Is it repeatable? Can you create a set of steps to cause the problem repeatedly? Can you narrow down the problem, such as only happening on one browser but not another, or one distro but not another?
Even if you don't know what causes the problem, the effort you put into narrowing down the circumstances makes it easier for someone else to fix it.
Whatever you discover, add it to the ticket in the bug system for all to see.
5. **Close fixed bugs**: Often bugs are fixed in the codebase but tickets reported about them don’t get updated in the ticketing system.
Cleaning up this cruft can be time-consuming, but it's valuable to the whole project.
Start by querying the ticket system for tickets older than a year and see if the bug still exists.
Check the project's release change log to see if the bug was fixed and can be closed.
If it's known to be fixed, note the version number in the ticket and close it.
Try to recreate the bug with the latest version of the software.
If it can't be recreated with the latest version, note that in the ticket and close it.
If it still exists, note that in the ticket as well and leave it open.
Working with Code
Programmers of all experience levels can help with the code in the project.
Don't think that you have to be a coding genius to make real contributions to your favorite project.
If your work involves modification to the code, investigate the method that the project uses for getting code from contributors.
Each project has its own workflow, so ask about how to do it before you set out to submit code.
For example, the PostgreSQL project is very rigorous in its process: Code modifications are sent in patch form to a mailing list where core developers scrutinize every aspect of the change. On the other end is a project like Parrot where it's easy to get commit privileges to the codebase. If the project uses GitHub, there may be a workflow that uses the pull request feature of GitHub. No two projects are the same.
Whenever you modify code, make sure that you act as a responsible member of the community and keep your code style to match the rest of the codebase. The code you add or modify should look like the rest. You might not like the bracing style or the handling of spaces for indentation, but it's rude to submit a code change that doesn't match the existing standards. It's the same as saying "I don't like your style, and I think mine is better, so you should do it my way."
6. **Test a beta or release candidate**: Any project that's designed to run on multiple platforms can have all sorts of portability problems.
When a release approaches and a beta or release candidate is published, the project leader hopes that it will be tested by many different people on many different platforms.
You can be one of those people and help ensure that the package works on your platform.
Typically you only need to download, build, and test the software, but the value to the project can be huge if you're on an uncommon distribution or hardware.
Just reporting back that the build and test works helps the project leaders know that the impending release is solid.
7. **Fix a bug**: This is usually where contributors wanting to get working on code start.
It’s simple: Find an interesting-sounding bug in the ticket system and try to fix it in the code.
Document the fix in the code if it's appropriate.
It's a good idea to add a test to the test suite to test the spot of code you fixed; some projects require bug fixes to include tests. Keep notes as you poke around this unfamiliar codebase. Even if you aren't able to fix the bug, document in the ticket what you discovered as part of the fix attempt. What you find helps those who come after you.
8. **Write a test**: Most projects have a test suite that tests the code, but it's hard to imagine a test suite that couldn't have more tests added to it.
Use a test coverage tool like gcov for C, or Devel::Cover for Perl to identify areas in the source code that aren't tested by the test suite.
Then, add a test to the suite to cover it.
9. **Silence a compiler warning**: The build process for many C-based projects often spew the odd compiler warning flag to the screen.
These warnings are usually not indicators of a problem, but they can look like it.
Having too many warnings can make the compiler sound like it's crying wolf.
Check to see if the code could actually be hiding a bug. If not, modifying the source to silence helps to hide these false positives.
10. **Add a comment**:
When you're digging through the code, you may find some spots that are confusing.
Chances are if you were confused, others will be as well. Document them in the code and submit a patch.
Work with Documentation
Documentation is typically the part of a project that gets short shrift.
It also can suffer from having been written from the point of view of those who are familiar with the project, rather than through the eyes of someone just getting into it.
If you've ever read docs for a project where you think, "It's as though this manual expects that I already know how to use the package," you know what I'm talking about.
Often a set of fresh eyes can point out deficiencies in the documentation that those close to the project don't notice.
11. **Create an example**: There is no project that has too many how-to examples.
Whether it's a web API, a library of routines, a GUI app like Gimp or a command line tool,
a good example of proper usage can more clearly and quickly explain proper usage of software than pages of documentation.
For an API or library, create an example program that uses the tool. This could even be extracted from code you've written, trimmed down to the bare necessities.
For a tool, show real-world examples of how you've used it in your daily life. If you’re visually oriented,
consider creating a screen-capture of an important process, such as how to install the application.
Work with Community
Open source is only partly about code. Community makes open source work. Here are ways you can help build it up.
12. **Answer a question**: The best way to help build the community is by helping others.
Answering a question, especially from someone who is just getting their feet wet, is crucial to helping the project grow and thrive.
The time you take to help a beginner, even if they're asking a question where you could easily throw back a quick "RTFM," pays off down the road in getting another active member of the community.
Everyone starts out somewhere, and projects need a constant inflow of people if they're to stay vital.
13. **Write a blog post**:
If you've got a blog, write about your experiences with the project that you're using.
Tell about a problem you faced using the software and what you did to solve it.
You'll be helping in two ways, both by helping keep the project on the minds of others around you,
and by creating a record for anyone else who has your problem in the future and searches the web for the answer.
(A blog of your technical adventures is also an excellent way to show real-world experience with the software in question next time you go hunting for a job using it.)
14. **Improve a website**:
If you've got skills in web design and can help improve the website, and thus the public-facing image of the project, that's time well spent.
Perhaps the project could use a graphic overhaul, or a logo to identify the project.
These may be skills lacking in the community. I know I'd love it if I could get some graphic design help on my projects' websites.
15. **Write technical documentation**
If you can write about how an application or piece of software works, you could write technical documentation about it. Especially open source projects that are looking to update, revamp, expand, or create technical docs for the general public to read. The more you write in plain english, the better. The best part, you don't have to be a programmer to write technical docs.
Most of all, listen to what people around you discuss. See if you can recognize a pressing need. For instance, recently on the Parrot developers' mailing list, it was decided to use GitHub as the trouble ticket system, abandoning the old Trac installation they had. Some people were against the move because there was no way to convert the tickets to GitHub's system. After a day of back and forth arguing, I piped up and said "How about if I write a converter?" People were thrilled at the idea. I spent the time to write a conversion program for the 450+ tickets, so we lost none of our ticket history. It was a great success. I got to pitch in, and the core developers stayed focused on the business of working on Parrot.
16. **Teach and Help others**:
The best way to learn more about a topic is to try to teach it.
The best teacher is the one who can explain complex stuff with simple examples. So you need to try to be the best teacher to be the best learner and the best in your programming world. Teaching others will make you feel better about yourself and it will help you get better skills and knowledge in your profession. When you get help from someone don't keep it to yourself share it with others. Make the world a better place to live.
docs/additional-material/Things a non Programmer can do.ta.md
+157
View File
@@ -0,0 +1,157 @@
# புரோகிராமர் அல்லாதவர் செய்யக்கூடிய விஷயங்கள்
## கேட்கத் தொடங்குங்கள்
திறந்த மூலத்தில் உள்ள அனைத்தும் மற்றவர்களை உள்ளடக்கியது.
நீங்கள் ஒரு குழுவில் சேர விரும்புகிறீர்கள், அதாவது சமூகத்தையும் அது எவ்வாறு செயல்படுகிறது என்பதையும் புரிந்துகொள்வது.
ஒரு ப்ராஜெக்ட்டில் நுழைந்து, "ஹாய், இதோ இந்த ப்ராஜெக்ட் செய்ய வேண்டும் என்று நான் நினைக்கிறேன்" என்று சொல்வது பொதுவாக நல்ல விஷயமாக எடுத்துக்கொள்ளப்படுவதில்லை.
சில திட்டங்கள் அந்த வகையான அணுகுமுறையை வரவேற்கலாம், ஆனால் திட்டம் சிறிது நேரம் இயங்கிக்கொண்டிருந்தால், அந்த அணுகுமுறை ஏற்றுக்கொள்ளப்படுவதற்கான வாய்ப்புகள் சிறியவை.
**திட்டத்திற்கு என்ன தேவை என்பதை அறிய சிறந்த வழி கேட்பது.**
1. **அஞ்சல் பட்டியலில் சேரவும்**: பல திட்டங்களுக்கு, திட்டத்தின் மேம்பாடு பற்றிய தகவல் பரிமாற்றத்தின் முக்கிய வழித்தடமாக அஞ்சல் பட்டியல் உள்ளது.
பெரிய திட்டங்களில், தேர்வு செய்ய பல அஞ்சல் பட்டியல்கள் உள்ளன.
எடுத்துக்காட்டாக, PostgreSQL திட்டமானது அதன் அஞ்சல் பட்டியல் பக்கத்தில் 12 பயனர் சார்ந்த பட்டியல்களையும் ஆறு டெவலப்பர் பட்டியல்களையும் கொண்டிருக்கவில்லை.
முக்கிய பயனர் சார்ந்த பட்டியலையும், கேட்கத் தொடங்கும் முக்கிய டெவலப்பர் பட்டியலையும் நீங்கள் பின்பற்ற பரிந்துரைக்கிறேன்.
2. **ஒரு வலைப்பதிவைப் பின்தொடரவும்**: முக்கிய டெவலப்பர்களால் பராமரிக்கப்படும் வலைப்பதிவுகள் எதிர்கால வெளியீடுகளில் என்ன வரப்போகிறது என்பது பற்றிய தகவல்களை அடிக்கடி தருகிறது,
மற்றும் அங்கு செல்ல என்ன எடுக்கப்பட்டது. திட்டத்துடன் தொடர்புடைய பல மூலங்களிலிருந்து செய்திகள் மற்றும் வலைப்பதிவு உள்ளீடுகளை ஒரு கிரக தளம் ஒருங்கிணைக்கிறது.
planet.gnome.org அல்லது planet.mysql.com போன்ற கிரக தளம் இருந்தால், அங்கேயே தொடங்கவும். "planet <projectname>" என்று கூகுளில் தேடினால் போதும்.
3. **IRC சேனலில் சேரவும்**: பல ஓப்பன் சோர்ஸ் திட்டங்களில் டெவலப்பர்கள் மற்றும் பயனர்கள் பிரச்சனைகள் மற்றும் மேம்பாடுகளைப் பற்றி விவாதிக்க பிரத்யேக இணைய ரிலே அரட்டை (IRC) சேனல்கள் உள்ளன.
சேனல் என்ன அழைக்கப்படுகிறது மற்றும் எந்த IRC நெட்வொர்க்கில் உள்ளது என்ற விவரங்களுக்கு திட்டத்தின் இணையதளத்தைப் பார்க்கவும்.
**டிக்கெட்டுகளுடன் வேலை செய்யுங்கள்**
எந்தவொரு திறந்த மூல திட்டத்திற்கும் குறியீடு தான் இதயம், ஆனால் குறியீட்டை எழுதுவது மட்டுமே பங்களிப்பதற்கான ஒரே வழி என்று நினைக்க வேண்டாம்.
புதிய அம்சங்களை உருவாக்குவதற்கும் பிழைகளை சரிசெய்வதற்குமான அவசரத்தில் குறியீட்டின் பராமரிப்பு மற்றும் குறியீட்டைச் சுற்றியுள்ள அமைப்புகள் பெரும்பாலும் புறக்கணிக்கப்படுகின்றன.
ஒரு திட்டத்தில் உங்கள் பாதத்தைப் பெறுவதற்கான எளிதான வழியாக இந்தப் பகுதிகளைப் பாருங்கள்.
பெரும்பாலான ப்ராஜெக்ட்கள் பொதுவில் காணக்கூடிய பிரச்சனை டிக்கெட் அமைப்பைக் கொண்டுள்ளன, இது திட்டத்தின் இணையதளத்தின் முதல் பக்கத்திலிருந்து இணைக்கப்பட்டு ஆவணத்தில் சேர்க்கப்பட்டுள்ளது.
இது பயனர்களுக்கும் டெவலப்பர்களுக்கும் இடையிலான தொடர்புக்கான முதன்மையான வழியாகும். அதை தற்போதைய நிலையில் வைத்திருப்பது திட்டத்திற்கு உதவ ஒரு சிறந்த வழியாகும்.
டிக்கெட் அமைப்பில் நீங்கள் சிறப்பு அனுமதிகளைப் பெற வேண்டியிருக்கலாம், பெரும்பாலான திட்டத் தலைவர்கள் டிக்கெட்டுகளை சுத்தம் செய்ய நீங்கள் உதவ விரும்புகிறீர்கள் என்று நீங்கள் கூறும்போது மகிழ்ச்சியுடன் வழங்குவார்கள்.
4. **பிழையைக் கண்டறிதல்**: பிழைகள் பெரும்பாலும் மோசமாகப் புகாரளிக்கப்படுகின்றன.
பிழையைக் கண்டறிதல் மற்றும் சோதனை செய்வது, பிரச்சனையின் பிரத்தியேகங்களைக் கண்டறிவதன் மூலம் டெவலப்பர்களின் நேரத்தைச் சேமிக்க உதவும்.
ஒரு பயனர், "நான் X செய்யும் போது மென்பொருள் வேலை செய்யாது" எனப் புகாரளித்தால், அந்தச் சிக்கலில் என்ன நடக்கிறது என்பதைத் தெரிந்துகொள்ள சிறிது நேரம் செலவிடுங்கள்.
இது மீண்டும் மீண்டும் செய்யக்கூடியதா? மீண்டும் மீண்டும் சிக்கலை ஏற்படுத்துவதற்கான படிகளின் தொகுப்பை உருவாக்க முடியுமா? ஒரு உலாவியில் மட்டும் நடப்பது மற்றொன்று அல்ல, அல்லது ஒரு டிஸ்ட்ரோ ஆனால் மற்றொன்றில் நடக்காதது போன்ற சிக்கலைக் குறைக்க முடியுமா?
பிரச்சனைக்கு என்ன காரணம் என்று உங்களுக்குத் தெரியாவிட்டாலும், சூழ்நிலைகளைக் குறைப்பதில் நீங்கள் எடுக்கும் முயற்சி, அதைச் சரிசெய்வதை மற்றொருவருக்கு எளிதாக்குகிறது.
நீங்கள் எதைக் கண்டறிந்தாலும், அதை அனைவரும் பார்க்க, பிழை அமைப்பில் உள்ள டிக்கெட்டில் சேர்க்கவும்.
5. **நிலையான பிழைகளை மூடு**: பெரும்பாலும் பிழைகள் கோட்பேஸில் சரி செய்யப்படும் ஆனால் அவற்றைப் பற்றி அறிவிக்கப்படும் டிக்கெட்டுகள் டிக்கெட் அமைப்பில் புதுப்பிக்கப்படுவதில்லை.
இந்த க்ராஃப்ட்டை சுத்தம் செய்வது நேரத்தை எடுத்துக்கொள்ளும், ஆனால் இது முழு திட்டத்திற்கும் மதிப்புமிக்கது.
ஒரு வருடத்திற்கும் மேலான டிக்கெட்டுகளுக்கான டிக்கெட் முறையை வினவுவதன் மூலம் தொடங்கி, பிழை இன்னும் இருக்கிறதா என்று பார்க்கவும்.
பிழை சரி செய்யப்பட்டதா மற்றும் மூட முடியுமா என்பதைப் பார்க்க, திட்டத்தின் வெளியீட்டு மாற்றப் பதிவைச் சரிபார்க்கவும்.
அது சரி செய்யப்பட்டது எனத் தெரிந்தால், டிக்கெட்டில் உள்ள பதிப்பு எண்ணைக் குறிப்பிட்டு அதை மூடவும்.
மென்பொருளின் சமீபத்திய பதிப்பைக் கொண்டு பிழையை மீண்டும் உருவாக்க முயற்சிக்கவும்.
சமீபத்திய பதிப்பில் அதை மீண்டும் உருவாக்க முடியாவிட்டால், டிக்கெட்டில் அதைக் கவனித்து அதை மூடவும்.
அது இன்னும் இருந்தால், டிக்கெட்டிலும் அதைக் கவனித்து அதைத் திறந்து விடுங்கள்.
குறியீட்டுடன் பணிபுரிதல்
அனைத்து அனுபவ நிலைகளிலும் உள்ள புரோகிராமர்கள் திட்டத்தில் உள்ள குறியீட்டிற்கு உதவலாம்.
உங்களுக்குப் பிடித்த திட்டத்திற்கு உண்மையான பங்களிப்பைச் செய்ய நீங்கள் ஒரு குறியீட்டு மேதையாக இருக்க வேண்டும் என்று நினைக்க வேண்டாம்.
உங்கள் பணியானது குறியீட்டை மாற்றியமைப்பதை உள்ளடக்கியிருந்தால், பங்களிப்பாளர்களிடமிருந்து குறியீட்டைப் பெற திட்டம் பயன்படுத்தும் முறையை ஆராயுங்கள்.
ஒவ்வொரு திட்டத்திற்கும் அதன் சொந்த பணிப்பாய்வு உள்ளது, எனவே குறியீட்டை சமர்ப்பிக்கும் முன் அதை எப்படி செய்வது என்று கேளுங்கள்.
எடுத்துக்காட்டாக, PostgreSQL திட்டம் அதன் செயல்பாட்டில் மிகவும் கடுமையானது: குறியீடு மாற்றங்கள் இணைப்புப் பட்டியலில் அஞ்சல் பட்டியலில் அனுப்பப்படுகின்றன, அங்கு முக்கிய டெவலப்பர்கள் மாற்றத்தின் ஒவ்வொரு அம்சத்தையும் ஆய்வு செய்கிறார்கள். மறுமுனையில் கிளி போன்ற ஒரு திட்டம் உள்ளது, அங்கு கோட்பேஸுக்கு உறுதி சலுகைகளைப் பெறுவது எளிது. திட்டம் GitHub ஐப் பயன்படுத்தினால், GitHub இன் இழுக்கும் கோரிக்கை அம்சத்தைப் பயன்படுத்தும் பணிப்பாய்வு இருக்கலாம். இரண்டு திட்டங்களும் ஒரே மாதிரியானவை அல்ல.
நீங்கள் குறியீட்டை மாற்றும் போதெல்லாம், சமூகத்தின் பொறுப்பான உறுப்பினராகச் செயல்படுவதை உறுதிசெய்து, மீதமுள்ள குறியீட்டுத் தளத்துடன் பொருந்துமாறு உங்கள் குறியீட்டு பாணியை வைத்திருக்கவும். நீங்கள் சேர்க்கும் அல்லது மாற்றியமைக்கும் குறியீடு மற்றதைப் போலவே இருக்க வேண்டும். பிரேசிங் ஸ்டைல் ​​அல்லது உள்தள்ளலுக்கான இடைவெளிகளைக் கையாள்வது உங்களுக்குப் பிடிக்காமல் இருக்கலாம், ஆனால் தற்போதுள்ள தரநிலைகளுடன் பொருந்தாத குறியீட்டு மாற்றத்தைச் சமர்ப்பிப்பது முரட்டுத்தனமானது. "உங்கள் பாணி எனக்குப் பிடிக்கவில்லை, என்னுடையது சிறந்தது என்று நான் நினைக்கிறேன், எனவே நீங்கள் அதை என் வழியில் செய்ய வேண்டும்" என்று சொல்வதும் ஒன்றுதான்.
6. **பீட்டாவைச் சோதிக்கவும் அல்லது வேட்பாளரை வெளியிடவும்**: பல தளங்களில் இயங்கும் வகையில் வடிவமைக்கப்பட்ட எந்தத் திட்டமும் எல்லா வகையான பெயர்வுத்திறன் சிக்கல்களையும் கொண்டிருக்கலாம்.
ஒரு வெளியீடு நெருங்கி, பீட்டா அல்லது வெளியீட்டு வேட்பாளர் வெளியிடப்படும் போது, ​​அது பல்வேறு தளங்களில் பல்வேறு நபர்களால் சோதிக்கப்படும் என்று திட்டத் தலைவர் நம்புகிறார்.
நீங்கள் அந்த நபர்களில் ஒருவராக இருக்கலாம் மற்றும் உங்கள் பிளாட்ஃபார்மில் தொகுப்பு செயல்படுவதை உறுதிசெய்ய உதவலாம்.
பொதுவாக நீங்கள் மென்பொருளைப் பதிவிறக்கம் செய்து, உருவாக்கி, சோதித்துப் பார்க்க வேண்டும், ஆனால் நீங்கள் அசாதாரணமான விநியோகம் அல்லது வன்பொருளில் இருந்தால் திட்டத்திற்கான மதிப்பு மிகப்பெரியதாக இருக்கும்.
உருவாக்கம் மற்றும் சோதனை வேலைகள் என்று அறிக்கையிடுவது, வரவிருக்கும் வெளியீடு உறுதியானது என்பதை திட்டத் தலைவர்கள் அறிய உதவுகிறது.
7. **பிழையை சரிசெய்தல்**: பொதுவாக, பங்களிப்பாளர்கள் குறியீட்டில் வேலை செய்ய விரும்பும் இடமாகும்.
இது எளிதானது: டிக்கெட் அமைப்பில் ஒரு சுவாரஸ்யமான-ஒலி பிழையைக் கண்டறிந்து குறியீட்டில் அதை சரிசெய்ய முயற்சிக்கவும்.
திருத்தம் பொருத்தமானதாக இருந்தால் குறியீட்டில் ஆவணப்படுத்தவும்.
நீங்கள் சரிசெய்த குறியீட்டின் இடத்தைச் சோதிக்க, சோதனைத் தொகுப்பில் ஒரு சோதனையைச் சேர்ப்பது நல்லது; சோதனைகளைச் சேர்க்க சில திட்டங்களுக்கு பிழை திருத்தங்கள் தேவை. இந்த அறிமுகமில்லாத கோட்பேஸை சுற்றிக் கொண்டே குறிப்புகளை வைத்துக் கொள்ளுங்கள். பிழையை உங்களால் சரிசெய்ய முடியாவிட்டாலும், திருத்த முயற்சியின் ஒரு பகுதியாக நீங்கள் கண்டறிந்ததை டிக்கெட்டில் பதிவு செய்யவும். நீங்கள் கண்டுபிடிப்பது உங்களுக்குப் பின் வருபவர்களுக்கு உதவும்.
8. **சோதனை எழுது**: பெரும்பாலான திட்டங்களில் குறியீட்டைச் சோதிக்கும் ஒரு சோதனைத் தொகுப்பு உள்ளது, ஆனால் கூடுதல் சோதனைகளைச் சேர்க்க முடியாத ஒரு சோதனைத் தொகுப்பைக் கற்பனை செய்வது கடினம்.
சோதனைத் தொகுப்பால் சோதிக்கப்படாத மூலக் குறியீட்டில் உள்ள பகுதிகளைக் கண்டறிய, Gcov for C அல்லது Devel::Cover for Perl போன்ற சோதனைக் கவரேஜ் கருவியைப் பயன்படுத்தவும்.
பின்னர், அதை மறைக்க ஒரு சோதனையை தொகுப்பில் சேர்க்கவும்.
9. **ஒரு கம்பைலர் எச்சரிக்கையை அமைதிப்படுத்து**: பல சி-அடிப்படையிலான திட்டங்களுக்கான உருவாக்க செயல்முறை பெரும்பாலும் ஒற்றைப்படை கம்பைலர் எச்சரிக்கைக் கொடியை திரையில் செலுத்துகிறது.
இந்த எச்சரிக்கைகள் பொதுவாக ஒரு சிக்கலின் குறிகாட்டிகள் அல்ல, ஆனால் அவை அப்படியே இருக்கும்.
பல எச்சரிக்கைகள் இருப்பதால், கம்பைலர் ஓநாய் அழுவது போல் ஒலிக்கும்.
குறியீடு உண்மையில் பிழையை மறைக்கிறதா என்பதைப் பார்க்கவும். இல்லையெனில், மூலத்தை அமைதிக்கு மாற்றுவது இந்த தவறான நேர்மறைகளை மறைக்க உதவுகிறது.
10. **ஒரு கருத்தைச் சேர்**:
நீங்கள் குறியீட்டைத் தோண்டி எடுக்கும்போது, ​​குழப்பமான சில இடங்களைக் காணலாம்.
நீங்கள் குழப்பமடைந்திருந்தால், மற்றவர்களும் அவ்வாறு இருப்பதற்கான வாய்ப்புகள் உள்ளன. குறியீட்டில் அவற்றை ஆவணப்படுத்தி ஒரு பேட்சைச் சமர்ப்பிக்கவும்.
ஆவணங்களுடன் வேலை செய்யுங்கள்
ஆவணப்படுத்தல் என்பது ஒரு திட்டத்தின் ஒரு பகுதியாகும், இது குறுகிய மாற்றத்தைப் பெறுகிறது.
யாரோ ஒருவரின் பார்வையில் நுழைவதை விட, திட்டத்துடன் நன்கு தெரிந்தவர்களின் பார்வையில் எழுதப்பட்டதால் இது பாதிக்கப்படலாம்.
நீங்கள் எப்போதாவது ஒரு ப்ராஜெக்ட்டுக்கான டாக்ஸைப் படித்திருந்தால், "இந்த கையேடு எனக்கு ஏற்கனவே பேக்கேஜை எப்படி பயன்படுத்துவது என்று தெரியும் என்று எதிர்பார்க்கிறது போல் இருக்கிறது", நான் எதைப் பற்றி பேசுகிறேன் என்று உங்களுக்குத் தெரியும்.
பெரும்பாலும் புதிய கண்களின் தொகுப்பு, திட்டத்திற்கு நெருக்கமானவர்கள் கவனிக்காத ஆவணங்களில் உள்ள குறைபாடுகளை சுட்டிக்காட்டலாம்.
11. **உதாரணத்தை உருவாக்கவும்**: பல எப்படி-எப்படி-எடுத்துக்கொள்ளும் உதாரணங்களைக் கொண்ட எந்த திட்டமும் இல்லை.
இது ஒரு வலை API ஆக இருந்தாலும், நடைமுறைகளின் நூலகமாக இருந்தாலும், Gimp அல்லது கமன் போன்ற GUI ஆப்ஸாக இருந்தாலும் சரி, ஆனால் தற்போதுள்ள தரநிலைகளுடன் பொருந்தாத குறியீட்டு மாற்றத்தைச் சமர்ப்பிப்பது முரட்டுத்தனமானது. "உங்கள் பாணி எனக்குப் பிடிக்கவில்லை, என்னுடையது சிறந்தது என்று நான் நினைக்கிறேன், எனவே நீங்கள் அதை என் வழியில் செய்ய வேண்டும்" என்று சொல்வதும் ஒன்றுதான்.
6. **பீட்டாவைச் சோதிக்கவும் அல்லது வேட்பாளரை வெளியிடவும்**: பல தளங்களில் இயங்கும் வகையில் வடிவமைக்கப்பட்ட எந்தத் திட்டமும் எல்லா வகையான பெயர்வுத்திறன் சிக்கல்களையும் கொண்டிருக்கலாம்.
ஒரு வெளியீடு நெருங்கி, பீட்டா அல்லது வெளியீட்டு வேட்பாளர் வெளியிடப்படும் போது, ​​அது பல்வேறு தளங்களில் பல்வேறு நபர்களால் சோதிக்கப்படும் என்று திட்டத் தலைவர் நம்புகிறார்.
நீங்கள் அந்த நபர்களில் ஒருவராக இருக்கலாம் மற்றும் உங்கள் பிளாட்ஃபார்மில் தொகுப்பு செயல்படுவதை உறுதிசெய்ய உதவலாம்.
பொதுவாக நீங்கள் மென்பொருளைப் பதிவிறக்கம் செய்து, உருவாக்கி, சோதித்துப் பார்க்க வேண்டும், ஆனால் நீங்கள் அசாதாரணமான விநியோகம் அல்லது வன்பொருளில் இருந்தால் திட்டத்திற்கான மதிப்பு மிகப்பெரியதாக இருக்கும்.
உருவாக்கம் மற்றும் சோதனை வேலைகள் என்று அறிக்கையிடுவது, வரவிருக்கும் வெளியீடு உறுதியானது என்பதை திட்டத் தலைவர்கள் அறிய உதவுகிறது.
7. **பிழையை சரிசெய்தல்**: பொதுவாக, பங்களிப்பாளர்கள் குறியீட்டில் வேலை செய்ய விரும்பும் இடமாகும்.
இது எளிதானது: டிக்கெட் அமைப்பில் ஒரு சுவாரஸ்யமான-ஒலி பிழையைக் கண்டறிந்து குறியீட்டில் அதை சரிசெய்ய முயற்சிக்கவும்.
திருத்தம் பொருத்தமானதாக இருந்தால் குறியீட்டில் ஆவணப்படுத்தவும்.
நீங்கள் சரிசெய்த குறியீட்டின் இடத்தைச் சோதிக்க, சோதனைத் தொகுப்பில் ஒரு சோதனையைச் சேர்ப்பது நல்லது; சோதனைகளைச் சேர்க்க சில திட்டங்களுக்கு பிழை திருத்தங்கள் தேவை. இந்த அறிமுகமில்லாத கோட்பேஸை சுற்றிக் கொண்டே குறிப்புகளை வைத்துக் கொள்ளுங்கள். பிழையை உங்களால் சரிசெய்ய முடியாவிட்டாலும், திருத்த முயற்சியின் ஒரு பகுதியாக நீங்கள் கண்டறிந்ததை டிக்கெட்டில் பதிவு செய்யவும். நீங்கள் கண்டுபிடிப்பது உங்களுக்குப் பின் வருபவர்களுக்கு உதவும்.
8. **சோதனை எழுது**: பெரும்பாலான திட்டங்களில் குறியீட்டைச் சோதிக்கும் ஒரு சோதனைத் தொகுப்பு உள்ளது, ஆனால் கூடுதல் சோதனைகளைச் சேர்க்க முடியாத ஒரு சோதனைத் தொகுப்பைக் கற்பனை செய்வது கடினம்.
சோதனைத் தொகுப்பால் சோதிக்கப்படாத மூலக் குறியீட்டில் உள்ள பகுதிகளைக் கண்டறிய, Gcov for C அல்லது Devel::Cover for Perl போன்ற சோதனைக் கவரேஜ் கருவியைப் பயன்படுத்தவும்.
பின்னர், அதை மறைக்க ஒரு சோதனையை தொகுப்பில் சேர்க்கவும்.
9. **ஒரு கம்பைலர் எச்சரிக்கையை அமைதிப்படுத்து**: பல சி-அடிப்படையிலான திட்டங்களுக்கான உருவாக்க செயல்முறை பெரும்பாலும் ஒற்றைப்படை கம்பைலர் எச்சரிக்கைக் கொடியை திரையில் செலுத்துகிறது.
இந்த எச்சரிக்கைகள் பொதுவாக ஒரு சிக்கலின் குறிகாட்டிகள் அல்ல, ஆனால் அவை அப்படியே இருக்கும்.
பல எச்சரிக்கைகள் இருப்பதால், கம்பைலர் ஓநாய் அழுவது போல் ஒலிக்கும்.
குறியீடு உண்மையில் பிழையை மறைக்கிறதா என்பதைப் பார்க்கவும். இல்லையெனில், மூலத்தை அமைதிக்கு மாற்றுவது இந்த தவறான நேர்மறைகளை மறைக்க உதவுகிறது.
10. **ஒரு கருத்தைச் சேர்**:
நீங்கள் குறியீட்டைத் தோண்டி எடுக்கும்போது, ​​குழப்பமான சில இடங்களைக் காணலாம்.
நீங்கள் குழப்பமடைந்திருந்தால், மற்றவர்களும் அவ்வாறு இருப்பதற்கான வாய்ப்புகள் உள்ளன. குறியீட்டில் அவற்றை ஆவணப்படுத்தி ஒரு பேட்சைச் சமர்ப்பிக்கவும்.
ஆவணங்களுடன் வேலை செய்யுங்கள்
ஆவணப்படுத்தல் என்பது ஒரு திட்டத்தின் ஒரு பகுதியாகும், இது குறுகிய மாற்றத்தைப் பெறுகிறது.
யாரோ ஒருவரின் பார்வையில் நுழைவதை விட, திட்டத்துடன் நன்கு தெரிந்தவர்களின் பார்வையில் எழுதப்பட்டதால் இது பாதிக்கப்படலாம்.
நீங்கள் எப்போதாவது ஒரு ப்ராஜெக்ட்டுக்கான டாக்ஸைப் படித்திருந்தால், "இந்த கையேடு எனக்கு ஏற்கனவே பேக்கேஜை எப்படி பயன்படுத்துவது என்று தெரியும் என்று எதிர்பார்க்கிறது போல் இருக்கிறது", நான் எதைப் பற்றி பேசுகிறேன் என்று உங்களுக்குத் தெரியும்.
பெரும்பாலும் புதிய கண்களின் தொகுப்பு, திட்டத்திற்கு நெருக்கமானவர்கள் கவனிக்காத ஆவணங்களில் உள்ள குறைபாடுகளை சுட்டிக்காட்டலாம்.
11. **உதாரணத்தை உருவாக்கவும்**: பல எப்படி-எப்படி-எடுத்துக்கொள்ளும் உதாரணங்களைக் கொண்ட எந்த திட்டமும் இல்லை.
அது ஒரு வலை API, நடைமுறைகளின் நூலகம், Gimp போன்ற GUI ஆப்ஸ் அல்லது கட்டளை வரி கருவியாக இருந்தாலும் சரி,
முறையான பயன்பாட்டிற்கான ஒரு சிறந்த எடுத்துக்காட்டு, ஆவணங்களின் பக்கங்களை விட மென்பொருளின் சரியான பயன்பாட்டை மிகவும் தெளிவாகவும் விரைவாகவும் விளக்க முடியும்.
API அல்லது நூலகத்திற்கு, கருவியைப் பயன்படுத்தும் ஒரு எடுத்துக்காட்டு நிரலை உருவாக்கவும். இது நீங்கள் எழுதிய குறியீட்டிலிருந்து பிரித்தெடுக்கப்படலாம், தேவைக்கேற்ப குறைக்கலாம்.
ஒரு கருவிக்கு, உங்கள் அன்றாட வாழ்க்கையில் அதை எப்படிப் பயன்படுத்துகிறீர்கள் என்பதற்கான நிஜ உலக உதாரணங்களைக் காட்டுங்கள். நீங்கள் பார்வை சார்ந்தவராக இருந்தால்,
பயன்பாட்டை எவ்வாறு நிறுவுவது போன்ற முக்கியமான செயல்முறையின் திரை-பிடிப்பை உருவாக்குவதைக் கருத்தில் கொள்ளுங்கள்.
சமூகத்துடன் வேலை செய்யுங்கள்
ஓப்பன் சோர்ஸ் என்பது ஓரளவுக்கு மட்டுமே குறியீடு பற்றியது. சமூகம் திறந்த மூல வேலை செய்கிறது. நீங்கள் அதை உருவாக்க உதவும் வழிகள் இங்கே உள்ளன.
12. **கேள்விக்கு பதிலளிக்கவும்**: சமூகத்தை கட்டியெழுப்ப சிறந்த வழி மற்றவர்களுக்கு உதவுவதே.
ஒரு கேள்விக்கு பதிலளிப்பது, குறிப்பாக கால்களை நனைக்கும் ஒருவரிடமிருந்து, திட்டம் வளரவும் செழிக்கவும் உதவும்.
ஒரு தொடக்கநிலையாளருக்கு உதவ நீங்கள் எடுக்கும் நேரம், நீங்கள் விரைவாக "RTFM" ஐ எங்கே எளிதாகத் திரும்பப் பெறலாம் என்று ஒரு கேள்வியைக் கேட்டாலும், சமூகத்தின் மற்றொரு செயலில் உள்ள உறுப்பினரைப் பெறுவதற்கான பாதையைக் குறைக்கிறது.
ஒவ்வொருவரும் எங்காவது தொடங்குகிறார்கள், மேலும் அவர்கள் முக்கியமாக இருக்க வேண்டுமென்றால் திட்டங்களுக்கு மக்கள் தொடர்ந்து வர வேண்டும்.
13. **ஒரு வலைப்பதிவு இடுகையை எழுதுங்கள்**:
உங்களிடம் வலைப்பதிவு இருந்தால், நீங்கள் பயன்படுத்தும் திட்டத்தில் உங்கள் அனுபவங்களைப் பற்றி எழுதுங்கள்.
மென்பொருளைப் பயன்படுத்தி நீங்கள் எதிர்கொண்ட பிரச்சனை மற்றும் அதைத் தீர்க்க நீங்கள் என்ன செய்தீர்கள் என்று சொல்லுங்கள்.
உங்களைச் சுற்றியுள்ள மற்றவர்களின் மனதில் திட்டத்தை வைத்திருக்க உதவுவதன் மூலம், நீங்கள் இரண்டு வழிகளில் உதவுவீர்கள்.
எதிர்காலத்தில் உங்கள் பிரச்சனையை எதிர்கொண்டு அதற்கான பதிலை இணையத்தில் தேடும் எவருக்கும் ஒரு பதிவை உருவாக்குவதன் மூலம்.
(உங்கள் தொழில்நுட்ப சாகசங்களின் வலைப்பதிவு, கேள்விக்குரிய மென்பொருளின் நிஜ-உலக அனுபவத்தைக் காட்ட, அடுத்த முறை நீங்கள் வேலைக்காக வேட்டையாடச் செல்லும் ஒரு சிறந்த வழியாகும்.)
14. **ஒரு இணையதளத்தை மேம்படுத்தவும்**:
நீங்கள் வலை வடிவமைப்பில் திறமை பெற்றிருந்தால் மற்றும் வலைகளை மேம்படுத்த உதவலாம்இது, மற்றும் திட்டத்தின் பொது முகம் படம், அந்த நேரம் நன்றாக செலவிடப்பட்டது.
திட்டமானது ஒரு கிராஃபிக் மாற்றத்தை அல்லது திட்டத்தை அடையாளம் காண ஒரு லோகோவைப் பயன்படுத்தலாம்.
இவை சமூகத்தில் இல்லாத திறன்களாக இருக்கலாம். எனது திட்டப்பணிகளின் இணையதளங்களில் ஏதேனும் கிராஃபிக் டிசைன் உதவி கிடைத்தால் நான் அதை விரும்புவேன் என்று எனக்குத் தெரியும்.
15. **தொழில்நுட்ப ஆவணங்களை எழுதவும்**
ஒரு பயன்பாடு அல்லது மென்பொருள் எவ்வாறு செயல்படுகிறது என்பதைப் பற்றி நீங்கள் எழுத முடிந்தால், அதைப் பற்றிய தொழில்நுட்ப ஆவணங்களை நீங்கள் எழுதலாம். குறிப்பாக ஓப்பன் சோர்ஸ் திட்டங்கள், பொது மக்கள் படிக்கும் வகையில் தொழில்நுட்ப ஆவணங்களை புதுப்பிக்க, புதுப்பிக்க, விரிவாக்க அல்லது உருவாக்க வேண்டும். நீங்கள் சாதாரண ஆங்கிலத்தில் எவ்வளவு அதிகமாக எழுதுகிறீர்களோ, அவ்வளவு சிறந்தது. சிறந்த பகுதி, தொழில்நுட்ப ஆவணங்களை எழுத நீங்கள் ஒரு புரோகிராமராக இருக்க வேண்டியதில்லை.
எல்லாவற்றிற்கும் மேலாக, உங்களைச் சுற்றியுள்ளவர்கள் என்ன பேசுகிறார்கள் என்பதைக் கேளுங்கள். ஒரு அழுத்தமான தேவையை உங்களால் அடையாளம் காண முடியுமா என்று பாருங்கள். உதாரணமாக, சமீபத்தில் கிளி டெவலப்பர்களின் அஞ்சல் பட்டியலில், அவர்கள் வைத்திருந்த பழைய ட்ராக் நிறுவலைக் கைவிட்டு, சிக்கல் டிக்கெட் அமைப்பாக GitHub ஐப் பயன்படுத்த முடிவு செய்யப்பட்டது. டிக்கெட்டுகளை கிட்ஹப் அமைப்பிற்கு மாற்ற வழி இல்லாததால் சிலர் இந்த நடவடிக்கைக்கு எதிராக இருந்தனர். ஒரு நாள் முன்னும் பின்னுமாக வாக்குவாதத்திற்குப் பிறகு, "நான் மாற்றி எழுதினால் எப்படி?" இந்த யோசனையில் மக்கள் மகிழ்ச்சியடைந்தனர். 450+ டிக்கெட்டுகளுக்கு மாற்றும் திட்டத்தை எழுத நான் நேரத்தை செலவிட்டேன், அதனால் எங்களின் டிக்கெட் வரலாறு எதையும் இழக்கவில்லை. இது பெரும் வெற்றி பெற்றது. நான் களமிறங்கினேன், முக்கிய டெவலப்பர்கள் கிளி வேலை செய்யும் வணிகத்தில் கவனம் செலுத்தினர்.
16. **மற்றவர்களுக்குக் கற்றுக் கொடுங்கள்**:
ஒரு தலைப்பைப் பற்றி மேலும் அறிய சிறந்த வழி அதைக் கற்பிக்க முயற்சிப்பதாகும்.
சிக்கலான விஷயங்களை எளிய உதாரணங்களுடன் விளக்கக்கூடியவர் சிறந்த ஆசிரியர். எனவே நீங்கள் சிறந்த கற்பவராகவும் உங்கள் நிரலாக்க உலகில் சிறந்தவராகவும் இருக்க சிறந்த ஆசிரியராக இருக்க முயற்சிக்க வேண்டும். மற்றவர்களுக்குக் கற்பிப்பது உங்களைப் பற்றி நன்றாக உணரவைக்கும், மேலும் உங்கள் தொழிலில் சிறந்த திறன்களையும் அறிவையும் பெற உதவும். நீங்கள் ஒருவரிடமிருந்து உதவியைப் பெற்றால், அதை நீங்களே வைத்துக் கொள்ளாதீர்கள், மற்றவர்களுடன் பகிர்ந்து கொள்ளுங்கள். உலகத்தை வாழ சிறந்த இடமாக மாற்றவும்.
docs/additional-material/Things a non Programmer can do.th.md
+125
View File
@@ -0,0 +1,125 @@
#สิ่งที่คนที่ไม่ใช่โปรแกรมเมอร์สามารถทำได้
## เริ่มฟัง
ทุกสิ่งในโอเพ่นซอร์สเกี่ยวข้องกับบุคคลอื่น
คุณกำลังมองหาที่จะเข้าร่วมทีม และนั่นหมายถึงการทำความเข้าใจชุมชนและวิธีการทำงาน
การเดินเข้าไปในโปรเจ็กต์แล้วพูดว่า "สวัสดี นี่คือสิ่งที่ฉันคิดว่าโปรเจ็กต์นี้ควรทำ" มักจะไม่ถือเป็นเรื่องดี
บางโครงการอาจยินดีกับแนวทางดังกล่าว แต่หากโครงการดำเนินไประยะหนึ่งแล้ว โอกาสที่ทัศนคตินั้นจะได้รับการยอมรับก็มีน้อย
**การฟังเป็นวิธีที่ดีที่สุดในการรู้ว่าโครงการต้องการอะไร**
1. **เข้าร่วมรายชื่ออีเมล**: สำหรับหลายโครงการ รายชื่ออีเมลเป็นช่องทางหลักในการสื่อสารเกี่ยวกับการพัฒนาโครงการ
ในโครงการขนาดใหญ่ มีรายชื่อผู้รับจดหมายให้เลือกมากมาย
ตัวอย่างเช่น โครงการ PostgreSQL มีรายชื่อผู้ใช้ไม่น้อยกว่า 12 รายการ และรายชื่อนักพัฒนาอีก 6 รายการในหน้ารายชื่อผู้รับเมล
ฉันขอแนะนำให้คุณปฏิบัติตามรายการหลักที่มุ่งเน้นผู้ใช้และรายชื่อนักพัฒนาหลักที่จะเริ่มฟัง
2. **ติดตามบล็อก**: บล็อกที่ดูแลโดยนักพัฒนาหลักมักจะให้ข้อมูลเกี่ยวกับสิ่งที่จะเกิดขึ้นในอนาคต
และสิ่งที่ต้องทำเพื่อไปถึงที่นั่น ไซต์ Planet รวบรวมข่าวสารและบล็อกจากแหล่งต่างๆ ที่เกี่ยวข้องกับโครงการ
หากมีไซต์ planet เช่น planet.gnome.org หรือ planet.mysql.com ให้เริ่มต้นจากที่นั่น เพียงค้นหา Google ด้วยคำว่า "planet <projectname>"
3. **เข้าร่วมช่อง IRC**: โครงการโอเพ่นซอร์สจำนวนมากมีช่อง Internet Relay Chat (IRC) โดยเฉพาะ ซึ่งนักพัฒนาและผู้ใช้ออกไปเที่ยวเพื่อหารือเกี่ยวกับปัญหาและการพัฒนา
ตรวจสอบเว็บไซต์ของโครงการเพื่อดูรายละเอียดว่าช่องดังกล่าวเรียกว่าอะไรและพบเครือข่าย IRC ใด
**ทำงานกับตั๋ว**
โค้ดเป็นหัวใจสำคัญของโครงการโอเพ่นซอร์ส แต่อย่าคิดว่าการเขียนโค้ดเป็นเพียงวิธีเดียวที่จะมีส่วนร่วม
การบำรุงรักษาโค้ดและระบบที่อยู่รอบๆ โค้ดมักถูกละเลยในการสร้างคุณสมบัติใหม่ๆ และแก้ไขข้อบกพร่อง
มองว่าพื้นที่เหล่านี้เป็นวิธีง่ายๆ ในการก้าวเข้าสู่โครงการ
โครงการส่วนใหญ่มีระบบตั๋วแจ้งปัญหาที่เปิดเผยต่อสาธารณะ ซึ่งเชื่อมโยงจากหน้าแรกของเว็บไซต์ของโครงการและรวมอยู่ในเอกสารประกอบ
เป็นช่องทางหลักในการสื่อสารระหว่างผู้ใช้และนักพัฒนา การทำให้เป็นปัจจุบันเป็นวิธีที่ดีในการช่วยโครงการ
คุณอาจต้องได้รับสิทธิ์พิเศษในระบบตั๋ว ซึ่งหัวหน้าโครงการส่วนใหญ่ยินดีที่จะให้คุณเมื่อคุณบอกว่าต้องการช่วยทำความสะอาดตั๋ว
4. **วินิจฉัยจุดบกพร่อง**: มักมีการรายงานจุดบกพร่องไม่ดี
การวินิจฉัยและคัดแยกจุดบกพร่องสามารถช่วยให้นักพัฒนาประหยัดเวลาโดยต้องอาศัยการทำงานที่ถูกต้องในการหาลักษณะเฉพาะของปัญหา
หากผู้ใช้รายงานว่า "ซอฟต์แวร์ไม่ทำงานเมื่อฉันทำ X" ใช้เวลาสักพักเพื่อหาสาเหตุเฉพาะของปัญหานั้น
มันทำซ้ำได้หรือไม่? คุณสามารถสร้างชุดขั้นตอนเพื่อทำให้เกิดปัญหาซ้ำๆ ได้หรือไม่ คุณสามารถจำกัดปัญหาให้แคบลง เช่น เกิดขึ้นในเบราว์เซอร์เดียวแต่ไม่เกิดขึ้นอีก หรือหนึ่ง distro แต่ไม่ได้เกิดขึ้นที่อื่น
แม้ว่าคุณจะไม่รู้ว่าอะไรเป็นสาเหตุของปัญหา แต่ความพยายามที่คุณพยายามจำกัดสถานการณ์ให้แคบลงจะทำให้คนอื่นแก้ไขได้ง่ายขึ้น
สิ่งที่คุณค้นพบ เพิ่มลงในตั๋วในระบบบั๊กเพื่อให้ทุกคนได้เห็น
5. **ปิดจุดบกพร่องที่แก้ไขแล้ว**: บ่อยครั้งจุดบกพร่องได้รับการแก้ไขในโค้ดเบส แต่ตั๋วที่รายงานเกี่ยวกับจุดบกพร่องเหล่านั้นไม่ได้รับการอัปเดตในระบบตั๋ว
การทำความสะอาดสิ่งที่ค้างอยู่นี้อาจใช้เวลานาน แต่ก็มีคุณค่าต่อทั้งโครงการ
เริ่มต้นด้วยการสืบค้นระบบตั๋วสำหรับตั๋วที่มีอายุมากกว่าหนึ่งปีและดูว่ายังมีจุดบกพร่องอยู่หรือไม่
ตรวจสอบบันทึกการเปลี่ยนแปลงการเปิดตัวของโปรเจ็กต์เพื่อดูว่าจุดบกพร่องได้รับการแก้ไขและสามารถปิดได้หรือไม่
หากทราบว่าได้รับการแก้ไขแล้ว ให้จดหมายเลขเวอร์ชันไว้ในตั๋วแล้วปิด
ลองสร้างจุดบกพร่องขึ้นใหม่ด้วยซอฟต์แวร์เวอร์ชันล่าสุด
หากไม่สามารถสร้างใหม่ด้วยเวอร์ชันล่าสุดได้โปรดทราบว่าในตั๋วแล้วปิด
หากยังมีอยู่ให้สังเกตในตั๋วด้วยและเปิดทิ้งไว้
การทำงานกับโค้ด
โปรแกรมเมอร์ทุกระดับประสบการณ์สามารถช่วยเขียนโค้ดในโปรเจ็กต์ได้
อย่าคิดว่าคุณจะต้องเป็นอัจฉริยะด้านการเขียนโค้ดจึงจะมีส่วนร่วมกับโปรเจ็กต์ที่คุณชื่นชอบได้อย่างแท้จริง
หากงานของคุณเกี่ยวข้องกับการแก้ไขโค้ด ให้ตรวจสอบวิธีการที่โปรเจ็กต์ใช้ในการรับโค้ดจากผู้ร่วมให้ข้อมูล
แต่ละโปรเจ็กต์มีขั้นตอนการทำงานของตัวเอง ดังนั้นโปรดสอบถามวิธีการดำเนินการก่อนที่คุณจะเริ่มส่งโค้ด
ตัวอย่างเช่น โครงการ PostgreSQL มีกระบวนการที่เข้มงวดมาก: การแก้ไขโค้ดจะถูกส่งในรูปแบบแพตช์ไปยังรายชื่ออีเมล ซึ่งนักพัฒนาหลักจะพิจารณาทุกแง่มุมของการเปลี่ยนแปลง อีกด้านหนึ่งเป็นโปรเจ็กต์อย่าง Parrot ที่ง่ายต่อการรับสิทธิ์ในโค้ดเบส หากโปรเจ็กต์ใช้ GitHub อาจมีเวิร์กโฟลว์ที่ใช้ฟีเจอร์คำขอดึงของ GitHub ไม่มีสองโครงการที่เหมือนกัน
เมื่อใดก็ตามที่คุณแก้ไขโค้ด ตรวจสอบให้แน่ใจว่าคุณทำหน้าที่เป็นสมาชิกที่มีความรับผิดชอบของชุมชน และรักษารูปแบบโค้ดของคุณให้ตรงกับโค้ดเบสที่เหลือ โค้ดที่คุณเพิ่มหรือแก้ไขควรมีลักษณะเหมือนกับโค้ดที่เหลือ คุณอาจไม่ชอบรูปแบบการค้ำยันหรือการจัดการช่องว่างสำหรับการเยื้อง แต่การส่งการเปลี่ยนแปลงโค้ดที่ไม่ตรงกับมาตรฐานที่มีอยู่ถือเป็นเรื่องหยาบคาย มันเหมือนกับการพูดว่า "ฉันไม่ชอบสไตล์ของคุณ และฉันคิดว่าสไตล์ของฉันดีกว่า ดังนั้นคุณควรทำในแบบของฉัน"
6. **ทดสอบตัวเลือกเบต้าหรือรีลีส**: โปรเจ็กต์ใดๆ ก็ตามที่ออกแบบมาให้ทำงานบนหลายแพลตฟอร์มอาจมีปัญหาด้านการพกพาได้ทุกประเภท
เมื่อใกล้ถึงการเปิดตัวและมีการเผยแพร่ตัวเลือกเบต้าหรือตัวเลือกการเปิดตัว หัวหน้าโครงการหวังว่าจะได้รับการทดสอบโดยผู้คนจำนวนมากบนแพลตฟอร์มที่แตกต่างกัน
คุณสามารถเป็นหนึ่งในคนเหล่านั้นและช่วยให้แน่ใจว่าแพ็คเกจใช้งานได้บนแพลตฟอร์มของคุณ
โดยทั่วไปคุณเพียงแค่ต้องดาวน์โหลด สร้าง และทดสอบซอฟต์แวร์ แต่มูลค่าของโปรเจ็กต์อาจมีมหาศาลหากคุณใช้การแจกจ่ายหรือฮาร์ดแวร์ที่ไม่ธรรมดา
เพียงรายงานกลับมาว่างานสร้างและทดสอบช่วยให้ผู้นำโครงการทราบว่าการเปิดตัวที่กำลังจะเกิดขึ้นนั้นแข็งแกร่ง
7. **แก้ไขข้อบกพร่อง**: โดยปกติจะเป็นจุดที่ผู้มีส่วนร่วมต้องการเริ่มเขียนโค้ด
ง่ายมาก: ค้นหาข้อบกพร่องที่ฟังดูน่าสนใจในระบบตั๋วแล้วลองแก้ไขในโค้ด
บันทึกการแก้ไขไว้ในโค้ดหากเหมาะสม
เป็นความคิดที่ดีที่จะเพิ่มการทดสอบลงในชุดการทดสอบเพื่อทดสอบจุดของโค้ดที่คุณแก้ไข บางโครงการจำเป็นต้องมีการแก้ไขข้อบกพร่องเพื่อรวมการทดสอบ จดบันทึกเมื่อคุณสำรวจโค้ดเบสที่ไม่คุ้นเคยนี้ แม้ว่าคุณจะไม่สามารถแก้ไขจุดบกพร่องได้ ให้บันทึกสิ่งที่คุณค้นพบไว้ในตั๋วเพื่อเป็นส่วนหนึ่งของความพยายามในการแก้ไข สิ่งที่คุณพบจะช่วยเหลือผู้ที่ตามหลังคุณ
8. **เขียนแบบทดสอบ**: โปรเจ็กต์ส่วนใหญ่มีชุดทดสอบที่ทดสอบโค้ด แต่ก็ยากที่จะจินตนาการถึงชุดทดสอบที่ไม่สามารถเพิ่มการทดสอบเข้าไปได้อีก
ใช้เครื่องมือความครอบคลุมการทดสอบ เช่น gcov สำหรับ C หรือ Devel::Cover สำหรับ Perl เพื่อระบุพื้นที่ในซอร์สโค้ดที่ไม่ได้รับการทดสอบโดยชุดทดสอบ
จากนั้นจึงเพิ่มการทดสอบลงในชุดเพื่อให้ครอบคลุม
9. **ปิดเสียงคำเตือนคอมไพเลอร์**: กระบวนการสร้างสำหรับโปรเจ็กต์ที่ใช้ C จำนวนมากมักจะพ่นแฟล็กคำเตือนคอมไพเลอร์แปลก ๆ ไปที่หน้าจอ
คำเตือนเหล่านี้มักจะไม่ใช่ตัวบ่งชี้ปัญหา แต่อาจมีลักษณะเช่นนั้นได้
การมีคำเตือนมากเกินไปอาจทำให้คอมไพเลอร์ดูเหมือนกำลังร้องไห้
ตรวจสอบว่าโค้ดสามารถซ่อนจุดบกพร่องได้จริงหรือไม่ ถ้าไม่เช่นนั้น การแก้ไขแหล่งที่มาเป็นความเงียบจะช่วยซ่อนผลบวกลวงเหล่านี้ได้
10. **เพิ่มความคิดเห็น**:
เมื่อคุณค้นหาโค้ด คุณอาจพบจุดที่สร้างความสับสน
มีโอกาสเกิดขึ้นว่าหากคุณสับสน คนอื่นๆ ก็จะสับสนเช่นกัน บันทึกไว้ในโค้ดและส่งแพตช์
ทำงานกับเอกสาร
โดยทั่วไปการจัดทำเอกสารจะเป็นส่วนหนึ่งของโครงการที่ใช้เวลาไม่นาน
นอกจากนี้ยังอาจต้องทนทุกข์ทรมานจากการเขียนจากมุมมองของผู้ที่คุ้นเคยกับโครงการ แทนที่จะผ่านสายตาของคนที่เพิ่งเข้ามา
หากคุณเคยอ่านเอกสารของโครงการโดยคิดว่า "ดูเหมือนว่าคู่มือนี้คาดหวังให้ฉันรู้วิธีใช้แพ็คเกจอยู่แล้ว" คุณจะรู้ว่าฉันกำลังพูดถึงอะไร
บ่อยครั้งที่สายตาที่สดใสสามารถชี้ให้เห็นข้อบกพร่องในเอกสารที่ผู้ใกล้ชิดกับโครงการไม่สังเกตเห็น
11. **สร้างตัวอย่าง**: ไม่มีโปรเจ็กต์ใดที่มีตัวอย่างวิธีปฏิบัติมากเกินไป
ไม่ว่าจะเป็นเว็บ API, ไลบรารีของกิจวัตร, แอป GUI เช่น Gimp หรือเครื่องมือบรรทัดคำสั่ง
ตัวอย่างที่ดีของการใช้งานที่เหมาะสมสามารถอธิบายการใช้งานซอฟต์แวร์ที่เหมาะสมได้ชัดเจนและรวดเร็วกว่าหน้าเอกสารประกอบ
สำหรับ API หรือไลบรารี ให้สร้างโปรแกรมตัวอย่างที่ใช้เครื่องมือนี้ สิ่งนี้สามารถดึงออกมาจากโค้ดที่คุณเขียนได้ โดยตัดทอนให้เหลือเพียงสิ่งจำเป็นเท่านั้น
สำหรับเครื่องมือ ให้แสดงตัวอย่างการใช้งานจริงของคุณในชีวิตประจำวัน หากคุณมุ่งเน้นด้านการมองเห็น
ลองพิจารณาสร้างภาพหน้าจอของกระบวนการสำคัญ เช่น วิธีการติดตั้งแอพพลิเคชั่น
ทำงานร่วมกับชุมชน
โอเพ่นซอร์สเป็นเพียงบางส่วนเกี่ยวกับโค้ดเท่านั้น ชุมชนทำให้โอเพ่นซอร์สทำงานได้ ต่อไปนี้เป็นวิธีที่คุณสามารถช่วยสร้างมันขึ้นมาได้
12. **ตอบคำถาม**: วิธีที่ดีที่สุดในการช่วยสร้างชุมชนคือการช่วยเหลือผู้อื่น
การตอบคำถาม โดยเฉพาะอย่างยิ่งจากคนที่เพิ่งเริ่มสนใจ เป็นสิ่งสำคัญอย่างยิ่งในการช่วยให้โครงการเติบโตและประสบความสำเร็จ
เวลาที่คุณใช้ในการช่วยเหลือผู้เริ่มต้น แม้ว่าพวกเขาจะถามคำถามที่คุณสามารถยกเลิก "RTFM" สั้นๆ ได้อย่างง่ายดาย แต่ก็ให้ผลตอบแทนที่คุ้มค่าในการรับสมาชิกที่กระตือรือร้นอีกคนในชุมชน
ทุกคนเริ่มต้นจากที่ไหนสักแห่ง และโครงการต่างๆ จำเป็นต้องมีผู้คนหลั่งไหลเข้ามาอย่างต่อเนื่องหากพวกเขายังคงมีความสำคัญ
13. **เขียนโพสต์บนบล็อก**:
หากคุณมีบล็อก ให้เขียนเกี่ยวกับประสบการณ์ของคุณกับโครงการที่คุณกำลังใช้อยู่
บอกเกี่ยวกับปัญหาที่คุณพบในการใช้ซอฟต์แวร์และสิ่งที่คุณทำเพื่อแก้ไข
คุณจะช่วยเหลือได้สองวิธี โดยทั้งสองวิธีช่วยให้โครงการนี้อยู่ในใจของผู้อื่นรอบตัวคุณ
และด้วยการสร้างบันทึกสำหรับใครก็ตามที่มีปัญหาของคุณในอนาคตและค้นหาคำตอบในเว็บ
(บล็อกเกี่ยวกับการผจญภัยทางเทคนิคของคุณยังเป็นวิธีที่ยอดเยี่ยมในการแสดงประสบการณ์ในโลกแห่งความเป็นจริงกับซอฟต์แวร์ดังกล่าวในครั้งต่อไปที่คุณหางานโดยใช้ซอฟต์แวร์ดังกล่าว)
14. **ปรับปรุงเว็บไซต์**:
หากคุณมีทักษะในการออกแบบเว็บไซต์และสามารถช่วยปรับปรุงเว็บไซต์ได้ และส่งผลให้โครงการมีภาพลักษณ์ที่เปิดเผยต่อสาธารณะ ก็ถือว่าใช้เวลาอย่างดี
บางทีโปรเจ็กต์อาจใช้การยกเครื่องกราฟิกหรือโลโก้เพื่อระบุโปรเจ็กต์
สิ่งเหล่านี้อาจเป็นทักษะที่ขาดในชุมชน ฉันรู้ว่าฉันจะยินดีมากหากได้รับความช่วยเหลือด้านการออกแบบกราฟิกบนเว็บไซต์โครงการของฉัน
15. **เขียนเอกสารทางเทคนิค**
หากคุณสามารถเขียนเกี่ยวกับวิธีการทำงานของแอปพลิเคชันหรือซอฟต์แวร์ได้ คุณสามารถเขียนเอกสารทางเทคนิคเกี่ยวกับแอปพลิเคชันหรือซอฟต์แวร์นั้นได้ โดยเฉพาะโครงการโอเพ่นซอร์สที่ต้องการอัปเดต ปรับปรุง ขยาย หรือสร้างเอกสารทางเทคนิคให้บุคคลทั่วไปได้อ่าน ยิ่งคุณเขียนภาษาอังกฤษธรรมดามากเท่าไรก็ยิ่งดีเท่านั้น ส่วนที่ดีที่สุด คุณไม่จำเป็นต้องเป็นโปรแกรมเมอร์จึงจะเขียนเอกสารทางเทคนิคได้
สิ่งสำคัญที่สุดคือฟังสิ่งที่คนรอบตัวคุณพูดคุยกัน ดูว่าคุณสามารถรับรู้ถึงความจำเป็นเร่งด่วนหรือไม่ ตัวอย่างเช่น เมื่อเร็ว ๆ นี้ในรายชื่อผู้รับจดหมายของนักพัฒนา Parrot มีการตัดสินใจที่จะใช้ GitHub เป็นระบบตั๋วปัญหา โดยละทิ้งการติดตั้ง Trac แบบเก่าที่พวกเขามี บางคนไม่เห็นด้วยกับการเคลื่อนไหวนี้เนื่องจากไม่มีทางที่จะแปลงตั๋วเป็นระบบของ GitHub ได้ หลังจากทะเลาะกันมาทั้งวัน ฉันก็พูดขึ้นและพูดว่า "ถ้าฉันเขียนตัวแปลงล่ะ" ผู้คนต่างตื่นเต้นกับความคิดนี้ ฉันใช้เวลาเขียนโปรแกรมแปลงตั๋วสำหรับตั๋วมากกว่า 450 ใบ ดังนั้นเราจึงไม่สูญเสียประวัติตั๋วเลย มันเป็นความสำเร็จที่ยิ่งใหญ่. ฉันได้เข้าร่วม และนักพัฒนาหลักยังคงมุ่งเน้นไปที่ธุรกิจการทำงานกับ Parrot
16. **สอนและช่วยเหลือผู้อื่น**:
วิธีที่ดีที่สุดในการเรียนรู้เพิ่มเติมเกี่ยวกับหัวข้อใดหัวข้อหนึ่งคือการพยายามสอนหัวข้อนั้น
ครูที่ดีที่สุดคือผู้ที่สามารถอธิบายเรื่องที่ซับซ้อนด้วยตัวอย่างง่ายๆ ดังนั้นคุณต้องพยายามเป็นครูที่ดีที่สุดเพื่อเป็นผู้เรียนที่ดีที่สุดและดีที่สุดในโลกการเขียนโปรแกรมของคุณ การสอนผู้อื่นจะทำให้คุณรู้สึกดีกับตัวเองมากขึ้น และจะช่วยให้คุณได้รับทักษะและความรู้ในวิชาชีพที่ดีขึ้นด้วย เมื่อคุณได้รับความช่วยเหลือจากใครสักคน อย่าเก็บมันไว้คนเดียว แบ่งปันกับผู้อื่น ทำให้โลกน่าอยู่ยิ่งขึ้น
docs/additional-material/git_workflow_scenarios/Useful-links-for-further-learning.md
+46
View File
@@ -0,0 +1,46 @@
# Useful Links
This document is dedicated to all the tips and tricks websites, blog posts, and helpful sites that make our lives easier. They are a great reference to serve all of our needs, be it a beginner or an expert. This page should act as an index of all those useful links that would help everybody who is new in the open-source domain or someone who wants to learn more.
## The List
1. [Interactive tutorial to git](https://try.github.io)
2. [Youtube: Git and GitHub for Beginners by freecodecamp](https://www.youtube.com/watch?v=RGOj5yH7evk)
3. [git - the simple guide](http://rogerdudler.github.io/git-guide/)
4. [On undoing, fixing, or removing commits in git](http://sethrobertson.github.io/GitFixUm/fixup.html)
5. [Git and GitHub tutorial translated to many languages](https://github.com/Roshanjossey/first-contributions)
6. [Merge Conflicts](https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/merge-conflicts)
7. [Resolving Merge Conflicts](https://githowto.com/resolving_conflicts)
8. [Basics of Git - The Simple Quick Start Guide](https://blog.praveen.science/basics-of-git-the-quick-start-guide/)
9. [Git Standards followed in our way of Spotify Agile Methodology](https://blog.praveen.science/git-standards-followed-in-our-way-of-spotify-agile-methodolgy/)
10. [Git Shortcuts](https://blog.praveen.science/git-shortcuts/)
11. [Official Git cheat sheet in many languages](https://services.github.com/on-demand/resources/cheatsheets)
12. [Git cheat sheet from Tower](https://www.git-tower.com/learn/cheat-sheets/git)
13. [Common Git Problems](https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd)
14. [Git Rebase](https://blog.gitprime.com/git-rebase-an-illustrated-guide/)
15. [Beginner's Guide to Rebasing and Squashing](https://github.com/servo/servo/wiki/Beginner%27s-guide-to-rebasing-and-squashing)
16. [Git Cheatsheet that shows correlations between commands and files](http://ndpsoftware.com/git-cheatsheet.html)
17. [How to contribute](https://opensource.guide/how-to-contribute/)
18. [Getting started with Open Source](https://github.com/OpenSourceHelpCommunity/Getting-Started-With-Contributing-to-Open-Sources)
19. [How to contribute](https://github.com/freeCodeCamp/how-to-contribute-to-open-source)
20. [Atlassians Git Tutorials](https://www.atlassian.com/git)
21. [Pull request reviews](https://help.github.com/articles/about-pull-request-reviews/)
22. [Another Interactive tutorial for git](https://learngitbranching.js.org/)
23. [Git commandline cheat-sheet](https://gist.github.com/davfre/8313299)
24. [Programming Books](https://github.com/EbookFoundation/free-programming-books)
25. [E-Book of professional tip and secrets](https://goalkicker.com/GitBook/GitProfessionalTipsSecrets.pdf)
26. [tutorial about simple rules of become git professional](https://medium.freecodecamp.org/follow-these-simple-rules-and-youll-become-a-git-and-github-master-e1045057468f)
27. [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
28. [5 Useful Tips For A Better Commit Message](https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message)
29. [Version Control using Git](https://ourcodingclub.github.io/2017/02/27/git.html)
30. [Version Control with Git](https://www.udacity.com/course/version-control-with-git--ud123)
31. [Audit the Coursera course from Google](https://www.coursera.org/learn/introduction-git-github)
32. [Using Version Control in VS Code](https://code.visualstudio.com/docs/editor/versioncontrol)
33. [Git vs Github: What's the Difference and How to Get Started with Both](https://kinsta.com/knowledgebase/git-vs-github/)
34. [Hello World Github guides](https://guides.github.com/activities/hello-world/)
35. [How To Use GitHub](https://www.edureka.co/blog/how-to-use-github/)
36. [10 Days of Git and Github](https://github.com/Asabeneh/10-days-of-git-and-github)
37. [Keyboard shortcuts for Github](https://docs.github.com/en/get-started/using-github/keyboard-shortcuts)
38. [Complete Git and GitHub Tutorial by Kunal Kushwaha](https://www.youtube.com/watch?v=apGV9Kg7ics&ab_channel=KunalKushwaha)
39. [Git workflow Cheat Sheet](https://drive.google.com/uc?export=download&id=1QPRh5YmqQm4DFfitelPYlBTWC2I6tTTM)
40. [Beginers Guide To Proper Git Workflow](https://medium.com/@anjulapaulus_84798/beginners-guide-to-proper-git-workflow-35a2d967734e)
Keep adding more links, that you find helpful.
docs/additional-material/git_workflow_scenarios/additional-material.md
+52
View File
@@ -0,0 +1,52 @@
# Additional information
We assume that you have already finished with the basic tutorial before coming here. This document will give you some additional information about advanced Git techniques.
### [Amending a commit](amending-a-commit.md)
This document provides information about how to amend a commit on the remote repository. Amending a commit is a way to modify the most recent commit you have made in your current branch. This can be helpful if you need to edit the commit message or if you forgot to include changes in the commit. You can continue to amend a commit until you push it to the remote repository.
> Use this when you need to adjust a commit you made.
### [Configuring git](configuring-git.md)
This document provides information about how to configure user details and other options in git.
> Use this to better control your git configurations.
### [Keeping your fork synced with the repository](keeping-your-fork-synced-with-this-repository.md)
This document provides information about how to keep your forked repository up-to-date with the base repository. This is important, as hopefully you and many others will contribute to the project.
> Follow these steps if your fork doesn't have any changes in parent repository.
### [Moving a Commit to a different Branch](moving-a-commit-to-a-different-branch.md)
This document provides information about how to move a Commit to another Branch.
> Take these steps to move a commit to another branch.
### [Removing a File](removing-a-file.md)
This document provides information about how to remove a file from your local repository.
> Follow these steps to learn how to remove a file prior to a commit
### [Removing a branch from your repository](removing-branch-from-your-repository.md)
This document provides information about how to delete a branch from your repository.
> Only after your pull request gets merged, follow to next steps
### [Resolving Merge Conflicts](resolving-merge-conflicts.md)
This document provides information about how to resolve merge conflicts.
> Take these steps to resolve the annoying merge conflicts.
### [Reverting a commit](reverting-a-commit.md)
This document provides information about how to revert a commit on the remote repository. It will come in handy in case you need to undo a commit that has already been pushed to Github.
> Take these steps if you want to reverse a commit.
### [Squashing Commits](squashing-commits.md)
This document provides information about how to squash commits with an interactive rebase.
> Use this if you want to open a PR in an open source project and the reviewer asks you to squash every commit into one, with an informative commit message.
### [Undo-ing a local commit](undoing-a-commit.md)
This document provides information about how to undo a commit on your local repository. This is what you need to do when you feel you've messed up your local repository and wish to reset the local repository.
> Take these steps if you want to undo/reset a local commit.
### [Useful Links](Useful-links-for-further-learning.md)
This document is dedicated to all the tips and tricks websites, blog posts, and helpful sites that make our lives easier. They are a great reference to serve all of our needs, be it a beginner or an expert. This page should act as an index of all those useful links that would help everybody who is new in the open-source domain or someone who wants to learn more.
### [Creating a .gitignore file](creating-a-gitignore-file.md)
This document explains what a .gitignore file does, why to use it and how to create a .gitignore file. This file is used in almost all git projects. It helps commit only necessary files to git.
### [Storing Credentials](storing-credentials.md)
This document explains how to store your credentials for repositories. This can be a security concern, so please follow the security policies of your place of work/study.
docs/additional-material/git_workflow_scenarios/amending-a-commit.md
+65
View File
@@ -0,0 +1,65 @@
# Amending a Commit
What if you commit a change to your remote repository only to realize later that you have a typo in the commit message or you forgot to add a line in your most recent commit.
How do you edit that? This is what this tutorial covers.
## Changing a recent commit message after you have pushed to Github.
To do this without opening a file:
* Type in the ```git commit --amend -m "followed by your new commit message"```
* Run ```git push origin <branch-name>``` to commit the changes to the repository.
Note: If you type in just ```git commit --amend```, your text editor would open up prompting you to edit the commit message.
Adding the ``-m`` flags prevents it.
## Modifying on a single commit
So, what if we forgot to make a minor change to a file like changing a single word and we have already pushed the commit to our remote repository?
To illustrate here is a log of my commits:
```
g56123f create file bot file
a2235d updated contributor.md
a5da0d modified bot file
```
Let's say I forgot to add a single word to the bot file
There are 2 ways to go about this. The first is to have an entirely new commit that contains the change like so:
```
g56123f create file botfile
a2235d updated contributor.md
a5da0d modified botfile
b0ca8f added single word to botfile
```
The second way is to amend the a5da0d commit, add this new word and push it to Github as one commit.
The second sounds better since it is just a minor change.
To achieve this, we would do the following:
* Modify the file. In this case, I will modify the botfile to include the word I omitted previously.
* Next, add the file to the staging area with ```git add <filename>```
Usually after adding files to the staging area, the next thing we do is git commit -m "our commit message" right?
But since what we want to achieve here is to amend the previous commit, we would instead run:
* ```git commit --amend```
This would then bring up the text editor and prompt you to edit the message. You can decide to leave the message as it was before or change it.
* Exit the editor
* Push your changes with ```git push origin <branch-name>```
That way, both changes would be in one single commit.
## Modifying commits on remote
If the commit that you like to amend has been already pushed to the remote, amending this commit will lead to your local history being diverged from the remote (since you basically create a new commit and replace the amended one). Since you want to change the commit on the remote, you need to overwrite the remotes history on your branch. To achieve that, follow the same procedure as described above, but use force push when pushing your commit to the remote.
> **Warning**
> Force pushing to the remote will overwrite (and discard) changes on the remote and only keep your pushed commits. Changes on the remote, that other team members did in the meantime, will be overwritten as well.
This is how you modify the last recent commit on the remote:
```bash
git add <your changed files>
git commit --amend -m "followed by your new commit message"
git push --force
```
> Using `--force-with-lease` is a safer option instead of `--force` which avoids overwriting other people's changes on the remote branch (if you do not intend to do so).
docs/additional-material/git_workflow_scenarios/check-commit-log.md
+37
View File
@@ -0,0 +1,37 @@
# Check commit log
In order to check commits log for a branch, or, a file, following command can be used:
`git log [options] [path]`
The output of this command is given in reverse chronological order by default.
## Command output example
```
$ git log
commit e3fabb30ab536bd5876461d8a749301a321e714f (HEAD -> check-commit-log-ko, upstream/main, origin/main, origin/HEAD, main)
Author: Dan Yunheum Seol <yunheum.seol@mail.mcgill.ca>
Date: Tue Jun 4 01:07:25 2024 -0400
Add dan-seol to Contributors list (#84962)
commit 4af4ec8a56e057ce8768af77eda528453974d0bc
Author: Edgar Humberto Tijerina Tamez <168693312+EdgarHTT@users.noreply.github.com>
Date: Mon Jun 3 23:06:05 2024 -0600
Add Edgar Tijerina to Contributors list (#84961)
```
## Command variations and options
- In order to perform the commits reachable from a particular commit ids: <i>(In this case, `foo` and `bar`)</i><br>
`git log foo bar `
- It is also possible to remove the commits reachable from a given commit id by adding a `^` in front of commit id: <i>(In this case, `baz`)</i><br>
`git log foo bar ^baz`
- Commit log for a particular file: <br>
`git log --all <filename>`
- Limit number of commits in log: <i>(In this case, `5`)</i><br>
`git log -n 5`
## Refer
- [Official documentation](https://git-scm.com/docs/git-log)
docs/additional-material/git_workflow_scenarios/configuring-git.md
+76
View File
@@ -0,0 +1,76 @@
# Configuring git
The first time you tried to commit using git, you might have gotten a prompt like the one below:
```bash
$ git commit
*** Please tell me who you are.
Run
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
```
Git needs to know who you are when you create a commit. When you are working collaboratively, you should be able to see who modified what parts of the project and when, and thus, git has been designed to create commits tied to a name and an email.
There are multiple ways to provide the `git commit` command with your email and name, and we'll go through some of them below.
### Global Config
When you store something in the global config, it is accessible system wide in all the repositories you work on. This is the preferred way and works for most use cases.
To store something in the global config, you use the `config` command as follows:
`$ git config --global <variable name> <value>`
In the case of user details, we run it as follows:
```
$ git config --global user.email "you@example.com"
$ git config --global user.name "Your Name"
```
### Repository Config
As the name says, these configurations are scoped to your current repository. If you want to commit to a particular repository, say, a work related project, with your company's email, then you could use this method.
To store something in the repository config, you use the `config` command by omitting the `--global` flag as follows:
`$ git config <variable name> <value>`
In the case of user details, we run it as follows:
```
$ git config user.email "you@alternate.com"
$ git config user.name "Your Name"
```
### Command-line Config
These type of configurations are scoped to the current command only. All git commands take `-c` arguments before the action verb to set temporary configuration data.
To store something in the command line config, run your command as follows:
`$ git -c <variable-1>=<value> -c <variable-2>=<value> <command>`
In our example, we would run the commit command as follows:
`git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"`
### Note on Precedence
Among the three methods described here, the precedence order is `command-line > repository > global`. This means that, if a variable is configured in the command-line as well as globally, the command-line value would be used for the operation.
## Beyond User Details
We have dealt with only the user details till now while working with the config. However, there are several other configuration options available. Some of them are:
1. `core.editor` - to specify the name of the editor used for writing commit messages, etc.
2. `commit.template` - to specify a file on the system as the initial commit template.
3. `color.ui` - to specify a boolean value for using colors in git's output.
We have abstracted some details for ease of understanding. For further reading, head over to [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration).
docs/additional-material/git_workflow_scenarios/creating-a-gitignore-file.md
+73
View File
@@ -0,0 +1,73 @@
# .gitignore
The .gitignore file is a text file that tells Git which files or folders to ignore in a project.
A local .gitignore file is usually placed in the root directory of a project. You can also create a global .gitignore file and any entries in that file will be ignored in all of your Git repositories.
## Why .gitignore
Now you may wonder why would you want git to ignore certain files and folders. Its because you don't want files like build files, cache files, other local configuration files like node modules, compilation files, temporary files IDE's create, etc to be tracked by git. It's usually used to avoid committing transient files from your working directory that aren't useful to other collaborators.
## Getting started
To create a local .gitignore file, create a text file and name it .gitignore (remember to include the . at the beginning). Then edit this file as needed. Each new line should list an additional file or folder that you want Git to ignore.
The entries in this file can also follow a matching pattern.
```
* is used as a wildcard match
/ is used to ignore path names relative to the .gitignore file
# is used to add comments to a .gitignore file
This is an example of what the .gitignore file could look like:
# Ignore Mac system files
.DS_store
# Ignore node_modules folder
node_modules
# Ignore all text files
*.txt
# Ignore files related to API keys
.env
# Ignore SASS config files
.sass-cache
```
To add or change your global .gitignore file, run the following command:
```
git config --global core.excludesfile ~/.gitignore_global
```
This will create the file ~/.gitignore_global. Now you can edit that file the same way as a local .gitignore file. All of your Git repositories will ignore the files and folders listed in the global .gitignore file.
## How to Untrack Files Previously Committed from New Gitignore
To untrack a single file, ie stop tracking the file but not delete it from the system use:
```
git rm --cached filename
```
To untrack every file in .gitignore:
First, commit any outstanding code changes, and then run:
```
git rm -r --cached
```
This removes any changed files from the index(staging area), then run:
```
git add .
```
Commit it:
```
git commit -m ".gitignore is now working"
```
To undo ```git rm --cached filename```, use ```git add filename```
docs/additional-material/git_workflow_scenarios/delete-branch-locally.md
+19
View File
@@ -0,0 +1,19 @@
# Deleting a locally created Branch
This will be handy when you accidentally misspelled a branch name.
This can be done in *3* ways
```
git branch -D <branch_name>
```
```
git branch --delete --force <branch_name> # Same as -D
```
```
git branch --delete <branch_name> # Error on unmerge
```
-D stands for --delete --force which will delete the branch even it's not merged (force delete), but you can also use -d which stands for --delete which throws an error respective of the branch merge status...
docs/additional-material/git_workflow_scenarios/gitflow.md
+119
View File
@@ -0,0 +1,119 @@
# Gitflow
Gitflow is a branching model for Git made by Vincent Driessen. Here the discussion would be the requirements and use-cases of Gitflow.<br />
The Gitflow workflow defines a strict branching model designed around the project release, which provides a robust framework for managing larger projects. Gitflow is ideally suited for projects that have a scheduled release cycle and for the DevOps best practice of continuous delivery. It assigns very specific roles to different branches and defines how and when they should interact. It uses individual branches for preparing, maintaining and recording releases.
## Implementation
1. **Develop and Master Branches**: Instead of a single master branch, Git Flow uses two branches to record the history of the project. It is based on two main branches with infinite lifetime namely master and develop:
- **Master Branch**: The master branch contains the production code and stores the official release history.
- **Develop Branch**: The develop branch contains pre-production code and serves as an integration branch for features.
- **Creating a Develop Branch**:<br />
Without using the Gitflow extensions:
```
git branch develop
git push -u origin develop
```
Using the Gitflow extensions: When using the gitflow extension library, executing `git flow init` on an existing repo will create the develop branch.
```
git flow init
```
2. **Feature Branch**: Each new feature should reside in its branch, which can be pushed to the central repository for backup/collaboration. Feature branches use the latest develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with the master branch.
- **Creating a Feature Branch**: <br />
Without git-flow extensions:
```
git checkout develop
git checkout -b feature_branch
```
With gitflow extensions:
```
git flow feature start feature_branch
```
- **Finishing a Feature Branch**: <br />
Without git-flow extensions:
```
git checkout develop
git merge feature_branch
```
With git-flow extensions:
```
git flow feature finish feature_branch
```
3. **Release Branch**: Once develop has acquired enough features for a release (or a predetermined release date is approaching), we fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Release branch may branch off from develop and must merge into both master and develop. <br />
Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release.
- **Creating a Release Branch**: <br />
Without the git-flow extensions:
```
git checkout develop
git checkout develop
git checkout -b release/0.1.0
```
When using the git-flow extensions:
```
git flow release start 0.1.0
```
Switched to a new branch 'release/0.1.0'
- **Finishing a Release Branch**: <br />
Without git-flow extensions:
```
git checkout master
git merge release/0.1.0
```
With git-flow extensions:
```
git flow release finish 0.1.0
```
4. **Hotfix Branch**: Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are necessary to act immediately upon an undesired status of master. Hotfix branches are a lot like release branches and feature branches except they’re based on master instead of develop. This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and the master branch should be tagged with an updated version number.
- **Creating a Hotfix Branch**: <br />
Without git-flow extensions:
```
git checkout master
git checkout -b hotfix_branch
```
With git-flow extensions:
```
git flow hotfix start hotfix_branch
```
- **Finishing a Hotfix Branch**: <br />
Without git-flow extensions:
```
git checkout master
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
```
With git-flow extensions:
```
git branch -D hotfix_branch
git flow hotfix finish hotfix_branch
```
## Advantages
- Ensures a clean state of branches at any given moment in the life cycle of a project.
- The naming convention of branches follows a systematic pattern making it easier to comprehend.
- Has extensions and support on most used git tools.
- Ideal in case of maintaining multiple versions in production.
- Great for a release-based software workflow.
- Offers a dedicated channel for hotfixes to production.
## Disadvantages
- Git history becomes unreadable.
- The master/ develop branch split is considered redundant and makes the Continuous Delivery/ Integration harder.
- Not recommended in case of maintaining a single version in production.
## Summary
Here we discussed the Git Flow Workflow. Git Flow is one of the many styles of Git workflows you and your team can utilize. Let’s summarize the whole workflow of Git Flow:
1. A develop branch is created from master.
1. Feature branches are created from develop.
1. When a feature is complete it is merged into the develop branch.
1. A release branch is created from develop.
1. When the release branch is done it is merged into develop and master.
1. If an issue in the master is detected a hotfix branch is created from master.
1. Once the hotfix is complete it is merged to both develop and master.
docs/additional-material/git_workflow_scenarios/installing-git-ubuntu.md
+104
View File
@@ -0,0 +1,104 @@
# Installing Git Ubuntu OS
Git by default is likely already installed in your Ubuntu OS . You can confirm this by launching your terminal and entering following command in to your terminal:
```shell
$ git --version
```
If you receive output similar to the following, then Voila! you have readily installed Git on your machine.
```shell
Output
$ git version 2.34.1
```
If this applies to you, proceed to [set up git](#set-up-git) below.
If a Git version number was not on the output as shown above, you can still install it using Ubuntu's APT default package manager.
Update your local package index first by using the apt package management tools. Head back to your terminal and enter the following command.
```shell
$ sudo apt update
```
Once this is completed, then enter the following command to install in Git:
```shell
$ sudo apt install git
```
You can confirm that you have installed Git correctly by running the following command and checking that you receive relevant output.
```shell
$ git --version
```
```shell
Output
$ git version 2.34.1
```
With Git successfully installed, you can now proceed below by setting it up.
# Set up Git
Configuration can be achieved by using the git config command.
Specifically, you need to provide your name and email address because Git embeds this information into each commit you do.
You can add this information by typing:
Now that we are done with installing Git, let us configure it for first time use using "git config" command.
We need to make sure your username and email address are set correctly. To set them, use the command:
```shell
$ git config --global user.name "Your Name"
$ git config --global user.email "youremail@domain.com"
```
You can display all the configuration items that have been set by entering the following command in your terminal:
```shell
$ git config --list
```
If all config field have been set up to your need the output should look something like
```shell
user.name=Your Name
user.email=youremail@domain.com
```
...
# Persist Git Credentials
By default, Git will keep asking you for your details everytime you want to push to a remote repo.
In Git, you can configure the caching of your credentials to avoid entering your username and password repeatedly. There are a couple of methods to achieve this:
1. Credential caching: Git provides a credential caching system that can store your credentials in memory for a specified period. This way, you don't have to re-enter your details every time you interact with a remote repository.
To enable credential caching, you can use the following command:
```shell
$ git config --global credential.helper cache
```
By default, Git will cache your credentials for 15 minutes. You can adjust the cache timeout period by specifying the --timeout option followed by the desired number of seconds.
For example, to set the cache timeout to 1 hour (3600 seconds), you can use:
```shell
$ git config --global credential.helper 'cache --timeout=3600'
```
2. Credential Storing: This sets Git's credential helper to "store". When using this credential helper, Git will store the credentials for a remote repository in a plain-text file on disk. This method is the simplest but least secure option for credential storage.
```shell
$ git config --global crednetial.helper store
```
With the store credential helper, the credentials entered for a remote repository will be stored permanently in a file located at ~/.git-credentials on Linux or macOS, or %USERPROFILE%\.git-credentials on Windows. The credentials will be stored in plain text format, which means they are readable if someone gains access to the file.
The advantage of using the store credential helper is that you won't be prompted for credentials every time you interact with the remote repository. However, keep in mind the security implications of storing credentials in plain text, especially if you are using a shared or public machine.
docs/additional-material/git_workflow_scenarios/keeping-your-fork-synced-with-this-repository.md
+45
View File
@@ -0,0 +1,45 @@
# Keeping your fork synced with this repository
First, the flow for a full sync should be understood, which is important. In this schema, there are 3 different repos: my public repo on Github `github.com/firstcontributions/first-contributions.git`, your fork of the repo on GitHub `github.com/Your-Name/first-contributions/` and your local machine's repo from which you are suppose to work. This kind of cooperation is typical for open source projects and called `Triangle Workflows`.
<img style="float;" src="https://firstcontributions.github.io/assets/additional-material/triangle_workflow.png" alt="triangle workflow" />
To keep your two repos up-to-date with my public repo, we first have to fetch and merge the public repo with your local machine's repo.
Our second move will be to push your local repo to your GitHub fork. As you've seen earlier, it's only from your fork that you can ask for a "pull request". So your GitHub fork is the last repo to be updated.
Now, let's see how to do it:
First, you must be on your main branch. To know which branch you are on, check the first line of:
```
git status
```
if you are not already on main:
```
git checkout main
```
Then you should add my public repo to your git with `add upstream remote-url`:
```
git remote add upstream https://github.com/firstcontributions/first-contributions.git
```
This is a way of telling git that another version of this project exists in the specified url and we're calling it `upstream`. Once your git has a name let's fetch the latest version of the public repository:
```
git fetch upstream
```
You've just fetched the latest version of my fork (`upstream` remote). Now, you need to merge the public repository into your main branch.
```
git rebase upstream/main
```
Here you're merging the public repository with your main branch. Your local machine's main branch is now up-to-date. Lastly, if you push your main branch to your fork, your GitHub fork will also have the changes:
```
git push origin main
```
Notice here you're pushing to the remote named `origin`.
If you want to fetch and merge the latest changes of my fork (`upstream` remote) to your local branch at same time then you can directly go for:
```
git pull upstream main
```
So by now or at this point, all your repositories are up-to-date. Well done! You should do this, every time your GitHub repo tells you that you are a few commits behind.
docs/additional-material/git_workflow_scenarios/moving-a-commit-to-a-different-branch.md
+25
View File
@@ -0,0 +1,25 @@
# Moving a commit to a different branch
What if you commit a change, and then realize that you committed to a different branch?
How can you change that? This is what this tutorial covers.
## Moving the latest commits to an existing branch
To do this, type:
```git reset HEAD~ --soft``` - Undoes the last commit, but leaves the changes available.
```git stash``` - Records the state of the directory.
```git checkout name-of-the-correct-branch``` - Switches to another branch.
```git stash pop``` - Removes latest stashed state.
```git add .``` - Or try adding individual files.
```git commit -m "your message here"``` - Saves and Commits the changes.
Now your changes are on the correct branch
### Moving the latest commits to a new Branch
To do this, type:
```git branch newbranch``` - Creates a new Branch. Saving all the Commits.
```git reset --hard HEAD~#``` - Move master back by # commits. Remember, these commits will be gone from master
```git checkout newbranch``` - Goes to the branch you created. It will have all the commits.
Remember: Any changes not committed will be LOST.
docs/additional-material/git_workflow_scenarios/removing-a-file.md
+23
View File
@@ -0,0 +1,23 @@
# Removing a file from Git
Sometimes, you may want to remove a file from Git but not delete it from your computer. You can achieve this by using the following command:
``git rm <file> --cached``
## So what happened?
Git will no longer keep track of changes in the removed file. As far as Git knows, it's as if you had deleted the file. If you were to locate the file in your file system, you will notice that it's still there.
Notice that in the example above, the flag `--cached` is used. If we didn't add this flag, Git will remove the file from not just the repo, but from your file system too.
If you commit the change with `git commit -m "Remove file1.js"` and pushed it to the remote repository using `git push origin master`, the remote repository will remove the file.
## Additional features
- If you want to remove more than one file, you can include them all in the same command:
`git rm file1.js file2.js file3.js --cached`
- You can use a wildcard (*) to remove similar files. For example, if you would like to remove all .txt files from your local repository:
`git rm *.txt --cached`
docs/additional-material/git_workflow_scenarios/removing-branch-from-your-repository.md
+31
View File
@@ -0,0 +1,31 @@
# Remove a branch from your repository
If you have followed the tutorial up-to-now, our `<add-your-name>` branch has finished its purpose, it is time to delete it from your local machine's repo. This isn't necessary, but the name of this branch shows its rather special purpose. Its life can be made correspondingly short.
First, let's merge your `<add-your-name>` to your master, so to go to your master branch:
```
git checkout master
```
Merge `<add-your-name>` to master:
```
git merge <add-your-name> master
```
Remove `<add-your-name>` on your local machine's repo:
```
git branch -d <add-your-name>
```
You have now deleted your local machine's `<add-your-name>` branch and everything looks neat and tidy.
Though, at this point, you should still have the `<add-your-name>` branch in your GitHub fork. However, before you delete this, remember that you have sent a "Pull request" to my repo from this remote branch. So unless I've already merged it, don't delete this branch.
However, if I have merged your branch and you want to delete the remote branch, use:
```
git push origin --delete <add-your-name>
```
Now, you know how to tidy your branches.
With time, many commits will be added to my public repo. And the master branches of your local machine and of your GitHub fork won't be up-to-date. So in order to keep your repositories synchronized with mine, follow the steps below.
#### [Keeping your fork synced with the repository](keeping-your-fork-synced-with-this-repository.md)
docs/additional-material/git_workflow_scenarios/resetting-a-branch.md
+18
View File
@@ -0,0 +1,18 @@
# Reset a branch
```reset``` is the command which can be used when we want to reset the repository with respect to a commit or a branch. A reset, as the name suggests, discards everything on the base(current) branch and makes it exactly same as the branch with which we chose to reset the base branch (calling it as origin branch). This essentially means, that we will have a copy of the origin branch with the name of base branch.<br/>
However, the question is, why don't we just delete the base branch and checkout a new branch with the name of base branch from origin branch. Technically, it will have the same effect as resetting but in some industrial situations we do not have the access to delete a branch, or we can not delete a branch as it will hamper/disrupt a CI/CD pipeline or maybe an ongoing workflow. Hence, to avoid such situations which can lead to downtimes, we suggest using `git reset` whenever we want to reset a particular branch.
## The Command
Its very easy to execute a git reset for branch.
```
git reset <base_branch> <origin_branch>
```
An example could be:
```
git reset stage master --hard
```
The above command will reset the `stage` branch with `master` and therefore make `stage` exactly same as `master`.
You must be wondering about why `--hard` flag is used? This is to ignore all the changes which are or will be staged before/after the reset.
docs/additional-material/git_workflow_scenarios/resetting-a-commit.md
+20
View File
@@ -0,0 +1,20 @@
# Reset a commit
```reset``` is the command which can be used when we want to move the repository back to a previous commit, discarding any changes made after that commit.<br/>
The main difference between resetting and reverting a commit is that git reset ```unstages a file and bring our changes back to the working directory```
and git revert ```removes the commits from the remote repository```. <br/>
```git reset``` can be achieved using following commands:
- The following command will give summary of all the commits using following two parameters:
- The first seven characters of the commit hash - this is what we need to refer to in our **reset** command.
- the commit message
```
git log --oneline
```
- One can reset repository back to the specific commit using following command: <br />
```git reset commithash```
where commithash being the first 7 characters of the commit hash we found in the log
docs/additional-material/git_workflow_scenarios/resolving-merge-conflicts.md
+35
View File
@@ -0,0 +1,35 @@
# What is a merge conflict?
When you try to merge another branch into your current working branch, you are taking changes from another context and combining them with your current working files.
If two people have changed the same lines in the same file, or if one person decided to delete it while the other person decided to modify it, Git cannot identify which is the correct version. Git will then mark the file as having a conflict - which you'll have to resolve before you can continue your work.
# How to resolve a merge conflict?
When faced with a merge conflict, git will mark the problematic area in the file by enclosing it in “<<<<<<<< HEAD” and “>>>>>>>>>>[other branch name]”
The contents after the first marker originate from your current working branch. After the angle brackets, Git tells us where (from which branch) the changes came from. A line with "=======" separates the two conflicting changes.
Our job is now to clean up these lines: when we're done, the file should look exactly as we want it to look. It is advisable to consult the teammate who wrote the conflicting changes to decide which version should be final. It could be either one of yours - or maybe a mixture between the two.
e.g. :
```
<<<<<<< HEAD:mergetest
This is my third line
=======
This is a fourth line I am adding
>>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest
```
`<<<<<<<`: Indicates the start of the lines that had a merge conflict. The first set of lines are the lines from the file that you were trying to merge the changes into.
`=======`: Indicates the break point used for comparison. Breaks up changes that user has committed (above) to changes coming from merge (below) to visually see the differences.
`>>>>>>>`: Indicates the end of the lines that had a merge conflict.
You resolve a conflict by editing the file and then manually merging the parts of the file that git had trouble merging. This may mean discarding either your changes or someone else's or going ahead with a mix of the two. You will also need to delete the '<<<<<<<', '=======', and '>>>>>>>' in the file.
Once you have resolved the conflict do a `git add`. Do not forget to run the tests, as you have to make sure that you have resolved the conflict.
You can also download different plugins depending on the IDE you are using for an easier way to resolve merge conflicts.
# How to undo a merge?
If you want to undo a merge then you can do `git merge —abort`
docs/additional-material/git_workflow_scenarios/reverting-a-commit.md
+41
View File
@@ -0,0 +1,41 @@
# Revert a commit
To revert a commit simply means to create a brand new commit that undoes all
the changes made in a previous one. It is like doing a ```CTRL + Z ``` on git.
Reversion is made easier in git because every commit you push to your remote repository has a unique alphanumeric key known as SHA(Secure Hash Algorithm) tied to it.
So this means you can revert any commit as long as you have the SHA.
But then, you have to be careful to reverse orderly so as not to mess your repository up.
To pick out the SHA of the specific commit we want to undo, a log of all the commits we have made so far would come in handy.
To get this, we would run the command:
```git log --oneline ```
Running the ```git log``` command alone would also give us the SHAs (in long form)
However using the ```--oneline ``` flag tells git that we want it displayed in a concise (one line) manner for easy read.
The first 7 characters displayed when you run this command is called the abbreviated commit hash.
For example, here is what I get when I run ```git log --oneline ``` on this repository:
```
389004d added spacing in title
c1b9fc1 Merge branch 'master' into tutorials
77eaafd added tutorial for reverting a commit
```
So this shows that with ```git log --oneline```, we can fetch a list of all the commits made on the repository together with the first 7 characters of its SHA.
Now, Let's assume I want to undo my commit of "added spacing in title", here are the steps I would take:
* Copy the SHA of the commit which, in this case is ```389004d```
* Then, run the command ```git revert 389004d```
This would pop open my text editor and prompt me to edit the commit message.
You can decide to leave the commit message as the default git message which starts with the word `Revert`
or you can also decide to customize the message to your liking.
* Next, I will save and close the text editor.
* Return to the command line.
* Run ```git push origin <branch-name>``` to push the reverted changes to Github.
And that is it, the change would be undone. In this case, my repository would be reverted to how it looked like in ```c1b9fc1```
docs/additional-material/git_workflow_scenarios/squashing-commits.md
+86
View File
@@ -0,0 +1,86 @@
# What is squashing?
In git, squashing refers to rewriting the history of your commits, so you end up with one commit with a description of the changes done.
It's usually done in open source projects because a lot of the history of a branch in open source projects is only relevant to the developer who created it, and this provides a simpler way to describe the changes made and also revert them if needed.
# How do you squash commits?
First, perform a git log to review the commits you would like to merge in your current branch.
```
git log
```
You should see a series of your commits like so:
```
commit blablabla
Author: omguhh
Date: 10/10/20
Commit message 1
commit blablabla2
Author: omguhh
Date: 10/10/20
Commit message 2
```
So now that you see the commits you wish to merge to one, we can move along into doing that with ```git rebase```. Assuming you're already familiar with ```git rebase```, we can starting squashing commits in the interactive mode of git rebase that you can activate like so:
```
git rebase -i
```
Now, with interactive rebasing you can specify the starting and end point of how far back you want to go with commits like so:
```
git rebase -i HEAD~2
```
Running this command will show you something like the following:
```
pick blablabla Changing test01.txt file
pick blablabla2 Adding dummy01.txt file
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
```
So if you want to squash ```blablabla2``` into ```blablablabla```, you would change the following :
```
pick blablabla Changing test01.txt file
squash blablabla2 Adding dummy01.txt file
```
If all goes well, you'd get a result that looks like this:
```
# This is a combination of 2 commits.
# The first commit's message is:
commit message 1
# This is the 2nd commit message:
commit message 2
```
That you can freely change before you decide to exit the editor to save these changes.
Running git log again should show you the commit message you entered before exiting the screen with the commits combined into one.
docs/additional-material/git_workflow_scenarios/stashing-a-file.md
+137
View File
@@ -0,0 +1,137 @@
# Stashing
What if you are working on a big code and suddenly you need to switch the branch from which you are currently working on to some other branch. Since the code, is not complete, and without any tests, you probably don't want to commit it. But you cannot move to the other branch without committing the changes, Git won't let you break this flow. What do we do then? How do we prevent an unnecessary commit, while being able to jump branches? This is what this tutorial covers.
## Stashing your work
Let's assume you are working on a project's branch where you have changed some files. Now if you run ```git status``` you can see your changes in the files.
```
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: lib/simplegit.rb
#
```
Now you want to switch your branch, but don't want to commit the changes yet; so you would stash the changes.
To push a new stash on to your stack, run ```git stash```:
```
$ git stash
Saved working directory and index state \
"WIP on master: 049d078 added the index file"
HEAD is now at 049d078 added the index file
(To restore them type "git stash apply")
```
Now your working directory is clean, use ```git status``` :
```
$ git status
# On branch master
nothing to commit, working directory clean
```
Now you can switch to any branch and do your work; your stashed changes are stored in form of a stack. To see which stashes you have stored in the stack you can use ```git stash list```:
```
$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051 Revert "added file_size"
stash@{2}: WIP on master: 21d80a5 added number to log
```
In case you want to re-apply the changes you just stashed, you can use the command ```git stash apply```. By using this command you can reapply the most recent stashed file. In order to reapply any other file, you can specify it by naming it like: ```git stash apply <stash-name>```, in place of ```<stash-name>``` write the name of the stash you need to reapply.
```
$ git stash apply
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: index.html
# modified: lib/simplegit.rb
#
```
You can see that git re-modifies the file that you uncommitted when you saved the stash. In this case, you had a clean working directory when you tried to apply the stash, and you tried to apply it on the same branch you saved it from; but having a clean working directory and applying it on the same branch aren’t necessary to successfully apply a stash. You can save a stash on one branch, switch to another branch later, and re-apply the changes in the new branch. You can also have modified and uncommitted files in your working directory when you apply a stash, git gives merge conflicts if anything no longer applies cleanly.
The changes made to your files are reapplied, but the file you staged was not restaged. To do so you need to run the command ```git stash apply``` with a ```--index``` to tell the command to reapply the staged changes. If you have run that instead, you would have returned to your original position:
```
$ git stash apply --index
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: lib/simplegit.rb
#
```
The apply command only applies the stashed work, but you still have that on your stack. In order to remove it, you can run ```git stash drop``` with the name of the stash to remove.
```
$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051 Revert "added file_size"
stash@{2}: WIP on master: 21d80a5 added number to log
$ git stash drop stash@{0}
Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
```
You can use ```git stash pop``` to un-stash the last changes drop it from your stash's stack.
## Un-applying a Stash
In some cases you want to apply stashed changes, do some work, but un-apply the changes that originally came from the stash. Git does not provide command like ```git unapply```, but it is possible to achieve this effect by simply retrieving the patch associated with a stash and applying it in reverse:
```$ git stash show -p stash@{0} | git apply -R```
Again if you don't specify a stash, Git assumes the most recent stash:
```$ git stash show -p | git apply -R```
You may want to create an alias and effectively add a ```stash-unapply``` command to your Git. For example:
```
$ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
$ git stash apply
$ #... work work work
$ git stash-unapply
```
## Creating a Branch from Stash
If you stash some work, leave it there for a while, and continue on the branch from which you stashed the work, you may have a problem reapplying the work. If the apply tries to modify a file that you’ve since modified, you’ll get a merge conflict and will have to resolve it. If you want an easier way to test the stashed changes again, you can run ```git stash branch```, which creates a new branch for you, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully:
```
$ git stash branch testchanges
Switched to a new branch "testchanges"
# On branch testchanges
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: lib/simplegit.rb
#
Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359)
```
This is a nice shortcut to recover stashed work easily and work on it in a new branch.
docs/additional-material/git_workflow_scenarios/storing-credentials.md
+48
View File
@@ -0,0 +1,48 @@
# Storing Credentials
You might have complained about this before - entering your username and password each time you access the repository can be a hassle and can interrupt your workflow if it takes too long. But it doesn't need to be that way.
We will be covering one of the methods available to us - [git credential cache](https://git-scm.com/docs/git-credential-cache).
**Note:** Please follow the security policies of your place of work/study.
## Caching
We can use git credential cache to store our username and password.
**Attention:** This method saves the credentials in *plaintext* on your PC's disk. Everyone on your computer can access it, e.g. malicious NPM modules.
### Global Credential Cache
If we wish to, we can store the credentials for every repository we are working with using one simple command:
```
$ git config --global credential.helper cache
```
**Reminder:** Please follow the security policies of your place of work/study.
### Repository Credential Cache
We can store the credentials for the repository we are working with using one simple command, similar to before:
```
$ git config credential.helper cache
```
**Reminder:** Please follow the security policies of your place of work/study.
### Cache Timeout
If we do not specify a length of time to store our credentials, they can potentially be stored forever. However, we can determine how long they will be kept in memory using this command:
```
git config credential.helper 'cache --timeout=<timeout>'
```
Using the helper, the credentials will never touch the disk and will be erased after the specified timeout. The default value is 900 seconds (15 minutes).
#### References
[Stack Overflow](https://stackoverflow.com/questions/35942754/how-can-i-save-username-and-password-in-git)
### [Additional Material](additional-material.md)
docs/additional-material/git_workflow_scenarios/undoing-a-commit.md
+55
View File
@@ -0,0 +1,55 @@
# Undo local commits
To undo a local commit, all you need to do is
```
git reset
```
This command will reset your staging area to your most recent commit, but the changes you made to your working directory will not change. So, you can still re-commit again what you've changed.
Or, if you only want to remove one file from your previous commit. Then, you can do the command below
```
git reset <file>
```
The command will remove only the specified file from the staging area, but changes made on the file will still remain.
Example of ```git reset``` usage
```
# Make changes in index.php and tutorial.php
# Add files into the staging area
$ git add .
# Remembered both files need to be committed separately
# Unstage tutorial.php
$ git reset tutorial.php
# Commit index.php first
$ git commit -m "Changed index.php"
# Commit tutorial.php now
$ git add tutorial.php
$ git commit -m "Changed tutorial.php"
```
Let's say if you have messed up your local repository and you just want to reset it to your last commit.
Then, you can run the command below.
```
git reset --hard
```
The command will not only reset your staging area, but also revert all your changes on the files to your last commit.
The mode ```--hard``` tells Git to undo all the changes in the working directory too.
You should only run this when you are really sure of throwing your whole local development out.
Example of ```git reset --hard``` usage
```
# Decided to start a crazy experiment
# Create a new file 'crazy.php' and add some code to it
# Commit crazy.php
$ git add crazy.php
$ git commit -m "Started a crazy dev"
# Edit crazy.php file again and changed a lot of other files
# Commit all tracked files
$ git add .
$ git commit -m "Continued dev"
# Tested and things went out of hand
# Decided to remove the whole things
$ git reset --hard HEAD~2
```
The ```git reset --hard HEAD~2``` moves the current branch backward by 2 commit points at the same time reverting all changes you have made and remove the 2 snapshots we have just created from project history.
P.s. Never perform ```git reset --hard``` if you've already pushed your commits to a shared repository as it will cause problems to everyone on that repository.
docs/additional-material/git_workflow_scenarios/why-using-branches.md
+53
View File
@@ -0,0 +1,53 @@
# WHY USING BRANCHES DURING CONTRIBUTING
## What are branches.
Branches are simply pointers to a commit.
When you branch out, git is essentially making a new state of your current code, upon which you can work, without affecting the important main state of the code (which is in master branch).
When you are happy with your experiments, and want to merge you experiments in main code, you run git merge
<branch name> master.
This will tell git, to add in all changes from your experiment branch into master.
This way, while working in an open source project with a number of contributors, it becomes easy to merge the best suited code without altering the main code or master branch.
## How it works?
A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit process. You can think of them as a way to request a brand new working directory, staging area, and project history. New commits are recorded in the history for the current branch, which results in a fork in the history of the project.
The git branch command lets you create, list, rename, and delete branches. It doesn’t let you switch between branches or put a forked history back together again. For this reason, git branch is tightly integrated with the git checkout and git merge commands.
## Why to use branches?
If the question "Why do we use branching in version control like git?" still persists in your mind, here's a quick explanation:
Let's take a simple example to understand the branching strategy. A production car needs a paint job before its launch. Prior to its official sale, it was decided that the car would come in 'olive green' color as default. But some of the members in the manufacturing team decided to showcase the car in 'red' color. Hence an ambiguous situation arises and to avoid this problem branching was introduced.The red color paint job is like a branch to the master repository 'Car'. Pushing this branch will suggest the red color. If merged with the master repository the car will get the red color otherwise it will continue with olive green. Merging a contributors branch to the master repo of the organization depends on the project head.
## Example
Alice is working on Feature A and Bob is working on Feature B. Alice is halfway done with Feature A and has made a few commits in alice. However, Feature A is quite hard to implement so Alice decides that she should rather work on Feature C and makes a few commits onto alice. Bob finished Feature B and decides that he would like to tackle Feature A and so pulls alice into bob.
After Bob finishes Feature A he would like to merge bob into master. However, bob now contains Feature A, Feature B and parts of Feature C, but Feature C is not ready to be merged! It's easy to see that a workflow like this can lead to many confusing merge conflicts.
The trick is that instead of having personal branches one should have feature branches. Alice should have a branch for Feature A and Feature C and Bob should have a branch for Feature B and Feature A. That way they both can work on different features without tramping on each other's toes.
## How to create branches?
#### Create a branch
```
git branch AnyBranchName
```
A new branch will be created named AnyBranchName and all the file changes in this branch will not be affected in the main branch.
For detailed explanation refer [How to create branch](https://www.atlassian.com/git/tutorials/using-branches)
#### Delete the branch
```
git branch -d AnyBranchName
```
Branch name AnyBranchName will be deleted from the git repository.
Refer to [Removing branch from your repository](https://github.com/jashnimje/first-contributions/blob/7dcae72208e4b42fcf834b4f189fa8ee78238077/additional-material/git_workflow_scenarios/removing-branch-from-your-repository.md)
docs/additional-material/translations/Belarusian/Useful-links-for-further-learning.by.md
+36
View File
@@ -0,0 +1,36 @@
# Карысныя спасылкі
Гэты дакумент прысвечаны ўсіх сайтаў з парадамі і рэкамендацыямі, паведамленнях у блогах і карысным сайтам, якія палягчаюць наша жыццё. Яны з'яўляюцца выдатным арыенцірам для задавальнення ўсіх нашых патрэбаў, няхай гэта будзе пачатковец або эксперт. Гэтая старонка павінна служыць індэксам ўсіх тых карысных спасылак, якія дапамогуць усім, хто пачатковец у вобласці адкрытага зыходнага кода, ці каму-небудзь, хто хоча даведацца больш.
## Спіс
1. [Interactive tutorial to git](https://try.github.io)
2. [git - the simple guide](http://rogerdudler.github.io/git-guide/)
3. [On undoing, fixing, or removing commits in git](http://sethrobertson.github.io/GitFixUm/fixup.html)
4. [Git and GitHub tutorial translated to many languages](https://github.com/Roshanjossey/first-contributions)
5. [Merge Conflicts](https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/merge-conflicts)
6. [Resolving Merge Conflicts](https://githowto.com/resolving_conflicts)
7. [Basics of Git - The Simple Quick Start Guide](https://blog.praveen.science/basics-of-git-the-quick-start-guide/)
8. [Git Standards followed in our way of Spotify Agile Methodology](https://blog.praveen.science/git-standards-followed-in-our-way-of-spotify-agile-methodolgy/)
9. [Git Shortcuts](https://blog.praveen.science/git-shortcuts/)
10. [Official Git cheat sheet in many languages](https://services.github.com/on-demand/resources/cheatsheets)
11. [Git cheat sheet from Tower](https://www.git-tower.com/learn/cheat-sheets/git)
12. [Common Git Problems](https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd)
13. [Git Rebase](https://blog.gitprime.com/git-rebase-an-illustrated-guide/)
14. [Beginner's Guide to Rebasing and Squashing](https://github.com/servo/servo/wiki/Beginner%27s-guide-to-rebasing-and-squashing)
15. [Git Cheatsheet that shows correlations between commands and files](http://ndpsoftware.com/git-cheatsheet.html)
16. [How to contribute](https://opensource.guide/how-to-contribute/)
17. [Getting started with Open Source](https://github.com/OpenSourceHelpCommunity/Getting-Started-With-Contributing-to-Open-Sources)
18. [How to contribute](https://github.com/freeCodeCamp/how-to-contribute-to-open-source)
19. [Atlassians Git Tutorials](https://www.atlassian.com/git)
20. [Pull request reviews](https://help.github.com/articles/about-pull-request-reviews/)
21. [Another Interactive tutorial for git](https://learngitbranching.js.org/)
22. [Git commandline cheat-sheet](https://gist.github.com/davfre/8313299)
23. [Programming Books](https://github.com/EbookFoundation/free-programming-books)
24. [E-Book of professional tip and secrets](https://goalkicker.com/GitBook/GitProfessionalTipsSecrets.pdf)
25. [tutorial about simple rules of become git professional](https://medium.freecodecamp.org/follow-these-simple-rules-and-youll-become-a-git-and-github-master-e1045057468f)
26. [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
27. [5 Useful Tips For A Better Commit Message](https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message)
28. [Version Control using Git](https://ourcodingclub.github.io/2017/02/27/git.html)
29. [Version Control with Git](https://www.udacity.com/course/version-control-with-git--ud123)
Працягвайце дадаваць больш спасылак, якія вам падаюцца карыснымі.
docs/additional-material/translations/Belarusian/additional-material.by.md
+46
View File
@@ -0,0 +1,46 @@
# Дадатковая інфармацыя
Тут мы мяркуем, што вы ўжо асвоілі асноўную інструкцыю. Дадатковая інфармацыя змяшчае некаторыя звесткі аб GIT камандах, необходимыж ў больш складаных сітуацыях.
### [Выпраўленні ў каміты](amending-a-commit.by.md)
Дакумент змяшчае інфармацыю аб тым, як ўнесці выпраўлення ў commit ў аддаленым рэпазітары.
> Яна неабходная для тых выпадкаў, калі вы хочаце змяніць commit, які вы зрабілі раней.
### [Канфігураванне GIT](configuring-git.by.md)
Дакумент змяшчае сведния пра тое, як змяніць інфармацыю аб карыстальніку і іншыя налады GIT.
> Ён будзе карысны, калі вы захочаце зрабіць ўстаноўкі GIT больш зручнымі.
### [Сінхранізацыя вашага адгалінаванні з асноўным рэпазітаром](keeping-your-fork-synced-with-this-repository.by.md)
Дакумент распавядае аб тым, як забяспечыць сінхранізацыю вашага адгалінаванні з асноўным рэпазітаром. Забеспячэнне сінхранізацыі небходнасць, так як, наколькі можна спадзявацца, вы будзеце працаваць над праектам не ў адзіноце, а ўносіць змены ў яго, разам з іншымі ўдзельнікамі.
> Выканайце гэтыя дзеянні, калі ваша адгалінаванне не мае змяненняў у master галінцы рэпазітара.
### [Перамяшчэнне камітаў ў іншую галінку](moving-a-commit-to-a-different-branch.by.md)
Дакумент змяшчае звесткі аб тым, як перамясціць commit ў іншую галінку.
> Выканайце названыя крокі, каб перамясціць комм ў іншую галінку.
### [Выдаленне файла](removing-a-file.by.md)
Дакумент апісвае як выдаліць файл з вашага лакальнага рэпазітара.
> Азнаёмцеся з гэтымі камандамі каб зразумець як выдаліць файл перад тым, як зрабіць commit.
### [Выдаленне галінкі з вашага рэпазітара](removing-branch-from-your-repository.by.md)
Дакумент змяшчае інфармацыю аб тым, як выдаліць галінку з вашага рэпазітара.
> Выкарыстоўвайце гэтыя каманды толькі пасля таго, як ваш pull-request быў задаволены.
### [Дазвол канфліктаў пры зліцці галінак](resolving-merge-conflicts.by.md)
Дакумент змяшчае інфармацыю аб тым, як вырашаць канфлікты, якія ўзнікаюць пры зліцці галінак.
> Прапанаваныя тут крокі дапамогуць вам разабрацца з вельмі непрыемнымі выпадкамі канфліктаў якія ўзнікаюць пры зліцці галінак.
### [Адмена камітаў](reverting-a-commit.by.md)
Дакумент інструктуе як адмяніць commit ў аддаленым рэпазітары. Такая аперацыя будзе карысная ў тых выпадках, калі вам неабходна адыграць назад той commit, які ўжо быў пасланы на Github (pushed).
> Выканайце названыя тут крокі каб адмяніць commit.
### [Сумяшчэнне камітаў (squashing)](squashing-commits.by.md)
Дакумент апісвае, як сумяшчаць камітаў пры дапамозе інтэрактыўнага перабазавання.
> Выкарыстоўвайце гэтыя інструкцыі, калі вы стварылі пул-реквест ў open source праекце, але эксперт праекта просіць вас сумясціць усе вашыя камітаў ў адзін комм з змястоўным каментаром.
### [Адмена лакальнага каміту](undoing-a-commit.by.md)
Дакумент утрымлівае інфармацыю, як адыграць назад commit ў вашым лакальным рэпазітары. Вам спатрэбіцца гэтая інфармацыя ў тым выпадку, калі вы вырашыце, што вы сапсавалі ваш рэпазітар і захочаце вярнуць яго змесціва да першапачатковага стану.
> Выконвайце гэтым інструкцыям, калі вы хочаце адмяніць тыя змены, якія былі зробленыя апошнім лакальным commit .
### [Карысныя спасылкі](Useful-links-for-further-learning.by.md)
Гэты файл утрымлівае спасылкі на блог-пасты, карысныя вэб-сайты, вэб-сайты з пералікам рэкамендацыі і прыёмаў, якія часта палягчаюць наша жыццё. Як пачаткоўцам, так і экспертам мы рэкамендуем звяртацца да іх па меры неабходнасці. Гэты файл утрымлівае спіс карысных спасылак, якія напэўна дапамогуць і тым, хто робіць першыя крокі ў open source, і тым, хто захоча павялічыць свае веды ў гэтай галіне.
docs/additional-material/translations/Belarusian/amending-a-commit.by.md
+46
View File
@@ -0,0 +1,46 @@
# Выпраўленні ў каміты
Уявіце, што вы зрабілі commit ў выдалены рэпазітар, а потым зразумелі, што дапусцілі памылку друку ў каментары да commit або забыліся ўставіць радок у гэты апошні па часе commit. Як паступіць у гэтай сітуацыі? Менавіта пра гэта і пойдзе гаворка ў гэтым дакуменце.
## Як змяніць каментар да нядаўняга камітаў пасля таго, як ён быў пасланы на Github (pushed)
Каб зрабіць гэта, не адкрываючы файл для рэдагавання,
* Набярыце ```git commit --amend -m "followed by your new commit message"```
* А затым выканаеце ```git push origin <branch-name>``` для таго, каб паслаць змены на Github.
Заўвага: Калі вы набярэце, толькі ```git commit --amend```, то адкрыецца тэкставы рэдактар і прапануе адрэдагаваць каментар да commit.
Выкарыстанне ключа `` -m`` адмяняе запуск рэдактара.
## Як зрабіць змены ў адным commit
Што калі мы забыліся зрабіць невялікае змяненне ў файле, напрыклад, замяніць адно слова ў commit, які ўжо пасланы ў выдалены рэпазітар?
Хай, для прыкладу, запісы ў часопісе маіх commit выглядаюць наступным чынам:
`` `
g56123f create file bot file
a2235d updated contributor.md
a5da0d modified bot file
`` `
Дапусцім, я забыўся дадаць адно слова ў файл bot file
Ёсць два спосабу выправіць гэта. Першы заключаецца ў стварэнні новага commit, які змяшчае гэта змена, напрыклад, так:
`` `
g56123f create file botfile
a2235d updated contributor.md
a5da0d modified botfile
b0ca8f added single word to botfile
`` `
Другі спосаб складаецца ў выпраўленні камітаў a5da0d, даданні гэтага прапушчанага слова і запушивании гэтых змяненняў на Github ў выглядзе аднаго камітаў.
Другі спосаб ўяўляецца пераважнай, паколькі справа ідзе толькі аб нязначным змене.
Каб дамагчыся гэтага, мы паступім наступным чынам:
* Зменім файл. У дадзеным выпадку я змяню файл botfile, дадаўшы да яго слова, якое я прапусціў раней.
* Далей, праіндэксуем гэты файл пры дапамозе каманды ```git add <filename>```
У звычайным выпадку адразу пасля індэксавання мы робім `` `git commit -m" коментар да нашага commit "` ``, правільна? Але паколькі ў дадзеным выпадку наша задача - выправіць папярэдні commit, - то замест гэтага мы выканаем такую каманду:
* ```git commit --amend```
У выніку адкрыецца акно тэкставага рэдактара, у якім мы маем магчымасць зрабіць змены ў каментары. Мы можам на самай справе адрэдагаваць каментар, ці пакінуць яго без зменаў.
* Выйдзем з рэдактара
* Запушим нашы змены пры дапамозе каманды ```git push origin <branch-name>```
Такім чынам, абодва выпраўлення апынуцца ў адным commit.
docs/additional-material/translations/Belarusian/configuring-git.by.md
+76
View File
@@ -0,0 +1,76 @@
# Канфігураванне GIT
Калі вы ўпершыню паспрабавалі зрабіць commit, вы маглі ўбачыць такое паведамленне:
```bash
$ git commit
*** Please tell me who you are.
Run
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
```
Каб стварыць commit, GIT павінен ведаць хто з'яўляецца яго аўтарам. Пры сумеснай працы, неабходна ведаць кім і калі былі змененыя тыя ці іншыя часткі праекта, таму GIT прадугледжвае, што кожны commits пры яго стварэнні асацыюецца з імем і емейл адрасам карыстальніка.
Існуе некалькі спосабаў, якія дазваляюць асацыяваць каманду `git commit` з вашым емейл і імем, і тут мы пералічым некаторыя з іх.
### Глабальная канфігурацыя
Інфармацыя, захаваная як частка глабальнай канфігурацыі, адносіцца да ўсёй сістэмы, г.зн. да ўсіх рэпазітароў, у якіх вы працуеце. Гэта пераважны спосаб, прыдатны для большасці з варыянтаў выкарыстання.
Каб захаваць што-небудзь у глабальным канфігурацыі, вы выкарыстоўваеце каманду `config` наступным чынам:
`$ git config --global <variable name> <value>`
Ва ўжыванні да інфармацыі пра карыстальніка, мы выконваем гэтыя каманды такім чынам:
`` `
$ git config --global user.email "you@example.com"
$ git config --global user.name "Your Name"
`` `
### Канфігурацыя рэпазітара
Як вынікае з назвы, гэтыя канфігурацыі адносяцца да вашага бягучага сховішча. Калі вы хочаце прыняць удзел у пэўным сховішчы, скажам, на праекце, звязаным з працай, з электроннай поштай вашай кампаніі, то вы можаце скарыстацца гэтым метадам.
Каб змяніць канфігурацыю на ўзроўні рэпазітара, варта апусціць ключ `--global` у камандзе` config` такім чынам:
`$ git config <variable name> <value>`
Ва ўжыванні да інфармацыі пра карыстальніка, гэта выглядае наступным чынам:
`` `
$ git config user.email "you@alternate.com"
$ git config user.name "Your Name"
`` `
### Канфігурацыя ў камандным радку
Гэты спосаб канфігурацыі адносіцца толькі да дадзенай камандзе. Усе каманды GIT дазваляюць выкарыстоўваць ключ `-c` перад дзеясловам ідэнтыфікуюць каманду для часовай ўстаноўкі канфігурацыйных параметеров.
Для змены параметраў канфігурацыі, якія распаўсюджваюцца толькі на дадзеную каманду, карыстайцеся наступным фарматам каманд GIT:
`$ git -c <variable-1>=<value> -c <variable-2>=<value> <command>`
Для нашага выпадку Каманда для камітаў будзе вылядеть так:
`git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"`
### Заўвага аб парадку предшествования
Парадак предшествования сярод трох згаданых тыпаў каманд канфігурацыі вызначаецца як `command-line > repository > global`. Гэта азначае, што калі якая-небудзь пераменная вызначана, як у глабальнай канфігурацыі, так і ў камандным радку, то будзе выкарыстана значэнне, прысвоенае у камандным радку.
## Не толькі інфармацыя пра карыстальніка
Да гэтага часу, абмяркоўваючы канфігурацыю GIT'а, мы дакраналіся толькі інфармацыі пра карыстальніка. Аднак GIT дазваляе канфігураваць яшчэ неслколько параметраў. Вось некторые з іх:
1. `core.editor` - паказвае назва рэдактара для рэдагавання каментар для камітаў і да т.п.,
2. `commit.template` - паказвае файл, які змяшчае першапачатковы темплат для камітаў,
3. `color.ui` - лагічная зменная, якая ўказвае ці варта испольовать каляровыя шрыфты ў паведамленнях на тэрмінале GIT'а.
Для прастаты мы апусцілі некаторыя дэталі. Для больш падрабязнага азнаямлення звярніцеся да [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration).
docs/additional-material/translations/Belarusian/keeping-your-fork-synced-with-this-repository.by.md
+42
View File
@@ -0,0 +1,42 @@
# Сінхранізацыя вашага адгалінаванні з асноўным рэпазітаром
Па-першае, варта разумець паток для поўнай сінхранізацыі, што важна. У гэтай схеме ёсць 3 розныя рэпазітары: мае адкрытыя сховішча ў Github `github.com / firstcontributions / first-doprino.git`, ваш відэлец сховішча на GitHub` github.com / Your-Name / first-donates / ` і сховішча мясцовай машыны, на якой вы павінны працаваць. Такі від супрацоўніцтва характэрны для праектаў з адкрытым зыходным кодам і называецца `Triangle Workflows`.
<img style="float;" src="https://firstcontributions.github.io/assets/additional-material/triangle_workflow.png" alt="triangle workflow" />
Каб захаваць вашыя два сховішчы ў актуальным стане з маім адкрытым сховішчам, мы спачатку павінны здабыць і аб'яднаць агульнае сховішча з рэпазітарам вашай лакальнай машыны.
Наш другі крок - перанесці ваша мясцовае сховішча ў відэлец GitHub. Як вы ўжо бачылі раней, толькі "з відэльцам" вы можаце папрасіць "pull request". Такім чынам, відэлец GitHub - апошняе сховішча, якое трэба абнавіць.
Зараз давайце паглядзім, як гэта зрабіць:
Па-першае, вы павінны быць на сваім вядучым аддзяленні. Каб даведацца, на якой філіяле вы знаходзіцеся, праверце першы радок:
```
git status
```
калі вы яшчэ не на майстры:
```
git checkout master
```
Затым вы павінны дадаць маё агульнадаступнае сховішча ў свой git з `add addstream stream-url`:
```
git remote add upstream https://github.com/firstcontributions/first-contributions.git
```
Гэта спосаб сказаць Git, што іншая версія гэтага праекта існуе ў паказаным URL-адресе, і мы называем яго "вышэй". Пасля таго, як ваш git мае імя, давайце пазнаём апошнюю версію грамадскага сховішча:
```
git fetch upstream
```
Вы толькі што атрымалі апошнюю версію майго відэльца (`upstream` remote). Зараз вам трэба аб'яднаць агульнадаступнае сховішча ў ваша галоўнае аддзяленне.
```
git rebase upstream/master
```
Тут вы аб'яднаеце грамадскае сховішча з вашай галоўнай галіной. Галоўнае аддзяленне вашай мясцовай машыны зараз актуальнае. І, нарэшце, калі вы націснеце галоўную галінку на відэлец, ваша відэлец GitHub таксама будзе змяняць:
```
git push origin master
```
Звярніце ўвагу, вы націскаеце на remote імя `origin`.
Такім чынам, да гэтага часу альбо ў гэты момант усе вашыя сховішчы актуальныя. Добра зроблена! Вы павінны рабіць гэта кожны раз, калі ваш сховішча GitHub паведамляе вам, што вы здзяйсняеце некалькі commits.
docs/additional-material/translations/Belarusian/moving-a-commit-to-a-different-branch.by.md
+25
View File
@@ -0,0 +1,25 @@
# Перамяшчэнне камітаў ў іншую галінку
Што рабіць, калі вы здзяйсняеце змены, а потым разумееце, што вы здзейснілі іншую галіну?
Як вы можаце гэта змяніць? Вось што ахоплівае гэты падручнік.
## Перамяшчэнне апошніх камітаў ў існуючую галінку
Для такога перамяшчэння, набярыце:
`` `git reset HEAD ~ --soft` `` - Адмяняе апошняе commit, але пакідае даступныя змены.
`` `git stash` `` - Захоўвае стан дырэкторыі.
`` `git checkout <імя правільнай галінкі>` `` - Перамыкаецца на іншую галінку.
`` `git stash pop` `` - Вяртае апошняе захаванае стан.
`` `git add .` `` - Дадае індывідуальныя файлы.
`` `git commit -m "your message here"``` - Захоўвае і ўносіць змены.
Зараз вашы змены - у правільнай галінцы.
### Перамяшчэнне апошніх камітаў ў новую галінку
Для такога перамяшчэння, набярыце:
`` `git branch newbranch` `` - Стварае новую галінку, захоўваючы ўсе камітаў.
`` `git reset --hard HEAD ~ [n]` `` - Вяртае галінку master назад на n камітаў. Майце на ўвазе, што змены змяшчаюцца ў гэтых камітаў будуць цалкам выдалены з галінкі master.
`` `git checkout newbranch` `` - Перамыкаецца на галінку, якую вы стварылі. Гэтая галінка цяпер змяшчае ўсе commits.
Запомніце: Любыя змены, якія не былі ўключаныя ў commit, будуць цалкам страчаныя.
docs/additional-material/translations/Belarusian/removing-a-file.by.md
+23
View File
@@ -0,0 +1,23 @@
# Выдаленне файла з-пад GIT кантролю
Часам можа ўзнікнуць неабходнасць выдаліць файл з-пад GIT кантролю, але захаваць яго на кампутары. Гэта можа быць дасягнута з дапамогай наступнай каманды:
`` git rm <файл> --cached``
## Што ж адбылося?
GIT больш не кантралюе змены ў аддаленым файле. З пункту гледжання GIT, гэты файл адсутнічае, але калі вы паспрабуеце лакалізаваць гэты файл у файлавай сістэме, то вы ўбачыце, што ён усё яшчэ на месцы.
Звярніце ўвагу, што ў прыведзеным вышэй прыкладзе выкарыстоўваецца сцяг `--cached`. Калі мы не дадамо гэты сцяг, Git выдаліць файл не толькі з сховішча, але і з вашай файлавай сістэмы.
Калі вы здзейсніце змяненне з дапамогай `git commit -m" Remove file1.js "` і перанеслі яго ў аддаленае сховішча з дапамогай `git push origin master`, выдалены рэпазітар выдаліць файл.
## Дадатковая інфармацыя
- Калі вы хочаце выдаліць больш за адзін файл, гэта можна зрабіць, пералічыўшы ўсе файлы ў адной камандзе:
`git rm file1.js file2.js file3.js --cached`
- Вы можаце выкарыстоўваць шаблон (*) для выдалення файлаў з блізкімі імёнамі, напрыклад, калі вы хочаце выдаліць усе .txt файлы з лакальнага рэпазітара, набярыце:
`git rm * .txt --cached`
docs/additional-material/translations/Belarusian/removing-branch-from-your-repository.by.md
+31
View File
@@ -0,0 +1,31 @@
# Выдаленне галінкі з вашага рэпазітара
Калі вы да гэтага часу выконвалі ўрок, то наша галіна `<add-your-name>` скончыла сваё прызначэнне, прыйшоў час выдаліць яго з рэпазітара вашай лакальнай машыны. Гэта не абавязкова, але назва гэтай галіны паказвае сваё даволі спецыяльнае прызначэнне. Яго жыццё можа быць адпаведна кароткім.
Спачатку давайце аб'яднаем ваша `<add-your-name>` з вашым майстрам, каб перайсці да вашай галіны:
```
git checkout master
```
Зліце `<add-your-name>` у майстар:
```
git merge <add-your-name> master
```
Выдаліце `<add-your-name>` у сховішчах вашай лакальнай машыны:
```
git branch -d <add-your-name>
```
Цяпер вы выдалілі галінку лакальнай машыны `<add-your-name>` і ўсё выглядае акуратна і акуратна.
Хоць, у гэты момант у вашай раздзеле GitHub усё яшчэ павінна быць аддзяленне `<add-your-name>`. Тым не менш, перш чым выдаліць гэта, памятайце, што вы адправілі "Pull request" у маё сховішча з гэтага аддаленага аддзялення. Таму, калі я ўжо аб'яднаў гэта, не выдаляйце гэтую галінку.
Аднак калі я аб'яднаў вашу галіну і вы хочаце выдаліць аддаленую галінку, выкарыстоўвайце:
```
git push origin --delete <add-your-name>
```
Цяпер вы ведаеце, як прывесці ў парадак свае галіны.
З часам у маім публічным сховішчы будзе дададзена шмат камісій. І галоўныя галіны мясцовай машыны і вашага відэльца GitHub не будуць актуальнымі. Такім чынам, каб захаваць вашыя сховішча сінхранізаванымі з маімі, выканайце наступныя дзеянні.
#### [Захоўваючы відэлец сінхранізаваным з сховішчам](keeping-your-fork-synced-with-this-repository.md)
docs/additional-material/translations/Belarusian/resolving-merge-conflicts.by.md
+33
View File
@@ -0,0 +1,33 @@
# Што такое канфлікт зліцця?
Пры спробе аб'яднаць іншую галінку з вашай бягучай працоўнай галіной, вы ўносіце змены ў іншы кантэкст і аб'ядноўваючы іх з вашымі бягучымі файламі.
Калі два чалавекі змянілі аднолькавыя радкі ў адным файле альбо калі адзін чалавек вырашыў выдаліць яго, а другі вырашыў змяніць яго, Git не зможа вызначыць, якая версія з'яўляецца правільнай. Затым Git пазначыць файл як канфлікт - які вам давядзецца вырашыць, каб працягнуць працу.
# Як вырашыць канфлікт аб аб'яднанні?
Сутыкнуўшыся з канфліктам зліцця, git пазначыць праблемную вобласць у файле, уключыўшы яе ў “<<<<<<<< HEAD” and “>>>>>>>>>>[other branch name]”
Змесціва пасля першага маркера паходзіць з вашай бягучай галіны. Пасля кутніх дужак, Git паведамляе нам, адкуль (з якой галіны) адбыліся змены. Радок з "=======" падзяляе два супярэчлівыя змены.
Наша задача складаецца ў тым, каб ачысціць гэтыя радкі: калі мы скончым, файл павінен выглядаць так, як мы хочам, каб ён выглядаў. Пажадана звярнуцца да таварыша па камандзе, які напісаў супярэчлівыя змены, каб вырашыць, якая версія павінна быць канчатковай. Гэта можа быць альбо ваша - альбо можа быць сумесь паміж імі.
напрыклад:
```
<<<<<<< HEAD:mergetest
This is my third line
=======
This is a fourth line I am adding
>>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest
```
`<<<<<<<`: Пазначае пачатак радкоў, якія мелі канфлікт аб'яднання. Першы набор радкоў - гэта радкі з файла, у які вы спрабавалі аб'яднаць змены.
`=======`: Паказвае кропку перапынку, якая выкарыстоўваецца для параўнання. Разбівае змены, якія карыстальнік здзейсніў (вышэй) да зменаў, якія адбываюцца ад аб'яднання (унізе), каб візуальна ўбачыць адрозненні.
`>>>>>>>`: Пазначае канец радкоў, якія мелі канфлікт зліцця.
Вы можаце вырашыць канфлікт, адрэдагаваўшы файл, а затым злучыўшы яго ўручную. Гэта можа азначаць адмену альбо змены альбо чыё-небудзь ці далейшае спалучэнне двух. Вам таксама трэба выдаліць файлы <<<<<<<< ',' ======= 'і' >>>>>>> '.
Пасля развязання канфлікту зрабіце `git add`. Не забудзьцеся запусціць тэсты, бо вы павінны пераканацца, што вы вырашылі канфлікт.
Вы таксама можаце загрузіць розныя плагіны ў залежнасці ад IDE, які вы выкарыстоўваеце для больш простага спосабу ўрэгулявання канфліктаў аб'яднання.
# Як адмяніць зліццё?
Калі вы хочаце адмяніць зліццё, то можаце зрабіць `git merge —abort`
docs/additional-material/translations/Belarusian/reverting-a-commit.by.md
+40
View File
@@ -0,0 +1,40 @@
# Вярнуць каміт
Скасаваць абавязацельства проста азначае стварыць зусім новы дакумент, які адмяняе ўсе
змены, унесеныя ў папярэдні. Гэта як рабіць `` CTRL + Z `` `на git.
У Git пераўтварэнне палягчаецца, таму што кожны ўклад, які вы commit на свой аддалены сховішча, мае ўнікальны алфавітна-лічбавы ключ, вядомы пад назвай SHA (Secure Hash Algorithm).
Такім чынам, гэта азначае, што вы можаце вярнуць любыя абавязацельствы, пакуль у вас ёсць SHA.
Але потым, вы павінны быць асцярожныя, каб змяніць упарадкаванасць, каб не сапсаваць ваша сховішча.
Каб выбраць SHA канкрэтнага абавязацельства, якое мы хочам адмяніць, зручны быў бы часопіс усіх дасягнутых намі абавязкаў.
Каб атрымаць гэта, мы запусцім каманду:
`` `git log --oneline` ``
Адзінае выкананне каманды `` git log`` таксама дасць нам SHA (у доўгай форме)
Аднак выкарыстанне сцяга `` --oneline `` кажа git, што мы хочам, каб ён быў адлюстраваны ў сціслым (адным радку) парадку для зручнага чытання.
Першыя 7 знакаў, якія адлюстроўваюцца пры выкананні гэтай каманды, называюцца скарочаным хэшам фіксацыі.
Напрыклад, вось што я атрымліваю, калі ў гэтым рэпазітары запускаю `` git log --oneline ``:
```
389004d added spacing in title
c1b9fc1 Merge branch 'master' into tutorials
77eaafd added tutorial for reverting a commit
```
Гэта паказвае, што з дапамогай `` git log --oneline``, мы можам атрымаць спіс усіх абавязацельстваў, зробленых у сховішча, разам з першымі 7 сімваламі яго SHA.
Давайце выкажам здагадку, што я хачу адмяніць здзяйсненне "дадання прамежкаў у загалоўку". Вось наступныя дзеянні:
* Скапіруйце SHA дакумента, які ў дадзеным выпадку з'яўляецца `` 389004d ``
* Затым запусціце каманду ```git revert 389004d```
Гэта адкрые мой тэкставы рэдактар і прапануе мне адрэдагаваць паведамленне пра commit.
Вы можаце вырашыць пакінуць паведамленне commit як паведамленне па змаўчанні git, якое пачынаецца са слова `Revert`
альбо вы таксама можаце вырашыць наладзіць паведамленне па сваім гусце.
* Далей я буду захоўваць і закрываць тэкставы рэдактар.
* Вярнуцца да каманднага радка.
* Запусціце `` `git push origin <branch-name>` ``, каб націснуць на зваротныя змены ў Github.
І гэта ўсё, змены будуць адменены. У гэтым выпадку маё сховішча будзе зменена на тое, як яно выглядала ў `` c1b9fc1``
docs/additional-material/translations/Belarusian/squashing-commits.by.md
+86
View File
@@ -0,0 +1,86 @@
# Што такое squashing?
У git, squashing маецца на ўвазе перапісванне гісторыі вашых учынкаў, таму вы ў канчатковым выніку займаецеся апісаннем зробленых змяненняў.
Звычайна гэта робіцца ў праектах з адкрытым зыходным кодам, таму што шмат гісторыяў філіялаў у праектах з адкрытым зыходным кодам мае дачыненне толькі да распрацоўшчыка, які іх стварыў, і гэта дае больш просты спосаб апісаць унесеныя змены, а таксама пры неабходнасці аднавіць іх.
# Як вы робіце squash камітаў?
Па-першае, выканаць часопіс git, каб прааналізаваць каміт, якія вы хацелі б аб'яднаць у вашай бягучай галіны.
```
git log
```
Вы павінны ўбачыць шэраг сваіх абавязацельстваў так:
```
commit blablabla
Author: omguhh
Date: 10/10/20
Commit message 1
commit blablabla2
Author: omguhh
Date: 10/10/20
Commit message 2
```
Такім чынам, зараз, калі вы бачыце каміты, якія вы хочаце злучыць з адным, мы можам перайсці да гэтага з `` git rebase `` . Зыходзячы з таго, што вы ўжо знаёмыя з `` git rebase `` , мы можам пачаць squashing камітаў ў інтэрактыўным рэжыме git rebase, які можна актываваць так:
```
git rebase -i
```
Цяпер, пры дапамозе інтэрактыўнага rebasing вы можаце вызначыць пачатковую і канчатковую кропку таго, як далёка вы хочаце ісці з такімі ўчынкамі:
```
git rebase -i HEAD~2
```
Запуск гэтай каманды пакажа вам нешта падабаецца наступнае:
```
pick blablabla Changing test01.txt file
pick blablabla2 Adding dummy01.txt file
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
```
Такім чынам, калі вы хочаце squash ``` blablabla2``` на ``` blablablabla```, вы змяніце наступнае:
```
pick blablabla Changing test01.txt file
squash blablabla2 Adding dummy01.txt file
```
Калі ўсё пойдзе добра, вы атрымаеце такі вынік:
```
# This is a combination of 2 commits.
# The first commit's message is:
commit message 1
# This is the 2nd commit message:
commit message 2
```
Што вы можаце свабодна змяніць, перш чым вырашыць выйсці з рэдактара, каб захаваць гэтыя змены.
Запуск часопіса git павінен паказаць вам паведамленне аб здзяйсненні, якое вы ўвялі перад выхадам на экран, з абавязацельствамі, аб'яднанымі ў адзін.
docs/additional-material/translations/Belarusian/stashing-a-file.by.md
+137
View File
@@ -0,0 +1,137 @@
# Прыхаваць
Што рабіць, калі вы працуеце над вялікім кодам і раптам вам трэба пераключыць галіну, з якой вы зараз працуеце, на іншую. Паколькі код не з'яўляецца поўным і без якіх-небудзь тэстаў вы, верагодна, не хочаце яго commit. Але вы не можаце перайсці ў іншую галіну без унясення змяненняў, Git не дазволіць вам парушыць гэты паток. Што мы тады робім? Як мы прадухіляем непатрэбнае commit, маючы магчымасць скакаць з галінак? Вось што ахоплівае гэты падручнік.
## Схаванне працы
Дапусцім, што вы працуеце ў аддзяленні праекта, дзе вы змянілі некаторыя файлы. Цяпер, калі вы запусціце ``git status``, вы можаце ўбачыць змены ў файлах.
```
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: lib/simplegit.rb
#
```
Цяпер вы хочаце пераключыць сваю галіну, але пакуль не хочаце ўносіць змены; каб вы захавалі змены.
Каб націснуць на stack новы сродак, запусціце `` git stash``:
```
$ git stash
Saved working directory and index state \
"WIP on master: 049d078 added the index file"
HEAD is now at 049d078 added the index file
(To restore them type "git stash apply")
```
Цяпер ваш працоўны каталог чысты, выкарыстоўвайце ```git status```:
```
$ git status
# On branch master
nothing to commit, working directory clean
```
Цяпер вы можаце перайсці ў любую галіну і зрабіць сваю працу; схаваныя змены захоўваюцца ў выглядзе stack. Каб даведацца, якія stashes вы захоўваеце ў stack, вы можаце выкарыстоўваць `` git stash list``:
```
$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051 Revert "added file_size"
stash@{2}: WIP on master: 21d80a5 added number to log
```
У выпадку, калі вы хочаце паўторна ўжыць змены, якія вы толькі што схавалі, вы можаце скарыстацца камандай `` git stash apply``. З дапамогай гэтай каманды вы можаце паўторна ўжыць апошні захованы файл. Для таго, каб паўторна прымяніць любы іншы файл, вы можаце пазначыць яго, назваўшы яго так: ```git stash apply <stash-name>```, замест `` `<stash-name>` `` напішыце імя stash i трэба зноў падаваць.
```
$ git stash apply
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: index.html
# modified: lib/simplegit.rb
#
```
Вы можаце бачыць, што git паўторна змяняе файл, які вы выдалілі, калі вы захавалі пазыцыю. У гэтым выпадку ў вас быў чысты рабочы каталог, калі вы спрабавалі прымяніць stash, і вы паспрабавалі прымяніць яго ў той жа галіны, ад якой вы захавалі; але мець чыстую працоўную дырэкторыю і ўжываць яе ў той жа галінцы не трэба, каб паспяхова ўжываць скрыні. Вы можаце захаваць скрыні на адной галінцы, перайсці на іншую галінку пазней і зноў ужыць змены ў новай галінцы. Вы таксама можаце мець змененыя і неадкрытыя файлы ў вашым працоўным каталогу, калі вы ўжываеце stash, git дае канфлікты зліцця, калі што-небудзь больш не ўжываецца чыста.
Змены, унесеныя ў вашыя файлы, паўторна ўжываюцца, але файл, які вы стварылі, не быў перазагружаны. Для гэтага вам трэба выканаць каманду `` git stash apply`` з ```--index```, каб сказаць камандзе зноў прымяняць паэтапныя змены. Калі б вы запусцілі гэта, вы вярнуліся ў зыходнае становішча:
```
$ git stash apply --index
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: lib/simplegit.rb
#
```
Каманда ўжываць прымяняецца толькі для зачыненай працы, але ў вас усё яшчэ ёсць у вашым stack. Для таго, каб выдаліць яго, вы можаце запусціць `` git stash drop`` з іменем stack для выдалення.
```
$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051 Revert "added file_size"
stash@{2}: WIP on master: 21d80a5 added number to log
$ git stash drop stash@{0}
Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
```
Вы можаце выкарыстоўваць `` git stash pop``, каб выдаліць апошнія змены, выдаліўшы іх са свайго stack.
## Адмена прымянення stash
У некаторых выпадках вы хочаце прымяніць затоеныя змены, выканаць некаторыя працы, але ўжываць змены, якія першапачаткова прыйшлі з stash. Git не падае такую каманду, як `` git unapply` ``, але можна дасягнуць гэтага эфекту, проста здабыўшы patch, звязаны са stash, і прымяніць яго ў зваротным парадку:
```$ git stash show -p stash@{0} | git apply -R```
Зноў жа, калі вы не ўкажыце stash, Git мяркуе самую свежую stash:
```$ git stash show -p | git apply -R```
Магчыма, вы захочаце стварыць псеўданім і эфектыўна дадаць каманду `` stash-unapply`` у свой Git. Напрыклад:
```
$ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
$ git stash apply
$ #... work work work
$ git stash-unapply
```
## Стварэнне аддзялення з stash
Калі вы захоўваеце якую-небудзь працу, пакіньце яе там на некаторы час і працягвайце працу на той галінцы, з якой вы схавалі працу, у вас могуць паўстаць праблемы пры паўторнай працы. Калі заяўка паспрабуе змяніць файл, які вы ў свой час змянілі, у вас атрымаецца канфлікт аб'яднання, і вам прыйдзецца яго вырашыць. Калі вы хочаце больш проста пратэставаць схаваныя змены, вы можаце запусціць `` git stash branch``, які стварае для вас новае аддзяленне, правярайце абавязацельствы, якія вы выконвалі, калі вы прыхавалі працу, і зноў адпраўляе сваю працу. там, а затым скідае скрыню, калі яна паспяхова ўжываецца:
```
$ git stash branch testchanges
Switched to a new branch "testchanges"
# On branch testchanges
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
#
# modified: lib/simplegit.rb
#
Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359)
```
Гэта добры цэтлік, каб лёгка аднавіць схаваную працу і працаваць над ёй у новым аддзяленні.
docs/additional-material/translations/Belarusian/undoing-a-commit.by.md
+59
View File
@@ -0,0 +1,59 @@
# Адмяніць мясцовыя каміты
Каб адмяніць мясцовыя каміты, усё, што вам трэба зрабіць, гэта
```
git reset
```
Гэтая каманда прывядзе да скіду staging вобласці да апошні каміт, але змены, якія ўнесены ў ваш працоўны каталог, не зменіцца. Такім чынам, вы ўсё яшчэ можаце зноў камітаць тое, што вы змянілі.
Ці, калі вы хочаце выдаліць толькі адзін файл з папярэдняга каміту. Затым вы можаце зрабіць каманду ніжэй
```
git reset <file>
```
Каманда выдаліць толькі пазначаны файл з staging вобласці, але змены, унесеныя ў файл, усё яшчэ застануцца.
Прыклад выкарыстання ```git reset```
```
# Make changes in index.php and tutorial.php
# Add files into the staging area
$ git add .
# Remembered both files need to be committed separately
# Unstage tutorial.php
$ git reset tutorial.php
# Commit index.php first
$ git commit -m "Changed index.php"
# Commit tutorial.php now
$ git add tutorial.php
$ git commit -m "Changed tutorial.php"
```
Дапусцім, калі вы пераблыталі сваё лакальнае сховішча і проста хочаце скінуць яго на апошні ўдзел.
Затым вы можаце запусціць каманду ніжэй.
```
git reset --hard
```
Каманда не толькі скіне ваша staging вобласць, але і верне ўсе вашы змены ў файлах да вашай апошняй commit.
Рэжым `` --hard `` загадвае Git таксама адмяняць усе змены ў працоўным каталогу.
Вы павінны запускаць гэта толькі тады, калі вы сапраўды ўпэўненыя ў тым, што выкінеце цэлае local development.
Прыклад выкарыстання ```git reset --hard```
```
# Decided to start a crazy experiment
# Create a new file 'crazy.php' and add some code to it
# Commit crazy.php
$ git add crazy.php
$ git commit -m "Started a crazy dev"
# Edit crazy.php file again and changed a lot other files
# Commit all tracked files
$ git add .
$ git commit -m "Continued dev"
# Tested and things went out of hand
# Decided to remove the whole things
$ git reset --hard HEAD~2
```
```git reset --hard HEAD~2``` перамяшчае бягучую галінку назад на 2 commits адначасова, аднаўляючы ўсе зробленыя вамі змены і выдаляючы 2 здымкі, якія мы толькі што стварылі з гісторыі праектаў.
P.s. Ніколі не выконвайце `` git reset --hard```, калі вы ўжо перанеслі свае commits ў агульнае сховішча, паколькі гэта прывядзе да праблем з усімі рэпазітарамі.
docs/additional-material/translations/Bengali/add-file.bn.md
+31
View File
@@ -0,0 +1,31 @@
## একটি নতুন ফাইল সংযুক্ত করার টিউটোরিয়াল
আপনি যদি নতুন একটি ফাইল আপনার Git রিপোজিটরিতে সংযুক্ত করতে চান, তাহলে এই টিউটোরিয়ালটি আপনার সাহায্য করতে পারে।
1. **নতুন ফাইল তৈরি করুন**:
- আপনি যে প্রজেক্ট ফোল্ডারে চান, তাতে যান।
- নতুন ফাইল তৈরি করতে আপনি যে টেক্সট সম্পাদক বা IDE ব্যবহার করে যেতে পারেন, বা যদি আপনার কোন আইডি থাকে তাহলে তার মাধ্যমেও ফাইল তৈরি করতে পারেন।
- ফাইলটির একটি নির্দিষ্ট নাম দিন এবং সংরক্ষণ করুন।
2. **ফাইলটি স্থানান্তর করুন**:
- টার্মিনাল খুলুন এবং রিপোজিটরি ফোল্ডারে চলে যান।
- নতুন ফাইলটি স্থানান্তর করতে আপনি নিম্নলিখিত কমান্ডটি ব্যবহার করুন:
```
git add নতুন_ফাইল.এক্সটেনশন
```
3. **কমিট করুন**:
- ফাইলটি স্থানান্তর করার পরে, একটি কমিট তৈরি করুন।
- নিম্নলিখিত কমান্ডটি ব্যবহার করুন:
```
git commit -m "নতুন ফাইল সংযুক্ত করা হয়েছে"
```
4. **রিমোট রিপোজিটরিতে পুশ করুন**:
- এখন আপনার ফাইলটি আপনার লোকাল রিপোজিটরিতে রয়েছে। এটি রিমোট রিপোজিটরিতে পাঠাতে হলে নিম্নলিখিত কমান্ডটি ব্যবহার করুন:
```
git push দূরস্থ_শাখা
```
- এখানে "দূরস্থ_শাখা" তা হলো সে নাম যেখানে আপনি ফাইলটি সংযুক্ত করতে চান।
এখন আপনি নতুন একটি ফাইলকে আপনার রিপোজিটরিতে সংযুক্ত করেছেন।
docs/additional-material/translations/Bengali/additional-material.be.md
+52
View File
@@ -0,0 +1,52 @@
# অতিরিক্ত তথ্য
আমরা ধরে নিচ্ছি যে আপনি এখানে আসার আগে প্রাথমিক টিউটোরিয়ালটি ইতিমধ্যেই শেষ করেছেন। এই নথিটি আপনাকে উন্নত গিট কৌশল সম্পর্কে কিছু অতিরিক্ত তথ্য দেবে।
### [একটি প্রতিশ্রুতি সংশোধন](amending-a-commit.md)
এই নথিটি রিমোট রিপোজিটরিতে একটি প্রতিশ্রুতি কীভাবে সংশোধন করতে হয় সে সম্পর্কে তথ্য সরবরাহ করে। একটি প্রতিশ্রুতি সংশোধন করা হল আপনার বর্তমান শাখায় করা সাম্প্রতিকতম প্রতিশ্রুতি পরিবর্তন করার একটি উপায়। আপনি যদি প্রতিশ্রুতি বার্তাটি সম্পাদনা করতে চান বা আপনি প্রতিশ্রুতিতে পরিবর্তনগুলি অন্তর্ভুক্ত করতে ভুলে যান তবে এটি সহায়ক হতে পারে। আপনি একটি প্রতিশ্রুতি সংশোধন করা চালিয়ে যেতে পারেন যতক্ষণ না আপনি এটিকে দূরবর্তী সংগ্রহস্থলে ঠেলে দেন।
> আপনার করা একটি প্রতিশ্রুতি সামঞ্জস্য করার প্রয়োজন হলে এটি ব্যবহার করুন।
### [গিট কনফিগার করা](configuring-git.md)
এই নথি ব্যবহারকারী বিবরণ এবং অন্যান্য বিকল্পগুলি গিটে কনফিগার করতে কিভাবে তথ্য প্রদান করে তা সম্পর্কে তথ্য প্রদান করে।
> গিট কনফিগারেশন চলাচল আপনার গিট কনফিগারেশন ভাল করার জন্য এটি ব্যবহার করুন।
### [আপনার ফর্ক এই রিপোজিটরি সাথে সিঙ্ক রাখা](keeping-your-fork-synced-with-this-repository.md)
এই নথি আপনার ফর্কড রিপোজিটরি আপ-টু-ডেট রাখতে কিভাবে সম্পর্কিত তথ্য প্রদান করে যেভাবে আপনি আশা করছেন এবং আশাবাদে আপনি এবং অনেকে প্রকল্পে অবদান রাখবেন।
> এই পদক্ষেপগুলি অনুসরণ করুন যদি আপনার ফর্কে কোনও পরিবর্তন না থাকে মূল রিপোজিটরি থেকে।
### [একটি কমিটকে আবার অন্য শাখায় সরানো](moving-a-commit-to-a-different-branch.md)
এই নথি একটি কমিটকে অন্য শাখায় সরাতে কীভাবে তথ্য প্রদান করে।
> একটি কমিটকে অন্য শাখায় সরাতে এই পদক্ষেপগুলি নিন।
### [একটি ফাইল সরানো](removing-a-file.md)
এই নথি আপনার লোকাল রিপোজিটরি থেকে একটি ফাইল সরাতে কীভাবে তথ্য প্রদান করে।
> একটি কমিট পূর্বে একটি ফাইল সরানোর জন্য এই পদক্ষেপগুলি অনুসরণ করুন।
### [আপনার রিপোজিটরি থেকে একটি শাখা সরানো](removing-branch-from-your-repository.md)
এই নথি তথ্য সরবরাহ করে কিভাবে আপনি আপনার রিপোজিটরি থেকে একটি শাখা মুছতে পারেন।
> আপনার পুল অনুরোধটি মার্জ হলে, পরবর্তী পদক্ষেপগুলি অনুসরণ করুন।
### [মার্জ সংঘর্ষ সমাধান](resolving-merge-conflicts.md)
এই নথি তথ্য সরবরাহ করে কিভাবে মার্জ সংঘর্ষ সমাধান করতে হয়।
> ক্ষিপ্তকর মার্জ সংঘর্ষগুলি সমাধান করতে এই পদক্ষেপগুলি নিন।
### [একটি কমিট পুনরায় ফিরানো](reverting-a-commit.md)
এই নথি তথ্য সরবরাহ করে কিভাবে রিমোট রিপোজিটরিতে একটি কমিট পুনরায় ফিরাতে হয়। এটি কাজে আসবে যখন আপনি ইতিমধ্যে Github-এ পুশ করা একটি কমিট কে আনডু করতে হবে।
> একটি কমিট পুনরায় ফিরাতে এই পদক্ষেপগুলি নিন।
### [কমিটগুলি স্কোয়াশ করা](squashing-commits.md)
এই নথি তথ্য সরবরাহ করে কিভাবে ইন্টারাক্টিভ রিবেস দ্বারা কমিটগুলি স্কোয়াশ করতে হয়।
> এটি ব্যবহার করুন যদি আপনি একটি ওপেন সোর্স প্রকল্পে একটি পিআর খোলতে চান এবং পর্যালোচক আপনি প্রত্যেক কমিটকে একটিতে স্কোয়াশ করতে বলে।
### [স্থানীয় কমিট পুনরায় করা](undoing-a-commit.md)
এই নথি তথ্য সরবরাহ করে কিভাবে আপনি আপনার স্থানীয় রিপোজিটরিতে একটি কমিট পুনরায় করতে পারেন। এটি তখন প্রয়োজন হয় যখন আপনি মনে করেন যে আপনি আপনার স্থানীয় রিপোজিটরি গুলি জটিল করে দিয়েছেন এবং আপনি স্থানীয় রিপোজিটরি রিসেট করতে চান।
> আপনি যদি একটি স্থানীয় কমিট পুনরায় করতে চান তবে এই পদক্ষেপগুলি নিন।
### [দরকারি লিঙ্কসমূহ](Useful-links-for-further-learning.md)
এই নথি সমস্ত টিপস এবং ট্রিক ওয়েবসাইট, ব্লগ পোস্ট এবং সাহায্যকারী সাইটগুলির উপর ভরা দেওয়া হয় যা আমাদের জীবনকে সহজ করে। এগুলি সমস্ত প্রয়োজনীয় তথ্যের জন্য একটি মহাপ্রয়োজনী সূত্র। এই পৃষ্ঠাটি সকল উপকারী লিঙ্কের একটি সূচী হিসেবে করতে পারে।
### [.gitignore ফাইল তৈরি করা](creating-a-gitignore-file.md)
এই নথি ব্যাখ্যা করে কী করে .gitignore ফাইল কাজ করে, তার জন্য কেন এবং .gitignore ফাইল কীভাবে তৈরি করতে হয়। এই ফাইলটি প্রায় সব গিট প্রকল্পে ব্যবহৃত হয়। এটি গিটে কেবল প্রয়োজনীয় ফাইলগুলি কমিট করতে সাহায
### [শংসাপত্র সংরক্ষণ করা](storing-credentials.md)
এই নথি বর্ণনা করে কীভাবে আপনি আপনার ভণ্ডার জন্য শংসার রক্ষণা করতে পারেন। এটি একটি নিরাপত্তা সম্পর্কিত সময় হতে পারে, তাই আপনি আপনার কাজে/অধ্যয়নের স্থানের নিরাপত্তা নীতিগুলি অনুসরণ করুন।
docs/additional-material/translations/Chinese/additional-material.zh-cn.md
+46
View File
@@ -0,0 +1,46 @@
# 附加资料
我们认为你在来到这里之前已经完成基本教学。附加资料会给你关于 Git 进阶技术的信息。
### [从你的 repository 删除分支](../removing-branch-from-your-repository.md)
这份文件教你如何从 repository 删除分支。
> 在做这些步骤前确定你的 pull request 是被合并的。
### [保持你的分叉与 repository 同步](../keeping-your-fork-synced-with-this-repository.md)
这份文件提供保持分叉与原始 repository 同步的资料。这件事情是很重要的，因为有其他人会对 project 做出贡献。
> 如果你的分叉没有对原始 repository 做改变，根据这些步骤操作。
### [回滚 commit](../reverting-a-commit.md)
这份文件提供如何对远端 repository 回滚 commit。这项操作在需要回滚 commit，但已经 push 到 Github时适用。
> 如果你想要回滚 commit，根据这些步骤操作。
### [修改 commit](../amending-a-commit.md)
这份文件教你如何在修改在远端的 commit。
> 在你需要调整 commit 的时候使用这个。
### [恢复本地的 commit](../undoing-a-commit.md)
这份文件教你如何恢复本地的 commit。在你觉得你搞砸了本地的 repository，并且希望重置你的 repository时，照着做就对了。
> 如果你需要回复/重置 commit 时，跟着做吧。
### [解决合并冲突](../resolving-merge-conflicts.md)
这份文件教你解决合并时的冲突。
> 跟着这些步骤来解决烦人的冲突。
### [删除文件](../removing-a-file.md)
这份文件教你从本地 repository 中删除文件。
> 跟着这些步骤学习如何从之前的 commit 中删除文件。
### [移动 commit 到另一个分支](../moving-a-commit-to-a-different-branch.md)
这份文件教你如何移动 commit 到另一个分支。
> 跟着步骤移动 commit 到另一个分支。
### [配置 git](../configuring-git.md)
这份文件教你设置 git 的用户资料与其他选项。
> 阅读这份文件让你对 git 配置更有掌握。
### [好用的链接](../Useful-links-for-further-learning.md)
这份文件包含许多好用的博文、网站、提示和小技巧，了解这些让我们可以更容易上手。这一页应该当做好用链接的索引，让开源的新手还有想认识开源的人可以了解更多。
### [挤压 commits](../squashing-commits.md)
这份文件教你如何通过交互式 rebase 挤压 commits。
> 如果你想要发出一个 PR，但检阅者要求你将一部分 commits 挤压成一个 commits 通过交互式 rebase。
docs/additional-material/translations/Chinese/addtional-material.cht.md
+46
View File
@@ -0,0 +1,46 @@
# 附加資料
我們認為你在來到這裡以前已經完成基本教學。附加資料會給你關於 Git 進階技術的資訊。
### [從你的 repository 刪除分支](../../git_worklow_scenarios/removing-branch-from-your-repository.md)
這份文件教你如何從 repository 刪除分支。
> 在做這些步驟前確定你的 pull request 是被合併的。
### [保持你的分叉與 repository 同步](../../git_workflow_scenarios/keeping-your-fork-synced-with-this-repository.md)
這份文件提供保持分叉與原始 repository 同步的資料。這件事情是很重要的，因為有其他人會對 project 做出貢獻。
> 如果你的分叉沒有對原始 repository 做改變，根據這些步驟做操作。
### [回復 commit](../../git_workflow_scenarios/reverting-a-commit.md)
這份文件提供如何對遠端 repository 回復 commit。這項操作適用在你需要回復 commit，但你已經 push 到 Github。
> 如果你想要回復 commit，根據這些步驟操作。
### [修訂 commit](../../git_workflow_scenarios/amending-a-commit.md)
這份文件教你如何在修訂在遠端的 commit。
> 在你需要調整 commit 的時候使用這個。
### [回復本地的 commit](../../git_workflow_scenarios/undoing-a-commit.md)
這份文件教你如何回復本地的 commit。在你覺得你搞砸了本地的 repository，並且希望重置你的 repository時，照著做就對了。
> 如果你需要回復/重置 commit 時，跟著做吧。
### [解決合併時的衝突](../../git_workflow_scenarios/resolving-merge-conflicts.md)
這份文件教你解決合併時的衝突。
> 跟著這些步驟來解決煩人的衝突。
### [刪除檔案](../../git_workflow_scenarios/removing-a-file.md)
這份文件教你從本地 repository 中刪除檔案。
> 跟著這些步驟學習如何從之前的 commit 中刪除檔案。
### [移動 commit 到另一個分支](../../git_workflow_scenarios/moving-a-commit-to-a-different-branch.md)
這份文件教你如何移動 commit 到另一個分支。
> 跟著步驟移動 commit 到另一個分支。
### [配置 git](../../git_workflow_scenarios/configuring-git.md)
這份文件教你設定 git 的使用者資料與其他選項。
> 閱讀這份文件讓你對 git 配置更有掌握。
### [好用的連結](../../git_workflow_scenarios/Useful-links-for-further-learning.md)
這份文件包含許多好用的部落格文章、網站、提示和小技巧，了解這些讓我們可以更容易上手。這一頁應該當做好用連結的索引，讓開源的新手還有想認識開源的人可以了解更多。
### [擠壓 commits](../../git_workflow_scenarios/squashing-commits.md)
這份文件教你如何藉由互動式 rebase 擠壓 commits。
> 如果你想要發出一個 PR，但檢閱者要求你將一部份 commits 擠壓成一個 commits 藉由互動式 rebase。
docs/additional-material/translations/Farsi/amending-a-commit.fa.md
+85
View File
@@ -0,0 +1,85 @@
# اصلاح یک کامیت
چه کار باید بکنی اگر یک تغییر را روی کامیت کردی ولی بعدا متوجه شدی که پیام کامیت مشکل داشته و یا فراموش کردی یک خط به آخرین کامیتت اضافه کنی.
چجوری میشود این را اصلاح کرد؟
این موضوعی است که در این آموزش به آن پرداخته میشود.
## تغییر دادن پیام یک کامیت که اخیرا به گیت هاب ارسال کردی
برای این کار بدون باز کردن فایلی:
1.تایپ کنید:
```
git commit --amend -m "پیام جدید برای این کامیت"
```
2.دستور
```
git push origin <نام-شاخه>
```
را اجرا کنید تا تغییرات در مخزن ثبت شوند
<br/>
نکته: اگر فقط تایپ کنی
```git commit --amend```، ویرایشگر متنت باز خواهد شد و درخواست تغییر پیام کامیت را خواهد داشت.
اضافه کردن ```m-``` از این پیشگیری می کند.
## اصلاح کردن یک کامیت
حالا اگر فراموش کرده باشی که یک تغییر کوچک مثل اضافه کردن یک کلمه به یک فایل را انجام بدی، و قبلا تغییرات را ثبت و به مخزن ارسال کرده باشی، چیکار باید انجام بدی؟
مثلا این لاگ (log) کامیت هاست:
```
g56123f create botfile
a2235d updated contributor.md
a5da0d modified botfile
```
برای مثال فراموش کردی که یک کلمه به (botfile) اضافه کنی.
از دو روش میشود این کار را انجام داد.
راه اول این است که یک کامیت جدید ایجاد کرد که شامل این تغییرات هست:
```
g56123f create botfile
a2235d updated contributor.md
a5da0d modified botfile
b0ca8f added single word to botfile
```
راه دوم این است که کامیت (a5da0d) را اصلاح کنی، کلمه جدید را اضافه کنی و به عنوان "یک" کامیت به مخزن ارسال کنی.
این راه به نسبت بهتر است برای اینکه فقط یک تغییر کوچک است.
برای این کار به ترتیب:
1.فایل را اصلاح کن. در این مثال فایل (botfile) را اصلاح میکنیم تا کلمه جدید را اضافه کنیم.
2.فایل را به تغییرات اضافه کنید:
```
git add <اسم-فایل>
```
معمولا بعد از اضافه کردن تغییرات، با دستور
```
git commit -m "our commit message"
```
تغییرات را ثبت میکنیم، ولی به خاطر اینکه می خواهیم کامیت قبلی را اصلاح کنیم، این دستور را اجرا کنیم:
```
git commit --amend
```
با اجرای این دستور ویرایشگر متن باز خواهد شد و تا پیام کامیت را تغییر بدی
ویرایشگر متن را ببند
تغییرات رو به مخزن ارسال کن..
```
git push origin <اسم-شاخه>
```
تمام شد. الان هر دو تغییر در یک کامیت ثبت شده اند.
docs/additional-material/translations/Farsi/delete-branch-locally.fa.md
+19
View File
@@ -0,0 +1,19 @@
# حذف کردن شاخه که به صورت محلی ایجاد شده است
این در زمانی سودمند خواهد بود که شما نام یک شاخه (برنچ) را اشتباه نوشته اید.
این کار به _3_ روش قابل انجام است
```
git branch -D <نام_مخزن>
```
```
git branch --delete --force <نام_مخزن> # Same as -D
```
```
git branch --delete <نام_مخزن> # Error on unmerge
```
پرچم `-D` مخفف `delete --force--` است که شاخه را حتی اگر مرج نشده باشد حذف میکند. (حذف اجباری)، ولی شما میتوانید از پرچم `d-` استفاده کنید که مخفف `delete--` است که با توجه با وضعیت مرج شاخه ارور خواهد داد.
docs/additional-material/translations/Farsi/moving-a-commit-to-a-different-branch.fa.md
+21
View File
@@ -0,0 +1,21 @@
## فراموش کردن رفتن به یک مخزن دیگر
وقتی که شما تغییراتی روی برنچ فعلی انجام داده ای و فراموش کرده اید آن را روی برنچ جدید انجام بدهید باید
1- مرحله اول
با دستور
```
git commit --amend -m "پیام جدید برای این کامیت"
```
را می کنید و وقتی کاملا تغییرات شما کامیت شده باشد
2- مخزن جدید ایجاد میکنید
با دستور
git checkout -b <نام_مخزن>
و می توانید تمام تغییرات را در مخزن جدید داشته باشید و در همان مخزن آن را
push
کنید
docs/additional-material/translations/French/additional-material.fr.md
+49
View File
@@ -0,0 +1,49 @@
# Informations supplémentaires
Nous partons du principe que vous avez déjà lu le tutoriel basique avant de vous rendre ici. Ce document vous donnera des informations complémentaires
sur les techniques avancées de Git.
### [Modifier un commit](amending-a-commit.md)
Cette page vous donnera les informations dont vous avez besoin pour modifier un commit sur un répertoire distant :
> Utilisez ceci pour corriger un commit que vous avez réalisé.
### [Configurer git](configuring-git.md)
Cette page vous donnera les informations dont vous avez besoin pour configurer les détails utilisateur vous concernant et d'autres options dans git :
> A utiliser pour un meilleur contrôle de la configuration de votre git.
### [Gardez votre embranchement (fork) synchronisé avec le répertoire](keeping-your-fork-synced-with-this-repository.md)
Ce document vous donne les informations pour conserver un répertoire "fork" à jour avec le répertoire source. Ceci est important et nous espérons que vous et beaucoup d'autres vont contribuer à ce projet.
> Suivez ces étapes si vous ne voyez aucun changement sur votre embranchement dans le répertoire parent.
### [Déplacer un Commit vers une Branche différente](moving-a-commit-to-a-different-branch.md)
Cette page vous donnera les informations dont vous avez besoin pour déplacer un Commit vers une Branche différente :
> Suivez ces étapes pour déplacer un Commit vers une Branche différente.
### [Supprimer un Fichier](removing-a-file.md)
Cette page vous donnera les informations dont vous avez besoin pour supprimer un Fichier depuis votre répertoire local :
> Suivez ces étapes pour apprendre comment supprimer un fichier avant d'effectuer un commit.
### [Supprimer une branche dans votre répertoire](removing-branch-from-your-repository.md)
Cette page vous donnera les informations dont vous avez besoin pour supprimer une branche de votre répertoire :
> Ne suivez ces étapes qu'une fois que votre demande de tirage a été fusionnée.
### [Résoudre les conflits de fusion (Merge Conflicts)](resolving-merge-conflicts.md)
Cette page vous donnera les informations dont vous avez besoin pour résoudre les problèmes de fusion :
> Suivez ces étapes pour résoudre ces problèmes de fusion (souvent pénibles).
### [Revenir à un commit](reverting-a-commit.md)
Cette page vous aidera si vous avez besoin de revenir à un commit précédent, sur le répertoire distant. Ceci est pratique dans le cas où vous auriez besoin d'annuler un commit que vous auriez déjà poussé sur Github.
> Suivez ces étapes si vous souhaitez reprendre un commit.
### [Aplatir des Commits](squashing-commits.md)
Cette page vous apprendra comment aplatir plusieurs commits en un seul.
> A utiliser si vous voulez ouvrir une demande de révision (pull request) et que l'évaluateur vous demande d'"aplatir" tous les commits en un seul, contenant un message d'information global.
### [Annuler un commit local](undoing-a-commit.md)
Cette page vous donne les informations dont vous avez besoin pour annuler un commit sur votre répertoire local. C'est ce que vous aurez besoin de faire si vous sentez que vous avez fait une erreur dans votre répertoire local et que vous voulez revenir à l'état précédent.
> Suivez ces instructions si vous voulez annuler / revenir à l'état précédent sur un commit local.
### [liens utiles](Useful-links-for-further-learning.md)
Cette page est dédiée à tous les sites de trucs et astuces, les blogs, et en règle générale les sites qui nous aident à rendre nos vies plus faciles. Ils sont d'excellentes références pour répondre à tous vos besoins, que vous soyez débutant ou expert. Cette page devrait être un index de tous ces liens utiles qui aideront tous ceux qui sont nouveaux dans le domaine de l'open-source ou ceux qui veulent approfondir leurs connaissances.
### [Créer un fichier .gitignore](creating-a-gitignore-file.md)
Ce document explique à quoi sert un fichier .gitignore, pourquoi l'utiliser et comment le créer. Ce fichier est utilisé dans quasiment tous les projets git. Il aide à ne prendre en compte dans les commits que les fichiers nécessaires.
docs/additional-material/translations/French/amending-a-commit.fr.md
+52
View File
@@ -0,0 +1,52 @@
# Modifier un commit
Imaginons que vous avez effectué un commit sur votre répertoire distant et que vous vous rendez compte plus tard qu'il
y a une coquille dans le message de commit ou que vous avez oublié d'ajouter une ligne dans votre tout dernier commit.
Comment faire pour rectifier cette erreur ? C'est le sujet de ce tutoriel.
## Changer un message de commit récent après l'avoir poussé sur Github
Pour se faire sans même ouvrir un fichier :
* Taper la commande ```git commit --amend -m "suivi de votre nouveau message de commit"```
* Lancer la commande ```git push origin <nom-de-la-branche>``` pour effectuer un commit vers le répertoire.
NB : Si vous tapez uniquement ```git commit --amend```, l'éditeur de texte s'ouvre et vous demande de modifier le
message de commit. Ajoutez l'option ``-m`` pour éviter de passer par l'éditeur de texte.
## Modifier un commit précis
Donc, qu'est-ce qu'il se passe si vous oubliez de faire un changement mineur sur un fichier, comme changer un mot et
que vous avez déjà poussé ce commit vers notre répertoire distant ?
Pour illustrer ce propos, voici un log de mes commits ;
```
g56123f création d'un fichier bot
a2235d mise à jour de contributeur.md
a5da0d modification du fichier bot
```
Imaginons que j'ai oublié d'ajouter un mot dans le fichier bot.
Il y a deux façons de régler ce problème. Le premier est de faire un nouveau commit qui contient le changement comme ceci :
```
g56123f création d'un fichier bot
a2235d mise à jour de contributeur.md
a5da0d modification du fichier bot
b0ca8f ajout d'un mot dans le fichier bot
```
La seconde façon est de modifier le commit a5da0d et d'ajouter ce nouveau mot puis le pousser sur Github le tout dans un seul commit.
Cette deuxième option semble plus adaptée, étant donné qu'il s'agit d'un changement mineur.
Pour se faire, il faut suivre les étapes suivantes :
* Modifier le fichier. Dans notre cas, on modifie le fichier bot pour y inclure le mot oublié.
* Ensuite, ajouter le fichier dans la zone de transit avec la commande ```git add <nom-du-fichier>```
D'habitude, après avoir ajouté des fichiers dans la zone de transit, l'étape suivante est d'exécuter la commande
git commit -m "notre message de commit", n'est-ce pas ? Mais comme ce qu'on veut ici c'est modifier le commit
précédent, on va plutôt lancer les commandes :
* ```git commit --amend```
Cela va faire apparaître l'éditeur de texte qui vous demande de modifier le message. Vous pouvez décider de laisser le
message tel quel ou bien le changer.
* Quitter l'éditeur
* Pousser vos changements avec la commande ```git push origin <nom-de-la-branche>```
De cette façon, les deux changements se trouvent dans un même commit.
docs/additional-material/translations/French/check-commit-log.fr.md
+20
View File
@@ -0,0 +1,20 @@
# Vérifier l'historique des commits
Pour vérifier l'historique des commits d'une branche ou d'un fichier, la commande suivante peut être utilisée :
git log [options] [path]
Par défaut, la sortie de cette commande est affichée dans l'ordre chronologique inverse.
## Variations et options de la commande
- Pour effectuer les commits accessibles à partir de certains identifiants de commit : <i>(Dans ce cas,`foo` et `bar`)</i><br>
`git log foo bar`
- Il est également possible de supprimer les commits accessibles à partir d'un identifiant de commit donné en ajoutant un `^` devant l'identifiant de commit: <i>(Dans ce cas, `baz`)</i><br>
`git log foo bar ^baz`
- Historique des commits pour un fichier spécifique <br>
`git log --all <nom_du_fichier>`
- Limiter le nombre de commits affichés dans l'historique : <i>(Dans ce cas, `5`)</i><br>
`git log -n 5`
## Référence
- [Documentation officielle](https://git-scm.com/docs/git/fr)
docs/additional-material/translations/Greek/git_workflow_scenarios/additional-material.gr.md
+52
View File
@@ -0,0 +1,52 @@
# Επιπλέον πληροφορίες
Υποθέτουμε ότι έχετε ήδη ολοκληρώσει το βασικό μάθημα πριν έρθετε εδώ. Αυτό το έγγραφο θα σας παρέχει πρόσθετες πληροφορίες για προηγμένες τεχνικές του Git.
### [Τροποποίηση μιας καταχώρησης (commit)](amending-a-commit.md)
Αυτό το έγγραφο παρέχει πληροφορίες σχετικά με το πώς να τροποποιήσετε μια καταχώρηση (commit) στο απομακρυσμένο αποθετήριο. Η τροποποίηση μιας καταχώρησης είναι ένας τρόπος για να διορθώσετε την πιο πρόσφατη καταχώρηση που έχετε κάνει στο τρέχον παρακλάδι σας. Αυτό μπορεί να είναι χρήσιμο εάν χρειάζεστε να επεξεργαστείτε το μήνυμα της καταχώρησης ή αν ξεχάσατε να συμπεριλάβετε αλλαγές στην καταχώρηση. Μπορείτε να συνεχίσετε να τροποποιείτε μια καταχώρηση μέχρι να την στείλετε στο απομακρυσμένο αποθετήριο.
> Χρησιμοποιήστε αυτό όταν χρειάζεστε να προσαρμόσετε μια καταχώρηση που έχετε κάνει.
### [Διαμόρφωση του Git](configuring-git.md)
Αυτό το έγγραφο παρέχει πληροφορίες σχετικά με το πώς να διαμορφώσετε τις λεπτομέρειες του χρήστη και άλλες επιλογές στο Git.
> Χρησιμοποιήστε αυτό για να έχετε καλύτερο έλεγχο των ρυθμίσεων του Git σας.
### [Συγχρονισμός του δικού σας αποθετηρίου με το αποθετήριο κύριου κώδικα](keeping-your-fork-synced-with-this-repository.md)
Αυτό το έγγραφο παρέχει πληροφορίες για το πώς να κρατήσετε το δικό σας διακλαδισμένο αποθετήριο ενημερωμένο με το κύριο αποθετήριο. Αυτό είναι σημαντικό, διότι ελπίζουμε ότι εσείς και πολλοί άλλοι θα συνεισφέρετε στο έργο.
> Ακολουθήστε αυτά τα βήματα εάν το δικό σας διακλαδισμένο αποθετήριο δεν έχει κάποιες αλλαγές στο κύριο αποθετήριο.
### [Μεταφορά μιας καταχώρησης (commit) σε διαφορετικό παρακλάδι](moving-a-commit-to-a-different-branch.md)
Αυτό το έγγραφο παρέχει πληροφορίες σχετικά με το πώς να μεταφέρετε μια καταχώρηση (commit) σε ένα άλλο παρακλάδι.
> Ακολουθήστε αυτά τα βήματα για να μετακινήσετε μια καταχώρηση (commit) σε άλλο παρακλάδι.
### [Διαγραφή ενός αρχείου](removing-a-file.md)
Αυτό το έγγραφο παρέχει πληροφορίες σχετικά με το πώς να διαγράψετε ένα αρχείο από το τοπικό αποθετήριο σας.
> Ακολουθήστε αυτά τα βήματα για να μάθετε πώς να διαγράψετε ένα αρχείο πριν από μια καταχώρηση (commit).
### [Διαγραφή παρακλαδιού από το αποθετήριο σας](removing-branch-from-your-repository.md)
Αυτό το έγγραφο παρέχει πληροφορίες σχετικά με το πώς να διαγράψετε ένα παρακλάδι από το αποθετήριο σας.
> Μόνο μετά την ενσωμάτωση (merge) του αιτήματος σας, ακολουθήστε τα επόμενα βήματα.
### [Επίλυση συγχώνευσης συγκρούσεων](resolving-merge-conflicts.md)
Αυτό το έγγραφο παρέχει πληροφορίες σχετικά με το πώς να επιλύσετε θέματα σύγκρουσης συγχώνευσης.
> Ακολουθήστε αυτά τα βήματα για να επιλύσετε τις ενοχλητικές συγχωνεύσεις συγκρούσεων.
### [Αναστροφή μιας καταχώρησης (commit)](reverting-a-commit.md)
Αυτό το έγγραφο παρέχει πληροφορίες σχετικά με το πώς να αναστρέψετε μια καταχώρηση (commit) στο απομακρυσμένο αποθετήριο. Θα σας φανεί χρήσιμο στην περίπτωση που χρειάζεστε να αναιρέσετε μια καταχώρηση (commit) που έχει ήδη ανέβει (pushed) στο Github.
> Ακολουθήστε αυτά τα βήματα αν θέλετε να αναστρέψετε μια καταχώρηση (commit).
### [Συμπίεση καταχωρήσεων (commits)](squashing-commits.md)
Αυτό το έγγραφο παρέχει πληροφορίες σχετικά με το πώς να συμπιέσετε (squash) καταχωρήσεις (commits) με μια διαδραστική επανεβολή (rebase).
> Χρησιμοποιήστε αυτό αν θέλετε να ανοίξετε ένα αίτημα συμμετοχής (pull request) σε ένα έργο ανοιχτού κώδικα και ο αναθεωρητής (reviewer) σας ζητήσει να συμπιέσετε κάθε καταχώρηση σε μία, με ένα ενημερωτικό μήνυμα καταχώρησης.
### [Αναίρεση τοπικής καταχώρησης (commit)](undoing-a-commit.md)
Αυτό το έγγραφο παρέχει πληροφορίες σχετικά με το πώς να αναιρέσετε μια καταχώρηση (commit) στο τοπικό αποθετήριό σας. Αυτό είναι αυτό που χρειάζεται να κάνετε όταν νιώθετε ότι έχετε μπερδέψει το τοπικό αποθετήριό σας και επιθυμείτε να επαναφέρετε το τοπικό αποθετήριο.
> Ακολουθήστε αυτά τα βήματα αν θέλετε να αναιρέσετε/επαναφέρετε μια τοπική καταχώρηση (commit).
### [Χρήσιμοι σύνδεσμοι](Useful-links-for-further-learning.md)
Αυτό το έγγραφο είναι αφιερωμένο σε όλους τους ιστότοπους με συμβουλές και κόλπα, αναρτήσεις σε ιστολόγια και χρήσιμους ιστότοπους που κάνουν τη ζωή μας πιο εύκολη. Αποτελεί μια εξαιρετική πηγή αναφοράς για όλες τις ανάγκες μας, είτε είμαστε αρχάριοι είτε ειδικοί, στον χώρο του ανοικτού κώδικα ή θέλουμε να μάθουμε περισσότερα.
### [Δημιουργία αρχείου .gitignore](creating-a-gitignore-file.md)
Αυτό το έγγραφο εξηγεί τι κάνει ένα αρχείο .gitignore, γιατί να το χρησιμοποιήσετε και πώς να δημιουργήσετε ένα αρχείο .gitignore. Αυτό το αρχείο χρησιμοποιείται σε σχεδόν όλα τα αποθετήρια Git. Βοηθά να κάνετε commit μόνο τα απαραίτητα αρχεία στο Git.
### [Αποθήκευση διαπιστευτηρίων](storing-credentials.md)
Αυτό το έγγραφο εξηγεί πώς να αποθηκεύσετε τα διαπιστευτήριά σας για αποθετήρια. Αυτό μπορεί να αποτελεί ανησυχία για την ασφάλεια, για αυτό παρακαλούμε να ακολουθείτε τις πολιτικές ασφαλείας του χώρου εργασίας/μελέτης σας.
docs/additional-material/translations/Greek/git_workflow_scenarios/amending-a-commit.gr.md
+69
View File
@@ -0,0 +1,69 @@
# Τροποποίηση μιας Καταχώρησης (Commit)
Τι γίνεται αν κάνετε μια αλλαγή στο απομακρυσμένο αποθετήριό σας μόνο για να συνειδητοποιήσετε αργότερα ότι έχετε ένα τυπογραφικό στο μήνυμα της καταχώρησης ή ότι ξεχάσατε να προσθέσετε μια γραμμή στην πιο πρόσφατη καταχώρησή σας. Πώς μπορείτε να το επεξεργαστείτε αυτό; Αυτό είναι αυτό που καλύπτεται σε αυτό το μάθημα.
## Αλλαγή του μηνύματος μιας πρόσφατης καταχώρησης μετά την αποστολή στο Github.
Για να το κάνετε αυτό χωρίς να ανοίξετε ένα αρχείο:
* Πληκτρολογήστε ```git commit --amend -m "και ακολουθείτε με το νέο μήνυμα καταχώρησης σας"```
* Εκτελέστε ```git push origin <όνομα παρακλαδιού>``` για να κάνετε commit τις αλλαγές στο αποθετήριο.
Σημείωση: Αν πληκτρολογήσετε μόνο ```git commit --amend```, ο κειμενογράφος σας θα ανοίξει και θα σας ζητήσει να επεξεργαστείτε το μήνυμα της καταχώρησης.
Η προσθήκη της σημαίας ```-m``` το αποτρέπει.
## Τροποποίηση μιας μόνο καταχώρησης
Τι γίνεται αν ξεχάσατε να κάνετε μια μικρή αλλαγή σε ένα αρχείο, όπως να αλλάξετε μια μόνο λέξη, και έχετε ήδη ανεβάσει την καταχώρηση στο απομακρυσμένο αποθετήριο;
Για να εξηγήσουμε, εδώ είναι ένα αρχείο καταγραφής των καταχωρήσεων μου:
```
g56123f: δημιουργία αρχείου botfile
a2235d: ενημέρωση του contributor.md
a5da0d: τροποποίηση του αρχείου botfile
```
Ας πούμε ότι ξέχασα να προσθέσω μια λέξη στο αρχείο bot.
Υπάρχουν 2 τρόποι να προχωρήσουμε σε αυτό. Ο πρώτος είναι να έχουμε μια εντελώς νέα καταχώρηση που περιέχει την αλλαγή ως εξής:
```
g56123f: δημιουργία αρχείου botfile
a2235d: ενημέρωση του contributor.md
a5da0d: τροποποίηση του αρχείου botfile
b0ca8f: προσθήκη μιας μόνο λέξης στο αρχείο botfile
```
Ο δεύτερος τρόπος είναι να τροποποιήσουμε την καταχώρηση a5da0d, να προσθέσουμε αυτή τη νέα λέξη και να το ανεβάσουμε στο Github ως ένα μόνο commit.
Ο δεύτερος τρόπος φαίνεται καλύτερος αφού είναι μια μικρή αλλαγή.
Για να το επιτύχουμε αυτό, θα κάνουμε τα εξής:
* Τροποποιήστε το αρχείο. Σε αυτή την περίπτωση, θα τροποποιήσω το αρχείο botfile για να προσθέσω τη λέξη που παρέλειψα προηγουμένως.
* Στη συνέχεια, προσθέστε το αρχείο στην περιοχή ενστάλαξης με το ```git add <όνομα αρχείου>```
Συνήθως, μετά την προσθήκη αρχείων στην περιοχή ενστάλαξης, το επόμενο πράγμα που κάνουμε είναι ```git commit -m "το μήνυμα καταχώρησής μας"``` σωστά;
Αλλά αφού αυτό που θέλουμε να επιτύχουμε εδώ είναι να τροποποιήσουμε την προηγούμενη καταχώρηση, αντ' αυτού θα τρέξουμε:
* ```git commit --amend```
Αυτό θα σας φέρει στον κειμενογράφο και θα σας ζητήσει να επεξεργαστείτε το μήνυμα. Μπορείτε να αποφασίσετε να αφήσετε το μήνυμα όπως ήταν πριν ή να το αλλάξετε.
* Έξοδος από τον κειμενογράφο
* Ανεβάστε τις αλλαγές σας με ```git push origin <όνομα παρακλαδιού>```
Με αυτόν τον τρόπο, και οι δύο αλλαγές θα είναι σε ένα μόνο commit.
## Τροποποίηση καταχωρήσεων στο απομακρυσμένο αποθετήριο
Εάν η καταχώρηση που θέλετε να τροποποιήσετε έχει ήδη ανεβεί στο απομακρυσμένο αποθετήριο, η τροποποίηση αυτής της καταχώρησης θα οδηγήσει στην αποκλιμάκωση της τοπικής ιστορίας από το απομακρυσμένο (καθώς ουσιαστικά δημιουργείτε μια νέα καταχώρηση και αντικαθιστάτε την τροποποιημένη). Εφόσον θέλετε να αλλάξετε την καταχώρηση στο απομακρυσμένο, θα πρέπει να αντικαταστήσετε την ιστορία του απομακρυσμένου στον παρακλάδι σας. Για να το επιτύχετε αυτό, ακολουθήστε την ίδια διαδικασία όπως περιγράφεται παραπάνω, αλλά χρησιμοποιήστε την εντολή force push (εξαναγκαστική αποστολή) όταν ανεβάζετε την καταχώρησή σας στο απομακρυσμένο.
> **Προειδοποίηση**
> Η force push στο απομακρυσμένο θα αντικαταστήσει (και θα απορρίψει) τις αλλαγές στο απομακρυσμένο και θα διατηρήσει μόνο τις καταχωρήσεις που ανεβάσατε. Οι αλλαγές στο απομακρυσμένο που έκαναν άλλα μέλη της ομάδας στο μεταξύ θα αντικατασταθούν επίσης.
Αυτό είναι πώς μπορείτε να τροποποιήσετε την πιο πρόσφατη καταχώρηση στο απομακρυσμένο:
```bash
git add <τα αρχεία που άλλαξαν>
git commit --amend -m "και ακολουθείτε με το νέο μήνυμα καταχώρησής σας"
git push --force
```
> Η χρήση της --force-with-lease είναι μια πιο ασφαλής επιλογή αντί για το --force, καθώς αποφεύγει την αντικατάσταση των αλλαγών άλλων ατόμων στον απομακρυσμένο κλάδο (εάν δεν το επιθυμείτε).
docs/additional-material/translations/Greek/git_workflow_scenarios/check-commit-log.gr.md
+25
View File
@@ -0,0 +1,25 @@
# Έλεγχος καταγραφής αλλαγών (commit log)
Για να ελέγξετε την καταγραφή αλλαγών (commit log) για ένα κλαδί ή ένα αρχείο, μπορείτε να χρησιμοποιήσετε την ακόλουθη εντολή:
```bash
git log [επιλογές] [διαδρομή]
```
Η έξοδος αυτής της εντολής παρέχεται με την προεπιλεγμένη σειρά αναστροφής χρονολογίας.
## Παραλλαγές και επιλογές της εντολής
- Για να καταγράψετε τις αλλαγές που είναι προσβάσιμες από συγκεκριμένα αναγνωριστικά αλλαγών (π.χ. foo και bar), χρησιμοποιήστε:
`
git log foo bar
`
- Είναι επίσης δυνατό να αφαιρέσετε τις αλλαγές που είναι προσβάσιμες από ένα συγκεκριμένο αναγνωριστικό αλλαγών (π.χ. baz), προσθέτοντας ένα ^ μπροστά από το αναγνωριστικό:
`git log foo bar ^baz`
- Για να δείτε την καταγραφή αλλαγών για ένα συγκεκριμένο αρχείο, χρησιμοποιήστε:
`git log --all <όνομα_αρχείου>`
- Περιορίστε τον αριθμό των αλλαγών στην καταγραφή (π.χ. `5`) χρησιμοποιώντας:
`git log -n 5`
## Αναφορές
- [Επίσημη τεκμηρίωση](https://git-scm.com/docs/git-log)
docs/additional-material/translations/Greek/git_workflow_scenarios/configuring-git.gr.md
+78
View File
@@ -0,0 +1,78 @@
# Διαμόρφωση του git
Την πρώτη φορά που προσπαθήσατε να κάνετε commit χρησιμοποιώντας το git, πιθανόν να είδατε ένα παραθυράκι παρόμοιο με αυτό:
```bash
$ git commit
*** Παρακαλώ πείτε μου ποιός είστε.
Εκτελέστε
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
για να ορίσετε την προεπιλεγμένη ταυτότητα του λογαριασμού σας.
Παραλείψτε την επιλογή --global για να ορίσετε την ταυτότητα μόνο σε αυτό το αποθετήριο.
```
Το git χρειάζεται να γνωρίζει ποιός είστε κάθε φορά που δημιουργείτε ένα commit. Όταν εργάζεστε συνεργατικά, πρέπει να μπορείτε να δείτε ποιος έχει τροποποιήσει ποια μέρη του έργου και πότε. Επομένως, το git έχει σχεδιαστεί έτσι ώστε να δημιουργεί commits που συσχετίζονται με ένα όνομα και ένα email.
Υπάρχουν πολλοί τρόποι για να παρέχετε το email και το όνομά σας στην εντολή `git commit`, και θα δούμε μερικούς από αυτούς παρακάτω.
### Παγκόσμια Διαμόρφωση
Όταν αποθηκεύετε κάτι στην παγκόσμια διαμόρφωση (global config), είναι προσβάσιμο σε όλα τα αποθετήρια στα οποία εργάζεστε. Αυτός είναι ο προτιμώμενος τρόπος και λειτουργεί για τις περισσότερες περιπτώσεις.
Για να αποθηκεύσετε κάτι στην παγκόσμια διαμόρφωση, χρησιμοποιείτε την εντολή `config` ως εξής:
`$ git config --global <όνομα_μεταβλητής> <τιμή>`
Στην περίπτωση των στοιχείων του χρήστη, το εκτελούμε ως εξής:
```
$ git config --global user.email "you@example.com"
$ git config --global user.name "Your Name"
```
### Διαμόρφωση Αποθετηρίου
Όπως υποδηλώνει το όνομά τους, αυτές οι διαμορφώσεις εφαρμόζονται στο τρέχον αποθετήριο. Αν θέλετε να κάνετε commit σε ένα συγκεκριμένο αποθετήριο, για παράδειγμα, ένα έργο που σχετίζεται με την εργασία σας, μπορείτε να χρησιμοποιήσετε αυτήν τη μέθοδο.
Για να αποθηκεύσετε κάτι στη διαμόρφωση αποθετηρίου, χρησιμοποιείτε την εντολή `config` αφήνοντας έξω τη σημαία `--global`, όπως εξής:
`$ git config <όνομα_μεταβλητής> <τιμή>`
Στην περίπτωση των στοιχείων του χρήστη, το εκτελούμε ως εξής:
```
$ git config user.email "you@alternate.com"
$ git config user.name "Your Name"
```
### Διαμόρφωση Μέσω Γρα
μμής Εντολών
Αυτού του τύπου διαμορφώσεις ισχύουν μόνο για την τρέχουσα εντολή. Όλες οι εντολές git δέχονται ορίσματα `-c` πριν το ρήμα δράσης για να ορίσουν προσωρινά δεδομένα διαμόρφωσης.
Για να αποθηκεύσετε κάτι στη διαμόρφωση μέσω γραμμής εντολών, εκτελέστε την εντολή σας ως εξής:
`$ git -c <μεταβλητή-1>=<τιμή> -c <μεταβλητή-2>=<τιμή> <εντολή>`
Στο παράδειγμά μας, θα εκτελούσαμε την εντολή commit ως εξής:
`git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"`
### Σημείωση για την Προτεραιότητα
Ανάμεσα στις τρεις μεθόδους που περιγράφηκαν εδώ, η προτεραιότητα είναι `command-line > repository > global`. Αυτό σημαίνει ότι, αν μια μεταβλητή έχει διαμορφωθεί τόσο μέσω γραμμής εντολών όσο και παγκοσμίως, η τιμή που δόθηκε μέσω γραμμής εντολών θα χρησιμοποιηθεί για τη λειτουργία.
## Εκτός από τα Στοιχεία του Χρήστη
Μέχρι στιγμής ασχοληθήκαμε μόνο με τα στοιχεία του χρήστη κατά τη διαμόρφωση. Ωστόσο, υπάρχουν πολλές άλλες διαθέσιμες επιλογές διαμόρφωσης. Ορισμένες από αυτές είναι:
1. `core.editor` - για να καθορίσετε το όνομα του επεξεργαστή που χρησιμοποιείται για τη σύνταξη μηνυμάτων commit κ.λπ.
2. `commit.template` - για να καθορίσετε ένα αρχείο στο σύστημα ως πρότυπο αρχικού commit.
3. `color.ui` - για να καθορίσετε μια λογική τιμή για τη χρήση χρωμάτων στην έξοδο του git.
Απλοποιήσαμε κάποιες λεπτομέρειες για ευκολία κατανόησης. Για περισσότερες πληροφορίες, επισκεφθείτε το [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration).
docs/additional-material/translations/Greek/git_workflow_scenarios/creating-a-gitignore-file.gr.md
+76
View File
@@ -0,0 +1,76 @@
# .gitignore
Το αρχείο .gitignore είναι ένα αρχείο κειμένου που λέει στο Git ποια αρχεία ή φάκελοι πρέπει να αγνοούνται σε ένα έργο.
Ένα τοπικό αρχείο .gitignore τοποθετείται συνήθως στον ριζικό φάκελο ενός έργου. Μπορείτε επίσης να δημιουργήσετε ένα παγκόσμιο .gitignore αρχείο και οποιεσδήποτε καταχωρίσεις σε αυτό το αρχείο θα αγνοούνται σε όλα τα αποθετήρια Git σας.
## Γιατί .gitignore
Τώρα μπορείτε να αναρωτηθείτε γιατί θέλετε το git να αγνοήσει ορισμένα αρχεία και φακέλους. Αυτό συμβαίνει διότι δεν θέλετε αρχεία όπως αρχεία κατασκευής, αρχεία cache, άλλα τοπικά αρχεία διαμόρφωσης όπως τα node modules, αρχεία μεταγλώττισης, προσωρινά αρχεία που δημιουργούνται από IDE, κ.λπ. να παρακολουθούνται από το git. Συνήθως χρησιμοποιείται για να αποφύγετε την δέσμευση προσωρινών αρχείων από τον τρέχοντα κατάλογο εργασίας που δεν είναι χρήσιμα για άλλους συνεργάτες.
## Ξεκινώντας
Για να δημιουργήσετε ένα τοπικό αρχείο .gitignore, δημιουργήστε ένα αρχείο κειμένου και ονομάστε το .gitignore (να θυμάστε να συμπεριλάβετε το . στην αρχή). Στη συνέχεια, επεξεργαστείτε αυτό το αρχείο όπως χρειάζεται. Κάθε νέα γραμμή πρέπει να αναφέρει ένα επιπλέον αρχείο ή φάκελο που θέλετε το Git να αγνοεί.
Οι καταχωρίσεις σε αυτό το αρχείο μπορούν να ακολουθούν και μοτίβα αντιστοίχισης.
```
* χρησιμοποιείται ως παντοτινή αντιστοιχία
/ χρησιμοποιείται για να αγνοήσετε ονόματα διαδρομών σχετικά με το αρχείο .gitignore
# χρησιμοποιείται για να προσθέσετε σχόλια σε ένα αρχείο .gitignore
Αυτό είναι ένα παράδειγμα του πώς μπορεί να φαίνεται το αρχείο .gitignore:
# Αγνόησε τα αρχεία συστήματος Mac
.DS_store
# Αγνόησε το φάκελο node_modules
node_modules
# Αγνόησε όλα τα αρχεία κειμένου
*.txt
# Αγνόησε αρχεία που σχετίζονται με κλειδιά API
.env
# Αγνόησε αρχεία ρυθμίσεων SASS
.sass-cache
```
Για να προσθέσετε ή να αλλάξετε το παγκόσμιο αρχείο .gitignore, εκτελέστε την ακόλουθη εντολή:
```
git config --global core.excludesfile ~/.gitignore_global
```
Αυτό θα δημιουργήσει το αρχείο ~/.gitignore_global. Τώρα μπορείτε να επεξεργαστείτε αυτό το αρχείο με τον ίδιο τρόπο με ένα τοπικό αρχείο .gitignore. Όλα τα αποθετήριά σας Git θα αγνοήσουν τα αρχεία και τους φακέλους που αναφέρονται στο παγκόσμιο αρχείο .gitignore.
## Πώς να Απεξαρτήσετε Αρχεία που Είχατε Ήδη Δεσμεύσει με νέο .gitignore
Για να απεξαρτήσετε ένα μεμονωμένο αρχείο, δηλαδή να σταματήσετε την παρακολούθηση του αρχείου αλλά να μην το διαγράψετε από το σύστημα, χρησιμοποιήστε:
```
git rm --cached filename
```
Για να απεξαρτήσετε όλα τα αρχεία στο .gitignore:
Πρώτα, κάντε commit σε οποιεσδήποτε εκκρεμείς αλλαγές κώδικα και στη συνέχεια εκτελέστε:
```
git rm -r --cached
```
Αυτό αφαιρεί οποιαδήποτε αλλαγμένα αρχεία από τον δείκτη (staging area), στη συνέχεια εκτελέστε:
```
git add .
```
Κάντε commit:
```
git commit -m ".gitignore δουλεύει τώρα"
```
Για να αναιρέσετε ```git rm --cached filename```, χρησιμοποιήστε ```git add filename```.
docs/additional-material/translations/Greek/git_workflow_scenarios/delete-branch-locally.gr.md
+19
View File
@@ -0,0 +1,19 @@
# Διαγραφή ενός τοπικά δημιουργημένου κλαδιού
Αυτό θα είναι χρήσιμο όταν κάνετε κατά λάθος λάθος το όνομα ενός κλαδιού.
Αυτό μπορεί να γίνει με *3* τρόπους
```
git branch -D <όνομα_κλαδιού>
```
```
git branch --delete --force <όνομα_κλαδιού> # Ίδιο με το -D
```
```
git branch --delete <όνομα_κλαδιού> # Σφάλμα κατά την ανενοχλησία
```
Το -D σημαίνει --delete --force, το οποίο θα διαγράψει το κλαδί ακόμα και αν δεν έχει συγχωνευτεί (αναγκαστική διαγραφή), αλλά μπορείτε επίσης να χρησιμοποιήσετε -d που σημαίνει --delete το οποίο θα εμφανίσει ένα σφάλμα ανάλογα με την κατάσταση συγχώνευσης του κλαδιού...
docs/additional-material/translations/Greek/git_workflow_scenarios/gitflow.gr.md
+125
View File
@@ -0,0 +1,125 @@
# Gitflow
Το Gitflow είναι ένα μοντέλο κλαδισμού για το Git που δημιουργήθηκε από τον Vincent Driessen. Εδώ θα συζητήσουμε τις απαιτήσεις και τις περιπτώσεις χρήσης του Gitflow.<br />
Η ροή εργασίας του Gitflow καθορίζει ένα αυστηρό μοντέλο κλαδισμού που σχεδιάστηκε γύρω από την έκδοση του έργου, παρέχοντας ένα αξιόπιστο πλαίσιο για τη διαχείριση μεγαλύτερων έργων. Το Gitflow είναι ιδανικό για έργα που έχουν προγραμματισμένο κύκλο κυκλοφορίας και για την καλύτερη πρακτική του DevOps για συνεχή παράδοση. Ορίζει πολύ συγκεκριμένους ρόλους για διάφορα κλαδιά και ορίζει πώς και πότε πρέπει να αλληλεπιδρούν. Χρησιμοποιεί ατομικά κλαδιά για την προετοιμασία, διατήρηση και καταγραφή κυκλοφοριών.
## Εφαρμογή
1. **Κλαδιά Develop και Master**: Αντί για ένα μόνο κύριο κλαδί, το Gitflow χρησιμοποιεί δύο κλαδιά για να καταγράψει το ιστορικό του έργου. Βασίζεται σε δύο κύρια κλαδιά με άπειρη διάρκεια ζωής, που ονομάζονται master και develop:
- **Κλαδί Master**: Το κλαδί master περιέχει τον παραγωγικό κώδικα και αποθηκεύει το επίσημο ιστορικό κυκλοφοριών.
- **Κλαδί Develop**: Το κλαδί develop περιέχει κώδικα προ-παραγωγής και λειτουργεί ως κλαδί ένταξης για χαρακτηριστικά.
- **Δημιουργία κλαδιού Develop**:<br />
Χωρίς τη χρήση των επεκτάσεων Gitflow:
```
git branch develop
git push -u origin develop
```
Χρησιμοποιώντας τις επεκτάσεις Gitflow: Όταν χρησιμοποιείτε τη βιβλιοθή
κη επέκτασης gitflow, η εκτέλεση της εντολής `git flow init` σε ένα υπάρχον αποθετήριο θα δημιουργήσει το κλαδί develop.
```
git flow init
```
2. **Κλαδί Χαρακτηριστικών**: Κάθε νέο χαρακτηριστικό θα πρέπει να βρίσκεται στο δικό του κλαδί, το οποίο μπορεί να πατηθεί στο κεντρικό αποθετήριο για δημιουργία αντιγράφου ασφαλείας/συνεργασίας. Τα κλαδιά χαρακτηριστικών χρησιμοποιούν το πιο πρόσφατο develop ως γονικό κλαδί. Όταν ένα χαρακτηριστικό είναι ολοκληρωμένο, συγχωνεύεται πίσω στο κλαδί develop. Τα χαρακτηριστικά δεν πρέπει ποτέ να αλληλεπιδρούν απευθείας με το κύριο κλαδί.
- **Δημιουργία κλαδιού Χαρακτηριστικού**: <br />
Χωρίς τις επεκτάσεις git-flow:
```
git checkout develop
git checkout -b feature_branch
```
Με τις επεκτάσεις gitflow:
```
git flow feature start feature_branch
```
- **Ολοκλήρωση κλαδιού Χαρακτηριστικού**: <br />
Χωρίς τις επεκτάσεις git-flow:
```
git checkout develop
git merge feature_branch
```
Με τις επεκτάσεις git-flow:
```
git flow feature finish feature_branch
```
3. **Κλαδί Κυκλοφορίας**: Μόλις το develop έχει αποκτήσει αρκετά χαρακτηριστικά για μια κυκλοφορία (ή πλησιάζει μια προκαθορισμένη ημερομηνία κυκλοφορίας), δημιουργούμε ένα κλαδί κυκλοφορίας από το develop. Η δημιουργία αυτού του κλαδιού ξεκινά τον επόμενο κύκλο κυκλοφοριών, οπότε δεν μπορούν να προστεθούν νέα χαρακτηριστικά μετά από αυτό το σημείο - μόνο διορθώσεις σφαλμάτων, δημιουργία τεκμηρίωσης και άλλες εργασίες που αφορούν την κυκλοφορία πρέπει να προστεθούν σε αυτό το κλαδί. Το κλαδί κυκλοφορίας μπορεί να παρακλάδιασει από το develop και πρέπει να συγχωνευτεί και στο master και το develop. <br />
Χρησιμοποιώντας ένα αφιερωμένο κλαδί για την προετοιμασία των κυκλοφοριών καθιστά δυνατή τη δυνατότητα μια ομάδα να βελτιστοποιεί την τρέχουσα κυκλοφορία ενώ μια άλλη ομάδα συνεχίζει να εργάζεται σε χαρακτηριστικά για την επόμενη κυκλοφορία.
- **Δημιουργία κλαδιού Κυκλοφορίας**: <br />
Χωρίς τις επεκτάσεις git-flow:
```
git checkout develop
git checkout develop
git checkout -b release/0.1.0
```
Χρησιμοποιώντας τις επεκ
τάσεις git-flow:
```
git flow release start 0.1.0
```
Μετάβαση σε ένα νέο κλαδί 'release/0.1.0'
- **Ολοκλήρωση κλαδιού Κυκλοφορίας**: <br />
Χωρίς τις επεκτάσεις git-flow:
```
git checkout master
git merge release/0.1.0
```
Χρησιμοποιώντας τις επεκτάσεις git-flow:
```
git flow release finish 0.1.0
```
4. **Κλαδί Διόρθωσης**: Τα κλαδιά συντήρησης ή "διόρθωσης" χρησιμοποιούνται για γρήγορη επισκευή παραγωγικών κυκλοφοριών. Τα κλαδιά διόρθωσης είναι απαραίτητα για να δράσουν αμέσως σε μια ανεπιθύμητη κατάσταση του κλαδιού master. Τα κλαδιά διόρθωσης είναι πολύ παρόμοια με τα κλαδιά κυκλοφορίας και τα κλαδιά χαρακτηριστικών, εκτός από το γεγονός ότι βασίζονται στο master αντί για το develop. Αυτό είναι το μόνο κλαδί που πρέπει να αποκλίνει απευθείας από το κλαδί master. Μόλις ολοκληρωθεί η διόρθωση, πρέπει να συγχωνευτεί τόσο στο master όσο και στο develop (ή το τρέχον κλαδί κυκλοφορίας), και το κλαδί master πρέπει να σημειωθεί με ένα ενημερωμένο αριθμό έκδοσης.
- **Δημιουργία κλαδιού Διόρθωσης**: <br />
Χωρίς τις επεκτάσεις git-flow:
```
git checkout master
git checkout -b hotfix_branch
```
Με τις επεκτάσεις git-flow:
```
git flow hotfix start hotfix_branch
```
- **Ολοκλήρωση κλαδιού Διόρθωσης**: <br />
Χωρίς τις επεκτάσεις git-flow:
```
git checkout master
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
```
Με τις επεκτάσεις git-flow:
```
git branch -D hotfix_branch
git flow hotfix finish hotfix_branch
```
## Πλεονεκτήματα
- Βεβαιώνει μια καθαρή κατάσταση των κλαδιών σε οποιοδήποτε σημείο του κύκλου ζωής ενός έργου.
- Η ονομασία των κλαδιών ακολουθεί ένα συστηματικό πρότυπο που διευκολύνει την κατανόηση.
- Έχει επεκτάσεις και υποστήριξη στα περισσότερα εργαλεία git που χρησιμοποιούνται.
- Ιδανικό για περιπτώσεις διατήρησης πολλαπλών εκδόσεων στην παραγωγή.
- Κατάλληλο για μια ροή εργασίας που βασίζεται σε κυκλοφορίες.
- Προσφέρει ένα αφιερωμένο μονοπάτι για διορθώσεις παραγωγής.
## Μειονεκτήματα
- Η ιστορία του Git γίνεται δυσανάγνωστη.
- Ο διαχωρισμός των κλαδιών master / develop θεωρείται περιττός και δυσκολεύει την Συνεχή Παράδοση / Ενσωμάτωση.
- Δεν συνίσταται στην περίπτωση διατήρησης μιας μόνο έκδοσης στην παραγωγή.
## Σύνοψη
Εδώ συζητήσαμε τη Ροή Εργασίας του Gitflow. Το Gitflow είναι ένα από τα πολλά στυλ ροών εργασίας του Git που μπορείτε να χρησιμοποιήσετε εσείς και η ομάδα σας. Ας συνοψίσουμε ολόκληρη τη ροή εργασίας του Gitflow:
1. Δημιουργείται ένα κλαδί develop από το master.
2. Δημιουργούνται κλαδιά χαρακτηριστικών από το develop.
3. Όταν ένα χαρακτηριστικό είναι ολοκληρωμένο, συγχωνεύεται στο κλαδί develop.
4. Δημιουργείται ένα κλαδί κυκλοφορίας από το develop.
5. Όταν το κλαδί κυκλοφορίας είναι έτοιμο, συγχωνεύεται στα κλαδιά develop και master.
6. Εάν εντοπιστεί πρόβλημα στο master, δημιουργείται ένα κλαδί διόρθωσης από το master.
7. Μόλις ολοκληρωθεί το διόρθωμα, συγχωνεύεται τόσο στο develop όσο και στο master.
docs/additional-material/translations/Hindi/Amending a Commit
+65
View File
@@ -0,0 +1,65 @@
# कमिट में संशोधन करना
आपके दूरस्थ संग्रहालय में एक परिवर्तन करते हैं, फिर बाद में पता चलता है कि आपके कमिट संदेश में त्रुटि है या आपने अपने सबसे हाल के कमिट में एक पंक्ति जोड़ना भूल दी है।
आप ऐसा कैसे संपादित करेंगे? इस पर यह ट्यूटोरियल विस्तार से बताता है।
##Github पर अपलोड करने के बाद हाल के कमिट संदेश को संशोधित करना।
इसे फ़ाइल खोले बिना करने के लिए:
* निम्नलिखित कमांड का उपयोग करें ```git commit --amend -m "आपके नए कमिट संदेश के बाद"
* चलाना ```git push origin <branch-name>``` संग्रहालय में परिवर्तन को कमिट (commit) करने के लिए क्या होगा।
नोट: यदि आप केवल ```git commit --amend```टाइप करते हैं, तो आपका पाठ संपादित करने के लिए आपके पाठ संपादक खुलेगा। ``-m`` फ़्लैग जोड़ने से इसे रोका जा सकता है।
## एक सिंगल कमिट पर संशोधन करना
तो, यदि हम एक फ़ाइल में एक छोटे से बदलाव को करना भूल जाते हैं, जैसे एक शब्द को बदलना, और हमने पहले से ही उस कमिट को हमारे रिमोट रिपॉजिटरी में पुश कर दिया है?
इसे व्यक्त करने के लिए यहां मेरे कमिट की एक लॉग है:
```
g56123f create file bot file
a2235d updated contributor.md
a5da0d modified bot file
```
चलिए मान लें कि मुझसे एक शब्द बदलने को भूल गया हूँ बॉट फ़ाइल में
इसके लिए दो तरीके हैं। पहला है कि इसमें परिवर्तन को शामिल करने वाला एक नया कमिट हो, जैसे:
```
g56123f create file botfile
a2235d updated contributor.md
a5da0d modified botfile
b0ca8f added single word to botfile
```
दूसरा तरीका है a5da0d कमिट को संशोधित करना, इस नए शब्द को जोड़ना और इसे एक कमिट के रूप में गिटहब पर पुश करना। दूसरा तरीका बेहतर लगता है क्योंकि यह केवल एक छोटे से बदलाव है।
इसे प्राप्त करने के लिए, हम निम्नलिखित करेंगे:
* फ़ाइल में संशोधन करें। इस मामले में, मैं बॉट फ़ाइल को संशोधित करके पिछले समय छूट गया शब्द शामिल करूंगा।
* आगे बढ़ें, git add <filename> के साथ फ़ाइल को स्टेजिंग क्षेत्र में जोड़ें|
आम तौर पर स्टेजिंग क्षेत्र में फ़ाइलें जोड़ने के बाद, अगला काम होता है git commit -m "हमारा कमिट संदेश" सही?
लेकिन क्योंकि हम यहां पिछले कमिट को संशोधित करना चाहते हैं, इसलिए हम इसके बजाय निम्नलिखित कमांड चलाएंगे:
* ```git commit --amend```
इससे पाठ संपादक खुलेगा और आपको संदेश संपादित करने के लिए कहेगा। आप पिछले जैसा संदेश छोड़ सकते हैं या इसे बदल सकते हैं।
* संपादक(Editor) से बाहर निकलें
* git push origin <branch-name> के साथ अपने बदलावों को पुश करें
इस तरह, दोनों बदलावों को एक ही सिंगल कमिट में रखा जाएगा।
## रिमोट पर कमिट संशोधित करना
यदि वह कमिट जिसे आप संशोधित करना चाहते हैं पहले से ही रिमोट पर पुश किया गया है, तो इसे संशोधित करने से आपका स्थानीय इतिहास रिमोट से अलग हो जाएगा (क्योंकि आप तदनुसार एक नया कमिट बनाते हैं और संशोधित कमिट को बदल देते हैं)। रिमोट पर कमिट को बदलने के लिए, अपनी शाखा पर रिमोट का इतिहास अधिलेखित करने की आवश्यकता होगी। इसे प्राप्त करने के लिए, ऊपर वर्णित प्रक्रिया का पालन करें, लेकिन जब आप अपनी कमिट को रिमोट पर पुश करें तो फ़ोर्स पुश का उपयोग करें।
> **Warning**
> फ़ोर्स पुश करने से रिमोट परिवर्तन (और उसे छोड़ देने) को अधिलेखित कर देगा और केवल आपके पुश किए गए कमिट रखेगा। रिमोट पर, टीम के अन्य सदस्यों द्वारा उस बीच में किए गए बदलावों को भी अधिलेखित कर देगा।
इस तरह आप रिमोट परिवर्तन को संशोधित करते हैं:
```bash
git add <आपकी बदली हुई फ़ाइलें>
git commit --amend -m "आपका नया कमिट संदेश के बाद"
git push --force
```
>उपयोग करने के लिए `--force` के बजाय `--force-with-lease` सुरक्षित विकल्प है जो रिमोट शाखा पर दूसरे लोगों के बदलावों को अधिलेखित करने से बचाता है (यदि ऐसा आपकी इच्छा नहीं है)।
docs/additional-material/translations/Hindi/Things a non Programmer can do
+128
View File
@@ -0,0 +1,128 @@
# Things a non Programmer can do
## सुनना शुरू करें
सब कुछ ओपन सोर्स में दूसरे लोगों को शामिल करता है।
आप एक टीम में शामिल होने की कोशिश कर रहे हैं, और इसका मतलब है कि आपको समुदाय को समझना होगा और यह कैसे काम करता है।
एक परियोजना में प्रवेश करके "नमस्ते, यहाँ मुझे लगता है कि इस परियोजना को यह करना चाहिए" कहना आमतौर पर अच्छी बात नहीं मानी जाती है।
कुछ परियोजनाएं इस तरह के दृष्टिकोण का स्वागत कर सकती हैं, लेकिन यदि परियोजना काफी समय से चल रही है, तो इस अवधारणा को स्वीकार करने की संभावना कम होती है।
**परियोजना की आवश्यकताओं को जानने के लिए सुनना सबसे अच्छा तरीका है।**
1. **मेलिंग सूची में शामिल हों**: कई परियोजनाओं के लिए, मेलिंग सूची परियोजना के विकास के बारे में संचार का मुख्य साधन होती है।
बड़ी परियोजनाओं में, कई मेलिंग सूची उपलब्ध होती हैं।
उदाहरण के लिए, पोस्टग्रेसक्यूएल परियोजना में कम से कम 12 उपयोगकर्ता-ओरिएंटेड सूचियां और छह डेवलपर सूचियां हैं।
मैं सुझाव देता हूँ कि आप मुख्य उपयोगकर्ता-ओरिएंटेड सूची और मूल डेवलपर सूची का पालन करें, जिसमें सुनना शुरू करें।
2. **एक ब्लॉग का पालन करें**: मूल डेवलपर द्वारा संचालित ब्लॉग आमतौर पर भविष्य में आने वाले रिलीज के बारे में जानकारी देते हैं,
और यहां पहुंचने के लिए क्या किया गया है। एक प्लैनेट साइट परियोजना से संबंधित कई स्रोतों से समाचार और ब्लॉग प्रविष्टियों को संग्रहीत करती है।
यदि कोई प्लैनेट साइट है, जैसे planet.gnome.org या planet.mysql.com, तो वहां से शुरू करें। "प्लैनेट <परियोजनानाम>" के लिए Google में खोजें।
3. **एक IRC चैनल में शामिल हों**: कई ओपन सोर्स परियोजनाओं में विशेष इंटरनेट रिले चैट (IRC) चैनल होते हैं जहां डेवलपर और उपयोगकर्ता समस्याओं और विकास की चर्चा करने के लिए रहते हैं।
परियोजना की वेबसाइट में देखें कि चैनल का नाम क्या है और यह IRC नेटवर्क कहां मिलेगा।
**टिकट के साथ काम करें**
कोड किसी भी ओपन सोर्स परियोजना का हृदय होता है, लेकिन सोचें इसे कि कोड लिखना केवल योगदान करने का एकमात्र तरीका नहीं है।
कोड और कोड के चारों ओर के सिस्टम की रखरखाव को अक्सर नई सुविधाओं को बनाने और बग्स को ठीक करने के दौरान अनदेखा कर दिया जाता है।
इन क्षेत्रों को एक आसान तरीके से परियोजना में कदम रखने का एक अवसर मानें।
अधिकांश परियोजनाएं एक सार्वजनिक दृश्यमान ट्रबल टिकट सिस्टम रखती हैं, जिसका लिंक परियोजना की वेबसाइट के मुख पृष्ठ से जुड़ा होता है और दस्तावेज़ीकरण में शामिल होता है।
यह उपयोगकर्ताओं और डेवलपर्स के बीच संचार का मुख्य माध्यम होता है। इसे अद्यतित रखना परियोजना में मदद करने का एक बड़ा तरीका है।
आपको टिकटिंग सिस्टम में विशेष अनुमतियाँ प्राप्त करने की आवश्यकता हो सकती है, जो अधिकांश परियोजना नेताओं को आपकी मदद करने की इच्छा बताते ही खुशी से देंगे।
4. **एक बग का निदान करें**: बग्स आमतौर पर गलत रूप में रिपोर्ट किए जाते हैं।
एक बग का निदान करना और उसे व्याख्या करना, समस्या के विशेषांकों का पता लगाने के काम में डेवलपर्स को समय बचाने में मदद कर सकता है।
यदि एक उपयोगकर्ता ने "मैं X करते समय सॉफ्टवेयर काम नहीं करता" रिपोर्ट की है, तो कुछ समय निकालें और इस समस्या के कारणों का पता लगाएं।
क्या यह दोहराया जा सकता है? क्या आप समस्या को बार-बार पैदा करने के लिए कुछ स्टेप्स निर्धारित कर सकते हैं? क्या आप समस्या को सीमित कर सकते हैं, जैसे कि यह केवल एक ब्राउज़र पर होता है लेकिन दूसरे पर नहीं या एक डिस्ट्रो पर होता है लेकिन दूसरे पर नहीं?
यदि आपको पता नहीं है कि समस्या का कारण क्या है, तो संकेतों को सीमित करने में जोखिम लेने का प्रयास करने से किसी दूसरे को इसे सुधारना आसान होता है।
चाहे आप कुछ भी खोजें, उसे बग सिस्टम में टिकट में जोड़ें ताकि सभी देख सकें।
5. **ठीक हुए बग्स को बंद करें**: अक्सर बग्स को कोडबेस में ठीक कर लिया जाता है, लेकिन उसके बारे में रिपोर्ट किए गए टिकट सिस्टम में अद्यतित नहीं होते हैं।
इस कचरे को साफ करना समय लेने वाला हो सकता है, लेकिन यह पूरे परियोजने के लिए महत्वपूर्ण है।
एक वर्ष से पुराने टिकटों के लिए टिकट सिस्टम में क्वेरी करें और देखें कि बग अभी भी मौजूद है या नहीं।
बग ठीक हुआ है और बंद किया जा सकता है यह जानने के लिए परियोजना के रिलीज चेंज लॉग की जांच करें।
यदि यह ठीक होने के बारे में ज्ञात है, तो टिकट में संस्करण नंबर नोट करें और उसे बंद करें।
नवीनतम संस्करण के साथ बग को पुनः बनाने का प्रयास करें।
यदि नवीनतम संस्करण के साथ इसे पुनः बनाना संभव नहीं है, तो टिकट में इसे नोट करें और उसे बंद करें।
यदि यह अभी भी मौजूद है, तो टिकट में यह नोट करें और खुले छोड़ दें।
कोड के साथ काम करना
प्रोग्रामर्स, सभी अनुभव स्तरों के, परियोजना में कोड के साथ मदद कर सकते हैं।
सोचें नहीं कि आपको एक कोड जीनियस होना चाहिए ताकि आप अपने पसंदीदा परियोजना में वास्तविक योगदान कर सकें।
यदि आपका काम कोड में संशोधन शामिल है, तो परियोजना द्वारा कोड को योगदानकर्ताओं से प्राप्त करने का तरीका जांचें।
हर परियोजना की अपनी वर्कफ़्लो होती है, इसलिए कोड सबमिट करने से पहले उसके बारे में पूछें।
उदाहरण के लिए, पोस्टग्रेएसक्यूएल (PostgreSQL) परियोजना इसकी प्रक्रिया में बहुत सख्त है: कोड संशोधन पैच रूप में एक मेलिंग सूची में भेजे जाते हैं जहां मुख्य डेवलपर्स बदलाव के हर पहलू की जांच करते हैं। दूसरी तरफ़, पैरॉट जैसी परियोजना में कोडबेस के लिए संबंधित अधिकार प्राप्त करना आसान होता है। यदि परियोजना GitHub का उपयोग करती है, तो GitHub के पुल अनुरोध सुविधा का उपयोग करने वाली एक वर्कफ़्लो हो सकती है। कोई भी दो परियोजनाएँ एक समान नहीं होतीं।
जब भी आप कोड संशोधित करते हैं, सुनिश्चित करें कि आप समुदाय के एक ज़िम्मेदार सदस्य के रूप में कार्य कर रहे हैं और अपने कोड की शैली को कोडबेस के शेष से मेल खाती हो। आपके द्वारा जोड़ा या संशोधित किया गया कोड शेष के जैसा दिखना चाहिए। शायद आपको ब्रेसिंग स्टाइल या इंडेंटेशन के स्थान परस्पर न पसंद हो, लेकिन एक ऐसा कोड बदलाव सबमिट करना असभ्य है जो मौजूदा मानकों से मेल नहीं खाता है। यह कहने के समान है "मुझे आपकी शैली पसंद नहीं है और मुझे लगता है कि मेरी शैली बेहतर है, इसलिए आपको मेरे तरीके से करना चाहिए।"
6. **बीटा या रिलीज कैंडिडेट (beta or release candidate) का परीक्षण करें**: किसी भी परियोजना जो बहुविधियों पर चलाने के लिए डिज़ाइन की गई हो सकती है, कई प्रकार की पोर्टेबिलिटी समस्याएं हो सकती हैं।
जब रिलीज के करीब आती है और एक बीटा या रिलीज कैंडिडेट प्रकाशित होता है, तो परियोजना के नेता की आशा होती है कि इसे कई अलग-अलग लोगों और अलग-अलग प्लेटफ़ॉर्मों पर परीक्षण किया जाए।
आप उन लोगों में से एक हो सकते हैं और सुनिश्चित कर सकते हैं कि पैकेज आपकी प्लेटफ़ॉर्म पर काम करता है।
आमतौर पर आपको केवल सॉफ़्टवेयर को डाउनलोड, बिल्ड और परीक्षण करने की आवश्यकता होती है, लेकिन यदि आप एक असामान्य वितरण या हार्डवेयर पर हैं, तो परियोजना के लिए महत्वपूर्ण मान्यता हो सकती है।
बस यह रिपोर्ट करें कि बिल्ड और परीक्षण काम करता है, जिससे परियोजना के नेता को पता चलता है कि आगामी रिलीज सुदृढ़ है।
7. **एक बग (bug) को ठीक करें** : यह आमतौर पर उन योगदानकर्ताओं के लिए है जो कोड पर काम करना चाहते हैं।
यह सरल है: टिकट सिस्टम में एक रोचक लगने वाले बग ढूंढें और कोड में उसे ठीक करने की कोशिश करें।
अगर यह उचित हो, तो कोड में ठीक करने को दस्तावेज़ीकरण करें।
यदि कोई परियोजना बग ठीक करने के लिए टेस्टों को शामिल करने की आवश्यकता है, तो एक टेस्ट सुइट में एक टेस्ट जोड़ने का एक अच्छा विचार होता है। आप इस अनजान कोडबेस के चारों ओर छूने के दौरान नोट्स रखें। यदि आप बग को ठीक नहीं कर पाते हैं, तो टिकट में दस्तावेज़ करें कि आपने ठीक करने के प्रयास के हिस्से के रूप में क्या खोजा है। आपके द्वारा मिली जानकारी उनकी मदद करती है जो आपके बाद आते हैं।
8. **एक टेस्ट लिखें:** अधिकांश परियोजनाओं में एक टेस्ट सुइट होती है जो कोड का टेस्ट करती है, लेकिन यह मुश्किल है कि कोई ऐसी टेस्ट सुइट हो जो इसे ज्यादा टेस्ट कर सके।
C के लिए gcov जैसा एक टेस्ट कवरेज टूल या Perl के लिए Devel::Cover का उपयोग करें ताकि स्रोत कोड में वे क्षेत्र निश्चित हों जो टेस्ट सुइट द्वारा टेस्ट नहीं होते हैं।
फिर, इसे कवर करने के लिए एक टेस्ट सुइट में एक टेस्ट जोड़ें।
9. **कैंपाइलर चेतावनी (compiler warning) को शांत करें** : बहुत से सी-आधारित परियोजनाओं के बिल्ड प्रक्रिया में अकसर स्क्रीन पर एक अजीब कैंपाइलर चेतावनी दिखाई देती है।
ये चेतावनियाँ आमतौर पर किसी समस्या के संकेतक नहीं होती हैं, लेकिन ऐसा दिख सकता है।
बहुत सारी चेतावनियों के होने से कैंपाइलर ऐसा लग सकता है कि यह झूल रहा है।
देखें कि क्या कोड वास्तव में एक बग को छिपा रह सकता है। यदि नहीं, तो शांत करने के लिए स्रोत को संशोधित करना मददगार होता है ताकि ये गलत चेतावनियाँ छुपा सकें।
10. **टिप्पणी जोड़ें**: कोड में खोज करते समय, आपको कुछ स्थानों पर कंफ़्यूज़ हो सकता है।
संभावना है कि यदि आप कंफ़्यूज़ हो रहे हैं, तो दूसरे भी होंगे। इन्हें कोड में दस्तावेज़ीकरण करें और एक पैच सबमिट करें।
दस्तावेज़ीकरण के साथ काम करें
दस्तावेज़ीकरण आमतौर पर एक परियोजना का वह हिस्सा होता है जिसे कम महत्व दिया जाता है।
यह यह भी संघर्ष कर सकता है क्योंकि इसे उन लोगों की दृष्टि से लिखा गया है जो परियोजना को अच्छी तरह से जानते हैं, बल्कि उनकी नज़रिए से जो इसमें अभी नए हैं।
यदि आपने कभी एक परियोजना के लिए दस्तावेज़ पढ़ी है जहां आपको लगता है, "ऐसा लगता है मानुअल मांगता है कि मेरे पास पहले से ही पैकेज का उपयोग करने का ज्ञान हो," तो आप जानते हैं कि मैं क्या कह रहा हूँ।
अक्सर एक ताजगी वाले नज़रों की संचालन में दस्तावेज़ीकरण में कमी का पता लगा सकती है जिसे परियोजना के नजदीकी लोग नहीं देखते हैं।
11. **एक उदाहरण बनाएं**: कोई परियोजना ऐसी नहीं है जिसमें केवल हो-टू उदाहरण हों।
चाहे यह एक वेब API हो, रूटीन का एक लाइब्रेरी हो, Gimp जैसा एक GUI ऐप हो या कमांड लाइन टूल हो,
सही उपयोग का एक अच्छा उदाहरण सॉफ़्टवेयर के सही उपयोग को पृष्ठों के दस्तावेज़ीकरण से अधिक स्पष्टता और तेज़ी से समझा सकता है।
एक API या लाइब्रेरी के लिए, उपकरण का उपयोग करके एक उदाहरण प्रोग्राम बनाएं। यह आपके द्वारा लिखे गए कोड से निकाला जा सकता है, जिसे नियमित करके कम कर दिया जाए।
टूल के लिए, अपने दैनिक जीवन में इसे कैसे उपयोग किया गया है के वास्तविक उदाहरण दिखाएं। यदि आप दृश्य-ओरिएंटेड हैं,
ऐप्लिकेशन की स्थापना कैसे करें जैसे महत्वपूर्ण प्रक्रिया का स्क्रीन कैप्चर बनाने का विचार करें।
समुदाय के साथ काम करें
ओपन सोर्स केवल कोड के बारे में होता है वही नहीं है। समुदाय ओपन सोर्स को कामयाब बनाता है। यहां वह तरीके हैं जिनसे आप उसे मजबूत कर सकते हैं।
12. **सवाल का जवाब दें**: समुदाय को बनाने की सबसे अच्छी विधि है दूसरों की मदद करना।
एक सवाल का जवाब देना, विशेष रूप से जब उसे शुरुआती तरीके से अभी अभी समझने वाले व्यक्ति से पूछा जाता है, परियोजना को बढ़ाने और मांगलिक बनाने में महत्वपूर्ण होता है।
आपका समय जो आप एक शुरुआत करने वाले की मदद करने में लगाते हैं, यद्यपि वे एक सवाल पूछ रहे हों जहां आप आसानी से तेज़ी से "RTFM" लौटा सकते हैं, तो आपको बाद में समुदाय का एक और सक्रिय सदस्य प्राप्त करने में लाभ मिलता है।
हर कोई कहीं ना कहीं से शुरुआत करता है, और परियोजनाएं जीवंत रहने के लिए निरंतर लोगों के प्रवाह की आवश्यकता होती है।
13. **ब्लॉग पोस्ट लिखें**: यदि आपके पास एक ब्लॉग है, तो उस परियोजना के साथ अपने अनुभवों के बारे में लिखें जिसका आप उपयोग कर रहे हैं।
सॉफ़्टवेयर का उपयोग करते समय आपने किसी समस्या का सामना किया हो तो उसके समाधान के बारे में बताएं।
आप दो तरीकों से मदद कर रहे होंगे, एक तो आप उस परियोजना को आपके चारों ओर रखने में मदद कर रहे होंगे,
और दूसरा, आपकी समस्या को भविष्य में किसी और द्वारा खोजने पर जवाब देने के लिए वेब खोज करने वालों के लिए एक रिकॉर्ड बना रहें होंगे।
(एक आपके तकनीकी एडवेंचर का ब्लॉग उस सॉफ़्टवेयर के साथ वास्तविक दुनिया के अनुभव को दिखाने का एक उत्कृष्ट तरीका हो सकता है जब आप उसका उपयोग करके नौकरी की तलाश में जाते हैं)|
14. **वेबसाइट में सुधार करें**: यदि आपके पास वेब डिज़ाइन के कौशल हैं और आप सहायता करने के लिए वेबसाइट को और इस प्रकरण में प्रोजेक्ट की जनता के सामने छवि को सुधार सकते हैं, तो यह समय बहुत अच्छा बिताया गया होता है।
शायद परियोजना को एक ग्राफ़िक बदल चाहिए, या परियोजना को पहचानने के लिए एक लोगो।
ये सामग्री उन योग्यताओं की कमी हो सकती है जो समुदाय में नहीं हैं। मुझे यह जानकर खुशी होगी कि अगर मेरे परियोजनाओं की वेबसाइटों पर ग्राफ़िक डिज़ाइन मदद मिल सके।
सबसे अधिक महत्वपूर्ण बात यह है कि आप चारों ओर के लोगों के बीच की चर्चा क्या है, इसे सुनें। यदि आप किसी महत्वपूर्ण आवश्यकता को पहचान सकते हैं, तो यह बड़ी बात हो सकती है। उदाहरण के लिए, हाल ही में पैरॉट डेवलपर्स के मेलिंग सूची पर त्रुटि टिकट सिस्टम के रूप में GitHub का उपयोग करने का निर्णय लिया गया, जहां वे पहले वाले Trac स्थापना को छोड़ रहे थे। कुछ लोग इस हरकत के खिलाफ थे क्योंकि उन्हें टिकट को GitHub के सिस्टम में परिवर्तित करने का कोई तरीका नहीं था। एक दिन की बहस के बाद, मैंने उठाने की कोशिश की और कहा "क्या अगर मैं एक कनवर्टर लिखता हूं?" लोग इस विचार से बहुत खुश थे। मैंने 450+ टिकटों के लिए एक कनवर्टर प्रोग्राम लिखने का समय बिताया, इसलिए हमारी टिकट इतिहास में से कोई भी खोने की समस्या नहीं हुई। यह एक बड़ी सफलता थी। मैंने सहयोग किया, और कोर डेवलपर्स पैरॉट पर काम करने के लिए केंद्रित रहे।
docs/additional-material/translations/Hindi/Useful-links-for-further-learning.hi.md
+45
View File
@@ -0,0 +1,45 @@
# उपयोगी लिंक्स
यह लेख उन सभी युक्तियों और युक्तियों वाली वेबसाइटों, ब्लॉग पोस्टों और सहायक साइटों को समर्पित है जो हमारे जीवन को आसान बनाती हैं। वे हमारी सभी जरूरतों को पूरा करने के लिए एक महान संदर्भ हैं, चाहे वह नौसिखिया हो या विशेषज्ञ। इस पृष्ठ को उन सभी उपयोगी लिंक के सूचकांक के रूप में कार्य करना चाहिए जो ओपन-सोर्स डोमेन में नए लोगों या किसी ऐसे व्यक्ति की मदद करेगा जो अधिक सीखना चाहता है।
## सूची
1. [गिट के लिए इंटरैक्टिव ट्यूटोरियल](https://try.github.io)
2. [यूट्यूब: फ़्रीकोडकैंप द्वारा शुरुआती लोगों के लिए Git और GitHub](https://www.youtube.com/watch?v=RGOj5yH7evk)
3. [git - सरल मार्गदर्शक](http://rogerdudler.github.io/git-guide/)
4. [गिट में कमिट को पूर्ववत करना, ठीक करना या हटाना](http://sethrobertson.github.io/GitFixUm/fixup.html)
5. [Git और GitHub ट्यूटोरियल का कई भाषाओं में अनुवाद किया गया](https://github.com/Roshanjossey/first-contributions)
6. [संघर्षों को मर्ज करें](https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/merge-conflicts)
7. [मर्ज विवादों का समाधान](https://githowto.com/resolving_conflicts)
8. [Git की मूल बातें - सरल त्वरित प्रारंभ मार्गदर्शिका](https://blog.praveen.science/basics-of-git-the-quick-start-guide/)
9. [Spotify एजाइल मेथडोलॉजी के हमारे तरीके में Git मानकों का पालन किया गया](https://blog.praveen.science/git-standards-followed-in-our-way-of-spotify-agile-methodolgy/)
10. [गिट शॉर्टकट](https://blog.praveen.science/git-shortcuts/)
11. [कई भाषाओं में आधिकारिक Git चीट शीट](https://services.github.com/on-demand/resources/cheatsheets)
12. [टॉवर से गिट चीट शीट](https://www.git-tower.com/learn/cheat-sheets/git)
13. [सामान्य गिट समस्याएँ](https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd)
14. [Git रिबेस](https://blog.gitprime.com/git-rebase-an-illustrated-guide/)
15. [रीबेस और स्क्वैष करना सीखें](https://github.com/servo/servo/wiki/Beginner%27s-guide-to-rebasing-and-squashing)
16. [Git चीटशीट जो कमांड और फ़ाइलों के बीच संबंध दिखाती है](http://ndpsoftware.com/git-cheatsheet.html)
17. [कैसे योगदान करें](https://opensource.guide/how-to-contribute/)
18. [ओपन सोर्स के साथ शुरुआत करें](https://github.com/OpenSourceHelpCommunity/Getting-Started-With-Contributing-to-Open-Sources)
19. [कैसे योगदान करें](https://github.com/freeCodeCamp/how-to-contribute-to-open-source)
20. [एटलसियंस गिट ट्यूटोरियल](https://www.atlassian.com/git)
21. [पुल अनुरोध समीक्षा](https://help.github.com/articles/about-pull-request-reviews/)
22. [गिट के लिए एक और इंटरैक्टिव ट्यूटोरियल](https://learngitbranching.js.org/)
23. [गिट कमांडलाइन चीट-शीट](https://gist.github.com/davfre/8313299)
24. [प्रोग्रामिंग के लिए पुस्तकें](https://github.com/EbookFoundation/free-programming-books)
25. [पेशेवर युक्तियों और रहस्यों की ई-पुस्तक](https://goalkicker.com/GitBook/GitProfessionalTipsSecrets.pdf)
26. [गिट पेशेवर बनने के सरल नियमों के बारे में ट्यूटोरियल](https://medium.freecodecamp.org/follow-these-simple-rules-and-youll-become-a-git-and-github-master-e1045057468f)
27. [Git कम्मिट संदेशों के बारे में एक नोट](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
28. [बेहतर कम्मिट संदेश के लिए 5 उपयोगी युक्तियाँ](https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message)
29. [Git का उपयोग करके वरज़न कंट्रोल](https://ourcodingclub.github.io/2017/02/27/git.html)
30. [Git के साथ वरज़न कंट्रोल](https://www.udacity.com/course/version-control-with-git--ud123)
31. [Google से कौरसेरा पाठ्यक्रम का ऑडिट करें](https://www.coursera.org/learn/introduction-git-github)
32. [वीएस कोड में वरज़न कंट्रोल का उपयोग करना](https://code.visualstudio.com/docs/editor/versioncontrol)
33. [Git बनाम Github: क्या अंतर है और दोनों के साथ कैसे शुरुआत करें](https://kinsta.com/knowledgebase/git-vs-github/)
34. [हेलो वर्ल्ड GitHub गाइड](https://guides.github.com/activities/hello-world/)
35. [GitHub का उपयोग कैसे करें](https://www.edureka.co/blog/how-to-use-github/)
36. [Git और Github के 10 दिन](https://github.com/Asabeneh/10-days-of-git-and-github)
37. [GitHub के लिए कीबोर्ड शॉर्टकट](https://docs.github.com/en/get-started/using-github/keyboard-shortcuts)
38. [संपूर्ण Git और GitHub ट्यूटोरियल कुणाल कुशवाह द्वारा](https://www.youtube.com/watch?v=apGV9Kg7ics&ab_channel=KunalKushwaha)
39. [गिट वर्कफ़्लो चीट शीट](https://drive.google.com/uc?export=download&id=1QPRh5YmqQm4DFfitelPYlBTWC2I6tTTM)
और अधिक लिंक जोड़ते रहें, जो आपको उपयोगी लगें।
docs/additional-material/translations/Hindi/add-file.hi.md
+31
View File
@@ -0,0 +1,31 @@
## एक नई फ़ाइल जोड़ने का ट्यूटोरियल
यदि आप एक नई फ़ाइल को अपने Git रिपॉज़िटरी में जोड़ना चाहते हैं, तो यह ट्यूटोरियल आपकी मदद करेगा।
1. **नई फ़ाइल बनाएं**:
- अपने प्रोजेक्ट फ़ोल्डर में जाएं।
- नई फ़ाइल बनाने के लिए अपने पसंदीदा टेक्स्ट संपादक का उपयोग करें या आपका कोई IDE हो तो वहां से नई फ़ाइल बना सकते हैं।
- फ़ाइल को विशेष नाम दें और सहेजें।
2. **फ़ाइल को स्टेज करें**:
- टर्मिनल खोलें और रिपॉज़िटरी फ़ोल्डर में जाएं।
- नई फ़ाइल को स्टेज करने के लिए निम्नलिखित कमांड का उपयोग करें:
```
git add नया_फ़ाइल.एक्शन
```
3. **कमिट करें**:
- फ़ाइल को स्टेज करने के बाद, एक कमिट बनाएं।
- निम्नलिखित कमांड का उपयोग करें:
```
git commit -m "नई फ़ाइल जोड़ी गई"
```
4. **रिमोट रिपॉज़िटरी में पुश करें**:
- आपकी फ़ाइल अब आपके लोकल रिपॉज़िटरी में है। अब इसे रिमोट रिपॉज़िटरी में भेजने के लिए निम्नलिखित कमांड का उपयोग करें:
```
git push दूरस्थ_शाखा
```
- यहाँ "दूरस्थ_शाखा" वह नाम है जिसमें आप फ़ाइल जोड़ना चाहते हैं।
अब आपने एक नई फ़ाइल अपने रिपॉज़िटरी में जोड़ दी है।
docs/additional-material/translations/Hindi/moving-a-commit-to-a-different-branch.hi.md
+23
View File
@@ -0,0 +1,23 @@
# एक कमिट शाखा को एक अलग शाखा में ले जाना
क्या होगा यदि आप कोई बदलाव कमिट करते हैं, और फिर महसूस करें कि आप एक अलग शाखा में हैं?
आप इसे कैसे बदल सकते हैं? यह ट्यूटोरियल कवर करता है।
## सबसे मौजूदा काम को मौजूदा शाखा में ले जाना
इस काम को करने के लिए, निम्नलिखित कदमों का पालन करें:
``` git reset HEAD~ --soft ``` - आपकी आखिरी कमिट को पूर्ववत करेगा, लेकिन उपलब्ध परिवर्तनों को छोड़ देगा।
``` git stash ``` - आपके निर्देशिका की स्थिति को बचाएगा।
``` git checkout name-of-the-correct-branch ``` - दूसरी शाखा में स्विच करेगा।
``` git stash pop ``` - आखिरी स्टेशेड स्टेटस को हटा देगा।
``` git add ``` - या अलग-अलग फाइलों को एक साथ स्टेज करने का प्रयास करेगा।
``` git commit -m "आपका संदेश यहां" ``` - परिवर्तनों को सुरक्षित करेगा और कमिट करेगा।
अब आपके परिवर्तन सही शाखा पर हैं
### सबसे पुराना काम एक नई शाखा में ले जाना
इस काम को करने के लिए, निम्नलिखित कदमों का पालन करें:
``` git branch newbranch``` - एक नई शाखा बनाएगा। सभी कमिट को सुरक्षित कर देगा।
``` git reset --hard HEAD~#``` - मास्टर को वापस # कमिट में ले जाएगा। याद रखें, यह काम मास्टर से जा चुका होगा।
``` git checkout newbranch``` - आपके द्वारा बनाई गई शाखा में जाएगा। इसमें सभी कमिट होंगे।
याद रखें: कोई भी बदलाव कमिट नहीं किया गया होगा तो वह खो जाएगा।
docs/additional-material/translations/Hindi/removing-a-file.hi.md
+22
View File
@@ -0,0 +1,22 @@
Here's the corrected README.md file with improved grammar:
# गिट से एक फाइल को हटाना
कभी-कभी, आपको किसी फ़ाइल को Git से हटाने की आवश्यकता होती है, लेकिन आप नहीं चाहते कि यह आपके कंप्यूटर से हटा दिया जाए। आप निम्नलिखित कमांड का उपयोग करके इसे प्राप्त कर सकते हैं:
``git rm <file> --cached``
## इसका क्या मतलब है?
Git अब हटाई गई फ़ाइल में किए गए परिवर्तनों का ट्रैकिंग नहीं करेगा। जैसा कि Git को पता होगा, आपने इस फ़ाइल को हटा दिया है। यदि आपने अपने फ़ाइल सिस्टम में फ़ाइल का पता लगाने का प्रयास किया हो, तो आप देखेंगे कि यह अभी भी वहीं है।
यह ध्यान दें कि ऊपर के उदाहरण में, ``--cached`` फ़्लैग का प्रयोग किया गया है। अगर हमने इस ध्वज को नहीं जोड़ा होता, तो Git न केवल रेपोसिटरी से, बल्कि आपके फ़ाइल सिस्टम से भी फ़ाइल को हटा देता।
यदि आप ``git commit -m "Remove file1.js"`` के साथ इस परिवर्तन को करते हैं और फिर ``git push origin master`` का उपयोग करके दूरस्थ रेपोसिटरी में पुश करते हैं, तो दूरस्थ रेपोसिटरी में फ़ाइल को हटा दिया जाएगा।
## अतिरिक्त विशेषताएँ
- यदि आपको एक से अधिक फ़ाइलों को हटाना है, तो आप उन सभी को एक ही कमांड में शामिल कर सकते हैं:
``git rm file1.js file2.js file3.js --cached``
- आप वाइल्डकार्ड (*) का उपयोग करके समान प्रकार की फ़ाइलों को हटाने के लिए उपयोग कर सकते हैं। उदाहरण के लिए, यदि आप अपने स्थानीय भंडार से सभी .txt फ़ाइलों को हटाना चाहते हैं:
``git rm *.txt --cached``
docs/additional-material/translations/Hindi/removing-branch-from-your-repository.hi.md
+31
View File
@@ -0,0 +1,31 @@
# अपने रिपॉजिटरी से एक शाखा निकालें
यदि आपने अब तक ट्यूटोरियल का पालन किया है, तो हमारी `<add-your-name>` शाखा ने अपना उद्देश्य पूरा कर लिया है, अब यह आपके स्थानीय मशीन के रेपो से इसे हटाने का समय है। यह आवश्यक नहीं है, लेकिन इस शाखा का नाम इसके बजाय विशेष उद्देश्य दिखाता है। इसका जीवन संगत रूप से छोटा हो सकता है।
सबसे पहले, अपने मास्टर में अपने `<add-your-name>` को मर्ज करें, इसलिए अपनी मास्टर शाखा पर जाएं:
```
git checkout master
```
उसके बाद मास्टर में `<add-your-name>`मर्ज करें:
```
git merge <add-your-name> master
```
फिर अपने स्थानीय मशीन के रेपो से `<add-your-name>` निकालें:
```
git branch -d <add-your-name>
```
अब आपने अपनी स्थानीय मशीन की `<add-your-name>` शाखा हटा दी है और सब कुछ साफ़ सुथरा लग रहा है।
हालांकि, इस समय, आपके पास अभी भी आपके गिटहब फोर्क में `<add-your-name>` शाखा होनी चाहिए। हालांकि, इससे पहले कि आप इसे हटा दें, याद रखें कि आपने इस रिमोट शाखा से अपने रेपो को "पुल रिक्वेस्ट" भेजा है। इसलिए जब तक कि मैं इसे मर्ज नहीं करता हूं, इस शाखा को न हटाएं।
हालांकि, अगर मैंने आपकी शाखा मर्ज कर ली है और आप रिमोट शाखा को हटाना चाहते हैं, तो इसका उपयोग करें:
```
git push origin --delete <add-your-name>
```
अब, आप जानते हैं कि अपनी शाखाओं को कैसे साफ किया जाए।
समय के साथ, मेरे सार्वजनिक रिपो में कई रेपो जोड़े जाएंगे। और आपकी स्थानीय मशीन और आपके गिटहब फर्क की मास्टर शाखाएं अद्यतित नहीं होंगी। तो अपने रेपोसिटोरिएस को मेरे साथ सिंक्रनाइज़ करने के लिए, नीचे दिए गए चरणों का पालन करें।
#### [अपने फोर्क को रिपॉजिटरी के साथ सिंक रखना] (keeping-your-fork-synced-with-this-repository.md)
docs/additional-material/translations/Hindi/resetting-a-branch.hi.md
+18
View File
@@ -0,0 +1,18 @@
# एक शाखा रीसेट करें
```reset``` वह कमांड है जिसका उपयोग तब किया जा सकता है जब हम किसी कमिट या शाखा के संबंध में रिपॉजिटरी को रीसेट करना चाहते हैं। एक रीसेट, जैसा कि नाम से पता चलता है, वर्तमान शाखा पर सब कुछ त्याग देता है और इसे उस शाखा के समान बना देता है जिसके साथ हमने आधार शाखा को रीसेट करना चुना (इसे मूल शाखा भी कहा जाता है)। इसका अनिवार्य रूप से मतलब यह है कि हमारे पास मूल शाखा के नाम के साथ मूल शाखा की एक कॉपी होगी।<br/>
हालाँकि, सवाल यह है कि हम आधार शाखा को क्यों नहीं हटा देते हैं और मूल शाखा से आधार शाखा के नाम से एक नई शाखा क्यों नहीं चेकआउट कर देते हैं। तकनीकी रूप से, इसका प्रभाव रीसेट करने जैसा ही होगा लेकिन कुछ औद्योगिक स्थितियों में हमारे पास किसी शाखा को हटाने की पहुंच नहीं है, या हम किसी शाखा को हटा नहीं सकते हैं क्योंकि यह सीआई/सीडी पाइपलाइन या शायद चल रहे वर्कफ़्लो को बाधित/बाधित कर देगा। इसलिए, ऐसी स्थितियों से बचने के लिए जो डाउनटाइम का कारण बन सकती हैं, हम सुझाव देते हैं कि जब भी हम किसी विशेष शाखा को रीसेट करना चाहते हैं तो `git reset` का उपयोग करें।
## कम्मांड
शाखा के लिए गिट रीसेट निष्पादित करना बहुत आसान है।
```
git reset <base_branch> <origin_branch>
```
उदाहरण के तौर पर:
```
git reset stage master --hard
```
उपरोक्त कमांड `stage` शाखा को `master` के साथ रीसेट कर देगा और इसलिए `stage` को बिल्कुल `master` के समान बना देगा।
आप सोच रहे होंगे कि `--hard` फ्लैग का उपयोग क्यों किया जाता है? इसका उद्देश्य उन सभी परिवर्तनों को अनदेखा करना है जो रीसेट से पहले/बाद में होंगे या होंगे।
docs/additional-material/translations/Hindi/resetting-a-commit.hi.md
+19
View File
@@ -0,0 +1,19 @@
# कमिट रीसेट करें
```reset``` वह कमांड है जिसका उपयोग तब किया जा सकता है जब हम रिपॉजिटरी को पिछली कमिट में वापस ले जाना चाहते हैं, उस कमिट के बाद किए गए किसी भी बदलाव को छोड़कर।<br/>
किसी कमिट को रीसेट करने और वापस लाने के बीच मुख्य अंतर यह है कि git रीसेट ```फ़ाइल को अनस्टेज करता है और हमारे परिवर्तनों को कार्यशील निर्देशिका में वापस लाता है``` और git revert ```रिमोट रिपॉजिटरी से कमिट्स को हटा देता है```। <br/>
```git reset``` निम्नलिखित कमांड का उपयोग करके प्राप्त किया जा सकता है:
- निम्नलिखित कमांड निम्नलिखित दो मापदंडों का उपयोग करके सभी कमिटों का सारांश देगा:
- कमिट हैश के पहले सात अक्षर - यही वह है जिसे हमें अपने **reset** कमांड में संदर्भित करना होगा।
- प्रतिबद्ध संदेश
```
git log --oneline
```
- कोई निम्नलिखित कमांड का उपयोग करके रिपॉजिटरी को विशिष्ट कमिट पर वापस रीसेट कर सकता है: <br />
```गिट रीसेट कमिटहैश```
जहां कमिटहैश कमिट हैश के पहले 7 अक्षर हैं जो हमें लॉग में मिले|
docs/additional-material/translations/Indonesian/Useful-links-for-further-learning.id.md
+46
View File
@@ -0,0 +1,46 @@
# Tautan-tautan Bermanfaat
Dokumen ini didedikasikan untuk semua situs web tips dan trik, postingan blog, dan situs bermanfaat yang membuat hidup kita lebih mudah. Ini adalah referensi yang bagus untuk memenuhi semua kebutuhan kita, baik itu pemula maupun ahli. Halaman ini berisi indeks dari semua tautan berguna yang akan membantu semua pemula dalam domain sumber terbuka atau seseorang yang ingin mempelajari lebih lanjut.
## Daftar Isi
1. [Tutorial git interaktif](https://try.github.io)
2. [Youtube: Git dan GitHub untuk pemula oleh freecodecamp](https://www.youtube.com/watch?v=RGOj5yH7evk)
3. [Git - panduan sederhana](http://rogerdudler.github.io/git-guide/)
4. [Tentang mengembalikan, menyesuaikan, atau menghapus commit pada git](http://sethrobertson.github.io/GitFixUm/fixup.html)
5. [Git and GitHub terjemahan tutorial untuk banyak bahasa](https://github.com/Roshanjossey/first-contributions)
6. [Konflik Merge](https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/merge-conflicts)
7. [Memperbaiki Konflik Merge](https://githowto.com/resolving_conflicts)
8. [Dasar - Dasar Git - Panduan cepat dan sederhana](https://blog.praveen.science/basics-of-git-the-quick-start-guide/)
9. [Standar - Standar Git menurut Agile Methodology Spotify](https://blog.praveen.science/git-standards-followed-in-our-way-of-spotify-agile-methodolgy/)
10. [Pintasan pada Git](https://blog.praveen.science/git-shortcuts/)
11. [Contekan Git resmi semua bahasa](https://services.github.com/on-demand/resources/cheatsheets)
12. [Contekan Git dari Tower](https://www.git-tower.com/learn/cheat-sheets/git)
13. [Permasalahan Umum Git](https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd)
14. [Rebase pada Git](https://blog.gitprime.com/git-rebase-an-illustrated-guide/)
15. [Panduan Pemula untuk melakukan Rebase dan Squash](https://github.com/servo/servo/wiki/Beginner%27s-guide-to-rebasing-and-squashing)
16. [Contekan Git yang menunjukan korelasi antara perintah dan file](http://ndpsoftware.com/git-cheatsheet.html)
17. [Bagaimana Cara Berkontribusi](https://opensource.guide/how-to-contribute/)
18. [Memulai dengan Sumber Terbuka](https://github.com/OpenSourceHelpCommunity/Getting-Started-With-Contributing-to-Open-Sources)
19. [Bagaimana Cara Berkontribusi](https://github.com/freeCodeCamp/how-to-contribute-to-open-source)
20. [Tutorial Git Atlassians](https://www.atlassian.com/git)
21. [Tinjauan permintaan Pull](https://help.github.com/articles/about-pull-request-reviews/)
22. [Tutorial Interaktif lainnya untuk git](https://learngitbranching.js.org/)
23. [Contekan baris perintah pada Git](https://gist.github.com/davfre/8313299)
24. [Buku - Buku Pemrograman](https://github.com/EbookFoundation/free-programming-books)
25. [E-Book untuk profesional tip and rahasia](https://goalkicker.com/GitBook/GitProfessionalTipsSecrets.pdf)
26. [Tutorial tentang cara sederhana menjadi profesional git](https://medium.freecodecamp.org/follow-these-simple-rules-and-youll-become-a-git-and-github-master-e1045057468f)
27. [Sebuah catatan tentang Pesan Git Commit](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
28. [5 Tip Berguna Untuk Pesan Commit yang baik](https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message)
29. [Kontrol Versi menggunakan Git](https://ourcodingclub.github.io/2017/02/27/git.html)
30. [Kontrol Versi dengan Git](https://www.udacity.com/course/version-control-with-git--ud123)
31. [Memeriksa kursus Coursera dari Google](https://www.coursera.org/learn/introduction-git-github)
32. [Menggunakan Kontrol Versi pada VS Code](https://code.visualstudio.com/docs/editor/versioncontrol)
33. [Git vs Github: Apa Perbedaannya dan Bagaimana cara menggunakan keduanya](https://kinsta.com/knowledgebase/git-vs-github/)
34. [Panduan Hello World Github](https://guides.github.com/activities/hello-world/)
35. [Bagaimana cara menggunakan GitHub](https://www.edureka.co/blog/how-to-use-github/)
36. [10 Hari tentang Git and Github](https://github.com/Asabeneh/10-days-of-git-and-github)
37. [Pintasan Keyboard untuk Github](https://docs.github.com/en/get-started/using-github/keyboard-shortcuts)
38. [Tutorial Lengkap Git and GitHub oleh Kunal Kushwaha](https://www.youtube.com/watch?v=apGV9Kg7ics&ab_channel=KunalKushwaha)
Tambahkan tautan baru yang menurut Anda dapat membantu.
docs/additional-material/translations/Indonesian/additional-material.id.md
+67
View File
@@ -0,0 +1,67 @@
# Informasi tambahan
Kami berasumsi Anda sudah menyelesaikan tutorial dasar sebelum datang ke sini. Dokumen ini akan memberikan beberapa informasi mengenai teknik Git yang lebih tinggi.
### [Hapus cabang dari repositori Anda](removing-branch-from-your-repository.id.md)
Dokumen ini memberikan informasi mengenai bagaimana menghapus sebuah cabang dari repositori Anda.
> Lakukan langkah ini setelah pull request Anda digabungkan (merge).
### [Agar fork Anda tetap sinkron dengan repositori](keeping-your-fork-synced-with-this-repository.md)
Dokumen ini memberikan informasi mengenai bagaimana agar repositori yang kita fork tetap up-to-date dengan repositori dasar. Hal ini penting, karena bisa jadi Anda dan banyak kontributor lain berkontribusi dalam proyek tersebut.
> Ikuti langkah-langkahnya jika fork Anda tidak punya perubahan dengan repositori induk.
### [Membatalkan commit](reverting-a-commit.md)
Dokumen ini memberikan informasi bagaimana caranya membatalkan commit di repositori remote. Langkah ini perlu jika sewaktu-waktu Anda harus membatalkan sebuah commit yang telanjur sudah didorong ke GitHub.
> Ikuti langkah-langkahnya untuk membatalkan sebuah commit.
### [Mengubah sebuah commit](amending-a-commit.md)
Dokumen ini memberikan informasi mengenai cara mengubah sebuah commit di repositori remote.
> Gunakan ini ketika kamu harus mengubah commit yang sudah dibuat.
### [Membatalkan commit lokal](undoing-a-commit.md)
Dokumen ini memberikan informasi mengenai cara membatalkan sebuah commit di repositori lokal Anda. Hal ini diperlukan ketika Anda berpikir sudah merusak repositori lokal dan ingin me-reset repositori tersebut.
> Lakukan cara ini jika ingin membatalkan/reset commit di lokal.
### [Mengatasi Merge Conflicts](resolving-merge-conflicts.md)
Dokumen ini memberikan informasi mengenai cara mengatasi saat terjadi konflik ketika melakukan merge.
> Lakukan langkah tersebut untuk mengatasi konflik merge yang mengganggu.
### [Menghapus sebuah berkas](removing-a-file.id.md)
Dokumen ini memberikan informasi mengenai cara menghapus sebuah berkas dari repositori lokal.
> Ikuti langkah tersebut untuk mempelajari bagaimana menghapus sebuah berkas sebelum di-commit.
### [Memindahkan Commit ke Cabang berbeda](moving-a-commit-to-a-different-branch.md)
Dokumen ini memberikan informasi mengenai cara memindahkan sebuah commit ke cabang lain.
> Ikuti langkah tersebut untuk memindahkan sebuah commit ke cabang lain.
### [Mengkonfigurasi git](configuring-git.md)
Dokumen ini memberikan informasi mengenai cara mengkonfigurasi detail pengguna dan opsi lain di git.
> Gunakan langkah ini agar konfigurasi git Anda menjadi lebih baik.
### [Tautan bermanfaat](Useful-links-for-further-learning.id.md)
Dokumen ini didedikasikan untuk semua pos blog, laman yang sangat membantu, situs tip dan trik yang akan membuat hidup kita lebih mudah. Tautan tersebut tidak hanya untuk pemula, namun juga bagi yang sudah mahir. Halaman ini akan menjadi indeks untuk semua tautan yang bermanfaat yang mungkin saja bisa membantu siapapun yang baru terjun di dunia open-source atau siapapun yang ingin belajar lebih lanjut.
### [Menyatukan banyak Commit](squashing-commits.md)
Dokumen ini menyediakan informasi mengenai bagaimana menyederhanakan banyak commit dengan rebase interaktif.
> Gunakan ini jika Anda ingin membuka sebuah PR (Pull Request) dalam proyek open source dan periview meminta kamu untuk menyatukan setiap commit menjadi satu, dengan pesan commit yang informatif.
docs/additional-material/translations/Indonesian/removing-a-file.id.md
+23
View File
@@ -0,0 +1,23 @@
# Menghapus file
Terkadang Anda ingin menghapus file dari Git, tetapi Anda tidak ingin menghapusnya dari komputer Anda. Anda dapat melakukan ini dengan menggunakan perintah berikut:
`git rm <file> --cached`
## Apa yang terjadi?
Git tidak akan lagi melacak perubahan pada file yang dihapus. Bagi Git, file ini sudah tidak ada lagi. Jika Anda mencari file tersebut di disk Anda, Anda melihat bahwa file itu masih ada.
Pada contoh di atas, kita menggunakan flag `--cached`. Jika kita tidak menggunakannya, Git juga akan menghapus file tersebut dari disk kita.
Jika sekarang kita membuat komit dengan `git commit -m "Hapus file1.js"` dan mengirimkannya ke repositori jarak jauh dengan perintah `git push origin master`, file tersebut juga akan dihapus dari repositori jarak jauh.
## Opsi tambahan
- Jika Anda ingin menghapus beberapa file, Anda dapat menyertakan semuanya dalam satu perintah:
`git rm file1.js file2.js file3.js --cached`
- Anda dapat menggunakan wildcard (\*) untuk menghapus file serupa. Misalnya, untuk menghapus semua file .txt dari repositori Anda, gunakan perintah:
`git rm *.txt --cached`
docs/additional-material/translations/Indonesian/removing-branch-from-your-repository.id.md
+31
View File
@@ -0,0 +1,31 @@
# Remove a branch from your repository
If you have followed the tutorial up-to-now, our `<add-your-name>` branch has finished its purpose, it is time to delete it from your local machine's repo. This isn't necessary, but the name of this branch shows its rather special purpose. Its life can be made correspondingly short.
First, let's merge your `<add-your-name>` to your master, so to go to your master branch:
```
git checkout master
```
Merge `<add-your-name>` to master:
```
git merge <add-your-name> master
```
Remove `<add-your-name>` on your local machine's repo:
```
git branch -d <add-your-name>
```
You have now deleted your local machine's `<add-your-name>` branch and everything looks neat and tidy.
Though, at this point, you should still have the `<add-your-name>` branch in your GitHub fork. However, before you delete this, remember that you have sent a "Pull request" to my repo from this remote branch. So unless I've already merged it, don't delete this branch.
However, if I have merged your branch and you want to delete the remote branch, use:
```
git push origin --delete <add-your-name>
```
Now, you know how to tidy your branches.
With time, many commits will be added to my public repo. And the master branches of your local machine and of your GitHub fork won't be up-to-date. So in order to keep your repositories synchronized with mine, follow the steps below.
#### [Keeping your fork synced with the repository](keeping-your-fork-synced-with-this-repository.md)
docs/additional-material/translations/Indonesian/resetting-a-commit.id.md
+21
View File
@@ -0,0 +1,21 @@
# Mengatur Ulang Sebuah commit
`git reset` adalah perintah yang dapat digunakan ketika kita ingin memindahkan repositori kembali ke _commit_ sebelumnya, membuang semua perubahan yang dibuat setelah _commit_ tersebut.<br/>
Perbedaan utama antara mengatur ulang dan mengembalikan _commit_ adalah bahwa `git reset` menghapus tahapan berkas dan membawa perubahan Anda ke direktori kerja
dan `git revert` menghapus _commit_ dari repositori remote.<br/>
`git reset` dapat dicapai dengan menggunakan perintah berikut:
- Perintah berikut ini akan memberikan ringkasan dari semua commit dengan menggunakan dua parameter berikut:
- Tujuh karakter pertama dari commit hash - inilah yang perlu kita rujuk dalam perintah **reset**.
- Pesan commit
```
git log --oneline
```
- Seseorang dapat mengatur ulang repositori kembali ke commit tertentu menggunakan perintah berikut: <br />
`git reset commithash`
di mana commithash adalah 7 karakter pertama dari hash commit yang kami temukan di log
docs/additional-material/translations/Italian/removing-a-file.it.md
+23
View File
@@ -0,0 +1,23 @@
# Rimuovere un file da Git
Può succedere che tu voglia rimuovere un file da Git, mantenendolo comunque nel tuo computer. Lo puoi fare eseguendo questo comando:
``git rm <file> --cached``
## Cosa fa questo comando?
Git non terrà più conto dei cambiamenti inclusi nel file rimosso. Per Git, è come se tu avessi cancellato il file. Se però vai a cercare il file nel tuo sistema, vedrai che comunque è ancora lì.
Come vedi, nell'esempio qui sopra viene usato il flag `--cached`. Senza questo flag Git rimuoverebbe il file non solamente dal repository, ma anche dal tuo sistema.
Se decidi di validare questo cambiamento con `git commit -m "Remove file1.js"` e successivamente invii le modifiche al repository remoto usando `git push origin master`, vedrai che il repository remoto avrà rimosso il file.
## Funzioni aggiuntive
- Per rimuovere più di un file, puoi aggiungerli tutti allo stesso comando in questo modo:
`git rm file1.js file2.js file3.js --cached`
- Puoi usare il metacarattere asterisco (*) per rimuovere i file simili tra loro. Per esempio, se vuoi rimuovere tutti i file con estensione .txt dal tuo repository locale puoi farlo così:
`git rm *.txt --cached`
docs/additional-material/translations/Italian/reverting-a-commit.it.md
+40
View File
@@ -0,0 +1,40 @@
# ripristinare una commit
Ripristinare (*revert) una commit significa creare una nuova commit che elimina tutti
i cambiamenti apportati da quella precedente. È come fare un ```ctrl + Z``` su git.
Il ripristino è reso più semplice in git perchè ogni commit che invii (*push) nella tua repository remota ha un'unica chiave alfanumerica associata, questa chiave è chiamata SHA (Secure Hash Algorithm).
questo significa che puoi ripristinare una commit fintanto che possiedi la sua chiave SHA.
ad ogni modo, bisogna prestare attenzione a ripristinare le commit in modo ordinato in modo da non mettere in disordine la tua repository.
Per ottenere la chiave SHA della commit che vuoi ripristinare, viene in aiuto il log di tutte le commit che sono state fatte.
per ottenere questo log possiamo utilizzare il comando:
```git log --oneline ```
Usando il comando ```git log``` da solo si ottengono comunque le SHA (in formato lungo)
utilizzando però la flag ```--oneline ``` diciamo a git che vogliamo stampare a video un formato conciso (una linea) per facilitare la lettura.
I primi 7 caratteri stampati quando esegui questo comando rappresentano un abbreviazione dell'hash della commit.
Per esempio, questo è quello che ottengo quando eseguo ```git log --oneline ``` su questa repository:
```
389004d added spacing in title
c1b9fc1 Merge branch 'master' into tutorials
77eaafd added tutorial for reverting a commit
```
Questo esempio dimostra come con ```git log --oneline```, possiamo ottenere la lista di commit fatte sulla repository assieme ai primi 7 caratteri del suo SHA.
Supponiamo ora che io voglia ripristinare la commit "added spacing in title", per fare questo seguirei questi passaggi:
* Copio lo SHA della commit che, in questo caso è ```389004d```
* poi, eseguo il comando ```git revert 389004d```
Facendo questo si apre il mio editor di testo e mi viene chiesto di modificare il messaggio di commit.
Puoi decidere di lasciare il messaggio di default che inizia con la parola `Revert`
oppure puoi anche decidere di personalizzare il messaggio come preferisci.
* In seguito, salvo il messaggio e chiudo l'editor di testo.
* Vengo mandato nella linea di comando.
* eseguo ```git push origin <branch-name>``` per inviare i cambiamenti ripristinati su Github.
E questo è tutto, i cambiamenti vengono eliminati. Nel mio caso, la repository viene ripristinata allo stesso stato di com'era in ```c1b9fc1```
docs/additional-material/translations/Korean/additional-material.ko.md
+52
View File
@@ -0,0 +1,52 @@
# 추가 정보
여러분이 여기에 오기 전에 기본실습 과정을 이미 완료했다고 가정합니다. 이 문서는 고급 Git 기술에 대한 추가적인 정보를 제공합니다.
### [커밋 수정하기](amending-a-commit.ko.md)
이 문서는 원격 저장소의 커밋을 수정하는 방법에 대한 정보를 제공합니다. 커밋을 수정하는 것은 당신의 현재 브랜치 내 가장 최근의 커밋을 변경하는 한 방법입니다. 이는 커밋 메세지를 수정해야 하거나 커밋에 변경사항을 포함하지 않은 경우에 유용합니다. 당신은 원격 저장소에 커밋을 푸시하기 전까지 커밋을 계속해서 수정할 수 있습니다.
> 당신이 만든 커밋을 수정해야 할 경우 사용하십시오.
### [git 설정하기](configuring-git.md)
이 문서는 git에서 사용자 정보 및 기타 옵션을 구성하는 방법에 대한 정보를 제공합니다.
> git 설정을 더 잘 다루려면 이 단계를 수행하십시오.
### [여러분이 포크한 저장소와 싱크상태 유지하기](keeping-your-fork-synced-with-this-repository.ko.md)
이 문서는 포크 된 저장소를 기본 저장소로 최신 상태로 유지하는 방법에 대한 정보를 제공합니다. 여러분과 다른 많은 사람들이 프로젝트에 기여하기를 바랍니다.
> 포크 된 상위 저장소가 변경되지 않은 경우 다음 단계를 수행하십시오.
### [커밋을 다른 브랜치로 이동하기](moving-a-commit-to-a-different-branch.ko.md)
이 문서는 커밋을 다른 브랜치로 이동하는 방법에 대한 정보를 제공합니다.
> 이 단계를 수행하여 커밋을 다른 브랜치로 이동하십시오.
### [파일 삭제하기](removing-a-file.ko.md)
이 문서는 로컬 저장소에서 파일을 지우는 방법에 대한 정보를 제공합니다.
> 커밋 전에 파일을 삭제하는 방법을 배우려면 다음의 과정을 수행하십시오.
### [여러분의 저장소에서 브랜치 삭제하기](removing-branch-from-your-repository.ko.md)
이 문서는 저장소에서 브랜치를 삭제하는 방법에 대한 정보를 제공합니다.
> PR(pull request) 요청이 병합 된 후에 본 단계를 수행하십시오.
### [병합 충돌 해결하기](resolving-merge-conflicts.ko.md)
이 문서는 병합 충돌을 해결하는 방법에 대한 정보를 제공합니다.
> 이 단계를 수행하여 곤란한 병합 충돌을 해결하십시오.
### [커밋 되돌리기](reverting-a-commit.ko.md)
이 문서는 원격 저장소에서 커밋을 되돌리는 방법에 대한 정보를 제공합니다. 이미 Github에 푸시 된 커밋을 되돌리려는 경우 유용합니다.
> 커밋을 되돌리려면 이 단계를 수행하십시오.
### [스쿼시 커밋하기](../squashing-commits.md)
이 문서는 대화형 리베이스로 커밋을 스쿼시하는 방법에 대한 정보를 제공합니다.
> 오픈 소스 프로젝트에서 PR을 보낼 때 리뷰어가 모든 커밋을 하나로 스쿼시하도록 요청하는 경우 유익한 커밋 메시지와 함께 이것을 사용하십시오.
### [로컬 커밋 되돌리기](undoing-a-commit.ko.md)
이 문서는 로컬 저장소에서 커밋을 실행 취소하는 방법에 대한 정보를 제공합니다. 로컬 저장소가 엉망이라고 느껴 당신이 로컬 저장소를 리셋하고자 할 때 당신이 해야 할 일입니다.
> 로컬 커밋을 취소하려면 이 단계를 수행하십시오.
### [유용한 링크](../Useful-links-for-further-learning.md)
이 문서는 모든 블로그 게시물, 유용한 사이트, 유용한 정보 및 웹 사이트에 대한 내용을 담고 있습니다. 우리가 모든 필요를 위해 참조하는 것은 초심자 또는 전문가 일 것입니다. 이 페이지는 오픈 소스 도메인을 처음 접하거나 더 많은 것을 배우고자 하는 사람들을 돕는 지표 역할을 해야 합니다.
### [.gitignore 파일 생성하기](creating-a-gitignore-file.ko.md)
이 문서는 .gitignore 파일의 역할, 사용 이유 및 .gitignore 파일 생성 방법을 설명합니다. 이 파일은 거의 모든 git 프로젝트에 사용됩니다. 이는 필요한 파일만 git에 커밋하도록 돕습니다.
### [크리덴셜 저장하기](storing-credentials.ko.md)
이 문서는 저장소들의 크리덴셜을 저장하는 방법을 설명합니다. 이는 보안 관련 문제가 될 수 있으므로, 당신의 직장/ 학업 에 알맞은 보안 정책을 따르십시오.
docs/additional-material/translations/Korean/amending-a-commit.ko.md
+46
View File
@@ -0,0 +1,46 @@
## 커밋 수정하기
만약 커밋 메시지에 오타가 있거나 가장 최근의 커밋에서 몇줄을 빼먹은 걸 나중에 깨닫고 원격 저장소로 커밋을 수정하고자 하는 경우 어떻게 할까요? 이 자습서는 이러한 내용을 다룹니다.
### Github에 이미 푸시한 후에 최근 커밋 메시지 변경하기
파일을 열지 않고 수행할 경우:
* 다음을 타이핑합니다. ```git commit --amend -m "followed by your new commit message"```
* 변경사항을 저장소에 커밋하려면 다음을 실행합니다. ```git push origin <branch-name>```
참고: 단지 ```git commit --amend``` 이것만 입력한다면, 텍스트 편집기가 커밋 메시지를 입력하라고 할 것입니다. ``-m`` 플래그를 추가하면 이것을 막을 수 있습니다.
### Modifying on a single commit
그럼 한 단어를 변경하는 것과 같이 사소한 변경사항을 깜빡하고 커밋을 이미 원격 저장소에 푸시했다면 어떻게 해야 할까요?
이를 설명하기 위해 여기 제 커밋 로그가 있습니다:
```
g56123f create file bot file
a2235d updated contributor.md
a5da0d modified bot file
```
봇 파일에 한 단어를 추가하는 것을 깜빡했다고 해 봅시다.
이 경우 두가지 방법이 있습니다. 첫번째는 다음과 같이 변경사항을 포함하는 완전히 새로운 커밋을 수행하는 것입니다:
```
g56123f create file botfile
a2235d updated contributor.md
a5da0d modified botfile
b0ca8f added single word to botfile
```
두번째 방법은 a5da0d 커밋을 수정하고, 새 단어를 추가하고 이를 하나의 커밋으로 Github에 푸시하는 것 입니다.
이 방법은 사소한 변화이기 때문에 더 나을수도 있습니다.
이를 위해 다음을 수행하십시오:
* 파일을 수정하십시오. 이 경우, 이전에 빠뜨린 단어를 포함하여 봇 파일을 수정합니다.
* 그 다음, ```git add <filename>``` 을 실행하여 파일을 스테이징 영역으로 추가합니다.
보통 파일을 스테이징 영역에 추가하고 나면, 다음으로 우리가 해야할 일은 git commit -m "our commit message" 입니다.
그러나 여기서 우리가 원하는 것은 이전 커밋을 수정하는 것이므로, 다음을 실행합니다:
* ```git commit --ammend```
그러면 텍스트 편집기가 뜨고 메시지를 수정하라는 프롬프트가 뜰 것입니다. 이전 그대로 메시지를 두거나 변경할 수 있습니다.
* 에디터를 빠져나오십시오.
* ```git push origin <branch-name``` 으로 변경사항을 푸시하십시오.
이렇게 하면 두 변경사항이 단일 커밋이 됩니다.
docs/additional-material/translations/Korean/check-commit-log.ko.md
+37
View File
@@ -0,0 +1,37 @@
# 커밋 로그 확인하기
특정 브랜치 및 파일과 관련된 커밋 로그를 확인하고 싶으시다면 다음 명령어를 유용하게 쓰실 수 있습니다:
`git log [options] [path]`
이 명령어는 기본적으로 커밋 로그를 시간 역순, 즉 내림차순으로 정렬하여 출력합니다.
## 명령어 출력 예시
```
$ git log
commit e3fabb30ab536bd5876461d8a749301a321e714f (HEAD -> check-commit-log-ko, upstream/main, origin/main, origin/HEAD, main)
Author: Dan Yunheum Seol <yunheum.seol@mail.mcgill.ca>
Date: Tue Jun 4 01:07:25 2024 -0400
Add dan-seol to Contributors list (#84962)
commit 4af4ec8a56e057ce8768af77eda528453974d0bc
Author: Edgar Humberto Tijerina Tamez <168693312+EdgarHTT@users.noreply.github.com>
Date: Mon Jun 3 23:06:05 2024 -0600
Add Edgar Tijerina to Contributors list (#84961)
```
## 명령어 변형(바리에이션) 및 선택 사항(옵션)
- 하나 혹은 여러 개의 특정 커밋 식별자(아이디)를 기준으로 접근 가능한 커밋 로그를 보고 싶으시다면 다음 명령어를 활용하세요: (`foo`나 `bar`를 예시로 들겠습니다)</i><br>
`git log foo bar`
- 반대로 특정 커밋 식별자를 기준으로 접근 가능한 커밋 로그를 출력에서 제외할 수도 있습니다. 커밋 식별자 앞에 삿갓표(캐럿 기호) `^`를 붙여 주세요: <i>(`baz`를 예시로 들자면)</i><br>
`git log foo bar ^baz`
- 특정 파일과 관련된 커밋 로그를 볼 수도 있습니다. 아래 명령어를 사용해 보세요: <br>
`git log --all <filename>`
- 커밋 로그 목록의 항목 수를 제한 할 수도 있습니다: <i>(예를 들어 `5` 항목으로 줄여보겠습니다)</i><br>
`git log -n 5`
## 참조 및 더 알아보기
- [Official documentation](https://git-scm.com/docs/git-log)
docs/additional-material/translations/Korean/delete-branch-locally.ko.md
+19
View File
@@ -0,0 +1,19 @@
# 이 문서는 로컬 저장소에서 브랜치를 삭제하는법을 제공합니다.
브랜치 이름을 실수로 잘못 입력했을대 유용합니다.
이것은 *3*가지 방법으로 할 수 있습니다.
```
git branch -D <브랜치 이름>
```
```
git branch --delete --force <브랜치 이름> # 위에 -D와 동일합니다.
```
```
git branch --delete <브랜치 이름> # unmerge 에러
```
-D는 --delete --force를 의미하며, 브랜치가 병합(merge)되지 않았더라도 강제로 삭제합니다. 하지만 -d 또는 --delete 옵션을 사용하면 브랜치의 병합(merge) 상태에 따라 오류가 발생할 수 있습니다...
docs/additional-material/translations/Korean/keeping-your-fork-synced-with-this-repository.ko.md
+41
View File
@@ -0,0 +1,41 @@
# 여러분이 포크한 저장소와 싱크상태 유지하기
먼저, 전체 싱크과정을 이해해야합니다. 본 스키마에는 3개의 저장소들이 있습니다. 저의 GitHub에 있는 제 공개저장소인 `github.com/Roshanjossey/first-contributions/`와 여러분의 포크된 저장소인 `github.com/Your-Name/first-contributions/`, 그리고 로컬 머신에 위치해서 현재 작업중인 저장소가 있습니다. 오픈 소스 프로젝트에 특화된 이러한 조합을 `트라이앵글 워크플로우`라고 부릅니다.
<img style="float;" src="https://firstcontributions.github.io/assets/additional-material/triangle_workflow.png" alt="triangle workflow" />
여러분의 두 개의 저장소들을 제 공개 저장소의 최신 상태와 싱크상태를 유지하기 위해서는 제일 먼저여러분의 로컬머신에 위치한 저장소를 제 공개 저장소와 fetch와 merge를 해야합니다.
두번째는 여러분의 로컬 저장소를 포크된 GitHub의 저장소에 push하는 것 입니다. 이전 과정에서 봤듯이 "pull request"를 요청할 수 있는 곳은 오직 포크된 저장소에서만 가능합니다. 따라서 마지막으로 업데이트 되어야하는 저장소는 포크된 GitHub입니다.
자, 어떻게하는지 보겠습니다:
먼저 여러분은 main 브랜치에 위치해 있어야합니다. 현재 어떤 브래치에 있는지 확인합니다.:
```
git status
```
현재 main 브랜치가 아니라면 변경합니다.:
```
git checkout main
```
제 공개 저장소를 아직 여러분의 git에 추가하지 않았다면 다음 명령으로 추가합니다. `add upstream remote-url`:
```
git remote add upstream https://github.com/Roshanjossey/first-contributions
```
지정한 URL을 이용해 현재 프로젝트의 또 다른 최신 버전이 있는지 git에게 확인을 요청하는 방법입니다. 그리고 우리는 이를 `upstream` 이라고 부르기로합니다. 일단 git이 이러한 이름을 가지고 있다면 다음과 같이 공개 저장소의 최진 버전을 가지고 옵니다. :
```
git fetch upstream
```
여러분은 이제 제 포크(upstream remote)에서 최신 버전을 내려 받았습니다. 이제 공개 저장소의 변경된 내용을 여러분의 main 브랜치에 병합해야합니다.
```
git rebase upstream/main
```
여러분의 main 브랜치와 공개 저장소를 병합하고 나면 이제 여러분의 로컬머신의 main 브랜치는 최신 상태입니다. 마지막으로 여러분의 main 브랜치를 여러분의 포크에 push하게 되면 포크한 GitHub 또한 변경사항들이 반영됩니다.:
```
git push origin main
```
origin으로 명명된 리모트에 push하는 것에 주의하세요.
이제 여러분의 모든 저장소가 최신 상태를 유지하게 되었습니다.
잘 하셨습니다! GitHub 저장소에 커밋이 추가적으로 발생할 때마다 이러한 작업을 해야합니다.
docs/additional-material/translations/Korean/moving-a-commit-to-a-different-branch.ko.md
+28
View File
@@ -0,0 +1,28 @@
## 커밋을 다른 브랜치로 옮기기
What if you commit a change, and then realize that you committed to a different branch?
How can you change that? This is what this tutorial covers.
만일 변경사항을 반영했는데 전혀 다른 브랜치에 커밋한 사실을 알았다면 어떻게할까요?
이걸 어떻게 바로잡을 수 있을까요? 바로 이 장에서 다룰 내용입니다.
### 가장 최근 커밋들을 기존에 있는 브랜치로 이동시키기
사용예:
```git reset HEAD~ --soft``` - 마지막 커밋을 되돌립니다. 물론 수정한 내용은 그대로 남아있습니다.
```git stash``` - 현재까지 수정한 모든 작업내용들의 상태를 저장합니다.
```git checkout name-of-the-correct-branch``` - 실제 반영하고자하는 브랜치를 체크아웃합니다.
```git stash pop``` - 마지막으로 저장한(stash) 변경내역들을 현재 브랜치에 반영하고 저장한 내역에서 삭제합니다.
```git add .``` - 또는 커밋에 반영할 변경내역들을 개별적으로 추가합니다.
```git commit -m "your message here"``` - 저장하고 변경내역을 커밋합니다.
자 이제 변경사항이 올바른 브랜치에 반영되었습니다.
### 가장 최근 커밋들을 신규 브랜치를 생성하여 이동시키기
사용예:
```git branch newbranch``` - 신규 브랜치를 생성하고 모든 커밋들을 저장합니다.
```git reset --hard HEAD~#``` - master 브랜치의 #번째 커밋을 되돌립니다. 되돌린 커밋들은 master에서 완전히 삭제되므로 주의하세요.
```git checkout newbranch``` - 생성한 브랜치로 이동합니다. 모든 커밋들을 가지고 있을겁니다.
주의: 커밋하지 않은 변경사항들은 사라집니다.
docs/additional-material/translations/Korean/removing-branch-from-your-repository.ko.md
+30
View File
@@ -0,0 +1,30 @@
## 여러분의 저장소에서 브랜치 삭제하기
지금까지의 튜토리얼을 수행했다면, 우리의 `<add-your-name>` 브랜치가 목적을 완료했습니다. 이제는 로컬 저장소에서 삭제할 차례입니다. 필수사항은 아니지만 이 브랜치의 이름은 다소 특별한 목적을 나타내므로 이미 병합되었다면 그 수명을 다했다고 할 수 있습니다.
First, let's merge your `<add-your-name>` to your master, so to go your master branch:
먼저, `<add-your-name>`을 마스터에 합쳐야합니다. 마스터 브랜치로 이동합니다.:
```
git checkout master
```
`<add-your-name>`를 마스터에 병합합니다.:
```
git merge <add-your-name> master
```
`<add-your-name>`를 로컬 저장소에서 삭제합니다.:
```
git branch -d <add-your-name>
```
이제 로컬 머신의 `<add-your-name>`브랜치를 삭제했고 모든 것이 깔끔하게 보입니다.
이 시점에서 GitHub 포크에 여전히 `<add-your-name>` 브랜치가 있어야합니다. 그러나 이것을 삭제하기 전에 이 원격지의 브랜치에서 상위 저장소로 "PR(Pull request)"을 보냈음을 기억하십시오. 따라서 아직 병합되지 않았다면이 브랜치를 삭제하지 마십시오.
그러나 해당 브래치를 이미 병합했고 원격 브랜치를 삭제하려면 다음을 사용하십시오.:
```
git push origin --delete <add-your-name>
```
자, 여러분은 이제 자신의 브래치를 정리하는 법을 배웠습니다.
시간이 지나면 많은 커밋이 저장소에 추가됩니다. 그리고 로컬 머신과 GitHub 포크의 마스터 브랜치는 최신 버전이 아닙니다. 따라서 저장소를 내 것과 동기화 된 상태로 유지하려면 아래 단계를 따르십시오.
#### [여러분이 포크한 저장소와 싱크상태 유지하기](keeping-your-fork-synced-with-this-repository.ko.md)
docs/additional-material/translations/Korean/resolving-merge-conflicts.ko.md
+43
View File
@@ -0,0 +1,43 @@
# 병합 충돌이 무엇인가요?
여러분이 또 다른 브랜치에서 현재 작업중인 브랜치로 병합하고자할 때, 또 다른 변경사항들도 같이 반영되어야 하므로 여러분의 현재 작업중인 파일들에 같이 결합이 이루어지게 됩니다.
만일 이때 두 사람이 같은 파일의 똑 같은 라인을 (각자 다르게)변경했거나 다른 사람이 수정 반영한 곳을 삭제하려고 한다면 Git은 어느 변경사항이 옳은 것인지 쉽게 판단할 수 없습니다.
이때 Git은 여러분 스스로 이 문제를 반드시 해결하도록 충돌이 있음을 파일에 표시합니다.
# 병합 충돌은 어떻게 해결하나요?
병합 충돌이 발생하면 Git은 문제가 되는 부분에 “<<<<<<<< HEAD” 와 “>>>>>>>>>>[other branch name]” 으로 감싸서 표시합니다.
이때 여러분이 현재 작업중인 브랜치가 먼저 표기됩니다. 꺽쇠기호 뒤를 보면 어느 브랜치에서 변경사항이 반영되었는지 알 수 있습니다.
"=======" 기호는 충돌이 발생한 부분을 각각 구분해줍니다.
여러분이 해야할 일은 바로 위와 같은 충돌표시들을 원하는 코드만 보이도록 깨끗하게 정리하는 것입니다.
따라서 충돌을 발생케한 여러분의 동료와 어느 변경사항이 옳은 것인지 서로 이야기를 나눠야합니다.
여러분의 변경사항이 옳을 수도 있고 그렇지 않을 수도 있습니다. 아니면 양자 모두의 변경사항을 합쳐야만 하는 경우도 있을 수 있겠죠.
예시:
```
<<<<<<< HEAD:mergetest
This is my third line
=======
This is a fourth line I am adding
>>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest
```
<<<<<<<: 병합 충돌이 시작되는 곳을 표시합니다. 여러분이 병합하고자하는 변경한 라인들로 이루어진 부분이 첫번째로 표기됩니다.
=======: 비교하기 위한 구분선을 나타냅니다. 쉽게 차이를 파악할 수 있도록 사용자가 커밋한 변경사항(위)과 병합을 위해 로드된 부분(아래)으로 구분되어 있습니다.
>>>>>>>: 병합 충돌이 발생한 마지막 위치를 표시합니다.
Git에서 병합하는 것에 문제가 있는 부분을 일일이 수작업으로 편집해서 병합하면서 충돌문제를 해결합니다.
이는 여러분의 수정사항을 삭제하거나 다른 누군가의 변경사항을 지우는 일이며 또는 이 두 부분을 하나로 합치는 것을 의미합니다.
그리고 해당 파일에서 '<<<<<<<', '=======', 그리고 '>>>>>>>'을 지워야합니다.
일단 충돌을 해결했다면 `git add`를 실행합니다.
아울러 충돌이 올바르게 해결되었는지 확인하기 위해 반드시 테스트를 수행하는 것을 잊지마십시요.
병합 충돌을 보다 쉽게 해결하려면 여러분이 사용하는 각각의 IDE에 맞는 적절한 플러그인을 다운로드 받아 설치하세요.
# 병합을 어떻게 되돌리나요?
병합을 취소하려면 `git merge —abort` 명령을 실행하세요.
docs/additional-material/translations/Korean/reverting-a-commit.ko.md
+35
View File
@@ -0,0 +1,35 @@
## 커밋 되돌리기
커밋을 되돌리려면 이전 커밋에서 수행 된 모든 변경 사항을 취소하는 새로운 커밋을 만드는 것입니다. 그것은 git에서 ```CTRL + Z ``` 를 실행하는 것과 같습니다.
원격 저장소에 푸시하는 모든 커밋에는 SHA(Secure Hash Algorithm)라고 하는 고유한 알파벳 키가 있으므로 git에서 되돌리기가 쉬워집니다. 즉, SHA를 사용하는 한 언제든지 커밋을 되돌릴 수 있습니다. 하지만 그렇게 하면, 당신의 저장소가 엉망이 되지 않도록 조심스럽게 순서대로 배열해야 합니다.
실행 취소하려는 특정 커밋의 SHA를 선택하려면 지금까지 작성한 모든 커밋의 로그가 도움이 될 것입니다.
이를 위해 다음 명령을 실행합니다:
```git log --oneline ```
```git log``` 명령만 실행하면 SHA(긴 형식)을 얻을 수 있지만 ```--oneline ``` 플래그를 사용하면 보다 가독성이 좋은(한줄) 방식으로 표시할 수 있습니다.
이 명령을 실행할 때 표시되는 첫번째 7개의 문자는 축약 커밋 해시라고 합니다.
예를 들어, 이 저장소에서 ```git log --oneline ``` 을 실행하면 다음과 같은 결과를 얻을 수 있습니다:
For example, here is what I get when I run ```git log --oneline ``` on this repository:
```
389004d added spacing in title
c1b9fc1 Merge branch 'master' into tutorials
77eaafd added tutorial for reverting a commit
```
따라서 ```git log --oneline``` 을 사용하면 SHA의 처음 7개의 문자와 함께 저장소에서 작성한 모든 커밋 목록을 가져올 수 있습니다.
이제 "added spacing in title"에 대한 커밋을 취소하고 싶다고 가정하고, 다음 단계를 수행하겠습니다.
* 커밋의 SHA를 복사합니다. 여기서는 ```389004d``` 입니다.
* 그리고 나서 ```git revert 389004d``` 명령을 싱행합니다.
이렇게 하면 텍스트 편집기가 열리고 커밋 메시지를 편집하라는 메시지가 표시됩니다. 커밋 메시지를 `Revert` 라는 단어로 시작하는 기본 git 메시지로 남겨두거나 원하는대로 메시지를 작성할 수도 있습니다.
* 다음으로, 텍스트 편집기를 저장하고 닫습니다.
* 커맨드 라인으로 돌아갑니다.
* ```git push origin <branch-name>``` 을 실행하여 되돌린 변경사항을 Github에 푸시하십시오.
그리고 바로 변경사항이 원상태로 돌아갈 것입니다. 이 경우에 저장소가 ```c1b9fc1``` 의 상태로 되돌아갑니다.
docs/additional-material/translations/Korean/undoing-a-commit.ko.md
+59
View File
@@ -0,0 +1,59 @@
## 로컬 커밋 되돌리기
로컬에서 커밋을 위해 스테이징 영역에 추가한 작업 내용을 되돌리기 위해서는 다음 명령을 실행합니다.
```
git reset
```
위 명령어는 수정한 코드가 반영된 스테이징 영역을 가장 최근에 반영한 커밋상태로 되돌립니다.
하지만 여러분의 작업 디렉토리에 수정한 내용들은 변경되지 않습니다. 따라서 여러분이 수정한 소스를 다시 커밋할 수 있습니다.
만일 이미 스테이징 영역에 반영된 수정한 파일들 중에서 하나의 파일만 커밋에서 제거하기를 원할 경우, 아래 명령을 실행합니다.
```
git reset <file>
```
이 명령어는 스테이징 영역에서 해당 파일만 제거합니다. 그러나 작업 디렉토리에는 변경된 파일 상태 그대로 남아 있습니다.
다음은 ```git reset``` 사용법에 관한 예제입니다.
```
# 먼저 index.php 와 tutorial.php 파일을 수정합니다.
# 스테이징 영역에 파일을 추가합니다.
$ git add .
# 두 파일을 각각 커밋해야하므로
# tutorial.php 파일을 스테이징 영역에서 제거합니다.
$ git reset tutorial.php
# index.php 파일을 먼저 커밋합니다.
$ git commit -m "Changed index.php"
# 다음으로 tutorial.php 파일을 커밋합니다.
$ git add tutorial.php
$ git commit -m "Changed tutorial.php"
```
로컬 저장소에 문제가 생겨 여러분의 코드를 마지막 커밋 상태로 모두 되돌리고 싶다면 아래 명령을 실행할 수 있습니다.
```
git reset --hard
```
이 명령어는 스테이징 영역을 마지막 커밋 상태로 되돌리는 것 뿐만 아니라 여러분의 로컬에 변경된 파일도 되돌릴 수 있습니다.
```--hard``` 모드는 Git으로 하여금 작업 디렉토리에 대한 변경들도 되돌릴 수 있도록 합니다.
따라서 로컬에서 개발한 모든 개발 내용을 초기화해도 되는지 반드시 확인 후 실행하셔야 합니다.
다음은 ```git reset --hard``` 사용에 관한 예제입니다.
```
# 엉뚱한 실험을 시작하기로 결정했습니다.
# 먼저 'crazy.php' 파일을 만들고 코드를 추가합니다.
# 그리고 crazy.php 파일을 커밋합니다.
$ git add crazy.php
$ git commit -m "Started a crazy dev"
# crazy.php 파일을 다시 수정하고 기타 여러 파일들을 생성하고 수정합니다.
# 그리고 수정한 모든 파일을 스테이징 영역에 추가하고 커밋합니다.
$ git add .
$ git commit -m "Continued dev"
# 테스트하고 마칩니다.
# 실험하기 전 상태로 되돌리기 위해 모든 수정사항을 제거합니다.
$ git reset --hard HEAD~2
```
```git reset --hard HEAD~2``` 명령어는 현재 브랜치에서 여러분이 수정한 이전의 커밋들 중에 2번째 커밋 포인트 상태로 이동함과 동시에 해당 커밋들에 대한 변경사항들이 이전 상태로 복구됩니다. 그리고 프로젝트 히스토리에서 이전에 추가된 2개의 스냅샷이 제거됩니다.
P.s. 만일 여러분의 공유 저장소로 이미 push를 완료한 상태에서 ```git reset --hard``` 명령을 실행할 경우, 해당 저장소를 사용하는 모든 사람들에게 문제를 일으킬 수 있으므로 절대 실행해서는 안됩니다.
docs/additional-material/translations/Malayalam/Things-a-non-programmer-can-do.ml.md
+123
View File
@@ -0,0 +1,123 @@
# പ്രോഗ്രാമർ അല്ലാത്ത ഒരാൾക്ക് ചെയ്യാൻ കഴിയുന്ന കാര്യങ്ങൾ
## ശ്രദ്ധിക്കാൻ തുടങ്ങുക
ഓപ്പൺ സോഴ്‌സിലെ എല്ലാം മറ്റുള്ളവരെ ഉൾക്കൊള്ളുന്നു.
നിങ്ങൾ ഒരു ടീമിൽ ചേരാൻ നോക്കുകയാണ്, അതിനർത്ഥം കമ്മ്യൂണിറ്റിയെക്കുറിച്ചും അത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും മനസ്സിലാക്കുക എന്നാണ്.
ഒരു പ്രോജക്‌റ്റിലേക്ക് ചെന്ന് "ഹായ്, ഈ പ്രോജക്‌റ്റ് ഇങ്ങനെ പ്രവർത്തിക്കണം എന്നാണു ഞാൻ കരുതുന്നത് " എന്ന് പറയുന്നത് ഒരു നല്ല കാര്യമായി കണക്കാക്കില്ല.
ചില പ്രോജക്‌റ്റുകൾ അത്തരം സമീപനത്തെ സ്വാഗതം ചെയ്‌തേക്കാം, എന്നാൽ പ്രോജക്‌റ്റ് കുറച്ച് കാലമായി പ്രവർത്തിക്കുന്നതാണെങ്കിൽ , അങ്ങനെ ഒരു മനോഭാവം സ്വീകരിക്കാനുള്ള സാധ്യത കുറവാണു . **പ്രോജക്റ്റിന് എന്താണ് വേണ്ടതെന്ന് അറിയാനുള്ള ഏറ്റവും നല്ല മാർഗം ശ്രദ്ധിച്ചു കേൾക്കുക എന്നതാണ് .**
1. **ഒരു മെയിലിംഗ് ലിസ്റ്റിൽ ചേരുക**: പല പ്രോജക്‌റ്റുകൾക്കും, പ്രോജക്‌റ്റിൻ്റെ വികസനത്തെക്കുറിച്ചുള്ള ആശയവിനിമയത്തിൻ്റെ പ്രധാന മാർഗമാണ് മെയിലിംഗ് ലിസ്റ്റ്.
വലിയ പ്രോജക്റ്റുകളിൽ, തിരഞ്ഞെടുക്കാൻ നിരവധി മെയിലിംഗ് ലിസ്റ്റുകൾ ഉണ്ട്.
ഉദാഹരണത്തിന്, PostgreSQL പ്രോജക്റ്റിന് അതിൻ്റെ മെയിലിംഗ് ലിസ്റ്റ് പേജിൽ 12 ഉപയോക്തൃ-അധിഷ്ഠിത ലിസ്റ്റുകളും ആറ് ഡെവലപ്പർ ലിസ്റ്റുകളും ഉണ്ട്.
പ്രധാന ഉപയോക്തൃ-അധിഷ്‌ഠിത ലിസ്‌റ്റും പ്രധാന ഡെവലപ്പർ ലിസ്റ്റും പിന്തുടരാനാണു ഞാൻ നിർദേശിക്കുന്നത് .
2. **ഒരു ബ്ലോഗ് പിന്തുടരുക**: കോർ ഡെവലപ്പർമാർ പരിപാലിക്കുന്ന ബ്ലോഗുകൾ ഭാവിയിലെ റിലീസുകളിൽ വരാനിരിക്കുന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ പലപ്പോഴും നൽകുന്നു,
അവിടെ എത്താൻ എന്തൊക്കെ ചെയ്തുവെന്നും . പ്രൊജെക്ടുമായി ബന്ധപ്പെട്ട നിരവധി ഉറവിടങ്ങളിൽ നിന്നുള്ള വാർത്തകളും ബ്ലോഗ് എൻട്രികളും ഒരു പ്ലാനറ്റ് സൈറ്റ് സമാഹരിക്കുന്നു.
planet.gnome.org അല്ലെങ്കിൽ planet.mysql.com പോലുള്ള ഒരു പ്ലാനറ്റ് സൈറ്റ് ഉണ്ടെങ്കിൽ, അവിടെ ആരംഭിക്കുക. "planet <projectname>" എന്നതിനായി ഗൂഗിളിൽ തിരയുക.
3. **ഒരു IRC ചാനലിൽ ചേരുക**: പല ഓപ്പൺ സോഴ്‌സ് പ്രോജക്‌റ്റുകൾക്കും സമർപ്പിത ഇൻ്റർനെറ്റ് റിലേ ചാറ്റ് (IRC) ചാനലുകൾ ഉണ്ട്, അവിടെ ഡവലപ്പർമാരും ഉപയോക്താക്കളും പ്രശ്‌നങ്ങളും വികസനവും ചർച്ചചെയ്യുന്നു.
ചാനലിനെ എന്താണ് വിളിക്കുന്നതെന്നും അത് ഏത് ഐആർസി നെറ്റ്‌വർക്കിലാണെന്നും വിശദാംശങ്ങൾക്കായി പ്രോജക്റ്റിൻ്റെ വെബ്‌സൈറ്റ് പരിശോധിക്കുക.
**ടിക്കറ്റുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുക**
ഏതൊരു ഓപ്പൺ സോഴ്‌സ് പ്രോജക്റ്റിൻ്റെയും ഹൃദയമാണ് കോഡ്, എന്നാൽ കോഡ് എഴുതുന്നത് സംഭാവന നൽകാനുള്ള ഏക മാർഗമാണെന്ന് കരുതരുത്.
പുതിയ സവിശേഷതകൾ സൃഷ്ടിക്കുന്നതിനും ബഗുകൾ പരിഹരിക്കുന്നതിനുമുള്ള തിരക്കിൽ കോഡിൻ്റെ പരിപാലനവും കോഡിന് ചുറ്റുമുള്ള സിസ്റ്റങ്ങളും പലപ്പോഴും അവഗണിക്കപ്പെടുന്നു.
ഒരു പ്രോജക്റ്റിലേക്ക് നിങ്ങളുടെ കാൽ എത്തിക്കുന്നതിനുള്ള എളുപ്പമാർഗ്ഗമായി ഈ മേഖലകൾ നോക്കുക.
മിക്ക പ്രോജക്റ്റുകൾക്കും പൊതുവായി കാണാവുന്ന ട്രബിൾ ടിക്കറ്റ് സംവിധാനമുണ്ട്, അത് പ്രോജക്റ്റിൻ്റെ വെബ്‌സൈറ്റിൻ്റെ മുൻ പേജിൽ നിന്ന് ലിങ്ക് ചെയ്‌ത് ഡോക്യുമെൻ്റേഷനിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.
ഉപയോക്താക്കളും ഡെവലപ്പർമാരും തമ്മിലുള്ള ആശയവിനിമയത്തിൻ്റെ പ്രാഥമിക മാർഗമാണിത്. അത് പുതുക്കി നിലനിർത്തുന്നത് പ്രോജെക്ടിനെ സഹായിക്കാനുള്ള മികച്ച മാർഗമാണ്.
ടിക്കറ്റിംഗ് സമ്പ്രദായത്തിൽ , നിങ്ങൾക്ക് പ്രത്യേക അനുമതികൾ ആവശ്യമായി വന്നേക്കാം, ടിക്കറ്റുകൾ വൃത്തിയാക്കാൻ സഹായിക്കണമെന്ന് നിങ്ങൾ പറയുമ്പോൾ , മിക്ക പ്രൊജക്‌റ്റ് നേതാക്കളും നിങ്ങൾക്ക് അനുമതി നൽകുന്നതിൽ സന്തോഷിക്കും.
4. **ഒരു ബഗ് ഡയഗ്നോസ് ചെയ്യുക**: ബഗുകൾ പലപ്പോഴും മോശമായി റിപ്പോർട്ട് ചെയ്യപ്പെടുന്നു.
ഒരു ബഗ് കണ്ടുപിടിക്കുന്നതും പരീക്ഷിക്കുന്നതും പ്രശ്നത്തിൻ്റെ പ്രത്യേകതകൾ കണ്ടെത്തുന്നതിനുള്ള ലെഗ് വർക്ക് ഉപയോഗിച്ച് ഡവലപ്പർമാരുടെ സമയം ലാഭിക്കാൻ സഹായിക്കും.
"ഞാൻ X ചെയ്യുമ്പോൾ സോഫ്‌റ്റ്‌വെയർ പ്രവർത്തിക്കുന്നില്ല" എന്ന് ഒരു ഉപയോക്താവ് റിപ്പോർട്ട് ചെയ്‌താൽ, ആ പ്രശ്‌നത്തിൻ്റെ പ്രത്യേകതകൾ മനസിലാക്കാൻ കുറച്ച് സമയം ചെലവഴിക്കുക.
ഇത് ആവർത്തിച്ചുള്ളതാണോ? ആവർത്തിച്ച് പ്രശ്‌നമുണ്ടാക്കാൻ നിങ്ങൾക്ക് ഒരു കൂട്ടം ഘട്ടങ്ങൾ സൃഷ്ടിക്കാനാകുമോ? ഒരു ബ്രൗസറിൽ മാത്രം സംഭവിക്കുന്നത് മറ്റൊന്നല്ല, അല്ലെങ്കിൽ ഒരു ഡിസ്ട്രോ എന്നാൽ മറ്റൊന്ന് അല്ലാത്തത് പോലെയുള്ള പ്രശ്നം നിങ്ങൾക്ക് ചുരുക്കാനാകുമോ?
പ്രശ്‌നത്തിൻ്റെ കാരണം എന്താണെന്ന് നിങ്ങൾക്കറിയില്ലെങ്കിൽപ്പോലും, സാഹചര്യങ്ങൾ ചുരുക്കാൻ നിങ്ങൾ നടത്തുന്ന പരിശ്രമം അത് പരിഹരിക്കുന്നത് മറ്റൊരാൾക്ക് എളുപ്പമാക്കുന്നു.
നിങ്ങൾ കണ്ടെത്തുന്നതെന്തും, എല്ലാവർക്കും കാണുന്നതിനായി ബഗ് സിസ്റ്റത്തിലെ ടിക്കറ്റിൽ ചേർക്കുക.
5. **ഫിക്സഡ് ബഗുകൾ അടയ്ക്കുക**: പലപ്പോഴും ബഗുകൾ കോഡ്ബേസിൽ പരിഹരിച്ചിട്ടുണ്ടെങ്കിലും അവയെക്കുറിച്ച് റിപ്പോർട്ട് ചെയ്യുന്ന ടിക്കറ്റുകൾ ടിക്കറ്റിംഗ് സിസ്റ്റത്തിൽ അപ്ഡേറ്റ് ചെയ്യപ്പെടില്ല.
ഈ ക്രാഫ്റ്റ് വൃത്തിയാക്കുന്നത് സമയമെടുക്കും, പക്ഷേ ഇത് മുഴുവൻ പ്രോജക്റ്റിനും വിലപ്പെട്ടതാണ്.
ഒരു വർഷത്തിലേറെ പഴക്കമുള്ള ടിക്കറ്റുകൾക്കായുള്ള ടിക്കറ്റ് സംവിധാനം അന്വേഷിച്ച് ആരംഭിക്കുക, ബഗ് ഇപ്പോഴും നിലവിലുണ്ടോ എന്ന് നോക്കുക.
ബഗ് പരിഹരിച്ചിട്ടുണ്ടോ എന്നും അത് അടയ്ക്കാൻ കഴിയുമോ എന്നും അറിയാൻ പ്രോജക്റ്റിൻ്റെ റിലീസ് മാറ്റ ലോഗ് പരിശോധിക്കുക.
അത് പരിഹരിച്ചതായി അറിയാമെങ്കിൽ, ടിക്കറ്റിലെ പതിപ്പ് നമ്പർ ശ്രദ്ധിക്കുകയും അത് അടയ്ക്കുകയും ചെയ്യുക.
സോഫ്റ്റ്‌വെയറിൻ്റെ ഏറ്റവും പുതിയ പതിപ്പ് ഉപയോഗിച്ച് ബഗ് പുനഃസൃഷ്ടിക്കാൻ ശ്രമിക്കുക.
ഏറ്റവും പുതിയ പതിപ്പ് ഉപയോഗിച്ച് ഇത് പുനർനിർമ്മിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, അത് ടിക്കറ്റിൽ ശ്രദ്ധിക്കുകയും അത് അടയ്ക്കുകയും ചെയ്യുക.
അത് ഇപ്പോഴും നിലവിലുണ്ടെങ്കിൽ, ടിക്കറ്റിൽ അത് ശ്രദ്ധിക്കുകയും തുറന്നിടുകയും ചെയ്യുക.
കോഡ് ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നു
എല്ലാ അനുഭവ തലങ്ങളിലുമുള്ള പ്രോഗ്രാമർമാർക്ക് പ്രോജക്റ്റിലെ കോഡ് ഉപയോഗിച്ച് സഹായിക്കാനാകും.
നിങ്ങളുടെ പ്രിയപ്പെട്ട പ്രോജക്റ്റിലേക്ക് യഥാർത്ഥ സംഭാവനകൾ നൽകാൻ നിങ്ങൾ ഒരു കോഡിംഗ് ജീനിയസ് ആയിരിക്കണമെന്ന് കരുതരുത്.
നിങ്ങളുടെ ജോലിയിൽ കോഡിലെ മാറ്റം ഉൾപ്പെടുന്നുവെങ്കിൽ, സംഭാവകരിൽ നിന്ന് കോഡ് ലഭിക്കുന്നതിന് പ്രോജക്റ്റ് ഉപയോഗിക്കുന്ന രീതി അന്വേഷിക്കുക.
ഓരോ പ്രോജക്ടിനും അതിൻ്റേതായ വർക്ക്ഫ്ലോ ഉണ്ട്, അതിനാൽ നിങ്ങൾ കോഡ് സമർപ്പിക്കുന്നതിന് മുമ്പ് അത് എങ്ങനെ ചെയ്യണമെന്ന് ചോദിക്കുക.
ഉദാഹരണത്തിന്, PostgreSQL പ്രോജക്റ്റ് അതിൻ്റെ പ്രക്രിയയിൽ വളരെ കർക്കശമാണ്: കോഡ് പരിഷ്ക്കരണങ്ങൾ ഒരു മെയിലിംഗ് ലിസ്റ്റിലേക്ക് പാച്ച് രൂപത്തിൽ അയയ്‌ക്കുന്നു, അവിടെ പ്രധാന ഡെവലപ്പർമാർ മാറ്റത്തിൻ്റെ എല്ലാ വശങ്ങളും സൂക്ഷ്മമായി പരിശോധിക്കുന്നു. മറുവശത്ത് പാരറ്റ് പോലെയുള്ള ഒരു പ്രോജക്റ്റ് ഉണ്ട്, അവിടെ കോഡ്ബേസിലേക്ക് കമ്മിറ്റ് പ്രിവിലേജുകൾ ലഭിക്കുന്നത് എളുപ്പമാണ്. പ്രോജക്റ്റ് GitHub ഉപയോഗിക്കുന്നുവെങ്കിൽ, GitHub-ൻ്റെ പുൾ അഭ്യർത്ഥന സവിശേഷത ഉപയോഗിക്കുന്ന ഒരു വർക്ക്ഫ്ലോ ഉണ്ടായിരിക്കാം. എല്ലാ പ്രോജെക്ടറും വൈവിധ്യമേറിയതാണ് .
നിങ്ങൾ കോഡ് പുതുക്കുമ്പോഴെല്ലാം , കമ്മ്യൂണിറ്റിയുടെ ഉത്തരവാദിത്തമുള്ള ഒരു അംഗമായി നിങ്ങൾ പ്രവർത്തിക്കുന്നുവെന്നും ബാക്കി കോഡ്‌ബേസുമായി പൊരുത്തപ്പെടുന്നതിന് നിങ്ങളുടെ കോഡ് ശൈലി നിലനിർത്തുന്നുവെന്നും ഉറപ്പാക്കുക. നിങ്ങൾ ചേർക്കുന്നതോ പരിഷ്ക്കരിക്കുന്നതോ ആയ കോഡ് ബാക്കിയുള്ളത് പോലെയായിരിക്കണം. ബ്രേസിംഗ് ശൈലിയോ ഇന്റേൺഡേഷൻ സ്‌പെയ്‌സുകൾ കൈകാര്യം ചെയ്യുന്നതോ ആയ രീതി നിങ്ങൾക്ക് ഇഷ്ടപ്പെട്ടേക്കില്ല.എന്തിരുന്നാലും ആ സ്റ്റാൻഡേർഡുകളുമായി ഒത്തുചേരാത്ത കോഡ് സമർപികുനത് വളരെ അധികം മോശമായ ഒരു കാര്യം ആണ് . "എനിക്ക് നിന്റെ രീതികൾ ഇഷ്ടമല്ല,എന്റെ രീതികൾ ആണ് നല്ലത്,അതുകൊണ്ട് ഞാൻ ചെയുന്ന പോലെ ചെയുക" എന്ന് പറയുന്നത് പോലെ തന്നെ ആണ് ഇതും .
6. **ഒരു ബീറ്റാ അഥവാ റീലീസ് ക്യാൻഡിഡേറ്റ് നെ പരീക്ഷിക്കുക**: ഒന്നിലധികം പ്ലാറ്റ്‌ഫോമുകളിൽ പ്രവർത്തിക്കാൻ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന ഏതൊരു പ്രോജക്റ്റിനും എല്ലാത്തരം പോർട്ടബിലിറ്റി പ്രശ്‌നങ്ങളും ഉണ്ടാകാം.
ഒരു റിലീസ് സമീപിക്കുകയും ഒരു ബീറ്റ അല്ലെങ്കിൽ റിലീസ് കാൻഡിഡേറ്റ് പ്രസിദ്ധീകരിക്കുകയും ചെയ്യുമ്പോൾ, അത് പല പ്ലാറ്റ്‌ഫോമുകളിൽ നിരവധി ആളുകൾ പരീക്ഷിക്കുമെന്ന് പ്രോജക്റ്റ് ലീഡർ പ്രതീക്ഷിക്കുന്നു.
നിങ്ങൾക്ക് അത്തരം ആളുകളിൽ ഒരാളാകാനും നിങ്ങളുടെ പ്ലാറ്റ്‌ഫോമിൽ പാക്കേജ് പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാനും സഹായിക്കാനാകും.
സാധാരണയായി നിങ്ങൾ സോഫ്റ്റ്‌വെയർ ഡൗൺലോഡ് ചെയ്യാനും നിർമ്മിക്കാനും പരിശോധിക്കാനും മാത്രമേ ആവശ്യമുള്ളൂ, എന്നാൽ നിങ്ങൾ അസാധാരണമായ വിതരണത്തിലോ ഹാർഡ്‌വെയറിലോ ആണെങ്കിൽ പ്രോജക്റ്റിൻ്റെ മൂല്യം വളരെ വലുതായിരിക്കും.
ബിൽഡ്, ടെസ്റ്റ് വർക്കുകൾ എന്നിവ റിപ്പോർട്ട് ചെയ്യുന്നത്, വരാനിരിക്കുന്ന റിലീസ് ദൃഢമാണെന്ന് പ്രോജക്റ്റ് ലീഡർമാരെ അറിയാൻ സഹായിക്കുന്നു.
7. **ഒരു ബഗ് പരിഹരിക്കുക**: സാധാരണയായി ഇവിടെയാണ് കോഡ് ആരംഭിക്കാൻ ആഗ്രഹിക്കുന്ന സഹകാരികൾ.
ഇത് ലളിതമാണ്: ടിക്കറ്റ് സിസ്റ്റത്തിൽ രസകരമായ ഒരു ബഗ് കണ്ടെത്തി കോഡിൽ അത് പരിഹരിക്കാൻ ശ്രമിക്കുക.
ഉചിതമെങ്കിൽ കോഡിൽ തിരുത്തൽ രേഖപ്പെടുത്തുക.
നിങ്ങൾ ഉറപ്പിച്ച കോഡിൻ്റെ സ്പോട്ട് പരിശോധിക്കാൻ ടെസ്റ്റ് സ്യൂട്ടിലേക്ക് ഒരു ടെസ്റ്റ് ചേർക്കുന്നത് നല്ലതാണ്; ചില പ്രോജക്റ്റുകൾക്ക് ടെസ്റ്റുകൾ ഉൾപ്പെടുത്തുന്നതിന് ബഗ് പരിഹരിക്കലുകൾ ആവശ്യമാണ്. അപരിചിതമായ ഈ കോഡ്ബേസിന് ചുറ്റും നോക്കുമ്പോൾ കുറിപ്പുകൾ സൂക്ഷിക്കുക. ബഗ് പരിഹരിക്കാൻ നിങ്ങൾക്ക് കഴിയുന്നില്ലെങ്കിലും, പരിഹരിക്കാനുള്ള ശ്രമത്തിൻ്റെ ഭാഗമായി നിങ്ങൾ കണ്ടെത്തിയ കാര്യങ്ങൾ ടിക്കറ്റിൽ രേഖപ്പെടുത്തുക. നിങ്ങൾ കണ്ടെത്തുന്നത് നിങ്ങളുടെ പിന്നാലെ വരുന്നവരെ സഹായിക്കുന്നു.
8. **ഒരു ടെസ്റ്റ് എഴുതുക**: മിക്ക പ്രോജക്റ്റുകൾക്കും കോഡ് പരിശോധിക്കുന്ന ഒരു ടെസ്റ്റ് സ്യൂട്ട് ഉണ്ട്, എന്നാൽ അതിൽ കൂടുതൽ ടെസ്റ്റുകൾ ചേർക്കാൻ കഴിയാത്ത ഒരു ടെസ്റ്റ് സ്യൂട്ട് സങ്കൽപ്പിക്കാൻ പ്രയാസമാണ്.
ടെസ്റ്റ് സ്യൂട്ട് പരിശോധിക്കാത്ത സോഴ്‌സ് കോഡിലെ ഏരിയകൾ തിരിച്ചറിയാൻ, C-നുള്ള gcov അല്ലെങ്കിൽ Devel::Cover-നുള്ള ഒരു ടെസ്റ്റ് കവറേജ് ടൂൾ ഉപയോഗിക്കുക.
തുടർന്ന്, അത് മറയ്ക്കാൻ സ്യൂട്ടിലേക്ക് ഒരു ടെസ്റ്റ് ചേർക്കുക.
9. **ഒരു കംപൈലർ മുന്നറിയിപ്പ് നിർത്തലാക്കുക**: പല സി-അധിഷ്‌ഠിത പ്രോജക്‌റ്റുകൾക്കായുള്ള ബിൽഡ് പ്രോസസ്സ് പലപ്പോഴും വിചിത്രമായ കംപൈലർ മുന്നറിയിപ്പ് ഫ്ലാഗ് സ്‌ക്രീനിലേക്ക് തുപ്പുന്നു.
ഈ മുന്നറിയിപ്പുകൾ സാധാരണയായി ഒരു പ്രശ്നത്തിൻ്റെ സൂചകങ്ങളല്ല, പക്ഷേ അവയ്ക്ക് അത് പോലെ കാണാനാകും.
വളരെയധികം മുന്നറിയിപ്പുകൾ ഉള്ളത് അരൗചകം ആണ് .
കോഡ് യഥാർത്ഥത്തിൽ ഒരു ബഗ് ഉണ്ടോ എന്ന് പരിശോധിക്കുക. ഇല്ലെങ്കിൽ, ഉറവിടത്തെ നിശബ്ദമാക്കുന്ന ഈ തെറ്റായ പോസിറ്റീവുകൾ മറയ്ക്കാൻ സഹായിക്കുന്നു.
10. **ഒരു കമന്റ് ചേർക്കുക**:
നിങ്ങൾ കോഡ് പരിശോധിക്കുമ്പോൾ, ആശയക്കുഴപ്പമുണ്ടാക്കുന്ന ചില സ്ഥലങ്ങൾ നിങ്ങൾ കണ്ടെത്തിയേക്കാം.
നിങ്ങൾ ആശയക്കുഴപ്പത്തിലാണെങ്കിൽ, മറ്റുള്ളവരും അങ്ങനെയാകാൻ സാധ്യതയുണ്ട്. അവ കോഡിൽ രേഖപ്പെടുത്തി ഒരു പാച്ച് സമർപ്പിക്കുക.
ഡോക്യുമെൻ്റേഷനുമായി പ്രവർത്തിക്കുക
ഡോക്യുമെൻ്റേഷൻ സാധാരണയായി ഒരു പ്രോജക്റ്റിൻ്റെ ഭാഗമാണ്, അത് ഷോർട്ട് ഷ്രിഫ്റ്റ് ലഭിക്കുന്നു.
ആരുടെയെങ്കിലും കണ്ണിലൂടെ അതിൽ പ്രവേശിക്കുന്നതിനുപകരം, പ്രോജക്റ്റുമായി പരിചയമുള്ളവരുടെ വീക്ഷണകോണിൽ നിന്ന് എഴുതിയതും ഇത് കഷ്ടപ്പെടാം.
നിങ്ങൾ എപ്പോഴെങ്കിലും ഒരു പ്രോജക്‌റ്റിനായി ഡോക്‌സ് വായിച്ചിട്ടുണ്ടെങ്കിൽ, "ഈ മാനുവൽ പ്രതീക്ഷിക്കുന്നത് പോലെയാണ് എനിക്ക് പാക്കേജ് എങ്ങനെ ഉപയോഗിക്കണമെന്ന് ഇതിനകം അറിയാമെന്ന്", ഞാൻ എന്താണ് സംസാരിക്കുന്നതെന്ന് നിങ്ങൾക്കറിയാം.
പ്രൊജക്‌റ്റിനോട് അടുപ്പമുള്ളവർ ശ്രദ്ധിക്കാത്ത ഡോക്യുമെൻ്റേഷനിലെ പോരായ്മകൾ പലപ്പോഴും ഒരു കൂട്ടം പുതിയ കണ്ണുകൾക്ക് ചൂണ്ടിക്കാണിക്കാൻ കഴിയും.
11. **ഒരു ഉദാഹരണം സൃഷ്‌ടിക്കുക**: വളരെയധികം ഉദാഹരണങ്ങളുള്ള ഒരു പ്രോജക്‌റ്റും ഇല്ല.
അതൊരു വെബ് API ആയാലും, ദിനചര്യകളുടെ ഒരു ലൈബ്രറി ആയാലും, Gimp പോലെയുള്ള GUI ആപ്പ് ആയാലും അല്ലെങ്കിൽ ഒരു കമാൻഡ് ലൈൻ ടൂളായാലും,
ശരിയായ ഉപയോഗത്തിൻ്റെ നല്ല ഉദാഹരണം ഡോക്യുമെൻ്റേഷൻ്റെ പേജുകളേക്കാൾ കൂടുതൽ വ്യക്തമായും വേഗത്തിലും സോഫ്റ്റ്വെയറിൻ്റെ ശരിയായ ഉപയോഗം വിശദീകരിക്കാൻ കഴിയും.
ഒരു API അല്ലെങ്കിൽ ലൈബ്രറിക്ക്, ഉപകരണം ഉപയോഗിക്കുന്ന ഒരു ഉദാഹരണ പ്രോഗ്രാം സൃഷ്ടിക്കുക. നിങ്ങൾ എഴുതിയ കോഡിൽ നിന്ന് പോലും ഇത് എക്‌സ്‌ട്രാക്‌റ്റ് ചെയ്‌തേക്കാം, അവശ്യസാധനങ്ങൾക്കായി ട്രിം ചെയ്യുക.
ഒരു ഉപകരണത്തിന്, നിങ്ങളുടെ ദൈനംദിന ജീവിതത്തിൽ നിങ്ങൾ അത് എങ്ങനെ ഉപയോഗിച്ചു എന്നതിൻ്റെ യഥാർത്ഥ ലോക ഉദാഹരണങ്ങൾ കാണിക്കുക. നിങ്ങൾ കാഴ്ച്ചാധിഷ്ഠിതനാണെങ്കിൽ,
ആപ്ലിക്കേഷൻ എങ്ങനെ ഇൻസ്റ്റാൾ ചെയ്യാം എന്നതുപോലുള്ള ഒരു പ്രധാന പ്രക്രിയയുടെ സ്ക്രീൻ ക്യാപ്ചർ സൃഷ്ടിക്കുന്നത് പരിഗണിക്കുക.
കമ്മ്യൂണിറ്റിയുമായി പ്രവർത്തിക്കുക
ഓപ്പൺ സോഴ്‌സ് ഭാഗികമായി കോഡിനെക്കുറിച്ചാണ്. കമ്മ്യൂണിറ്റി ഓപ്പൺ സോഴ്‌സ് വർക്ക് ചെയ്യുന്നു. അത് കെട്ടിപ്പടുക്കാൻ നിങ്ങളെ സഹായിക്കുന്ന വഴികൾ ഇതാ.
12. **ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുക**: സമൂഹത്തെ കെട്ടിപ്പടുക്കാൻ സഹായിക്കുന്നതിനുള്ള ഏറ്റവും നല്ല മാർഗം മറ്റുള്ളവരെ സഹായിക്കുക എന്നതാണ്.
ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നത്, പ്രത്യേകിച്ച് തുടക്കക്കാരെ , പ്രോജക്റ്റ് വളരാനും അഭിവൃദ്ധിപ്പെടാനും സഹായിക്കുന്നതിന് അത് നിർണായകമാണ്.
ഒരു തുടക്കക്കാരനെ സഹായിക്കാൻ നിങ്ങൾ എടുക്കുന്ന സമയം, അവർ ഒരു ചോദ്യം ചോദിക്കുന്നുണ്ടെങ്കിൽ പോലും, പിനീട് അത് കമ്മ്യൂണിറ്റിക്കു വിലമതിക്കാനാവാത്ത സംഭാവന നൽകുന്ന ഒരാൾ ആയി മാറിയേക്കാം .
13. **ഒരു ബ്ലോഗ് പോസ്റ്റ് എഴുതുക**:
നിങ്ങൾക്ക് ഒരു ബ്ലോഗ് ഉണ്ടെങ്കിൽ, നിങ്ങൾ ഉപയോഗിക്കുന്ന പ്രോജക്റ്റിലെ നിങ്ങളുടെ അനുഭവങ്ങളെക്കുറിച്ച് എഴുതുക.
സോഫ്‌റ്റ്‌വെയർ ഉപയോഗിച്ച് നിങ്ങൾ നേരിട്ട ഒരു പ്രശ്‌നത്തെക്കുറിച്ചും അത് പരിഹരിക്കാൻ നിങ്ങൾ എന്താണ് ചെയ്‌തതെന്നും പറയുക.
നിങ്ങളുടെ ചുറ്റുമുള്ള മറ്റുള്ളവരുടെ മനസ്സിൽ പ്രോജക്റ്റ് നിലനിർത്താൻ സഹായിക്കുന്നതിലൂടെ നിങ്ങൾ രണ്ട് തരത്തിൽ സഹായിക്കും.
ഭാവിയിൽ നിങ്ങളുടെ പ്രശ്‌നമുള്ള മറ്റാരെങ്കിലും ഒരു റെക്കോർഡ് സൃഷ്‌ടിക്കുകയും ഉത്തരത്തിനായി വെബിൽ തിരയുകയും ചെയ്യുക.
(നിങ്ങളുടെ സാങ്കേതിക സാഹസങ്ങളുടെ ഒരു ബ്ലോഗ്, അടുത്ത തവണ നിങ്ങൾ ജോലിക്കായി വേട്ടയാടാൻ പോകുമ്പോൾ, സംശയാസ്‌പദമായ സോഫ്‌റ്റ്‌വെയർ ഉപയോഗിച്ച് യഥാർത്ഥ ലോകാനുഭവം കാണിക്കുന്നതിനുള്ള മികച്ച മാർഗം കൂടിയാണ്.)
14. **ഒരു വെബ്‌സൈറ്റ് മെച്ചപ്പെടുത്തുക**:
നിങ്ങൾക്ക് വെബ് ഡിസൈനിംഗിൽ വൈദഗ്ദ്ധ്യം ഉണ്ടെങ്കിൽ, വെബ്‌സൈറ്റ് മെച്ചപ്പെടുത്താൻ സഹായിക്കുകയും അതുവഴി പ്രോജക്റ്റിൻ്റെ പൊതുജനങ്ങൾ അഭിമുഖീകരിക്കുന്ന ഇമേജ് മെച്ചപ്പെടുത്തുകയും ചെയ്യുന്നുവെങ്കിൽ, അത് നന്നായി ചെലവഴിച്ച സമയം.
ഒരുപക്ഷേ പ്രോജക്റ്റ് തിരിച്ചറിയാൻ ഒരു ഗ്രാഫിക് ഓവർഹോൾ അല്ലെങ്കിൽ ഒരു ലോഗോ ഉപയോഗിച്ചേക്കാം.
ഇത് സമൂഹത്തിൽ ഇല്ലാത്ത കഴിവുകളായിരിക്കാം. എൻ്റെ പ്രോജക്‌റ്റുകളുടെ വെബ്‌സൈറ്റുകളിൽ എന്തെങ്കിലും ഗ്രാഫിക് ഡിസൈൻ സഹായം ലഭിച്ചാൽ എനിക്കത് ഇഷ്ടമാകുമെന്ന് എനിക്കറിയാം.
15. **സാങ്കേതിക ഡോക്യുമെൻ്റേഷൻ എഴുതുക**
ഒരു ആപ്ലിക്കേഷനോ സോഫ്‌റ്റ്‌വെയറോ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് എഴുതാൻ കഴിയുമെങ്കിൽ, അതിനെക്കുറിച്ചുള്ള സാങ്കേതിക ഡോക്യുമെൻ്റേഷൻ നിങ്ങൾക്ക് എഴുതാം. പ്രത്യേകിച്ച് ഓപ്പൺ സോഴ്‌സ് പ്രോജക്‌റ്റുകൾ അപ്‌ഡേറ്റ് ചെയ്യാനോ നവീകരിക്കാനോ വിപുലീകരിക്കാനോ പൊതുജനങ്ങൾക്ക് വായിക്കാൻ സാങ്കേതിക ഡോക്‌സ് സൃഷ്‌ടിക്കാനോ ശ്രമിക്കുന്നു. നിങ്ങൾ പ്ലെയിൻ ഇംഗ്ലീഷിൽ എത്രയധികം എഴുതുന്നുവോ അത്രയും നല്ലത്. ഏറ്റവും നല്ല ഭാഗം, സാങ്കേതിക ഡോക്‌സ് എഴുതാൻ നിങ്ങൾ ഒരു പ്രോഗ്രാമർ ആകണമെന്നില്ല.
എല്ലാറ്റിനുമുപരിയായി, നിങ്ങളുടെ ചുറ്റുമുള്ള ആളുകൾ ചർച്ച ചെയ്യുന്നത് ശ്രദ്ധിക്കുക. നിങ്ങൾക്ക് ഒരു പ്രധാന ആവശ്യം തിരിച്ചറിയാൻ കഴിയുമോ എന്ന് നോക്കുക. ഉദാഹരണത്തിന്, അടുത്തിടെ പാരറ്റ് ഡെവലപ്പർമാരുടെ മെയിലിംഗ് ലിസ്റ്റിൽ, അവരുടെ പഴയ ട്രാക്ക് ഇൻസ്റ്റാളേഷൻ ഉപേക്ഷിച്ച് ട്രബിൾ ടിക്കറ്റ് സിസ്റ്റമായി GitHub ഉപയോഗിക്കാൻ തീരുമാനിച്ചു. ടിക്കറ്റുകൾ GitHub-ൻ്റെ സംവിധാനത്തിലേക്ക് മാറ്റാൻ മാർഗമില്ലാത്തതിനാൽ ചിലർ ഈ നീക്കത്തെ എതിർത്തിരുന്നു. ഒരു ദിവസത്തെ അങ്ങോട്ടുമിങ്ങോട്ടും തർക്കിച്ചതിന് ശേഷം, ഞാൻ പൈപ്പ് ചെയ്തു, "ഞാൻ ഒരു കൺവെർട്ടർ എഴുതിയാൽ എങ്ങനെ?" ആളുകൾ ആശയത്തിൽ ആവേശഭരിതരായി. 450+ ടിക്കറ്റുകൾക്കായി ഒരു കൺവേർഷൻ പ്രോഗ്രാം എഴുതാൻ ഞാൻ സമയം ചെലവഴിച്ചു, അതിനാൽ ഞങ്ങളുടെ ടിക്കറ്റ് ചരിത്രമൊന്നും നഷ്‌ടപ്പെട്ടില്ല. അത് വലിയ വിജയമായിരുന്നു. ഞാൻ ഇടപെട്ടു, പ്രധാന ഡെവലപ്പർമാർ തത്തയിൽ ജോലി ചെയ്യുന്ന ബിസിനസിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചു.
15. **മറ്റുള്ളവരെ പഠിപ്പിക്കുകയും സഹായിക്കുകയും ചെയ്യുക**:
ഒരു വിഷയത്തെക്കുറിച്ച് കൂടുതലറിയാനുള്ള ഏറ്റവും നല്ല മാർഗം അത് പഠിപ്പിക്കാൻ ശ്രമിക്കുക എന്നതാണ്.
സങ്കീർണ്ണമായ കാര്യങ്ങൾ ലളിതമായ ഉദാഹരണങ്ങളിലൂടെ വിശദീകരിക്കാൻ കഴിയുന്നവനാണ് മികച്ച അധ്യാപകൻ. അതിനാൽ നിങ്ങളുടെ പ്രോഗ്രാമിംഗ് ലോകത്തിലെ ഏറ്റവും മികച്ച പഠിതാവാകാനും മികച്ച അധ്യാപകനാകാനും നിങ്ങൾ ശ്രമിക്കേണ്ടതുണ്ട്. മറ്റുള്ളവരെ പഠിപ്പിക്കുന്നത് നിങ്ങളെക്കുറിച്ച് നിങ്ങൾക്ക് കൂടുതൽ മെച്ചമുണ്ടാക്കും കൂടാതെ നിങ്ങളുടെ തൊഴിലിൽ മികച്ച വൈദഗ്ധ്യവും അറിവും നേടാൻ ഇത് നിങ്ങളെ സഹായിക്കും. നിങ്ങൾക്ക് ഒരാളിൽ നിന്ന് സഹായം ലഭിക്കുമ്പോൾ, അത് സ്വയം സൂക്ഷിക്കരുത്, അത് മറ്റുള്ളവരുമായി പങ്കിടുക. ലോകത്തെ ജീവിക്കാനുള്ള മികച്ച സ്ഥലമാക്കി മാറ്റുക.
docs/additional-material/translations/Marathi/Removing-a-file.ma.md
+20
View File
@@ -0,0 +1,20 @@
# गिटमधून फाइल काढून टाकणे
कधीकधी, आपण कुठलीक फाइल गिटमधून काढून टाकायला इच्छिता, परंतु ती आपल्या संगणकावरून काढून टाकायला इच्छित नाही. आपण खालील आदेशाचा वापर करून ती मिळवू शकता:
``git rm <file> --cached``
## तर काय झालं?
Git आता काढून टाकलेल्या फाइलमधील बदलांची ट्रॅकिंग करत नाही. ज्यामुळे Gitला वाटतं, आपण फाइल काढून टाकली आहे. आपल्याला जर आपल्या फाइल सिस्टिममध्ये त्याची स्थिती शोधायची होती, तर आपण पाहील की ती आत्ता तेथी आहे.
यात द्यान द्या की उपरोक्त उदाहरणात, ``--cached`` ध्वज वापरला गेला आहे. जर आपल्याला हे ध्वज जोडण्यात येत नसेल, तर Gitला केवळ रेपोमधून नविन दूरस्थ, तर आपल्या फाइल सिस्टिममध्ये फाइल काढून टाकेल.
जर आप git commit ``-m "Remove file1.js"`` साठी बदल करता आणि हे ``git push origin master`` वापरून दूरस्थ रेपॉजिटरीमध्ये दाखविता तर दूरस्थ रेपॉजिटरी तुमच्या फाइलला काढून टाकेल.
## अतिरिक्त सुविधा
- जर आपल्या अनेक फाइल नकाल करायला इच्छिता, तर आप त्यांची सर्व एकाच कमांडमध्ये समाविष्ट करू शकता:
``git rm file1.js file2.js file3.js --cached``
- तुम्ही वाइल्डकार्ड (*) वापरून एकसारख्या फाइल काढू शकता. उदाहरणार्थ, जर तुम्हाला आपल्या स्थानिक संग्रहामध्ये सर्व .txt फाइल काढू शकता:
``git rm *.txt --cached``
docs/additional-material/translations/Marathi/additional-material.ma.md
+46
View File
@@ -0,0 +1,46 @@
# अतिरिक्त माहिती
येथे आपण असे गृहीत धरू की आपण आधीच मूलभूत सूचनांमध्ये प्रभुत्व मिळवले आहे. पूरक माहितीमध्ये GIT आदेशांबद्दल काही माहिती असते, जी अधिक जटिल परिस्थितींमध्ये आवश्यक असते.
### [कमिटमधील बदल](amending-a-commit.md)
दस्तऐवजात रिमोट रिपॉझिटरीमध्ये कमिट कसे सुधारायचे याबद्दल माहिती आहे.
> तुम्ही पूर्वी केलेली वचनबद्धता बदलायची असेल तेव्हा ते आवश्यक असते.
### [गिट कॉन्फिगर करणे](configuring-git.md)
दस्तऐवजात वापरकर्ता माहिती आणि इतर GIT सेटिंग्ज कशी बदलायची याबद्दल माहिती आहे.
> जीआयटी इन्स्टॉलेशन अधिक सोयीस्कर बनवायचे असल्यास ते उपयुक्त ठरेल.
### [तुमचा फोर्क मुख्य रेपॉजिटरीसह सिंक्रोनाइझ करणे](keeping-your-fork-synced-with-this-repository.md)
दस्तऐवज मुख्य रेपॉजिटरीसह आपला काटा कसा समक्रमित ठेवायचा याबद्दल बोलतो. सिंक्रोनाइझेशन आवश्यक आहे कारण, आशा आहे की, तुम्ही एकट्या प्रकल्पावर काम करणार नाही, तर इतर योगदानकर्त्यांसह त्यात बदल कराल.
> तुमच्या शाखेत रिपॉझिटरीच्या मास्टर शाखेत कोणतेही बदल नसल्यास या चरणांचे अनुसरण करा.
### [कमिट दुसऱ्या शाखेत हलवणे](moving-a-commit-to-a-different-branch.md)
दस्तऐवजात कमिट दुसर्‍या शाखेत कसे हलवायचे याबद्दल माहिती आहे.
> कमिट दुसर्‍या शाखेत हलवण्यासाठी दिलेल्या स्टेप्स फॉलो करा.
### [फाइल काढून टाकत आहे](removing-a-file.md)
दस्तऐवज तुमच्या स्थानिक भांडारातून फाइल कशी काढायची याचे वर्णन करते.
> कमिट करण्यापूर्वी फाइल कशी काढायची हे समजून घेण्यासाठी या कमांडचे पुनरावलोकन करा.
### [तुमच्या भांडारातून शाखा काढून टाकत आहे](removing-branch-from-your-repository.md)
दस्तऐवजात तुमच्या भांडारातून शाखा कशी काढायची याबद्दल माहिती आहे.
> तुमची पुल विनंती मंजूर झाल्यानंतरच या कमांड्स वापरा.
### [शाखा विलीन करताना संघर्ष सोडवणे](resolving-merge-conflicts.md)
दस्तऐवजात शाखांचे विलीनीकरण करताना उद्भवणारे संघर्ष कसे सोडवायचे याबद्दल माहिती आहे.
> येथे सुचविलेल्या पायर्‍या शाखांचे विलीनीकरण करताना उद्भवणाऱ्या संघर्षाच्या किरकोळ प्रकरणांना सामोरे जाण्यास मदत करतील.
### [कमिट परत करणे](reverting-a-commit.md)
दस्तऐवज रिमोट रिपॉजिटरीमध्ये कमिट कसे पूर्ववत करायचे याचे निर्देश देते. असे ऑपरेशन अशा प्रकरणांमध्ये उपयुक्त ठरेल जेव्हा तुम्हाला गिथबवर आधीच ढकललेले कमिट प्ले बॅक करावे लागेल.
> कमिट पूर्ववत करण्यासाठी येथे चरणांचे अनुसरण करा.
### [स्क्वॅशिंग कमिट (स्क्वॅशिंग)](squashing-commits.md)
दस्तऐवज परस्परसंवादी रीबेसेस वापरून कमिट कसे एकत्र करायचे याचे वर्णन करते.
> तुम्ही ओपन सोर्स प्रोजेक्टवर पुल रिक्वेस्ट तयार केली असल्यास या सूचना वापरा, परंतु प्रोजेक्ट एक्सपर्ट तुम्हाला तुमच्या सर्व कमिट एका अर्थपूर्ण टिप्पणीसह एकत्र करण्यास सांगतात.
### [स्थानिक कमिट पूर्ववत करणे](undoing-a-commit.md)
दस्तऐवज तुम्हाला तुमच्या स्थानिक रेपॉजिटरीमध्ये कमिट कसे परत करायचे याची माहिती देतो. जर तुम्ही ठरवले की तुम्ही तुमच्या भांडारात गडबड केली आहे आणि त्यातील मजकूर त्यांच्या मूळ स्थितीत पुनर्संचयित करू इच्छित असाल तर तुम्हाला या माहितीची आवश्यकता असेल.
> तुम्हाला शेवटच्या स्थानिक कमिटने केलेले बदल पूर्ववत करायचे असल्यास या सूचनांचे अनुसरण करा.
### [उपयोगी दुवे](उपयोगी-लिंक-फॉर-further-learning.md)
या फाइलमध्ये ब्लॉग पोस्ट्स, उपयुक्त वेबसाइट्स, वेबसाइट्सची सूची असलेल्या टिप्स आणि युक्त्या आहेत ज्या अनेकदा आमचे जीवन सुलभ करतात. नवशिक्यांसाठी आणि तज्ञांसाठी, आवश्यकतेनुसार आम्ही त्यांच्याशी संपर्क साधण्याची शिफारस करतो. या फाइलमध्ये उपयुक्त लिंक्सची सूची आहे जी ओपन सोर्समध्ये पहिले पाऊल टाकणाऱ्यांना आणि या क्षेत्रातील त्यांचे ज्ञान वाढवू इच्छिणाऱ्यांना नक्कीच मदत करेल.
docs/additional-material/translations/Nepali/additional-material.np.md
+48
View File
@@ -0,0 +1,48 @@
# थप जानकारी
हामी मान्दछौं कि तपाईंले यहाँ जानु अघि आधारभूत ट्यूटोरियल पढिसक्नुभएको छ। यो कागजातले तपाईंलाई Git प्रविधिहरूमा थप जानकारी दिनेछ उन्नत ।
### [प्रतिबद्धता सम्पादन गर्नुहोस्](amending-a-commit.np.md)
यो पृष्ठले तपाईंलाई रिमोट डाइरेक्टरीमा कमिट परिमार्जन गर्न आवश्यक जानकारी दिनेछ:
> तपाईंले गर्नुभएको प्रतिबद्धता ठीक गर्न यो प्रयोग गर्नुहोस्।
### [git कन्फिगर गर्नुहोस्](configuring-git.np.md)
यो पृष्ठले तपाइँलाई तपाइँको प्रयोगकर्ता विवरणहरू र git मा अन्य विकल्पहरू कन्फिगर गर्न आवश्यक जानकारी दिनेछ:
> तपाईंको git कन्फिगरेसनको राम्रो नियन्त्रणको लागि प्रयोग गर्नुहोस्।
### [डाइरेक्टरी संग सिंक मा आफ्नो फोर्क राख्नुहोस्](keeping-your-fork-synced-with-this-repository.np.md)
यो कागजातले तपाईंलाई स्रोत डाइरेक्टरीसँग "फोर्क" डाइरेक्टरीलाई अद्यावधिक राख्नको लागि जानकारी दिन्छ। यो महत्त्वपूर्ण छ र हामी आशा गर्छौं कि तपाईं र अरू धेरैले यस परियोजनामा ​​योगदान गर्नुहुनेछ।
> यदि तपाईंले अभिभावक डाइरेक्टरीमा आफ्नो शाखामा कुनै परिवर्तनहरू देख्नुभएन भने यी चरणहरू पालना गर्नुहोस्।
### [एउटा कमिटलाई फरक शाखामा सार्नुहोस्](moving-a-commit-to-a-different-branch.np.md)
यो पृष्ठले तपाईंलाई फरक शाखामा प्रतिबद्धता सार्न आवश्यक जानकारी दिनेछ:
> कमिटलाई फरक खुट्टामा सार्न यी चरणहरू पालना गर्नुहोस्।
### [फाइल मेटाउनुहोस्](removing-a-file.np.md)
यो पृष्ठले तपाईंलाई आफ्नो स्थानीय डाइरेक्टरीबाट फाइल मेटाउन आवश्यक जानकारी दिनेछ:
> कमिट गर्नु अघि फाइल कसरी मेटाउने भनेर सिक्नको लागि यी चरणहरू पालना गर्नुहोस्।
### [तपाईंको डाइरेक्टरीमा एउटा शाखा मेटाउनुहोस्](removing-branch-from-your-repository.np.md)
यस पृष्ठले तपाइँलाई तपाइँको निर्देशिकाबाट शाखा मेटाउन आवश्यक जानकारी दिनेछ:
> तपाईंको पुल अनुरोध मर्ज भएपछि मात्र यी चरणहरू पालना गर्नुहोस्।
### [मर्ज विवादहरू समाधान गर्नुहोस्](resolving-merge-conflicts.np.md)
यो पृष्ठले तपाईंलाई मर्ज मुद्दाहरूको समस्या निवारण गर्न आवश्यक जानकारी दिनेछ:
> यी (प्रायः कष्टप्रद) मिश्रण समस्याहरू समाधान गर्न यी चरणहरू पालना गर्नुहोस्।
### [प्रतिबद्धतामा फर्कनुहोस्](reverting-a-commit.np.md)
यदि तपाइँ रिमोट डाइरेक्टरीमा अघिल्लो कमिटमा फर्कन आवश्यक छ भने यो पृष्ठले तपाइँलाई मद्दत गर्नेछ। तपाईले पहिले नै Github मा धकेल्नु भएको कमिटलाई अन्डू गर्न आवश्यक छ भने यो उपयोगी छ।
> यदि तपाइँ कमिट उल्टाउन चाहनुहुन्छ भने यी चरणहरू पालना गर्नुहोस्।
### [सपाट कमिटहरू](squashing-commits.np.md)
यस पृष्ठले तपाइँलाई सिकाउनेछ कि कसरी एकमा धेरै कमिटहरू समतल गर्ने।
> यदि तपाइँ पुल अनुरोध खोल्न चाहनुहुन्छ भने प्रयोग गर्नुहोस् र समीक्षकले तपाइँलाई समग्र जानकारी सन्देश सहित सबै कमिटहरूलाई "फ्लैट" गर्न सोध्छन्।
### [उपयोगी लिङ्कहरू](undoing-a-commit.np.md)
यो पृष्ठले तपाइँलाई तपाइँको स्थानीय डाइरेक्टरीमा कमिट अनडू गर्न आवश्यक जानकारी दिन्छ। यदि तपाईंले आफ्नो स्थानीय डाइरेक्टरीमा गल्ती गरेको महसुस गर्नुभयो र अघिल्लो अवस्थामा फर्कन चाहनुहुन्छ भने तपाईंले यो गर्न आवश्यक छ।
> यदि तपाइँ स्थानीय कमिटमा पूर्वस्थितिमा पूर्ववत/उल्टाउन चाहनुहुन्छ भने यी निर्देशनहरू पालना गर्नुहोस्।
### [उपयोगी लिङ्कहरू](Useful-links-for-further-learning.np.md)
यो पृष्ठ सबै टिप्स र ट्रिक्स साइटहरू, ब्लगहरू, र सामान्य साइटहरूमा समर्पित छ जसले हामीलाई हाम्रो जीवन सजिलो बनाउन मद्दत गर्दछ। तिनीहरू तपाइँका सबै आवश्यकताहरू पूरा गर्न उत्कृष्ट सन्दर्भहरू हुन्, चाहे तपाइँ शुरुवात वा विशेषज्ञ हुनुहुन्छ। यो पृष्ठ ती सबै उपयोगी लिङ्कहरूको अनुक्रमणिका हुनुपर्छ जसले खुला स्रोतमा नयाँ भएका वा आफ्नो ज्ञानलाई अझ गहिरो बनाउन चाहने जो कोहीलाई मद्दत गर्नेछ।
### [एउटा .gitignore फाइल सिर्जना गर्नुहोस्](creating-a-gitignore-file.np.md)
यो कागजातले .gitignore फाइल केका लागि हो, यसलाई किन प्रयोग गर्ने र कसरी सिर्जना गर्ने भनेर बताउँछ। यो फाइल लगभग सबै git परियोजनाहरूमा प्रयोग गरिन्छ। यसले कमिटहरूमा मात्र आवश्यक फाइलहरू विचार गर्न मद्दत गर्दछ।
docs/additional-material/translations/Nepali/amending-a-commit.np.md
+50
View File
@@ -0,0 +1,50 @@
# प्रतिबद्धता सम्पादन गर्नुहोस्
मानौं कि तपाईंले आफ्नो रिमोट डाइरेक्टरीमा प्रतिबद्धता गर्नुभयो र पछि यो महसुस गर्नुहोस् कमिट सन्देशमा टाइपो छ वा तपाईंले आफ्नो अन्तिम कमिटमा लाइन थप्न बिर्सनुभयो। यो त्रुटि कसरी सच्याउने? यो यस ट्यूटोरियल को विषय हो।
## Github मा धक्का दिए पछि भर्खरको प्रतिबद्ध सन्देश परिवर्तन गर्नुहोस्
फाइल नखोली नै यो गर्नका लागि:
* आदेश टाइप गर्नुहोस् ```git कमिट --amend -m "तपाईँको नयाँ प्रतिबद्ध सन्देश पछि"```
* निर्देशिकामा कमिट गर्न ```git push origin <branch-name>``` आदेश चलाउनुहोस्।
NB: यदि तपाइँ केवल ```git कमिट --amend``` टाइप गर्नुहुन्छ भने, पाठ सम्पादक खुल्छ र तपाइँलाई परिमार्जन गर्न सोध्छ।
सन्देश पठाउनुहोस्। पाठ सम्पादक प्रयोग गर्नबाट बच्न ``-m`` विकल्प थप्नुहोस्।
## एक विशिष्ट प्रतिबद्धता परिमार्जन गर्नुहोस्
त्यसोभए के हुन्छ यदि तपाईंले फाइलमा सानो परिवर्तन गर्न बिर्सनुभयो, जस्तै शब्द परिवर्तन गर्नुहोस् र
तपाईंले पहिले नै हाम्रो रिमोट डाइरेक्टरीमा यो प्रतिबद्धता पुश गरिसक्नुभएको छ?
यस बिन्दुलाई चित्रण गर्न, यहाँ मेरो प्रतिबद्धताहरूको लग छ;
```
g56123f बोट फाइल सिर्जना गर्दै
contributor.md बाट a2235d अपडेट
a5da0d बोट फाइल सम्पादन गर्नुहोस्
```
कल्पना गरौं कि मैले बोट फाइलमा एउटा शब्द थप्न बिर्सें।
यो समस्या समाधान गर्न दुई तरिकाहरू छन्। पहिलो भनेको नयाँ प्रतिबद्धता बनाउनु हो जसमा परिवर्तन समावेश छ:
```
g56123f बोट फाइल सिर्जना गर्दै
contributor.md बाट a2235d अपडेट
a5da0d बोट फाइल सम्पादन गर्नुहोस्
b0ca8f बोट फाइलमा शब्द थप्नुहोस्
```
दोस्रो तरिका भनेको a5da0d कमिट परिमार्जन गर्नु हो र यो नयाँ शब्द थप्नुहोस् र यसलाई Github मा सबै एक कमिटमा पुश गर्नुहोस्।
यो दोस्रो विकल्प बढी उपयुक्त देखिन्छ, यो एक सानो परिवर्तन हो।
त्यसो गर्न, यी चरणहरू पालना गर्नुहोस्:
* फाइल सम्पादन गर्नुहोस्। हाम्रो अवस्थामा, हामी बिर्सिएको शब्द समावेश गर्न बोट फाइल परिमार्जन गर्छौं।
* त्यसपछि फाइललाई स्टेजिङ क्षेत्रमा ```git add <filename>``` आदेशको साथ थप्नुहोस्
सामान्यतया, स्टेजिङ क्षेत्रमा फाइलहरू थपेपछि, अर्को चरण आदेश चलाउन हो
git कमिट -एम "हाम्रो प्रतिबद्ध सन्देश", हैन? तर हामी यहाँ के चाहन्छौं भने प्रतिबद्धता परिमार्जन गर्नु हो
अघिल्लो, हामी यसको सट्टा आदेशहरू चलाउनेछौं:
* ``git कमिट -- amend```
यसले पाठ सम्पादक ल्याउनेछ जसले तपाईंलाई सन्देश सम्पादन गर्न सोध्छ। तपाईं छोड्ने निर्णय गर्न सक्नुहुन्छ
सन्देश जस्तो छ वा परिवर्तन गर्नुहोस्।
* सम्पादकबाट बाहिर निस्कनुहोस्
* आफ्ना परिवर्तनहरूलाई ```git push origin <branch-name>``` सँग पुश गर्नुहोस्
यसरी दुबै परिवर्तनहरू एउटै कमिटमा छन्।

Some files were not shown because too many files have changed in this diff Show More