sosokker/first-contributions
1
0
Fork 0
mirror of https://github.com/Sosokker/first-contributions.git synced 2025-12-18 12:44:06 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

reset repo

Browse Source
This commit is contained in:
Roshan Jossy 2022-11-22 01:05:15 +01:00
commit 56a4bfa3d5
193 changed files with 18186 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

86
.github/CONTRIBUTING.md vendored Normal file
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) |
| العربية | [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) | []() |
| 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) |
| Hausa | [Hausa](../translations/README.ha.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 | [Portuguese (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 | [Portuguese (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) []() |

20
.github/ISSUE_TEMPLATE.md vendored Normal file
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. 🎉

30
.github/ISSUE_TEMPLATE/issue-template.md vendored Normal file
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. 🎉

390
.gitignore vendored Normal file
View File

@ -0,0 +1,390 @@
.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

133
CODE_OF_CONDUCT.md Normal file
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

572
Contributors.md Normal file
View File

@ -0,0 +1,572 @@
# Contributors
<!-- prettier-ignore-start -->
- [Carlos Luque] (https://github.com/carlosluque)
- [Benjamin Morgiewicz](https://github.com/BaseBenjamin13)
- [Keenan Speaks] (https://github.com/Styleshift)
- [Sabir Khan](https://github.com/simplysabir)
- [Aman Bharti](https://github.com/aman0ab)
- [Archishman Dash](https://www.github.com/aholic-archie)
- [Esta es mi primer contribucion](https://github.com/PabloCH23)
- [Juanma Romero](https://github.com/juanmaroni/)
- [Craig Leppan] (https://github.com/yoyozi)
- [Josh Mayeda] (https://github.com/joshmayeda)
- [Chhabi Acharya](https://github.com/Chhabii)
- [Jeevan Naik](https://github.com/JeevanNaikOP)
- [Anuhya sabbani](https://github.com/anuhyasabbani)
- [Bojidar Vladimirov](https://github.com/BojidarV)
- [Poyraz Bahcivan](https://github.com/poyrazbahcivan)
- [Ryan Ignasiak](https://github.com/theravenousR)
- [Arman Hadzigrahic](https://github.com/armeono)
- [Theo Dep](https://github.com/theoDep)
- [Andreas](https://github.com/Andreas1593)
- [Chase Hunter](https://github.com/TaylorChaseHunter)
- [Yash Wake](https://github.com/yashwxd)
- [Ankith Motha](https://github.com/Alpha-github/)
- [Masih Karimi](https://github.com/MasihKarimi)
- [Gabriel Waegner](https://github.com/Gwaegs)
- [Anand S](https://github.com/anand2000s)
- [Aryan Wadhwa](https://github.com/TastyBiscuit0808/first-contributions)
- [Ishmael Peavy] (https://github.com/ipeavy)
- [Joker-CDSS-Abasiediedu] (https://github.com/Joker-CDSS)
- [R.Noto](https://github.com/RikitoNoto)
- [James Hansen](https://github.com/jameszenartist)
- [Brandon Andrews](https://github.com/brandrewsss)
- [Gabriel Fernandes](https://github.com/GabrielFernandes251)
- [Lorenzo Francisco](https://github.com/lozo6)
- [Pratyush Tyagi](https://github.com/Pratyush0612)
- [Surajit Dey Sarkar](https://github.com/Surajitds)
- [Mohit Marathe](https://github.com/Mohit2758)
- [Satarupa Deb]( https://github.com/Satarupa22-SD)
- [Edwin Kim](https://github.com/edwinkim97)
- [Rezgui Med Aziz](https://github.com/medAzizRezgui)
- [Henrikas Budrys](https://github.com/hbportfolio)
- [Vijendra Pandey](https://github.com/VijendraPandey)
- [Erik Opinaldo](https://github.com/erikopinaldo)
- [Utpal Savaliya](https://github.com/utpalsavliya)
- [stardustgd](https://github.com/stardustgd)
- [mahalakshmikutcharlapati](https://github.com/mahalakshmikutcharlapati)
- [randose](https://github.com/randose)
- [sagehourihan](https://github.com/SageHourihan)
- [Chandan Arya](https://github.com/alpha2lucifer)
- [suman](https://github.com/sumanghosh13)
- [Thet Paing Soe](https://github.com/ThetPaingSoe)
- [regularmute](https://github.com/regularmute)
- [Tewodros Amare](https://github.com/teddygizachew)
- [Stephen Silveira](https://github.com/stephen-silveira)
- [Anmol Bansal](https://github.com/AnmolBansalDEV)
- [Adeolu Oyinlola](https://github.com/deoluoyinlola)
- [Alisher Muzaffarov](https://github.com/aliml92)
- [bohemian-x] (https://github.com/bohemiancode-x)
- [Apeksha Arora](http://github.com/apekshasan)
- [RAHUL g](https://github.com/Rahulg8270)
- [Chirayu Pancholi](https://github.com/Chirayu31)
- [AnushaPalle](https://github.com/AnushaPalle)
- [Hemant Lohar] (https://github.com/Hemant-Lohar)
- [Soubhik Maji](https://github.com/majisoubhik01)
- [Jisan-mia](https://github.com/Jisan-mia)
- [Gideon Opoku](https://github.com/nana562)
- [wfrsk](hhpts://github.com/wfrsk)
- [Khalid-Hasan](https://github.com/khalidx3)
- [David Lopez](https://github.com/davidnoelopez)
- [Moustafa Hassan](https://github.com/MoustafaHassan1)
- [Brendan Tuckerman](https://github.com/MrMaverick79/)
- [Renz Sira](https://github.com/rcsira)
- [CarmenResquin] (https://github.com/CarmenResquin)
- [Rounak Shrestha](https://github.com/Rounak-stha)
- [Obafemi Oludahunsi] (https://github.com/Obafemi-NG)
- [James Hunter] (https://github.com/Jameshunter1)
- [SAHIL SINHA](https://github.com/SahilSinha007)
- [Maximiliano Carrasco](https://github.com/macsito-prog)
- [Sarthak Mittal](https://github.com/SarthakMittal777)
- [Luisa Haase](https://github.com/luisaha)
- [Nayna Sahu ](https://github.com/NaynaSahu/)
- [Bruno De Paula 🚀](https://github.com/Gr33nLight)
- [Sudarsan Balaji](https://github.com/artfuldev)
- [Ricardo Beaujon] (http://rbeaujon.com)
- [jatin kumar](https://github.com/jatin75757)
- [ahmad nawaz khan](https://github.com/4hmaad)
- [Ishita Batra](https://github.com/ishita6)
- [Devanshu Mahapatra](https://github.com/Devanshu-17)
- [Pablo Alejandro](https://github.com/Pabloalesca)
- [Khan Winter](https://github.com/thecoolwinter)
- [Mickhat](https://github.com/Mickhat)
- [Mohit Bishwokarma](https://github.com/Mohitbishukarma)
- [Matt Arias](https://github.com/FreedSoul)
- [Alex Song](https://github.com/TheRealAlexSong)
- [mahalakshmikutcharlapati](https://github.com/mahalakshmikutcharlapati)
- [Andrea Mammoliti](https://github.com/AndreusSH)
- [Praddyum Verma](https://praddy2009.github.io/)
- [Divyanshu Singhal](https://github.com/divyanshu9821)
- [bhavana] (https://github.com/bhavana-263)
- [Don Chisolm](https://github.com/Donchiz77)
- [Usman Khan](https://github.com/UsmanK7)
- [Shannon Torcato](https://github.com/shannontorcato)
- [DaneeSkripter](htttps://github.com/daneeskripter)
- [IsaacWritesCode](https://github.com/IsaacWritesCodeGithub)
- [Reed Conway](https://github.com/ReedConway)
- [Pratheek Shetty](https://github.com/pratheek-shett)
- [Dionne Mascarenhas](https://github.com/dmasc2)
- [Usman Khan](https://github.com/UsmanK7)
- [SAURABH200300](https://github.com/SAURABH200301)
- [Mustafa Bhm](https://github.com/mustafa-bhm)
- [Joswagc](https://github.com/joswagc)
- [Khushi Shukla](https://github.com/Khushi-Shukla)
- [Srijan D](https://github.com/Srijan-D)
- [srinivasthedeveloper](https://github.com/srinivasthedeveloper)
- [divijaa](https://github.com/divijaa)
- [ngweishen99](https://github.com/ngweishen99)
- [Avedis_Yapoudjian](https://github.com/AvedisY)
- [xa49](https://github.com/xa49)
- [bytesofbec](https://github.com/bytesofbec)
- [SamAtkinsonModeste](https://www.github.com/SamAtkinsonModeste)
- [william-chalk](https://github.com/william-chalk)
- [terminalPoltergeist](https://github.com/terminalPoltergeist)
- [katumba jonathan paul](https://github.com/kpaool)
- [Sushil Suthar](https://github.com/isushilsuthar)
- [Anupama Jedi](https://github.com/anupama003)
- [Jalebium69](https://github.com/jesherjoshua)
- [marioluiss](https://github.com/MarioLuiss)
- [Bojidar Vladimirov](https://github.com/BojidarV)
- [Cocozin13](https://github.com/Cocozin13)
- [Yuvraj Seegolam](https://github.com/yuvraj108c)
- [Gabriel Coelho](https://github.com/bielcoelho)
- [Urvesh Radadiya](https://github.com/URVESH1121)
- [Jibrin Ahmed](https://github.com/TacetSteeze)
- [Kely Sarmi](https://github.com/kelysi)
- [Adit Bhargava](https://github.com/zcsop1206)
- [Tanu Singh](https://github.com/TanuSingh17)
[Adarsh Sharma](https://github.com/Adarsh1885)
- [Shreyas Bhagwat](https://github.com/ShreyasBhagwat)
- [Sahil Barsaiyan](https://github.com/Sahilb12)
- [Dario Gumucio](https://github.com/dariogumucio)
- [Aman Bhagat](https://GitHub.com/sanayaa)
- [Zoltan Nahoczki](https://github.com/nahoczki)
- [Siddharth Singh](https://github.com/siddharthqs/rust_quant)
- [Akshay Jain](https://github.com/rudeakshay)
- [Sujith P](https://github.com/Alfa-ZORO)
- [NIKITA PANDEY 🦋](https://github.com/NIKITApandey01)
- [Cesar Rodas](https://github.com/Care99)
- [Sahil Singh](www.linkedin.com/in/sahil-singh-ss9824)
- [imappuru](https://github.com/imappuru)
- [plaguss](https://github.com/plaguss)
- [Rafiqul Shopon](https://github.com/rafiqulshopon)
- [verissimon](https://github.com/verissimon)
- [DragonFireShield](https://github.com/dragonfireshield)
- [Al Aasad Nur Riyad](https://github.com/nurRiyad)
- [Muhammed Emin Boydak](https://github.com/eminboydak)
- [Teguh Widodo](https://github.com/teguhwin8)
- [Harshit Arora](https://github.com/harshit0755)
- [Mayank Jha](https://github.com/mkjha482)
- [Frank Akrasi Antwi](https://github.com/fantwi)
- [Shreya Dubey](https://github.com/ShreyaDubey1001)
- [LaplancheMaxime](https://github.com/LaplancheMaxime)
- [Vicky Grover](https://github.com/LaplancheMaxime)
- [Siddhant Majumder](https://github.com/Codeworm08)
- [Soumyadip Bhowmik](https://github.com/SoumyadipBhowmik)
- [Alex Reveles](https://github.com/aajj333)
- [Samuel Oluyede](https://github.com/Masei25)
- [Ankush](https://github.com/ankushrai999)
- [Phillip Chu](https://github.com/phillippchu)
- [Aazim Parwaz](https://github.com/Aazim-parwaz)
- [Monish Prabhu](https://github.com/monish-pr/)
- [Khaled](https://github.com/KALs3)
- [Deepali](https://github.com/deepseas07)
- [Ailen Paez](https://github.com/paezailen)
- [Bella Emz] (https://github.com/EmzB)
- [Vatsal K](https://github.com/vatsalkudecha)
- [Mika] (https://github.com/SK-2022)
- [Prakhar Bhatia](https://github.com/prakharbhatia4)
- [vinthara](https://github.com.vinthara)
- [Vaibhavi Gaur](https://github.com/vai14-gaur)
- [Julio Lezcano](https://github.com/lezcano17)
- [Dhriti](https://github.com/Dhriti-singh)
- [Haseeb Ahmad Siddiqui](https://github.com/hasebsiddiqui)
- [Dominic R.](https://github.com/jD2R)
- [Bestin K Benny](https://github.com/bestin015)
- [Chani](https://github.com/ChaniDev)
- [Vaishnavi](https://github.com/vaisrinivasan)
- [Dhruv](https://github.com/Elektrikk)
- [Meet Vansjaliya](https://github.com/meetvansjaliya)
- [Anmoldeep Kaur](https://github.com/anmoldeep1512)
- [JOSE VEDIA](https://github.com/Jose-b-v)
- [Freya Shah](https://github.com/Freya-29)
- [Pasan Pahasara](https://github.com/Pasan-Pahasara)
- [Chethas Pv](https://github.com/chethas7)
- [Cyan Cipher](https://github.com/CyanCipher)
- [kelys] (https://github.com/kelysi)
- [Muskan_Kansal] (https://github.com/crazylot)
- [Aayush Arora](https://github.com/AroraAayush)
- [Michelle Wong](https://github.com/strawberrie68/)
- [Suraj Patra](https://github.com/Suraj-Patra)
- [Mallela D. Vinay](https://github.com/MD571)
- [Mariam Lawal](https://github.com/Maerryham)
- [ADITI-2003](https://github.com/ADITI-2003)
- [Glitchr](https://github.com/Glitchr)
- [Shabeeb PV](https://github.com/shabeebleo)
- [Sakshi](https://github.com/sagupta8399)
- [Krombopulos](https://github.com/krombopulos-eddie)
- [Muskan](https://github.com/Muskan-Git-Code)
- [Urmil Bhavsar](https://github.com/urmil22)
- [Abhay Kshirsagar](https://github.com/AK6263/)
- [Vedant Garhwal](https://github.com/vedant21-2005)
- [Ziabeher Phillips](https://github.com/Zabzx)
- [Pankaj Adhikari](https://github.com/Pankaj809)
- [shashank-gupta](https://github.com/shashank-2310/)
- [bungbloopity](https://github.com/bungbloopity/)
- [Mohammed Arshad](https://github.com/mohammedarshad18)
- [Aleksandr Bochkarev](https://github.com/sash00k/)
- [Dylan Messerly](https://github.com/CodeDTX11)
- [Zhenya Mateyuk](https://github.com/jEUGENEdev/)
- [Soy el Yisus](https://github.com/Jebushdd)
- [Mila](https://github.com/jaetenty)
- [Ayush Shete](https://github.com/ayushete02)
- [Rishabh Gist](https://github.com/rishabhgist)
- [Satyasuranjeet](https://github.com/Satyasuranjeet)
- [Ritwika Das](www.linkedin.com/in/ritwika-das-1510a4207)
- [Anya McDonald](https://github.com/anyahush)
- [Kartik Kumar](https://github.com/yellowterrum)
- [devzohaib](https://github.com/devzohaib)
- [Adanvasconcelos](https://github.com/AdanVasconcelos)
- [Tanmay Bhujade](https://github.com/Tanmaybhujade)
- [Ehmad Saeed](https://github.com/ehmadsaeed)
- [Alex Buser](https://github.com/Albuser)
- [Alex Peain](https://github.com/Alexpeain)
- [Artyom Malyarenko](https://github.com/malaartyom)
- [Snigdha Sinha](https://github.com/snigdhaop)
- [Dibyendu Das](https://github.com/dibyendu02)
- [Megha](https://github.com/SBMegha)
- [Rahul Saha](https://github.com/Rahul10Saha)
- [Dixon Loo](https://github.com/dxnlu)
- [Jose Armando](https://github.com/Armando-Grados)
- [Sathish Kumar Saminathan](https://github.com/satissssss)
- [MAHASAPU](https://github.com/MahasApu)
- [Sarah Mukuti](https://github.com/cesarWrites)
- [Bharat Mishra](https://github.com/BMlookingforaW)
- [Pradyumn](https://github.com/Hannibal404)
- [Utku Çamlıdağ](https://github.com/UtkuCmldg)
- [Suchit Deshmukh](https://github.com/suchitd11)
- [YogatBear](https://github.com/YogatBear)
- [Smart-Peach](https://github.com/Smart-Peach)
- [Siddhant](https://github.com/SiddJ01)
- [Erika Delfino](https://github.com/edelfino11)
- [JSalinas](https://github.com/javier-salinas)
- [Davies Jeffrey](https://github.com/djokhar05)
- [Hailey Steineke](https://github.com/hdsteineke)
- [Abishek Reddy](https://github.com/Abishek-Reddy)
- [Sahil Wankhade](https://github.com/ArcheR1901)
- [Roberto](https://github.com/VespuccioTech)
- [Abdullatif Khayat](https://github.com/Abdullatif-K123)
- [Ayasha](https://github.com/AyashaSikilkar)
- [Varun Kumar](https://github.com/kukutapuvarun)
- [Suchit](https://github.com/Suchitsj12)
- [Safadtm](https://github.com/safadtm)
- [Anandaram](https://github.com/raawwm/first-contributions)
- [Gaby Victoria](https://github.com/GabyVictoria0122)
- [Corentin Gouanvic](https://github.com/Stoaties)
- [Sherly Febrianti](https://github.com/sherlyfebrianti96)
- [Shrimad Bhagwat](https://github.com/Shrimad-Bhagwat)
- [Giuliano Marcus Bianco](https://github.com/giuliano-marcus-bianco)
- [Niket Tiwari](https://github.com/Tiwari-Niket )
- [Jason Kasari](https://github.com/jkasari)
- [Abhi Patel](https://github.com/AbhiPatel10 )
- [Marko Vitkovic](https://github.com/MarkoVitkovic)
- [Yatndeep Dubey](https://github.com/Yatndeep )
- [Autumn Ouellette](https://github.com/Autumn-Ou)
- [Fatin Almalik](https://github.com/Fatin-Almalik)
- [Mohammad Mubaslat](https://github.com/mohammadmubaslat)
- [Arnaduga](https://github.com/arnaduga)
- [PatentLobster](https://github.com/PatentLobster)
- [Varun Prashant Kadkade](https://github.com/varun2430)
- [Aditya Vijay](https://github.com/kiriotheo)
- [Strelets Alexander](https://github.com/Tenkoru)
- [Indranil Saha](https://github.com/saha-indranil)
- [Aman Khatri](https://github.com/Amank927)
- [divya](https://github.com/Divya2k05)
- [Arunima Chaudhuri](https://github.com/tinniaru3005)
- [Domenico Ivan Fortuna](https://github.com/dromex22)
- [Celeste Dubini](https://github.com/celestedubini)
- [Aksheet10](https://github.com/Aksheet10)
- [David Letaw](https://github.com/davidletaw)
- [Sam Erde](https://github.com/SamErde)
- [Danny Bae](https://github.com/danveb)
- [Abhishek Nayak](https://github.com/Abhishek2nayak)
- [Sarthak Patel](https://github.com/sarthakworkspace)
- [Ping](https://github.com/yaein-c)
- [Shubharthi Nath](https://github.com/shubharthinath)
- [Michael Danilov](https://github.com/michaeld03)
- [Hywenklis Rherbert](https://github.com/hywenklis)
- [Biswa Baibhab Subudhi](https://github.com/biswabaibhab007)
- [KacperC](https://github.com/CKacper)
- [Shivam Dangi](https://github.com/shivamdangi7)
- [Nikhil S Kalburgi](https://github.com/nikhilkalburgi)
- [Farhan khan](https://github.com/farhanalws4u)
- [Chandra Sekhar Vinnakota](https://github.com/Iamchandra-3)
- [Jackie Zou](https://github.com/jz0u)
- [Niklas Betke](https://github.com/nikbetke)
- [Vishal Kumar Sinha](https://github.com/VishSinh)
- [Oluwatimilehin Esan](https://github.com/therealtmmy)
- [Satendra Mishra](https://github.com/Satendram)
- [Himanshu Singh](https://github.com/singh-himanshu-16)
- [Deepa Kumari](https://github.com/deepa181)
[Sudip Neupane](https://github.com/sulphuric-sudip)
- [NandiniPokharna](https://github.com/NandiniPokharna)
- [Ruphaa Ganesan](https://github.com/ruphaa)
- [unpluggedsam](https://github.com/unpluggedsam)
- [JasminTajShaik](https://github.com/JasminTajShaik2601)
- [Isaac Mellad Pemberton](https://github.com/Iketyke)
- [Nishant Kumar](https://github.com/thinkwithcode)
[Javier-Bernabe](https://github.com/javbg97)
- [Pragathees](https://github.com/pragasekar)
- [Thomas Jacka](https://github.com/TJacka)
- [rabisha](https://github.com/rabi-1)
- [William-David](https://github.com/William-David)
- [Yash Bellary](https://github.com/bellaryyash23)
- [jeongwoo903](https://github.com/jeongwoo903)
- [Desmond-Fon](https://github.com/Desmond-Fon)
- [Srijanya Durganala](https://github.com/Srijanya.D)
- [TusharPramanick](https://github.com/TusharPramanick)
- [Krishan-Walia](https://github.com/krishanwalia30)
- [Krishna-Kadu](https://github.com/KaiserKadu)
- [Timothy Chua](https://github.com/tdchua)
- [TesseractionCode](https://github.com/TesseractionCode)
- [Jyotishmoy konwar](https://github.com/Jyotishmoy365)
- [Krishan-Kant-11](https://github.com/Krishan-Kant-11)
- [KiriNeTo](https://github.com/KiriNeTo)
- [Enrique Ambrocio](https://github.com/Enrique-Ambrocio)
- [Martin Poncio](https://github.com/lmponcio)
- [Kiran Kuumar Mohanty](https://github.com/theluckiestsoul)
- [Adam Chen](https://github.com/adamchen151)
- [Jonathan G Araya](https://github.com/Jonathana1106)
- [jungchoib](https://github.com/jungchoib)
- [rajdugad](https://github.com/rajdugad)
- [Tarek-Azzazi](https://github.com/tarekazzazi)
- [EricWink](https://github.com/ericwink)
- [Jongkwang131](https://github.com/Jongkwang131)
- [sneha-2510](https://github.com/sneha-2510)
- [javesshhh](https://github.com/javesshhh)
- [KratikJain10](https://github.com/KratikJain10)
- [RogueTM](https://github.com/RogueTMs)
- [jiwonqaz](https://github.com/jiwonqaz)
- [Joshua Varghese](https://github.com/joshvarg)
- [chowonbhin](https://github.com/chowonbhin)
- [mimeosd](https://github.com/mimeosd)
- [Tanmay Pradhan](https://github.com/tanmaypradhan4112)
- [Chirag Goyal](https://github.com/ChiragGoyal98)
- [Animesh Singh](https://github.com/Animesh0764)
- [Jeet Oza](https://github.com/Oza-Jeetkumar-Vishnubhai)
- [Ayush Dodiya](https://github.com/AHD153)
- [KDE030617](https://github.com/KDE030617)
- [starR-ight](https://github.com/StarR-ight)
- [Leigh-Ola](https://github.com/Leigh-Ola)
- [SAket MIshra](https://github.com/saket3199)
- [Yathin](https://github.com/yathinkv)
- [jiunjiun69](https://github.com/jiunjiun69)
- [Etinosa Ekhator](https://github.com/Etinosa22)
- [seongjunyeong](https://github.com/seongjunyeong)
- [Jungmw03](https://github.com/Jungmw03)
- [yutakdv](https://github.com/yutakdv)
- [TurtleJay](https://github.com/TurtleJay)
- [Gaurav Giri](https://github.com/gaurovgiri)
[yaho1231](https://github.com/yaho1231/)
[SuperAngel11](https://github.com/SuperAngel11/)
- [T4EK](https://github.com/T4EK)
[spartan289](https://github.com/spartan289)
- [Ashwin Bhagavatula](https://github.com/ashwinbhagavatula)
- [smdch](https://github.com/smdch)
- [kevins0101](https://github.com/kevins0101)
- [Samarth](https://github.com/samarth777)
- [Abidi-S](https://github.com/Abidi-S)
- [Sandeep Nayak](https://github.com/SANDEEP-NAYAK)
- [Tarif Higolja](https://github.com/mr-hingolja)
- [Sahil Ahmed](https://github.com/PirateOfAndaman)
- [youngjun1227](https://github.com/youngjun1227)
- [Preston Harms](https://github.com/R3dPnd)
- [kaushalgosaliya5](https://github.com/kaushalgosaliya5)
- [Taaki](https://github.com/taaki2311)
- [kaushalgosaliya5](https://github.com/kaushalgosaliya5)
- [Jo-SungJun](https://github.com/Jo-SungJun)
- [Samvardhan](https://github.com/samvardhan777)
- [Iyyappan R](https://github.com/dvrsaran)
- [Rohit Yadav](https://www.linkedin.com/in/rohit-yadav-0852481b2/)
- [Tyler Martin @HeyTylerMartin](https://github.com/HeyTylerMartin)
- [Arshad Khan](https://github.com/The-Arshad-Khan)
- [Ricardo Fontenla](https://github.com/ricfontenla)
- [M3tal M0nk3y](https://github.com/M3talM0nk3y)
- [Akshay Soni](https://github.com/akshaysoni10)
- [Denis Koshelev](https://github.com/kshpdr)
- [youngjun1227](https://github.com/youngjun1227)
- [Ankit Gupta](https://github.com/Ankit-Gupta0)
- [Vinci Liu](https://github.com/vinciliu30)
- [William Larsen](https://github.com/thewildwilli)
- [Higor Chagas](https://github.com/HigorChagas)
- [Matty Charitan](https://github.com/Matty-charitan)
- [Piyush Raviraj](https://github.com/Piyushraviraj2611)
- [Dwayne Gibbs](https://dwaynegibbs.net)
- [AVINASH YADAV](https://github.com/Happylife10)
- [Joshua Knorz](https://github.com/JoshKn)
- [Tri Pham](https://github.com/TriMPham98)
- [Vishvesh Pratap Singh](https://github.com/Vish221)
- [iParadocx](https://github.com/iParadocx)
- [Aditya Pudaruth](https://github.com/Aditya-Pudaruth)
- [Aman Choudhary](https://github.com/aman-choudhary1)
- [Dmitrii Sidenko](https://github.com/DmSide)
- [Santiago Urbano](https://github.com/sanurb)
- [સ્મિત કાછડીયા](https://github.com/smeekas)
- [Rao Khuram Shahzad](https://github.com/KhuramShahzad-5335)
- [Nikita Mahamuni](https://github.com/Nikita0509/)
- [Yash Deharia](https://github.com/yashdeharia)
- [Akshay Kudalkar](https://github.com/Akshaykk12)
- [Shravan Seth](https://github.com/ShravanSeth)
- [Shaavi Gupta](https://github.com/ShaaviGupta)
- [Sai Rohit](https://github.com/sairohit360)
- [James Anyalewechi](https://github.com/jamesgotech)
- [Dibakar Upadhyaya](https://github.com/Dibakar01)
- [Johan Kreivi](https://github.com/0h4y)
- [Gaurav Patil](https://github.com/GauravPatil8778)
- [Suryajith Ms](https://github.com/Suryajith32)
- [Ananya Agarwal](https://github.com/ananyaa01)
- [Ali El-Shamy](https://github.com/elshali)
- [Rami Shawwa](https://edbtz.com)
- [Chhaganlaal](https://github.com/Chhaganlaal)
- [Chandra Kiran](https://github.com/chandra-kiran1)
- [Aryan Thakore](https://github.com/Aryan1982)
- [Hamza Nehme](https://github.com/hnehme99)
- [Chris Boles](https://github.com/cboles80)
[Dev-it-a-dev](https://github.com/dev-it-a-dev)
- [Alexis Gonzalez](https://github.com/Alex-is-Gonzalez)
- [Shreyash Gupta](https://github.com/shreyash2610)
- [Manish Kumar](https://github.com/Manish-kumar-DEV)
- [Nora Aguirre](https://github.com/nora-programadora)
- [Guna Abola](https://github.com/g-abola)
- [Shabana Naik](https://github.com/ShabanaNaik)
- [Alex Sanzhanov](https://github.com/Sanzhanov)
- [Aecio Neto](https://github.com/aecio-neto)
- [Neha Jadhav](https://github.com/jadhavneha)
- [Kjell-Magnus](https://github.com/kmgrime)
- [Giorgio Menini](https://github.com/Menno00)
- [Suhas Katrahalli](https://github.com/Suhas2002)
- [Jivan Dandapat](https://github.com/jivandandapat)
- [Deepali Sayana](https://github.com/deepseas07)
- [André Carvalhal](https://github.com/ANDREC1986)
- [Rahul Saha](https://github.com/Rahul10Saha)
- [Vishal](https://github.com/VishalPraneeth)
- [Sadiq Siraj Ebrahim](https://github.com/sadiqebrahim)
- [Wajid Ali Tabassum](https://github.com/wajidalitabassum143)
- [Manvendra Prasad](https://github.com/Manv3ndra)
- [Abhinav Chaudhary](https://github.com/lan10rn)
- [Saumya Upadhyay](https://github.com/Saumyaup11)
- [Pranava Kumar Mishra](https://github.com/SatayS)
- [yogesh](https://github.com/yogesh-0911)
- [paras](https://github.com/paras9192)
- [LaElijah](https://github.com/LaElijah)
- [Shivansh Guleria](https://github.com/ShivanshGuleria)
- [Swaraj](https://github.com/swarajzz)
- [Franklin Mensah](https://github.com/fiificode)
- [Bright Odey](https://github.com/starburn-hub)
- [Rahul chaurasiya](https://github.com/Rahul-chaurasiya?)
- [Anugrah Rachman](https://github.com/kidomega-byte/)
- [Hector Quemada](https://github.com/hdquemada)
- [Maheen Saleh](https://github.com/maheensaleh)
- [Sebastian Wu](https://github.com/sebswU)
- [Sofie Borchgrevink](https://github.com/sofieborchgrevink)
- [Karanjot Singh](https://karanjot.vercel.app)
- [Sachit Khadka](https://github.com/Sachit56/first-contributions)
- [SHUBHAM PATIDAR ](https://www.linkedin.com/in/shubham-patidar-98ba5b148)
- [Apurv Tiwari](https://github.com/Mahakal0123)
- [Ajith R Thampi](https://github.com/ajithrthampi)
- [Dhanesh Phulphagar](https://github.com/darayn)
- [R3DRUN3](https://github.com/R3DRUN3)
- [Dhanesh Phulphagar](https://github.com/darayn)
- [Rishi Singh](https://github.com/mrsingh-rishi)
- [Arpan Adlakhiya](https://github.com/mrr0b0t-0x1)
- [Nia Ahmed](https://github.com/technialogy)
- [Bikash yadav](https://github.com/bikashydv)
- [Sowmya S](https://github.com/sowmya-s-26)
- [Andres Emedan](https://github.com/andresemedan)
- [Julian Macioce](https://github.com/JMacioce)
- [Prerit Agrawal](https://github.com/preritagrawal06)
- [Chiranjit Debnath](https://github.com/tomtanner)
- [JSTNSNE](https://github.com/JSTNSNE)
- [JSTNSNE](https://github.com/JSTNSNE)
[ J Sripranya](https://github.com/Sripranya)
[Karthinivash S R](https://github.com/karthinivashSR)
- [Aimee T](https://github.com/aimeetacchi)
- [Abhijith H](https://github.com/Abhijith-H13)
- [Abhighyaa](https://github.com/Abhighyaa)
- [Kaif Shakeel] (https://github.com/KaifShakeel76)
- [Alfeu Xerinda](https://githhub.com/Hard-007)
- [Chandan Singh](https://githhub.com/chandan8678)
- [Sangam Singh](https://githhub.com/codersangam)
- [Shubhanshu Gupta](https://github.com/Gptshubh)
- [shaileshb](https://github.com/shaileshhb)
- [Victor F.](https://github.com/victorfyonemoto)
- [Andre Müller](https://github.com/Amueller36)
- [duzzysroad](https://github.com/duzzysroad)
- [Srivathsan V](https://github.com/Srivathsan-V)
- [TJ Albertson](https://github.com/TJ-Albertson)
- [Ruthik Jadhav](https://github.com/Ruthik130201)
- [Vladimir Cvejanov](https://github.com/VladenCode)
- [Suman Raj](https://github.com/the-suman)
- [Megan Moulos](https://github.com/meganmoulos/)
- [Peter Hansteen](https://github.com/pitrh)
- [Thales Carlesso](https://github.com/ThalesIanMendes)
- [Teju_1212](https://github.com/teju_1212)
- [Aaron Geo Binoy](https://github.com/aarongeo1)
- [Rakshit Gupta](https://github.com/rakshitgupta23)
- [Sameera Dissanayaka](https://github.com/ceylonprogrammer)
- [Chirag Chakraborty](https://github.com/noobchirag69)
- [Aditya Singh](https://github.com/second007)
- [Aman Sharma](https://github.com/amansharma703)
-[Muhammed Fahad v k ](https://github.com/fahadvillan6)
- [Siddharth Bhardwaj](https://github.com/TheUnofficialGod)
- [Jesse Gerbrandt](https://github.com/Jgerbrandt)
- [Aditya Singhal](https://github.com/adityaacse)
- [Utsav Akash Naskar](https://github.com/Utsav1999)
- [Anish Doshi](https://github.com/doshianish8)
- [Saurabh Sinha](https://github.com/sinhasaurabh3104)
- [Girish Nair](https://github.com/javagirish)
- [Prathamesh Sable](https://github.com/prathameshks)
- [Martarion](https://github.com/Martarion-Code)
- [Martins Ngene](https://github.com/Martinsngene)
- [vishal dhavale](https://github.com/vishu1893)
- [Subhajit Mahata](https://github.com/subhajitkp007)
- [Yashvardhan Agnihotri](https://github.com/25011908vardhan)
- [Priyadarshini Sharma](https://github.com/PriyadarshiniSharma)
- [luv sharma](https://github.com/luvsharmag)
- [Raj Patra](https://github.com/raj-patra)
- [Alan Flores](https://github.com/AlanF20)
- [Aaryan Singh](https://github.com/Aaryan376)
- [Arjava Tripathi](https://github.com/ArjavaTripathi)
- [Amit Roy](https://github.com/amitroy-thedev)
- [Siddhi Khade](https://github.com/SiddhiKhade)
- [Pavanteja](https://github.com/Pavanteja17)
- [Shaurya Gupta](https://github.com/Shaurya50211)
- [shrthk-7](https://github.com/shrthk-7)
- [Yash Thakur](https://github.com/philomathaf)
- [Rajarshi Bhattacharya](https://github.com/rajarshi023)
- [Adnan Ahmed](https://github.com/fidato818)
- [Mandar Deshmukh](https://github.com/mandarsd18)
- [Azzarox](https://github.com/azzarox)
- [Aman Badone](https://github.com/amanbadone)
- [Rishabh yaduwanshi](https://github.com/rishabhyaduwanshi)
- [Suraj Patel](https://github.com/Surajpatel2003)
- [Raghav Krishan Kedia](https://github.com/Raghav-Kedia)
- [WhiteR4ven](https://github.com/WhiteR4ven)
- [Aviraj Saxena](https://github.com/theavirajsaxena)
- [Allesandria Bugatti](https://github.com/Abargallo19)
- [shrthk-7](https://github.com/shrthk-7)
- [Dharmik Nadiyapara](https://github.com/Dharmik-0)
- [Shivodit Gill](https://github.com/HotDogEnemy)
- [Shantanu29kumar](https://github.com/Shantanu29kumar)
- [IsaacNewTom](https://github.com/IsaacNewTom)
- [Jai-Marothiya](https://github.com/Jai-Marothiya)
- [Ahan Bandyopadhyay](https://github.com/ahanban15)
- [Monodeep-Das](https://github.com/Monodeep-Das)
- [Sai Manoj Etcherla](https://github.com/saimanoj22)
- [Adam Anderson](https://github.com/Adam-E-Anderson)
- [Mayank Agrawal](https://github.com/Mayank30-creator)
- [Aman Kumar Pandey](https://github.com/amanpandey2101)
- [Patil 2104](https://github.com/patil2104)
- [HiTShiroya](https://github.com/HiTShiroya)
- [Supriadi](https://github.com/obocloud)
<!-- prettier-ignore-end -->

21
LICENSE Normal file
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.

207
README.md Normal file
View File

@ -0,0 +1,207 @@
[![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-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA)
[![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](translations/Translations.md)._
<kbd>[<img title="Shqip" alt="Shqip" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/al.svg" width="22">](translations/README.al.md)</kbd>
<kbd>[<img title="Uzbek" alt="Uzbek language" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/uz.svg" width="22">](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">](translations/README.aze.md)</kbd>
<kbd>[<img title="বাংলা" alt="বাংলা" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/bd.svg" width="22">](translations/README.bn.md)</kbd>
<kbd>[<img title="Bulgarian" alt="Bulgarian" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/bg.svg" width="22">](translations/README.bg.md)</kbd>
<kbd>[<img title="Português" alt="Português" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/br.svg" width="22">](translations/README.pt_br.md)</kbd>
<kbd>[<img title="Català" alt="Català" src="https://firstcontributions.github.io/assets/Readme/catalan1.png" width="22">](translations/README.ca.md)</kbd>
<kbd>[<img title="中文 (Simplified)" alt="中文 (Simplified)" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/cn.svg" width="22">](translations/README.zh-cn.md)</kbd>
<kbd>[<img title="Czech" alt="Czech" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/cz.svg" width="22">](translations/README.cs.md)</kbd>
<kbd>[<img title="Deutsch" alt="Deutsch" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/de.svg" width="22">](translations/README.de.md)</kbd>
<kbd>[<img title="Dansk" alt="Dansk" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/dk.svg" width="22">](translations/README.da.md)</kbd>
<kbd>[<img title="العربية" alt="العربية" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/eg.svg" width="22">](translations/README.eg.md)</kbd>
<kbd>[<img title="Española" alt="Española" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/es.svg" width="22">](translations/README.es.md)</kbd>
<kbd>[<img title="Française" alt="Française" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/fr.svg" width="22">](translations/README.fr.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">](translations/README.gl.md)</kbd>
<kbd>[<img title="Ελληνικά" alt="Ελληνικά" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/gr.svg" width="22">](translations/README.gr.md)</kbd>
<kbd>[<img title="ქართული" alt="ქართული" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/ge.svg" width="22">](translations/README.ge.md)</kbd>
<kbd>[<img title="Magyar" alt="Magyar" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/hu.svg" width="22">](translations/README.hu.md)</kbd>
<kbd>[<img title="Bahasa Indonesia" alt="Bahasa Indonesia" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/id.svg" width="22">](translations/README.id.md)</kbd>
<kbd>[<img title="עִברִית" alt="עִברִית" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/il.svg" width="22">](translations/README.hb.md)</kbd>
<kbd>[<img title="हिंदी/ગુજરાતી/मराठी/മലയാളം/ಕನ್ನಡ/తెలుగు/छत्तीसगढ़ी/বাংলা/தமிழ்" alt="हिंदी/ગુજરાતી/मराठी/മലയാളം/ಕನ್ನಡ/తెలుగు/छत्तीसगढ़ी/বাংলা/தமிழ்" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/in.svg" width="22">](translations/Translations.md)</kbd>
<kbd>[<img title="தமிழ்" alt="தமிழ்" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/lk.svg" width="22">](translations/README.ta.md)</kbd>
<kbd>[<img title="فارسی" alt="فارسی" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/ir.svg" width="22">](translations/README.fa.md)</kbd>
<kbd>[<img title="پښتو" alt="پښتو" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/af.svg" width="22">](translations/README.pus.md)</kbd>
<kbd>[<img title="Italiano" alt="Italiano" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/it.svg" width="22">](translations/README.it.md)</kbd>
<kbd>[<img title="日本語" alt="日本語" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/jp.svg" width="22">](translations/README.ja.md)</kbd>
<kbd>[<img title="සිංහල" alt="සිංහල" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/lk.svg" width="22">](translations/README.si.md)</kbd>
<kbd>[<img title="Kiswahili (Kenya)" alt="Kiswahili (Kenya)" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/ke.svg" width="22">](translations/README.kws.md)</kbd>
<kbd>[<img title="한국어" alt="한국어" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/kr.svg" width="22"> <img title="한국어" alt="한국어" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/kp.svg" width="22">](translations/README.ko.md)</kbd>
<kbd>[<img title="Lietuvių kalba" alt="Lietuvių kalba" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/lt.svg" width="22">](translations/README.lt.md)</kbd>
<kbd>[<img title="Limba Română" alt="Limba Română" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/md.svg" width="22"> <img title="Limba Română" alt="Limba Română" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/ro.svg" width="22">](translations/README.ro.md)</kbd>
<kbd>[<img title="မြန်မာ" alt="မြန်မာ" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/mm.svg" width="22">](translations/README.mm_unicode.md)</kbd>
<kbd>[<img title="Македонски" alt="Македонски" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/mk.svg" width="22">](translations/README.mk.md)</kbd>
<kbd>[<img title="Español de México" alt="Español de México" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/mx.svg" width="22">](translations/README.mx.md)</kbd>
<kbd>[<img title="Bahasa Melayu / بهاس ملايو‎ / Malay" alt="Bahasa Melayu / بهاس ملايو‎ / Malay" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/my.svg" width="22">](translations/README.my.md)</kbd>
<kbd>[<img title="Dutch" alt="Dutch" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/nl.svg" width="22">](translations/README.nl.md)</kbd>
<kbd>[<img title="Norsk" alt="Norsk" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/no.svg" width="22">](translations/README.no.md)</kbd>
<kbd>[<img title="नेपाली" alt="नेपाली" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/np.svg" width="15">](translations/README.np.md)</kbd>
<kbd>[<img title="Wikang Filipino" alt="Wikang Filipino" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/ph.svg" width="22">](translations/README.tl.md)</kbd>
<kbd>[<img title="English (Pirate)" alt="English (Pirate)" src="https://firstcontributions.github.io/assets/Readme/pirate.png" width="22">](translations/README.en-pirate.md)</kbd>
<kbd>[<img title="اُاردو" alt="اردو" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/pk.svg" width="22">](translations/README.ur.md)</kbd>
<kbd>[<img title="Polski" alt="Polski" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/pl.svg" width="22">](translations/README.pl.md)</kbd>
<kbd>[<img title="Português (Portugal)" alt="Português (Portugal)" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/pt.svg" width="22">](translations/README.pt-pt.md)</kbd>
<kbd>[<img title="Русский язык" alt="Русский язык" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/ru.svg" width="22">](translations/README.ru.md)</kbd>
<kbd>[<img title="عربى" alt="عربى" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/sa.svg" width="22">](translations/README.ar.md)</kbd>
<kbd>[<img title="Svenska" alt="Svenska" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/se.svg" width="22">](translations/README.se.md)</kbd>
<kbd>[<img title="Slovenčina" alt="Slovenčina" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/sk.svg" width="22">](translations/README.slk.md)</kbd>
<kbd>[<img title="Slovenščina" alt="Slovenščina" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/si.svg" width="22">](translations/README.sl.md)</kbd>
<kbd>[<img title="ภาษาไทย" alt="ภาษาไทย" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/th.svg" width="22">](translations/README.th.md)</kbd>
<kbd>[<img title="Türkçe" alt="Türkçe" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/tr.svg" width="22">](translations/README.tr.md)</kbd>
<kbd>[<img title="中文(Traditional)" alt="中文(Traditional)" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/tw.svg" width="22">](translations/README.zh-tw.md)</kbd>
<kbd>[<img title="Українська" alt="Українська" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/ua.svg" width="22">](translations/README.ua.md)</kbd>
<kbd>[<img title="Tiếng Việt" alt="Tiếng Việt" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/vn.svg" width="22">](translations/README.vn.md)</kbd>
<kbd>[<img title="Zulu (South Africa)" alt="Zulu (South Africa)" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/za.svg" width="22">](translations/README.zul.md)</kbd>
<kbd>[<img title="Afrikaans (South Africa)" alt="Afrikaans (South Africa)" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/za.svg" width="22">](translations/README.afk.md)</kbd>
<kbd>[<img title="Igbo (Nigeria)" alt="Igbo (Nigeria)" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/ng.svg" width="22">](translations/README.igb.md)</kbd>
<kbd>[<img title="Yoruba (Nigeria)" alt="Yoruba (Nigeria)" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/ng.svg" width="22">](translations/README.yor.md)</kbd>
<kbd>[<img title="Hausa (Nigeria)" alt="Hausa (Nigeria)" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/ng.svg" width="22">](translations/README.hau.md)</kbd>
<kbd>[<img title="Latvia" alt="Latvia" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/lv.svg" width="22">](translations/README.lv.md)</kbd>
<kbd>[<img title="Suomeksi" alt="Suomeksi" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/fi.svg" width="22">](translations/README.fi.md)</kbd>
<kbd>[<img title="Беларуская мова" alt="Беларуская мова" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/by.svg" width="22">](translations/README.by.md)</kbd>
<kbd>[<img title="Српски" alt="Српски" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/rs.svg" width="22">](translations/README.sr.md)</kbd>
<kbd>[<img title="Қазақша" alt="Қазақша" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/kz.svg" width="22">](translations/README.kz.md)</kbd>
<kbd>[<img title="Bosanski" alt="Bosanski" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/ba.svg" width="22">](translations/README.bih.md)</kbd>
<kbd>[<img title="Bosanski" alt="Bosanski" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/et.svg" width="22">](translations/README.bih.md)</kbd>
<kbd>[<img title="Hrvatski" alt="Hrvatski" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/hr.svg" width="22">](translations/README.hr.md)</kbd>
<kbd>[<img title="پښتو" alt="پښتو" src="https://cdn.staticaly.com/gh/hjnilsson/country-flags/master/svg/af.svg" width="22">](translations/README.ps.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://help.github.com/articles/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 and then click the _copy to clipboard_ icon.
Open a terminal and run the following git command:
```
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:
```
git clone https://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):
```
cd first-contributions
```
Now create a branch using the `git switch` command:
```
git switch -c your-new-branch-name
```
For example:
```
git switch -c add-alonzo-church
```
## 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:
```
git add Contributors.md
```
Now commit those changes using the `git commit` command:
```
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`:
```
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.
</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-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA).
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](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/2/2d/Visual_Studio_Code_1.18_icon.svg" 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](gui-tool-tutorials/github-desktop-tutorial.md) | [Visual Studio 2017](gui-tool-tutorials/github-windows-vs2017-tutorial.md) | [GitKraken](gui-tool-tutorials/gitkraken-tutorial.md) | [Visual Studio Code](gui-tool-tutorials/github-windows-vs-code-tutorial.md) | [Atlassian Sourcetree](gui-tool-tutorials/sourcetree-macos-tutorial.md) | [IntelliJ IDEA](gui-tool-tutorials/github-windows-intellij-tutorial.md) |

117
additional-material/Things a non Programmer can do.md Normal file
View File

@ -0,0 +1,117 @@
# 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 save 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.
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.

45
additional-material/git_workflow_scenarios/Useful-links-for-further-learning.md Normal file
View File

@ -0,0 +1,45 @@
# 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)
Keep adding more links, that you find helpful.

50
additional-material/git_workflow_scenarios/additional-material.md Normal file
View File

@ -0,0 +1,50 @@
# 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.
> 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 do these steps after your pull request get's merged.
### [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.

48
additional-material/git_workflow_scenarios/amending-a-commit.md Normal file
View File

@ -0,0 +1,48 @@
# 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.

20
additional-material/git_workflow_scenarios/check-commit-log.md Normal file
View File

@ -0,0 +1,20 @@
# Check commit log
In order to check commit 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 variations and options
- In order to log 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)

76
additional-material/git_workflow_scenarios/configuring-git.md Normal file
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).

73
additional-material/git_workflow_scenarios/creating-a-gitignore-file.md Normal file
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```

19
additional-material/git_workflow_scenarios/delete-branch-locally.md Normal file
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...

119
additional-material/git_workflow_scenarios/gitflow.md Normal file
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.

45
additional-material/git_workflow_scenarios/keeping-your-fork-synced-with-this-repository.md Normal file
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 master branch. To know which branch you are on, check the first line of:
```
git status
```
if you are not already on master:
```
git checkout master
```
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 master branch.
```
git rebase upstream/master
```
Here you're merging the public repository with your master branch. Your local machine's master branch is now up-to-date. Lastly, if you push your master branch to your fork, your GitHub fork will also have the changes:
```
git push origin master
```
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 master
```
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.

25
additional-material/git_workflow_scenarios/moving-a-commit-to-a-different-branch.md Normal file
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.

23
additional-material/git_workflow_scenarios/removing-a-file.md Normal file
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`

31
additional-material/git_workflow_scenarios/removing-branch-from-your-repository.md Normal file
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)

18
additional-material/git_workflow_scenarios/resetting-a-branch.md Normal file
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.

20
additional-material/git_workflow_scenarios/resetting-a-commit.md Normal file
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

35
additional-material/git_workflow_scenarios/resolving-merge-conflicts.md Normal file
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 on 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`

41
additional-material/git_workflow_scenarios/reverting-a-commit.md Normal file
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```

86
additional-material/git_workflow_scenarios/squashing-commits.md Normal file
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.

137
additional-material/git_workflow_scenarios/stashing-a-file.md Normal file
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.

55
additional-material/git_workflow_scenarios/undoing-a-commit.md Normal file
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.

53
additional-material/git_workflow_scenarios/why-using-branches.md Normal file
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)

36
additional-material/translations/Belarusian/Useful-links-for-further-learning.by.md Normal file
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)
Працягвайце дадаваць больш спасылак, якія вам падаюцца карыснымі.

46
additional-material/translations/Belarusian/additional-material.by.md Normal file
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, і тым, хто захоча павялічыць свае веды ў гэтай галіне.

46
additional-material/translations/Belarusian/amending-a-commit.by.md Normal file
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.

76
additional-material/translations/Belarusian/configuring-git.by.md Normal file
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).

42
additional-material/translations/Belarusian/keeping-your-fork-synced-with-this-repository.by.md Normal file
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.

25
additional-material/translations/Belarusian/moving-a-commit-to-a-different-branch.by.md Normal file
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, будуць цалкам страчаныя.

23
additional-material/translations/Belarusian/removing-a-file.by.md Normal file
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`

31
additional-material/translations/Belarusian/removing-branch-from-your-repository.by.md Normal file
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)

33
additional-material/translations/Belarusian/resolving-merge-conflicts.by.md Normal file
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`

40
additional-material/translations/Belarusian/reverting-a-commit.by.md Normal file
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``

86
additional-material/translations/Belarusian/squashing-commits.by.md Normal file
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 павінен паказаць вам паведамленне аб здзяйсненні, якое вы ўвялі перад выхадам на экран, з абавязацельствамі, аб'яднанымі ў адзін.

137
additional-material/translations/Belarusian/stashing-a-file.by.md Normal file
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)
```
Гэта добры цэтлік, каб лёгка аднавіць схаваную працу і працаваць над ёй у новым аддзяленні.

59
additional-material/translations/Belarusian/undoing-a-commit.by.md Normal file
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 ў агульнае сховішча, паколькі гэта прывядзе да праблем з усімі рэпазітарамі.

46
additional-material/translations/Chinese/addtional-material.cht.md Normal file
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。

49
additional-material/translations/French/additional-material.fr.md Normal file
View File

@ -0,0 +1,49 @@
# Additional information
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.
### [Applatir des Commits](squashing-commits.md)
Cette page vous apprendra comment applatir 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'"applatir" 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 site 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.

52
additional-material/translations/French/amending-a-commit.fr.md Normal file
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.

25
additional-material/translations/Hindi/moving-a-commit-to-a-different-branch.hi.md Normal file
View File

@ -0,0 +1,25 @@
# एक कमिट शाखा को एक अलग शाखा में ले जाना
क्या होगा यदि आप कोई बदलाव कमिट करते हैं, और फिर महसूस करें कि आप एक अलग शाखा में आए हैं?
आप इसे कैसे बदल सकते हैं? यह ट्यूटोरियल कवर करता है।
## सबसे मौजूदा काम को मौजूदा शाखा में ले जाना
ऐसा करने के लिए, टाइप करें:
``` 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``` - आपके द्वारा बनाई गई शाखा में जाता है। इसमें सभी कमिट होंगे।
याद रखें: कोई भी बदलाव कमिट नहीं किया गया तो खो जाएगा।

25
additional-material/translations/Hindi/nepali.np.md Normal file
View File

@ -0,0 +1,25 @@
# एक कमिट शाखा को एक अलग शाखा में ले जाना
क्या होगा यदि आप कोई बदलाव कमिट करते हैं, और फिर महसूस करें कि आप एक अलग शाखा में आए हैं?
आप इसे कैसे बदल सकते हैं? यह ट्यूटोरियल कवर करता है।
## सबसे मौजूदा काम को मौजूदा शाखा में ले जाना
ऐसा करने के लिए, टाइप करें:
``` 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``` - आपके द्वारा बनाई गई शाखा में जाता है। इसमें सभी कमिट होंगे।
याद रखें: कोई भी बदलाव कमिट नहीं किया गया तो खो जाएगा।

20
additional-material/translations/Hindi/removing-a-file.hi.md Normal file
View File

@ -0,0 +1,20 @@
# गिट से एक फाइल को हटाना
कभी-कभी, आप किसी फ़ाइल को 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``

31
additional-material/translations/Hindi/removing-branch-from-your-repository.hi.md Normal file
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)

46
additional-material/translations/Indonesian/additional-material.id.md Normal file
View File

@ -0,0 +1,46 @@
# Informasi tambahan
Kami berasumsi anda sudah menyelesaikan tutorial dasar sebelum datang ke sini. Informasi tambahan ini akan memberikan beberapa informasi mengenai teknik Git yang lebih tinggi.
### [Hapus cabang dari repositori anda](removing-branch-from-your-repository.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 uptodate dengan repositori dasar. Hal ini penting, karena bisa jadi anda dan banyak kontributor lain berkontribusi dalam proyek tersebut.
> Ikuti langkah-langkahnya agar fork anda tidak punya banyak 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.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.
### [Mengonfigurasi git](configuring-git.md)
Dokumen ini memberikan informasi mengenai cara mengonfigurasi detil 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 mau membuka sebuah PR dalam proyek open source dan periview meminta kamu untuk menyatukan setiap commit menjadi satu, dengan pesan commit yang informatif.

23
additional-material/translations/Indonesian/removing-a-file.id.md Normal file
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. Adapun Git, file ini sudah tidak ada lagi. Jika Anda mencari file 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 dari disk kita.
Jika sekarang kita membuat komit dengan `git commit -m "Hapus file1.js"` dan kirimkan 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 banyak file, Anda dapat memasukkan 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`

23
additional-material/translations/Italian/removing-a-file.it.md Normal file
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`

42
additional-material/translations/Korean/additional-material.ko.md Normal file
View File

@ -0,0 +1,42 @@
# 추가 정보
여러분이 여기에 오기 전에 기본실습 과정을 이미 완료했다고 가정합니다. 이곳에서는 고급 Git 기술에 대한 정보를 제공합니다.
### [여러분의 저장소에서 브랜치 삭제하기](removing-branch-from-your-repository.ko.md)
이 문서는 저장소에서 브랜치를 삭제하는 방법에 대한 정보를 제공합니다.
> PR(pull request) 요청이 병합 된 후에 본 단계를 수행하십시오.
### [여러분이 포크한 저장소와 싱크상태 유지하기](keeping-your-fork-synced-with-this-repository.ko.md)
이 문서는 포크 된 저장소를 기본 저장소로 최신 상태로 유지하는 방법에 대한 정보를 제공합니다. 여러분과 다른 많은 사람들이 프로젝트에 기여하기를 바랍니다.
> 포크 된 상위 저장소가 변경되지 않은 경우 다음 단계를 수행하십시오.
### [커밋 되돌리기](reverting-a-commit.ko.md)
이 문서는 원격 저장소에서 커밋을 되돌리는 방법에 대한 정보를 제공합니다. 이미 Github에 푸시 된 커밋을 되돌리려는 경우 유용합니다.
> 커밋을 되돌리려면 이 단계를 수행하십시오.
### [커밋 수정하기](amending-a-commit.ko.md)
이 문서는 원격 저장소에서 커밋을 수정하는 방법에 대한 정보를 제공합니다.
> 당신이 만든 커밋을 수정해야 할 때 사용하십시오.
### [로컬 커밋 되돌리기](undoing-a-commit.ko.md)
이 문서는 로컬 저장소에서 커밋을 실행 취소하는 방법에 대한 정보를 제공합니다. 로컬 저장소가 엉망이라고 느껴 당신이 로컬 저장소를 리셋하고자 할 때 당신이 해야 할 일입니다.
> 로컬 커밋을 취소하려면 이 단계를 수행하십시오.
### [병합 충돌 해결하기](resolving-merge-conflicts.ko.md)
이 문서는 병합 충돌을 해결하는 방법에 대한 정보를 제공합니다.
> 이 단계를 수행하여 곤란한 병합 충돌을 해결하십시오.
### [커밋을 다른 브랜치로 이동하기](moving-a-commit-to-a-different-branch.ko.md)
이 문서는 커밋을 다른 브랜치로 이동하는 방법에 대한 정보를 제공합니다.
> 이 단계를 수행하여 커밋을 다른 브랜치로 이동하십시오.
### [git 설정하기](../configuring-git.md)
이 문서는 git에서 사용자 정보 및 기타 옵션을 구성하는 방법에 대한 정보를 제공합니다.
> git 설정을 더 잘 다루려면 이 단계를 수행하십시오.
### [유용한 링크](../Useful-links-for-further-learning.md)
이 문서는 모든 블로그 게시물, 유용한 사이트, 유용한 정보 및 웹 사이트에 대한 내용을 담고 있습니다. 우리가 모든 필요를 위해 참조하는 것은 초심자 또는 전문가 일 것입니다. 이 페이지는 오픈 소스 도메인을 처음 접하거나 더 많은 것을 배우고자 하는 사람들을 돕는 지표 역할을 해야 합니다.
### [스쿼시 커밋하기](../squashing-commits.md)
이 문서는 대화형 리베이스로 커밋을 스쿼시하는 방법에 대한 정보를 제공합니다.
> 오픈 소스 프로젝트에서 PR을 보낼 때 리뷰어가 모든 커밋을 하나로 스쿼시하도록 요청하는 경우 유익한 커밋 메시지와 함께 이것을 사용하십시오.

46
additional-material/translations/Korean/amending-a-commit.ko.md Normal file
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``` 으로 변경사항을 푸시하십시오.
이렇게 하면 두 변경사항이 단일 커밋이 됩니다.

41
additional-material/translations/Korean/keeping-your-fork-synced-with-this-repository.ko.md Normal file
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입니다.
자, 어떻게하는지 보겠습니다:
먼저 여러분은 master 브랜치에 위치해 있어야합니다. 현재 어떤 브래치에 있는지 확인합니다.:
```
git status
```
현재 master 브랜치가 아니라면 변경합니다.:
```
git checkout master
```
제 공개 저장소를 아직 여러분의 git에 추가하지 않았다면 다음 명령으로 추가합니다. `add upstream remote-url`:
```
git remote add upstream https://github.com/Roshanjossey/first-contributions
```
지정한 URL을 이용해 현재 프로젝트의 또 다른 최신 버전이 있는지 git에게 확인을 요청하는 방법입니다. 그리고 우리는 이를 `upstream` 이라고 부르기로합니다. 일단 git이 이러한 이름을 가지고 있다면 다음과 같이 공개 저장소의 최진 버전을 가지고 옵니다. :
```
git fetch upstream
```
여러분은 이제 제 포크(upstream remote)에서 최신 버전을 내려 받았습니다. 이제 공개 저장소의 변경된 내용을 여러분의 master 브랜치에 병합해야합니다.
```
git rebase upstream/master
```
여러분의 master 브랜치와 공개 저장소를 병합하고 나면 이제 여러분의 로컬머신의 master 브랜치는 최신 상태입니다. 마지막으로 여러분의 master 브랜치를 여러분의 포크에 push하게 되면 포크한 GitHub 또한 변경사항들이 반영됩니다.:
```
git push origin master
```
origin으로 명명된 리모트에 push하는 것에 주의하세요.
이제 여러분의 모든 저장소가 최신 상태를 유지하게 되었습니다.
잘 하셨습니다! GitHub 저장소에 커밋이 추가적으로 발생할 때마다 이러한 작업을 해야합니다.

28
additional-material/translations/Korean/moving-a-commit-to-a-different-branch.ko.md Normal file
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``` - 생성한 브랜치로 이동합니다. 모든 커밋들을 가지고 있을겁니다.
주의: 커밋하지 않은 변경사항들은 사라집니다.

30
additional-material/translations/Korean/removing-branch-from-your-repository.ko.md Normal file
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)

43
additional-material/translations/Korean/resolving-merge-conflicts.ko.md Normal file
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` 명령을 실행하세요.

35
additional-material/translations/Korean/reverting-a-commit.ko.md Normal file
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``` 의 상태로 되돌아갑니다.

59
additional-material/translations/Korean/undoing-a-commit.ko.md Normal file
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``` 명령을 실행할 경우, 해당 저장소를 사용하는 모든 사람들에게 문제를 일으킬 수 있으므로 절대 실행해서는 안됩니다.

46
additional-material/translations/Portuguese/additional-material.pt_br.md Normal file
View File

@ -0,0 +1,46 @@
# Informações Adicionais
Nós imaginamos que você já tenha terminado o tutorial básico antes de vir aqui. As informações adicionais te darão algumas informações sobre técnicas mais avançadas de Git.
### [Emendando um commit](../git_workflow_scenarios/amending-a-commit.md)
Esse documento provê informações sobre como emendar um commit no repositório remoto.
> Use isso quando você precisar ajustar um commit que você tenha feito.
### [Configurando o git](../git_workflow_scenarios/configuring-git.md)
Esse documento provê informações sobre como configurar detalhes de usuário e outras opções do git.
> Use isso para melhor controlar as suas configurações do git.
### [Mantendo o seu fork em sincronia com o repositório](../git_workflow_scenarios/keeping-your-fork-synced-with-this-repository.md)
Esse documento provê informações sobre como manter o seu fork atualizado com o repositório base. Isso é importante, já que se espera que você e muitas outras pessoas contribuem com o projeto.
> Siga esses passos se o seu fork não possui as mesmas alterações do repositório pai.
### [Movendo um Commit para um Branch diferente](../git_workflow_scenarios/moving-a-commit-to-a-different-branch.md)
Esse documento provê informações sobre como mover um Commit para outro Branch.
> Siga esses passos para mover um commit para outro branch.
### [Removendo um arquivo](../git_workflow_scenarios/removing-a-file.md)
Esse documento provê informações sobre como remover um arquivo do seu repositório local.
> Siga esses passos para aprender como remover um arquivo do seu repositório local.
### [Removendo um Branch do seu repositório](../git_workflow_scenarios/removing-branch-from-your-repository.md)
Esse documento provê informações sobre como deletar um Branch do seu repositório.
> Apenas siga esses passos após o seu pull request ter sido mesclado.
### [Resolvendo conflitos de Merge](../git_workflow_scenarios/resolving-merge-conflicts.md)
Esse documento provê informações sobre como resolver conflitos de Merge.
> Siga esses passos para resolver conflitos de Merge irritantes.
### [Revertendo um commit](../git_workflow_scenarios/reverting-a-commit.md)
Esse documento provê informações sobre como reverter um commit feito no repositório remoto. Isso é muito útil quando você precisa desfazer um commit que tenha sido publicado no GitHub.
> Siga esses passos se você quiser reverter um commit.
### [Comprimir Commits juntos](../git_workflow_scenarios/squashing-commits.md)
Esse documento provê informações sobre como esmagar commits juntos em um só realizando um rebase.
> Use esses passos se você quiser realizar um PR em um projeto open source e a pessoa que realizou o review pedir para você mesclar todos os commits em um só, com uma mensagem de commit informativa.
### [Desfazendo um commit local](../git_workflow_scenarios/undoing-a-commit.md)
Esse documento provê informações sobre como desfazer um commit no seu repositório local. Isso é o que você precisa fazer quando você sente que fez alguma besteira no seu repositório e deseja desfazer.
> Take these steps if you want to undo/reset a local commit.
### [Links úteis](../git_workflow_scenarios/Useful-links-for-further-learning.md)
Esse documento é dedicado a todos os blog posts, sites úteis, dicas e truques que fazem a nossa vida mais simples. Seja você um expert ou um iniciante, essa pagina deve servir como um index para todos esses links úteis para ajudar qualquer um que seja novo no mundo de projetos open-source ou alguém que queira prender mais a respeito.

52
additional-material/translations/Portuguese/amending-a-commit.pt_br.md Normal file
View File

@ -0,0 +1,52 @@
# Corrigindo um Commit
E se você fizer o commit de uma alteração para o seu repositório remoto, e posteriormente acabar percebendo que ele possui um erro na mensagem do commit, ou você se esqueceu de adicionar uma linha de código no seu commit mais recente?
Como você editaria isso? É isso que esse tutorial cobre.
## Alterando uma mensagem de commit recente após ter dado push para o Github
Para fazer isto sem abrir um arquivo:
* Digite o comando ```git commit --amend -m "seguido da sua nova mensagem de commit"```
* Execute ```git push origin <nome-da-branch>``` para fazer o commit das mudanças para o repositório.
Nota: Se você digitar apenas ```git commit --amend```, seu editor de texto abrirá te pedindo para editar a mensagem de commit.
Adicionar a flag ``-m`` previne isso.
## Fazendo modificações em um único commit
E se nós nos esquecermos de fazer uma pequena mudança em um arquivo, como adicionar uma única palavra, mas nós já demos push no commit para o nosso repositório remoto?
Para ilustrar, aqui está um log dos meus commits:
```
g56123f arquivo bot criado
a2235d atualizado contributor.md
a5da0d arquivo bot modificado
```
Supomos que eu esqueci de adicionar uma palavra no arquivo bot.
Há 2 modos de resolver esse problema. O primeiro é fazer um novo commit que contém a mudança, dessa forma:
```
g56123f arquivo bot criado
a2235d atualizado contributor.md
a5da0d arquivo bot modificado
b0ca8f adicionada palavra no arquivo bot
```
O segundo modo é corrigir o commit a5da0d, adicionar essa nova palavra e dar push para o Github como um único commit.
Essa ação soa melhor, já que é apenas uma pequena alteração.
Para fazer isso, nós faríamos o seguinte:
* Modificar o arquivo. Nesse caso, modificarei o arquivo bot para incluir a palavra que eu esqueci anteriormente.
* Em seguida, adicionar o arquivo para a área de preparação (*staging area*) com o comando ```git add <nome-do-arquivo>```
Normalmente, após adicionar arquivos na área de preparação, a próxima coisa que nós fazemos é entrar com o comando ```git commit -m "nossa mensagem de commit"```, certo?
Mas, como o que nós queremos fazer aqui é corrigir o commit anterior, nós ao invés disso iremos rodar:
* ```git commit --amend```
Isso irá inicializar o editor de texto para que possamos editar a mensagem. Você decide se irá deixar a mensagem como ela estava antes, ou editá-la.
* Sair do editor salvando as alterações
* Dar push nas suas alterações com o comando ```git push origin <nome-da-branch>```
Dessa forma, ambas as alterações agora estarão em um único commit.

73
additional-material/translations/Portuguese/confinguring-git.pt-br.md Normal file
View File

@ -0,0 +1,73 @@
#Configurando GIT
A primeira vez que você tentar fazer um commit usando git, deve ter recebido uma como esta:
```bash
$ git commit
*** Please tell me who you are.
Rode:
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
Para definir a identidade padrão da sua conta.
Omita “--global” para definir a identidade apenas nesse repositório
o Git precisa saber quem você é ao criar um commit. Quando você está trabalhando colaborativamente, deve ser capaz de ver quem modificou quais partes do projeto e quando, e assim, o git foi projetado para criar commits vinculados a um nome e um email.
Existem várias maneiras de fornecer o comando “git commit” com seu email e nome. Veremos algumas delas a seguir.
### Configuração global
Quando você armazena algo na configuração global, fica acessível em todos os sistemas e repositórios nos quais você trabalha. Essa é principal forma e funciona para a maioria dos casos de uso.
Para armazenar algo na configuração use o comando “config” da seguinte maneira:
$ git config --global <variable name> <value>
No caso dos detalhes do usuário, nós os executamos da seguinte maneira:
$ git config --global user.email "you@example.com"
$ git config --global user.name "Your Name"
### Configuração do repositório
Como o nome diz, essas configurações tem como alvo seu repositório atual. Se você quiser se comprometer com um repositório específico, por exemplo, um projeto relacionado a trabalho, com o email de sua empresa, então você pode usar esse método.
Para armazenar algo na configuração do repositório, você usa o comando “config” omitindo a sinalização “--global”, da seguinte forma:
$ git config <variable name> <value>
No caso dos detalhes do usuário, nós o executamos da seguinte maneira:
$ git config user.email "you@alternate.com"
$ git config user.name "Your Name"
### Configuração da linha de comando
Esse tipo de configuração tem como alvo apenas o comando atual. Todos os comandos git usam argumentos “-c” antes do verbo de ação para definir dados de configurações temporários
Para armazenar algo na configuração da linha de comando. Execute seu comando da seguinte maneira:
$ git -c <variable-1>=<value> -c <variable-2>=<value> <command>
No exemplo citado, executaríamos o comando commit da seguinte forma:
git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"
### Nota sobre precedência
Entre os três metodos descritos aqui, a ordem de precedência é “linha de comando > repositório > global”. Isso significa que, se uma variável for configurada na linha de comando e também globalmente, o valor da linha de comando será usado para a operação.
## Além dos detalhes do usuário:
Nós lidamos apenas com os detalhes do usuário até agora, enquanto trabalhamos com a configuração. No entanto, existem várias outras opcões disponíveis. Algumas delas são:
1. `core.editor` - para especificar o nome do editor usado para escrever mensagens de commit etc
2. `commit.template` - para especificar um arquivo no sistema como o modelo de commit inicial
3. `color.ui` - para especificar um valor booleano para usar cores na saída do git
Nós abstraimos alguns detalhes para facilitar o entendimento. Para ler mais, acesse:
[git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration).

40
additional-material/translations/Portuguese/keeping-your-fork-synced-with-this-repository.pt_br.md Normal file
View File

@ -0,0 +1,40 @@
## Mantendo o seu Fork sincronizado com este repositório
Primeiro, o fluxo para uma sincronização completa precisa ser entendido. Nesse cenário, temos 3 repositórios diferentes: o meu repositório público no Github `github.com/Roshanjossey/first-contributions/`, seu Fork no GitHub `github.com/Seu-Nome/first-contributions/` e o repositório local, no qual você deve trabalhar. Esse tipo de cooperação é típica de projetos de *open source* (código aberto) e é chamado de `Triangle Workflows`.
<img style="float;" src="https://firstcontributions.github.io/assets/additional-material/triangle_workflow.png" alt="triangle workflow" />
Para manter seus dois repositórios atualizados com meu repositório público, o primeiro passo é dar um Fetch (buscar) e então um Merge (mesclar) do repositório público ao seu repositório local.
O segundo passo é fazer um Push do repositório local para o seu Fork no GitHub. Como vimos anteriormente, é somente a partir do seu Fork que você consegue fazer um Pull Request. Por isso, esse Fork é o último repositório a ser atualizado.
Agora, vamos ver como fazer isso:
Primeiro, você precisa estar em seu Branch principal (master). Para saber em qual Branch você está, verifique a primeira linha que aparece como resultado do seguinte comando:
```
git status
```
Se você não está no master, vá para ele:
```
git checkout master
```
Em seguida, você deve adicionar meu repositório público ao seu git com `add upstream url-remoto`:
```
git remote add upstream https://github.com/Roshanjossey/first-contributions
```
Esta é uma forma de dizer ao Git que existe uma outra versão deste projeto na URL especificada e estamos chamando-a de `upstream`. Agora busque a nova versão do meu repositório:
```
git fetch upstream
```
Aqui você está buscando todas as mudanças no meu Fork (o remoto `upstream`). Agora, você precisa mesclá-lo ao repositório público no seu Branch principal.
```
git rebase upstream/master
```
Aqui você está aplicando todas as mudanças que buscou ao seu Branch principal (master). Seu repositório local agora está atualizado. Por último, se você fizer um Push do seu Branch master para o seu Fork, seu GitHub também terá as alterações:
```
git push origin master
```
Note que aqui você está fazendo um Push para o repositório remoto chamado `origin`.
Agora, todos os seus repositórios estão atualizados. Bom trabalho! Você deve seguir esses passos sempre que seu repositório no GitHub avisar que está alguns Commits atrás do meu repositório.

25
additional-material/translations/Portuguese/moving-a-commit-to-a-different-branch.pt_br.md Normal file
View File

@ -0,0 +1,25 @@
# Movendo um commit para outra branch
E se apenas depois de ter realizado o commit de uma alteração, vocẽ perceber que fez esse commit na branch errada?
Como você poderia corrigir isso? É sobre isso que este tutorial se trata.
## Movendo os últimos commits para uma branch existente
Para fazer isso, digite:
```git reset HEAD~ --soft``` - Desfaz o último commit, mas mantém as alterações disponíveis.
```git stash``` - Grava o estado do diretório.
```git checkout name-of-the-correct-branch``` - Alterna para a outra branch.
```git stash pop``` - Recupera o último estado salvo.
```git add .``` - Ou tente adicionar arquivos individualmente.
```git commit -m "your message here"``` - Faça o commit das alterações.
Agora suas alterações estão na branch correta
### Movendo o último commit para uma branch nova
Para fazer isso, digite:
```git branch newbranch``` - Cria uma nova branch, mantendo todos os commits.
```git reset --hard HEAD~#``` - Retrocede a branch uma quantidade # de commits. Atenção, estes commits serão removidos da branch.
```git checkout newbranch``` - Vá para a nova branch que você criou, ela possuíra todos os commits.
Lembre-se: Qualquer alteração não comitada será PERDIDA.

24
additional-material/translations/Portuguese/removing-a-file.pt_br.md Normal file
View File

@ -0,0 +1,24 @@
# Removendo um arquivo do Git
Às vezes, você pode querer remover um arquivo do Git, mas não excluí-lo do seu computador. Você pode fazer isso usando o seguinte comando:
``git rm <file> --cached``
## Então o que aconteceu?
O Git não irá mais controlar as mudanças no arquivo removido. Pelo que Git sabe, é como se você tivesse excluído o arquivo. Se você localizar o arquivo em seu sistema de arquivos, notará que ele ainda está lá.
Observe que no exemplo acima, o sinalizador `--cached` é utilizado. Se não adicionarmos esse sinalizador, o Git removerá o arquivo não apenas do repositório, mas também do seu sistema de arquivos.
Se você confirmar a mudança com `git commit -m" Remove file1.js "` e enviar para o repositório remoto usando `git push origin master`, o repositório remoto removerá o arquivo.
## Características adicionais
- Se você deseja remover mais de um arquivo, pode incluí-los todos no mesmo comando:
`git rm file1.js file2.js file3.js --cached`
- Você pode utilizar o caractere coringa (*) para remover todos os arquivos semelhantes. Por exemplo se você deseja remover todos os .txt do seu repositório local:
`git rm *.txt --cached`

31
additional-material/translations/Portuguese/removing-branch-from-your-repository.pt_br.md Normal file
View File

@ -0,0 +1,31 @@
## Removendo o Branch do seu repositório
Se você seguiu o tutorial até agora, seu Branch `<add-seu-nome>` concluiu seu objetivo, e é hora de deletá-lo do seu repositório local. Isso não é necessário, mas o próprio nome desse Branch mostra como seu objetivo é específico. Sua vida pode ser tornada curta por causa dessa especificidade.
Primeiro, vamos mesclar o Branch `<add-seu-nome>` ao seu Branch principal (master), então vamos para ela:
```
git checkout master
```
Mescle `<add-seu-nome>` ao master:
```
git merge <add-seu-nome> master
```
Remova `<add-seu-nome>` do seu repositório local:
```
git branch -d <add-seu-nome>
```
Agora você deletou seu Branch local `<add-seu-nome>` e tudo está limpo e arrumado.
Nesse ponto, você ainda deve ter o Branch `<add-seu-nome>` no seu Fork. Antes de deletá-lo, lembre-se que você mandou um Pull Request para o meu repositório a partir desse Branch remoto. Então, a não ser que eu já tenha mesclado o Branch, não o delete.
Porém, se eu já tiver mesclado seu Branch e você quer deletar o Branch remoto, use:
```
git push origin --delete <add-seu-nome>
```
Agora, você sabe como arrumar seus Branches.
Com o tempo, muitos Commits serão adicionados ao meu repositório público. E os Branches principais (master) da sua máquina local e do seu Fork não estarão mais atualizados. Então, para manter seus repositórios sincronizados com o meu, siga os passos abaixo.
#### [Mantendo o seu Fork sincronizado com este repositório](keeping-your-fork-synced-with-this-repository.pt_br.md)

46
additional-material/translations/Russian/additional-material.ru.md Normal file
View File

@ -0,0 +1,46 @@
# Дополнительная информация
Здесь мы предполагаем, что вы уже освоили основную инструкцию. Дополнительная информация содержит некоторые сведения о GIT командах, необходимыж в более сложных ситуациях.
### [Исправления в коммите](amending-a-commit.md)
Документ содержит информацию о том, как внести исправления в коммит в удаленном репозитории.
> Она необходима для тех случаев, когда вы хотите изменить коммит, который вы сделали ранее.
### [Конфигурирование GITа](configuring-git.md)
Документ содержит сведния о том, как изменить информацию о пользователе и другие настройки GITа.
> Он будет полезен, если вы захотите сделать установки GITа более удобными.
### [Синхронизация вашего ответвления с основным репозиторием](keeping-your-fork-synced-with-this-repository.md)
Документ рассказывает о том, как обеспечить синхронизацию вашего ответвления с основным репозиторием. Обеспечение синхронизации небходимо, так как, насколько можно надеяться, вы будете работать над проектом не в одиночестве, а вносить изменения в него, наряду с другими участниками.
> Выполните эти действия, если ваше ответвление не имеет изменений в master ветке репозитория.
### [Перемещение коммита в другую ветку](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 (pushed).
> Выполните указанные здесь шаги чтобы отменить коммит.
### [Совмещение коммитов (squashing)](squashing-commits.md)
Документ описывает, как совмещать коммиты при помощи интерактивного перебазирования.
> Используйте эти инструкции, если вы создали пул-реквест в open source проекте, но эксперт проекта просит вас совместить все ваши коммиты в один коммит с содержательным комментарием.
### [Отмена локального коммита](undoing-a-commit.md)
Документ информирует, как отыграть назад коммит в вашем локальном репозитории. Вам понадобится эта информация в том случае, если вы решите, что вы испортили ваш репозиторий и захотите вернуть его содержимое к первоначальному состоянию.
> Следуйте этим инструкциям, если вы хотите отменить те изменения, котрые были сделаны последним локальным коммитом.
### [Полезные ссылки](Useful-links-for-further-learning.md)
Этот файл содержит ссылки на блог-посты, полезные веб-сайты, веб-сайты с перечислением рекоммендаций и приемов, которые часто облегчают нашу жизнь. Как начинающим, так и экспертам мы рекомендуем обращаться к ним по мере необходимости. Этот файл содержит список полезных линьков, которые наверняка помогут и тем, кто делает первые шаги в open source, и тем, кто захочет рассширить свои знания в этой области.

45
additional-material/translations/Russian/amending-a-commit.ru.md Normal file
View File

@ -0,0 +1,45 @@
# Исправления в коммите
Представьте, что вы сделали коммит в удаленный репозиторий, а потом поняли, что допустили опечатку в комментарии к коммиту или забыли вставить строку в этот последний по времени коммит. Как поступить в такой ситуации? Именно об этом и пойдет речь в этом документе.
## Как изменить комментарий к недавнему коммиту после того, как он был послан на Github (pushed)
Чтобы сделать это, не открывая файл для редактирования,
* наберите ```git commit --amend -m "здесь следует текст нового комментария"```
* а затем исполните ```git push origin <имя-ветки>``` для того, чтобы послать изменения на Github.
Примечание: Если вы наберете, только ```git commit --amend```, то откроется текстовый редактор и предложит отредактировать комментарий к коммиту. Использование ключа ``-m`` отменяет запуск редактора.
## Как сделать изменения в одном коммите
Что если мы забыли сделать небольшое изменение в файле, например, заменить одно слово в коммите, который уже послан в удаленный репозиторий?
Пусть, для примера, записи в журнале моих коммитов выглядят следующим образом:
```
g56123f создай файл bot file
a2235d исправлен contributor.md
a5da0d изменен bot file
```
Допустим, я забыл добавить одно слово в файл bot file
Есть два способа исправить это. Первый заключается в создании нового коммита, содержащего это изменение, например, так:
```
g56123f создай файл bot file
a2235d исправлен contributor.md
a5da0d изменен botfile
b0ca8f добавлено одно слово в botfile
```
Второй способ состоит в исправлении коммита a5da0d, добавлении этого пропущенного слова и запушивании этих изменений на Github в виде одного коммита.
Второй способ представляется предпочтительным, поскольку дело идёт лишь о незначительном изменении.
Чтобы добиться этого, мы поступим следующим образом:
* Изменим файл. В данном случае я изменю файл botfile, добавив к нему слово, которое я пропустил ранее.
* Далее, проиндексируем этот файл при помощи команды ```git add <имяфайла>```
В обычном случае сразу после индексирования мы делаем ```git commit -m "комментраий к нашему коммиту"```, правильно? Но поскольку в данном случае наша задача - исправить предыдущий коммит, - то вместо этого мы выполним такую команду:
* ```git commit --amend```
В результате откроется окно текстового редактора, в котором мы имеем возможность сделать изменения в комментарии. Мы можем в самом деле отредактировать комментарий, или оставить его без изменений.
* Выйдем из редактора
* Запушим наши изменения при помощи команды ```git push origin <имя-ветки>```
Таким образом, оба исправления окажутся в одном коммите.

76
additional-material/translations/Russian/configuring-git.ru.md Normal file
View File

@ -0,0 +1,76 @@
# Конфигурирование GITа
Когда вы впервые попытались сделать коммит, вы могли увидеть такое сообщение:
```bash
$ git commit
*** Please tell me who you are. [Пожалуйста, сообщите, кто вы.]
Исполните следующие команды:
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
чтобы идентифицировать пользователя по умолчанию для данной учетной записи.
Опустите ключ --global если вы хотите указать пользователя только для данного репозитория.
```
Чтобы создать коммит, GIT должен знать кто является его автором. При совместной работе, необходимо знать кем и когда были изменены те или иные части проекта, поэтому GIT предусматривает, что каждый коммит при его создании ассоциируется с именем и емейл адресом пользователя.
Существует несколько способов, которые позволяют ассоциировать команду `git commit` с вашим емейлом и именем, и здесь мы перечислим некоторые из них.
### Глобальная конфигурация
Информация, сохраненная как часть глобальной конфигурации, относится ко всей системе, т.е. ко всем репозиториям, в которых вы работаете. Это предпочтительный способ, подходящий для большинства из вариантов использования.
Для сохранения данных в глобальной конфигурации пользуйтесь коммандой `config` в следующей форме:
`$ git config --global <название переменной> <значение переменной>`
В применении к информации о пользователе, мы исполняем эти команды таким образом:
```
$ git config --global user.email "you@example.com"
$ git config --global user.name "Your Name"
```
### Конфигурация репозитория
Как указывает заголовок, такая конфигурация работает в пределах данного репозитория. Если вы хотите сделать коммит в определенном репозитории, скажем содержащем проект связанный с вашим бизнесом, используя емейл вашей компании, тогда вы можете использовать этот способ конфигурации.
Чтобы изменить конфигурацию на уровне репозитория, следует опустить ключ `--global` в команде `config` таким образом:
`$ git config <название переменной> <значение переменной>`
В применении к информации о пользователе, это выглядит следующим образом:
```
$ git config user.email "you@alternate.com"
$ git config user.name "Your Name"
```
### Конфигурация в командной строке
Этот способ конфигурации относится только к данной команде. Все команды GIT'а позволяют использовать ключ `-c` перед глаголом идентифицирующим команду для временной установки конфигурационных параметеров.
Для изменения параметров конфигурации, распространяющихся только на данную команду, пользуйтесь следующим форматом команд GIT'a:
`$ git -c <переменная-1>=<значение переменной-1> -c <переменная-2>=<значение переменной-2> <команда>`
Для нашего случая комманда для коммита будет вылядеть так:
`git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Ваш комментарий к коммиту"`
### Замечание о порядке предшествования
Порядок предшествования среди трех упомянутых типов команд конфигурации определяется как `конфигурация в командной строке > конфигурация репозитория > глобальная конфигурация`. Это означает, что если какая-либо переменная определена, как в глобальной конфигурации, так и в командной строке, то будет использовано значение, присвоенное в командной строке.
## Не только информация о пользователе
До сих пор, обсуждая конфигурацию GIT'а, мы касались лишь информации о пользователе. Однако GIT позволяет конфигурировать еще неслколько параметров. Вот некторые из них:
1. `core.editor` - указывает название редактора для редактирования комментарий для коммита и т.п.,
2. `commit.template` - указывает файл, который содержит первоначальный темплат для коммита,
3. `color.ui` - логическая переменная, указывающая следует ли испольовать цветные шрифты в сообщениях на терминале GIT'а.
Для простоты мы опустили некоторые детали. Для более подробного ознакомления обратитесь к [git-scm.com](https://git-scm.com/book/ru/v1/Введение-Первоначальная-настройка-Git).

25
additional-material/translations/Russian/moving-a-commit-to-a-different-branch.ru.md Normal file
View File

@ -0,0 +1,25 @@
# Перемещение коммита в другую ветку
Что если вы сделали коммит, а затем поняли, что изменили неправильную ветку?
Как исправить такую ошибку? На этот вопрос отвечает данная инструкция.
## Перемещение последних коммитов в существующую ветку
Для такого перемещения, наберите:
```git reset HEAD~ --soft``` - Отменяет последний коммит, но сохраняет сделанныые изменения.
```git stash``` - Сохраняет состояние директории.
```git checkout <имя правильной ветки>``` - Переключается на другую ветку.
```git stash pop``` - Возвращает последнее сохраненное состояние.
```git add .``` - Добавляет индивидуальные файлы.
```git commit -m "ваш комментарий"``` - Сохраняет и делает коммит изменений.
Теперь ваши изменения - в правильной ветке.
### Перемещение последних коммитов в новую ветку
Для такого перемещения, наберите:
```git branch newbranch``` - Создает новую ветку, сохраняя все коммиты.
```git reset --hard HEAD~[n]``` - Возвращает ветку master назад на n коммитов. Имейте в виду, что изменения содержащиеся в этих коммитах будут полностью удалены из ветки master.
```git checkout newbranch``` - Переключается на ветку, которую вы создали. Эта ветка теперь содержит все коммиты.
Запомните: Любые изменения, которые не были включены в коммит, будут полностью ПОТЕРЯНЫ.

23
additional-material/translations/Russian/removing-a-file.ru.md Normal file
View File

@ -0,0 +1,23 @@
# Удаление файла из-под GIT контроля
Иногда может возникнуть необходимость удалить файл из-под GIT контроля, но сохранить его на компьютере. Это может быть достигнуто с помощью следующей команды:
``git rm <файл> --cached``
## Что же произошло?
GIT более не контролирует изменения в удалённом файле. С точки зрения GIT'а, этот файл отсутствует, но если вы попробуете локализовать этот файл в файловой системе, то вы увидите, что он всё еще на месте.
Заметьте, что в приведенной выше комманде используется ключ `--cached`. Если бы мы не добавили этот ключ, GIT уничтожил бы файл не только из репозитория, но также и из файловой системы.
Если вы сделаете коммит при помощи команды `git commit -m "Удалить file1.js"` и затем запушите его в удалённый репозиторий командой `git push origin master`, файл будет стёрт также и из удалёного репозитория.
## Дополнительная информация
- Если вы хотите удалить более одного файла, это можно сделать, перечислив все файлы в одной команде:
`git rm file1.js file2.js file3.js --cached`
- Вы можете использовать шаблон (*) для удаления файлов с близкими именами, например, если вы хотите удалить все .txt файлы из локального репозитория, наберите:
`git rm *.txt --cached`

46
additional-material/translations/Slovenian/additional-material.sl.md Normal file
View File

@ -0,0 +1,46 @@
# Dodatne informacije
Predvidevamo da ste že končali osnovni vodič. Sedaj boste dobili dodatne informacije o napredni uporabi Git-a.
### [Popravljanje commita](amending-a-commit.sl.md)
Informacije o tem kako spremeniti commit v oddaljenem repositoryu.
> Uporabi, ko moraš spremeniti že narejeni commit.
### [Nastavljanje Git-a](configuring-git.sl.md)
Informacije o tem kako nastaviti uporabnika in druge možnosti v Git-u.
> Uporabi za boljši nadzor nad svojo Git konfiguracijo.
### [Kako imeti svojo različico sinhronizirano z oddaljenim repository-em](keeping-your-fork-synced-with-this-repository.sl.md)
Informacije o tem kako obdržati svojo različico v skladu z glavnim repository-em. To je pomembno, ker lahko veliko ljudi prispeva k projektu.
> Sledi tem korakom, če tvoja verzija nima nobenih sprememb v nadrejenem imeniku (parent directory).
### [Premikanje commita v drugo vejo](moving-a-commit-to-a-different-branch.sl.md)
Informacije o tem kako premakniti commit v drugo vejo.
> Sledi tem korakom in premakni commit v drugo vejo.
### [Odstranjevanje datoteke](removing-a-file.sl.md)
Informacije o tem kako odstraniti datoteko z svojega lokalnega repository-ja.
> Sledi tem korakom in odstrani datoteko pred commitom.
### [Odstrani vejo s svojega repository-ja](removing-branch-from-your-repository.sl.md)
Informacije o tem kako zbrisati vejo s svojega repository-ja.
> Sledi tem korakom šele potem, ko je bil tvoj pull-request že združen.
### [Razreševanje sporov pri združevanju](resolving-merge-conflicts.sl.md)
Informacije o tem kako razrešiti spore pri združevanju (resolve merge conflicts).
> Sledi tem korakom pri razreševanju nadležnih sporov pri združevanju.
### [Povrnitev commita](reverting-a-commit.sl.md)
Informacije o tem kako povrniti commit na oddaljenem repository-ju v prejšnje stanje. Zelo uporabno, če moraš razveljaviti commit, ki je bil že poslan na GitHub.
> sledi tem korakom, če želiš povrniti commit v prejšnje stanje.
### [Stiskanje commit-ov](squashing-commits.sl.md)
Informacije o tem kako stisnite commite z interaktivnim rebase-om.
> Uporabi te korake, če želiš narediti pull-request v odprto-kodni projekt in te pregledovalec prosi, da stisni (squash) vse commite v enega in dodaj informativno commit sporočilo.
### [Razveljavljanje lokalnega commita](undoing-a-commit.sl.md)
Informacije o tem kako razveljaviti commit v svojem localnem repository-ju. Uporabno, ko si naredil zmešnjavo v lokalnem repository-ju in ga želiš postaviti na prejšnje stanje.
> Sledi korakom, ko želiš razveljaviti lokalni commit.
### [Uporabne povezave](../git_workflow_scenarios/Useful-links-for-further-learning.md)
Ta dokument je namenjem vsem blogom, uporabnim stranem, spletnim stranem s triki in namigi, ki naredijo naša življenja lažja. Stran naj bi bila kazalo teh uporabnih povezav, ki lahko pomagajo vsem novincem v odprto-kodnem svetu in vsem, ki imajo željo po dodatnem znanju.

48
additional-material/translations/Slovenian/amending-a-commit.sl.md Normal file
View File

@ -0,0 +1,48 @@
# Popravljanje Commita
Kaj narediti, če pošlješ commit v oddaljeni repository in potem ugotoviš da si se zatipkal ali pa pozabil dodati vrstico kode v svoj zadnji commit.
Kako to popraviti? O tem govori ta vodič.
## Spreminjanje komentarja commit-a, ki je bil pred kratkim poslan na GitHub
To lahko naredimo brez da bi odprli datoteko:
* V terminal vpiši ```git commit --amend -m "followed by your new commit message"```
* Zaženi ```git push origin <branch-name>``` da pošlješ commit s spremembo v repository.
Opomba: Če vtipkaš samo ```git commit --amend```, se odpre tvoj urejevalnik besedil in te pozove da spremeniš komentar commit-a.
Zastavica ``-m`` to prepreči.
## Sprememba enega commit-a
No, kaj storiti, če pozabimo narediti eno malo spremembo v datoteki, kot na primer spremeniti eno besedo, vendar smo že poslali commit v oddaljeni repository?
Prikaz praktičnega primera (zgodovina commit-ov tega repository-a):
```
g56123f create file botfile
a2235d updated contributor.md
a5da0d modified botfile
```
Recimo da smo pozabili dodati eno samo besedo datoteki botfile.
Obstajata dva načina kako se stvari lotiti. Prvi primer je da naredimo nov commit, ki vsebuje spremembo:
```
g56123f create file botfile
a2235d updated contributor.md
a5da0d modified botfile
b0ca8f added single word to botfile
```
Drugi način je, da spremenimo commit a5da0d, mu dodamo pozabljeno besedo in ga pošljemo v GitHub, vse skupaj kot en commit.
Drugi način nam je bolj všeč, ker imamo opravka z manjšo spremembo.
Da to dosežemo, storimo naslednje:
* Spremenimo datoteko. V tem primeru bomo spremenili datoteko botfile in ji dodali spuščeno besedo.
* Nato bomo dodali datoteko v čakalnico z ```git add <filename>```.
Običajno ko dodamo datoteke v čakalnico, je naslednji korak, da naredimo commit s komentarjem ( git commit -m "our commit message" ).
V tem primeru pa želimo popraviti že narejen commit, zato namesto tega izvedemo:
* ```git commit --amend```
Ukaz nam v tem primeru prikaže urejevalnik besedila in nam omogoči da spremenimo komentar. Sami se odločimo, ali spremenimo komentar, ali pustimo prejšnjega.
* Zapustimo urejevalnik besedil.
* Pošljemo spremembe z `` `git push origin <branch-name>` ``.
Na ta način bosta obe spremembi združeni v enem commit-u.

77
additional-material/translations/Slovenian/configuring-git.sl.md Normal file
View File

@ -0,0 +1,77 @@
# Nastavljanje Git okolja
Ko si prvič poskusil narediti commit z Git-om, je možno da se je prikazalo naslednje sporočilo:
```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 mora vedeti kdo si, da lahko ustvari commit. Ko delaš v skupini z več ljudmi, naj bi se vedno vedelo kdo je naredil katero spremembo v projektu in kdaj jo je nardil. V ta namen je bil Git ustvarjen tako, da so commit-i vezani na ime in e-pošto.
Obstaja več načinov kako ukazu `git commit` podati svoje ime in e-pošto in nekaj jih bomo pregledali v naslednjih vrsticah.
### Globalna konfiguracija
Ko nekaj shranimo v globalno konfiguracijo (global config), je ta nastavitev dosegljiva vsem repository-em na katerih delaš. Ta način se priporoča in deluje v večini primerov.
Da nekaj shranimo v globalno konfiguracijo, uporabimo ukaz `config`:
`$ git config --global <variable name> <value>`
V primeru uporabniških podatkov:
```
$ git config --global user.email "you@example.com"
$ git config --global user.name "Your Name"
```
### Konfiguracija repository-ja
Kot nam že samo ime pove, so te konfiguracije omejene samo na en repository. Če želiš narediti commit v točno določen repository, recimo službeni projekt, s svojo službeno e-pošto, potem uporabimo to metodo.
Da nekaj shranimo v konfiguracijo repository-ja, uporabimo ukaz `config` in spustimo zastavico `--global`:
`$ git config <variable name> <value>`
V primeru uporabniških podatkov:
```
$ git config user.email "you@alternate.com"
$ git config user.name "Your Name"
```
### Konfiguracija ukazne vrstice
Te konfiguracije so omejene samo na trenutno ukazno vrstico. Vsi Git ukazi sprejmejo predpono `-c` pred glagolom ukaza. S tem ustvarimo začasno konfiguracijo.
Da nekaj shranimo v konfiguracijo ukazne vrstice:
`$ git -c <variable-1>=<value> -c <variable-2>=<value> <command>`
V našem primeru bi ukaz commit uporabili takole:
`git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"`
### O prednosti
Zaporedje uporabe med zgoraj omenjenimi metodami je sledeče `command-line > repository > global`. To pomeni da, če je spremenljivka shranjena v ukazni vrstici in globalno, bi bila uporabljena vrednost v konfiguraciji ukazne vrstice.
## Dodatno
Do sedaj smo delali samo z nastavitvami uporabnika, vendar obstaja še nekaj drugih konfiguracij. Nekatere med njimi so:
1. `core.editor` - za določitev urejevalnika besedila, ki se uporabi za pisanje komentarjev, itd.
2. `commit.template` - za določitev datoteke v sistemu, ki se uporabi kot začetna predloga za commit
3. `color.ui` - za določitev boolean vrednosti za uporabo barv v Git-ovem izpisu.
Nekaj podrobnosti smo poenostavili za lažje razumevanje. Več si lahko prebereš na [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration).

40
additional-material/translations/Slovenian/keeping-your-fork-synced-with-this-repository.sl.md Normal file
View File

@ -0,0 +1,40 @@
# Kako imeti svojo različico sinhronizirano z oddaljenim repository-em
Najprej moramo razumeti kako poteka sinhronizacija. V tej shemi so trije različni repository-ji: moj javni repository na GitHub-u `github.com/Roshanjossey/first-contributions/`, tvoja različica tega repository-ja na GitHub-u `github.com/Your-Name/first-contributions/` in lokalni repository na tvojem računalniku. Ta način delovanja je značilen za odprto-kodne projekte in se imenuje `Triangle Workflow`.
<img style="float;" src="https://firstcontributions.github.io/assets/additional-material/triangle_workflow.png" alt="triangle workflow" />
Da obdržimo tvoja dva repository-ja sinhronizirana z mojim javnim repository-jem, moramo najprej pridobiti javni repository in ga združiti s tvojim lokalnim repository-jem ( fetch and merge ).
Naslednji korak bo, da pošljemo tvoj lokalni repository v tvojo GitHub različico. Kot smo že prej videli, lahko samo iz GitHub različice zahtevamo "pull request". Zato je tvoja GitHub različica zadnji repository, ki se ga posodobi na zadnjo verzijo.
No pa poglejmo kako se to naredi:
Najprej moraš biti v svoji glavni veji ( master branch ). Da izveš na kateri veji si trenutno, izvedi ta ukaz in poglej prvo vrstico odgovora:
```
git status
```
Če nisi na glavni veji uporabi:
```
git checkout master
```
Potem dodaš moj javni repository svojemu git-u z ukazom `add upstream remote-url`:
```
git remote add upstream https://github.com/Roshanjossey/first-contributions
```
Na ta način povemo git-u da obstaja še ena verzija tega projekta na podanem naslovu in da jo imenujemo `upstream`. Sedaj, ko ima tvoj git ime in naslov, lahko s tega naslova pridobimo zadnjo verzijo javnega repository-ja z ukazom `fetch`:
```
git fetch upstream
```
Pravkar ste pridobili zadnjo verzijo moje različice (`upstream` remote). Sedaj pa je potrebno še združiti javni repository v tvojo glavno vejo (master branch).
```
git rebase upstream/master
```
Tukaj združuješ javni repository s svojo glavno vejo. Glavna veja na tvojem računalniku je sedaj posodobljena. Na koncu pošlješ še svojo glavno vejo v tvojo različico (fork) na GitHub-u in tudi ta bo posodobljena z zadnjimi spremembami:
```
git push origin master
```
Tukaj lahko vidiš da pošiljaš v oddaljeni repository imenovan `origin`.
Na tej točki, so vsi tvoji repository-ji posodobljeni. Dobro opravljeno! To stori vsakič, ko te tvoj GitHub repository opozori, da ni sinhroniziran z ostalimi repository-ji.

24
additional-material/translations/Slovenian/moving-a-commit-to-a-different-branch.sl.md Normal file
View File

@ -0,0 +1,24 @@
# Premikanje commita v drugo vejo
Kaj storiti, če izvedeš commit svojih sprememb, in potem ugotoviš da si izvedel commit v napačni veji? Kako lahko to spremenimo? To je razloženo v tem vodiču.
## Premikanje zadnjega commita v obstoječo vejo
To storiš z naslednjimi ukazi:
```git reset HEAD~ --soft``` - Razveljavi zadnji commit, spremembe ostanejo na voljo.
```git stash``` - Posname stanje direktorija in ga shrani v `stash`.
```git checkout name-of-the-correct-branch``` - Prestavi v drugo vejo.
```git stash pop``` - Vzame zadno shranjeno stanje iz `stash-a`.
```git add .``` - Ali dodaš posamezne datoteke.
```git commit -m "your message here"``` - Shrani in izvede commit sprememb.
Sedaj so tvoje spremembe na pravi veji.
### Premikanje zadnjih nekaj commitov v novo vejo
To storiš z naslednjimi ukazi:
```git branch newbranch``` - Ustvariš novo vejo. Nova veja ima vse prej ustvarjene commite.
```git reset --hard HEAD~#``` - Premakni glavno vejo ( master ) nazaj za # commit-ov. Ti commit-i bodo izbrisani z glavne veje!
```git checkout newbranch``` - Prestaviš se v novo vejo, ki ima vse prej ustvarjene commit-e.
Pomembno: Vse spremembe, ki niso bile commit-ane, bodo IZGUBLJENE!

23
additional-material/translations/Slovenian/removing-a-file.sl.md Normal file
View File

@ -0,0 +1,23 @@
# Odstranjevanje datoteke
Včasih si želiš odstraniti datoteko z Git-a, vendar je ne želiš odstraniti s svojega računalnika. To lahko storiš z uporabo naslednjega ukaza:
``git rm <file> --cached``
## Kaj se je zgodilo?
Git ne bo več sledil spremembam v odstranjeni datoteki. Kar se tiče Git-a, ta datoteka ne obstaja več. Če poiščeš datoteko na svojem disku, vidiš da še vedno obstaja.
V zgornjem primeru smo uporabili zastavico `--cached`. Če je ne bi uporabili, bi Git odstranil datoteko tudi z našega diska.
Če sedaj ustvarimo commit z `git commit -m "Remove file1.js"` in ga pošljemo v oddaljeni repository z ukazom `git push origin master`, bo datoteka odstranjena tudi iz oddaljenega repository-ja.
## Dodatne možnosti
- Če želiš odstraniti več datotek, jih lahko vse vljučiš v en ukaz:
`git rm file1.js file2.js file3.js --cached`
- Lahko uporabiš nadomestni znak (*) da odstraniš podobne datoteke. Na primer, če želiš odstraniti vse datoteke s končnico .txt s svojega repository-ja, uporabi ukaz:
`git rm *.txt --cached`

30
additional-material/translations/Slovenian/removing-branch-from-your-repository.sl.md Normal file
View File

@ -0,0 +1,30 @@
# Odstrani vejo s svojega repository-ja
Če si sledil vodiču do tukaj, sedaj tvoja veja `<add-your-name>` ni več uporabna in jo lahko zbrišeš z lokalnega repository-ja. To ni nujno potrebno, vendar ime te veje kaže njen namen obstoja. Ker je opravila svoje delo, jo lahko zbrišeš.
Najprej združiš `<add-your-name>` z glavno ( master ) vejo, zato se postavi vanjo:
```
git checkout master
```
Združi `<add-your-name>` z master:
```
git merge <add-your-name> master
```
Odstrani `<add-your-name>` z lokalnega repository-ja:
```
git branch -d <add-your-name>
```
Sedaj si zbrisal `<add-your-name>` vejo s svojega računalnika in vse zgleda urejeno. Vendar ta veja še vedno obstaja v tvoji GitHub različici ( fork ). Preden jo zbrišeš tudi tam, vedi da moraš najprej poslati "Pull request" mojemu repository-ju. Tako da, če je še nisem združil v moj repository, te veje na GitHub-u še ne zbriši!
Če pa je tvoja GitHub veja že združena v moj projekt, in jo želiš zbrisati, uporabi naslednji ukaz:
```
git push origin --delete <add-your-name>
```
Sedaj veš kako počistiti neuporabne veje s svojega repository-ja.
S časom bo veliko commit-ov dodanih v moj javni repository, in glavni veji na tvojem računalniku in GitHub različici ne bosta več posodobljeni na zadnjo verzijo. Da bodo vsi tvoji repository-ji sinhronizirani z mojim, sledi korakom v tem vodiču:
#### [Kako imeti svojo različico sinhronizirano z oddaljenim repository-em](keeping-your-fork-synced-with-this-repository.sl.md)

34
additional-material/translations/Slovenian/resolving-merge-conflicts.sl.md Normal file
View File

@ -0,0 +1,34 @@
# Kaj je spor pri združevanju?
Ko poskusiš združiti drugo vejo v vejo v kateri trenutno delaš, vzameš spremembe iz drugega konteksta in jih združiš z datotekami s katerimi trenutno delaš.
Če dve osebi spremenita vrstico v isti datoteki, ali če se ena oseba odloči zbrisati datoteko medtem, ko se jo druga odloči spremeniti, Git ne ve več kaj je pravilno. Git bo označil datoteko kot spor. Spor, ki ga moraš razrešiti preden lahko nadaljuješ z delom.
# Kako razrešiti spor pri združevanje?
Ko Git zazna spor pri združevanju, bo mesto problema v datoteku označil tako, da ga bo obdal z:
“<<<<<<<< HEAD” and “>>>>>>>>>>[other branch name]”
Vsebina za prvo oznako bo izhajala iz tvoje trenutne veje. Nato sledi vrstica z "=======", tej pa sledi vsebina iz veje, ki je v nazkrižju s tvojo. Za tem pridejo znaki ">>>>>" in ime te druge veje.
Naša naloga je da uredimo te vrstice. Ko smo končali, naj bi datoteka izgledala točno tako, kot hočemo da izgleda. Lahko da se bo potrebno posvetovati s sodelavcem, ki je napisal vsebino, ki je v navzkrižju z našo, da se bomo lahko odločili katera koda je prava. Mogoče bo tvoja, mogoče bo njegova - ali pa mešanica obeh.
Primer:
```
<<<<<<< HEAD:mergetest
This is my third line
=======
This is a fourth line I am adding
>>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest
```
`<<<<<<<`: Nakazuje začetek vrstic, kjer je spor. Te vrstice so iz tvoje datoteke, ki si jo poskusil združiti.
`=======`: Nakazuje prelomno točko za primerjavo. Razdeli spremembe iz tvojega commit-a (zgoraj) in spremembe nekoga drugega (spodaj) za lažjo predstavo.
`>>>>>>>`: Nakazuje konec vrstic, kjer je spor.
Spor razrešiš z urejanjem datoteke in ročnim združevanjem delov datoteke, kjer je Git naletel na problem. To lahko pomeni da je potrebno zavreči tvoje spremembe, spremembe nekoga drugega ali pa ustvariti mešanico obeh. Prav tako je potrebno zbrisati '<<<<<<<', '=======', in '>>>>>>>'.
Ko je bil spor razrešen, uporabi ukaz `git add`. Ne pozabi izvesti teste, s katerimi se prepričaš da je bil spor pravilno razrešen.
Lahko si tudi namestiš različne plugine, ki so odvisni od tvojega IDE-ja, za lažje reševanje sporov.
# Kako razveljaviti združitev ( merge )?
Če želiš razveljaviti združitev uporabi ukaz `git merge —abort`.

38
additional-material/translations/Slovenian/reverting-a-commit.sl.md Normal file
View File

@ -0,0 +1,38 @@
# Povrnitev commit-a
Povrnitev commit-a pomeni, da ustvarimo nov commit, ki odstrani vse spremembe, ki smo jih napravili v prejšnjem commit-u. Kot da bi naredili ```CTRL + Z ``` v Git-u.
Povrnitev v Git-u je sorazmerno enostavna, ker je vsak commit, ki ga pošljemo v oddaljen repository, povezan s svojim unikatnim alfanumeričnim SHA (Secure Hash Algorithm) ključem.
To pomeni da lahko povrnemu vsak commit, če le imamo njegov SHA.
V vsakem primeru pa moramo biti previdni pri povračanju, ker si lahko poškodujemo repository.
Da lahko izberemo SHA točno določenega commit-a, ki ga hočemo odstraniti, nam zelo prav pride seznam vseh commit-ov, ki smo jih napravili.
Ta seznam dobimo s tem ukazom:
```git log --oneline ```
Ukaz ```git log``` bi nam prav tako vrnil SHA, vendar v daljši obliki izpisa.
Uporaba zastavice ```--oneline ``` Git-u pove da hočemo pregleden izpis v eni vrstici.
Prvih 7 znakov v vsaki vrstici izpisa se imenuje skrajšani hash commit-a.
Za primer, to je izpis ```git log --oneline ``` za ta repository:
```
389004d added spacing in title
c1b9fc1 Merge branch 'master' into tutorials
77eaafd added tutorial for reverting a commit
```
To nam torej pokaže, da lahko z ```git log --oneline```, pridobimo seznam vseh commit-ov narejenih v repository-ju s prvimi 7 znaki njihovih SHA.
No, sedaj lahko poskusimo zbrisati commit "added spacing in title" z naslednjimi koraki:
* Kopiraj SHA commit-a, v tem primeru ```389004d```
* Potem uporabi ukaz ```git revert 389004d```
Sedaj se zažene naš urejevalnik besedila in nas pozove naj uredimo komentar commit-a.
Lahko se odločiš, da pustiš privzeto sporočilo Git-a, ki se začne z besedo `Revert`, ali pa spremeniš komentar po svojih željah.
* Nato shranimo in zapremo urejevalnik besedila.
* Vrnemo se v ukazno vrstico.
* Uporabimo ukaz ```git push origin <branch-name>``` da pošljemo spremembe na GitHub.
In to je to, spremembe bodo odstranjene. V tem primeru bi se moj repository povrnil na stanje v commit-u ```c1b9fc1```.

94
additional-material/translations/Slovenian/squashing-commits.sl.md Normal file
View File

@ -0,0 +1,94 @@
# Kaj je stiskanje?
V Git-u stiskanje ( squashing ) pomeni popravljanje zgodovine svojih commit-ov, tako da na koncu ostaneš samo z enim commit-om in enim komentarjem narejenih sprememb.
To je običajni postopek v odprto kodnih projektih, ker je velik del zgodovine vsake veje pomemben samo programerju, ki jo je ustvaril. Poleg tega na ta način poenostavimo sledenje izvedenih sprememb in jih tudi lažje povrnemo v prejšnje stanje, če je to potrebno.
# Kako stisneš commit-e?
Najprej uporabimo ukaz `git log` da lahko pregledamp commit-e v svoji veji, ki bi jih rad združili ( merge ).
```
git log
```
Videti bi morali serijo commit-ov, kot na primer:
```
commit blablabla
Author: omguhh
Date: 10/10/20
Commit message 1
commit blablabla2
Author: omguhh
Date: 10/10/20
Commit message 2
```
Sedaj, ko vidimo commit-e, ki jih želimo združiti v enega, lahko začnemo tako da uporabimo ukaz ```git rebase```. Predvidevam da že poznaš ukaz ```git rebase``` in lahko začnemo stiskanje commit-ov v interaktivnem načinu ukaza `git rebase`, ki ga aktiviramo tako:
```
git rebase -i
```
V interaktivnem načinu ukaza rebase lahko določimo začetno in končno točko do katere nazaj želimo iti. HEAD je začetna točka, "~2" pa pomeni da gremo dva commita nazaj v zgodovino. Ukaz se uporabi takole:
```
git rebase -i HEAD~2
```
Ko uporabimo ta ukaz, se nam bo prikazalo nekaj podobnega tem vrsticam:
```
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
```
Ukazi navedeni v zgornjem sporočilu:
- p, pick = uporabi commit
- r, reword = uporabi commit, vendar uredi komentar
- e, edit = uporabi commit, vendar se ustavi za spremembo
- s, squash = uporabi commit, vendar ga stisni v prejšnji commit
- f, fixup = enak kot "squash", vendar zavrzi komentar tega commit-a
- x, exec = zaženi ukaz ( preostanek vrstice ) v shell-u
To pomeni da, če želimo stisniti ```blablabla2``` v ```blablablabla```, bi zgornje sporočilo spremenili tako:
```
pick blablabla Changing test01.txt file
squash blablabla2 Adding dummy01.txt file
```
Če gre vse po planu, dobimo rezultat, ki zgleda takole:
```
# 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
```
To sporočilo lahko po želji spremenimo preden zapremo urejevalnik besedila, kar shrani spremembe.
Če še enkrat uporabimo ukaz `git log`, bi morali dobiti komentar commit-a, ki smo ga vnesli preden smo zaprli urejevalnik besedila, in commit-i bi morali biti združeni v enega.

136
additional-material/translations/Slovenian/stashing-a-file.sl.md Normal file
View File

@ -0,0 +1,136 @@
# Shranjevanje za pozneje ( Stashing )
Kaj storiti, če delaš na velikem projektu, in moraš nenadoma zamenjati vejo, na kateri trenutno delaš, za neko drugo vejo? Koda, na kateri si delal, ni dokončana in dokler je ne preveriš dobro, ne želiš izvesti commit. Vendar se ne moreš premakniti na drugo vejo brez da bi izvedel commit, Git ti ne pusti prekiniti delovni tok ( workflow ). Kaj storiti? Kako preprečiti nepotreben commit in hkrati preskočiti na drugo vejo? Na to vprašanje odgovarja ta vodič.
## Shranjevanje svojega dela
Predpostavimo da delaš na veji projekta, kjer si naredil nekaj spremembe. Če uporabiš ukaz ```git status```, lahko vidiš kje so bile spremembe narejene.
```
$ 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
#
```
Sedaj se želiš prestaviti na drugo vejo, vendar še nočeš izvesti commit s temi spremembami. Zato bi shranil spremembe za pozneje ( stash ).
Spremembe lahko shraniš na svoj stack z uporabo ukaza ```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")
```
Sedaj je tvoje delovno okolje ( working directory ) čisto. To lahko preveriš z uporabo ukaza ```git status```:
```
$ git status
# On branch master
nothing to commit, working directory clean
```
Sedaj se lahko prestaviš na katerokoli vejo in delaš naprej; tvoje shranjene spremembe so shranjene na stack-u. Spremembe, ki so shranjene na stack-u, si lahko ogledaš z uporabo ukaza ```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
```
V primeru da želiš uveljaviti (re-apply) spremembe, ki si jih ravnokar shranil, lahko uporabiš ukaz ```git stash apply```. S tem ukazom lahko uveljaviš zadnjo shranjeno spremembo. Če želiš uveljaviti katerokoli drugo spremembo, jo moraš točno določiti: ```git stash apply <stash-name>```, kjer je ```<stash-name>``` ime spremembe, ki jo želiš uveljaviti.
```
$ 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 je sedaj spremenil datoteko, ki smo jo povrnili v prvotno stanje, ko smo spremembe shranili v stack. V tem primeru smo imeli čisto delovno okolje, ko smo poskusili uveljaviti stash, in uveljavili smo jih na isti veji, s katere smo jih shranili. Nič od tega, čisto delovno okolje in ista veja, ni nujno da uveljavimo spremembe iz stasha. Spremembe lahko shranimo na eni veji, se prestavimo na drugo vejo in tam uveljavimo iste spremembe. Lahko bi tudi spremenili ali odstranili datoteke v svojem delovnem okolju, ko bi uveljavili stash. V primeru da pride do sporov pri združevanju shranjenih sprememb v obstoječe datoteke, bo Git te spore javil.
Spremembe so bile uveljavljene, vendar datoteka, ki je bila pripravljena za commit, sedaj ni več pripravljena. Da dosežemo še to, moramo uporabiti ukaz ```git stash apply``` z ```--index```, da sporočimo ukazu da mora uveljaviti tudi to stanje. Ko uporabimo ta ukaz, se vrnemo v točno tako stanje, kot je bilo na začetku:
```
$ 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
#
```
Ukaz `apply` samo uveljavi spremembe, ki so bile shranjene, vendar te še vedno ostanejo na stack-u. Z ukazom ```git stash list``` si lahko prikažeš vsebino stack-a. Da nekaj z njega zbrišemo, uporabimo ukaz ```git stash drop```, ki mu dodamo ime stash-a.
```
$ 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)
```
Z ukazom ```git stash pop``` lahko hkrati uveljavimo spremembe in jih odstranimo s stack-a.
## Razveljavljanje Stash-a
V nekaterih primerih hočeš uveljaviti shranjene spremembe, nekaj narediti, in razveljaviti spremembe, ki so prišle iz stash-a. Git nima ukaza ```git unapply```, vendar je možno doseči isti učinek z kombiniranjem ukazov. Najprej prikažemo željeni stash in ga nato vzratno uveljavimo:
```$ git stash show -p stash@{0} | git apply -R```
Če ne določimo, kateri stash želimo, Git predvideva da želimo zadnjega:
```$ git stash show -p | git apply -R```
Lahko ustvariš alias in v bistvu dodaš ukaz ```stash-unapply``` v svoj Git. Na primer:
```
$ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
$ git stash apply
$ #... work work work
$ git stash-unapply
```
## Ustvari vejo iz Stash-a
Če si shranil spremembe in jih nekaj časa pustil pri miru, vmes pa delal naprej na veji s katere si jih shranil, se ti lahko naredi da boš imel težave z uveljaljanjem sprememb. Če uveljavljaš spremembe na datoteki, ki si jo vmes spremenil, boš dobil spor pri združevanju in ga boš moral razrešiti. Obstaja lažji način povračanja sprememb iz stash-a z uporabo ukaza ```git stash branch```, ki ustvari novo vejo, pridobi commit na katerem si bil, ko si shranil spremembe, na njem uveljavi spremembe in potem zbriše stash, če je bil uspešno uveljavljen:
```
$ 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)
```
To je prikladna bližnjica s katero lahko enostavo pridobimo shranjene spremembe in jih uporabimo v novi veji.

55
additional-material/translations/Slovenian/undoing-a-commit.sl.md Normal file
View File

@ -0,0 +1,55 @@
# Razveljavljanje lokalnega commit-a
Vse kar rabiš storiti, da razveljaviš lokalni commit, je:
```
git reset
```
Ta ukaz bo resetiral stanje v čakalnici na tvoj zadnji commit, vendar bodo spremembe ostale v delovnem okolju. Če želiš, lahko ponovno ustvariš commit s temi spremembami.
Lahko pa tudi odstraniš samo eno datoteko s svojega prejšnjega commit-a. Uporabiš ukaz:
```
git reset <file>
```
Ukaz bo odstranil samo določeno datoteko s čakalnice, vendar bodo spremembe narejene na datoteki ostale.
Primer uporabe ```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"
```
Predpostavimo da si pokvaril svoj lokalni repository in ga želiš resetirati na svoj zadnji commit.
Lahko uporabiš spodnji ukaz:
```
git reset --hard
```
Ukaz bo izpraznil čakalnico in tudi povrnil vse spremembe v datotekah na stanje v zadnjem commit-u.
Možnost ```--hard``` pove Git-u da mora odstraniti tudi vse spremembe v delovnem okolju.
Ta ukaz uporabi samo takrat, ko si prepričan da želiš odstraniti vse spremembe nastale od zadnjega commit-a!
Primer uporabe ukaza ```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 thing
$ git reset --hard HEAD~2
```
Ukaz ```git reset --hard HEAD~2``` premakne trenutno vejo nazaj za 2 commit-a in hkrati povrne vse spremembe na to točko. Odstrani tudi 2 posnetka, ki smo ju ravnokar ustvarili iz zgodovine projekta.
P.s: Nikoli ne izvedi ```git reset --hard``` , če si že poslal svoje commit-e v skupni repository, ker boš s tem ustvaril probleme vsem, ki uporabljajo ta repository!

23
additional-material/translations/Ukrainian/removing-a-file.ua.md Normal file
View File

@ -0,0 +1,23 @@
# Видалення файлу з-під GIT контролю
Іноді може виникнути необхідність видалити файл з-під GIT контролю, але зберегти його на комп'ютері. Це може бути досягнуто за допомогою наступної команди:
`` Git rm <файл> --cached``
## Що ж сталося?
GIT більш не контролює зміни у віддаленому файлі. З точки зору GIT'а, його немає, але якщо ви спробуєте локалізувати цей файл в файловій системі, то ви побачите, що він все ще на місці.
Зауважте, що в наведеній вище комманде використовується ключ `--cached`. Якби ми не додали цей ключ, GIT знищив би файл не тільки зі сховищ, але також і з файлової системи.
Якщо ви зробите Комміт за допомогою команди `git commit -m" Видалити file1.js "` і потім запущено його в віддалений репозиторій командою `git push origin master`, файл буде стертий також і з віддаленого сховища.
## Додаткова інформація
- Якщо ви хочете видалити більше одного файлу, це можна зробити, перерахувавши всі файли в одній команді:
    `Git rm file1.js file2.js file3.js --cached`
- Ви можете використовувати шаблон (*) для видалення файлів з близькими іменами, наприклад, якщо ви хочете видалити всі .txt файли з локального сховища, наберіть:
    `Git rm * .txt --cached`

46
additional-material/translations/Urdu/additional-material.ur.md Normal file
View File

@ -0,0 +1,46 @@
# اضافی معلومات
ہم سمجھتے ہیں کہ آپ یہاں آنے سے پہلے بنیادی سبق کے ساتھ پہلے ہی ختم ہو چکے ہیں. اضافی معلومات آپ کو اعلی درجے کی گیٹ کی تکنیک کے بارے میں کچھ معلومات دے گی.
### [ایک ارتکاب ترمیم] (amending-a-commit.md)
یہ دستاویز دور دراز ذخیرہ پر ایک عہد میں ترمیم کے بارے میں معلومات فراہم کرتا ہے.
> اس کا استعمال کریں جب آپ نے ایک عہد کو ایڈجسٹ کرنے کی ضرورت ہے.
### [Git ترتیب دیں] (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)
یہ دستاویز آپ کے مقامی ذخیرہ پر ایک وعدے کو کس طرح رد کرنے کے بارے میں معلومات فراہم کرتا ہے. جب آپ محسوس کرتے ہیں کہ آپ نے اپنے مقامی ذخیرہ کو مسلط کیا ہے اور مقامی ذخیرہ کو ری سیٹ کرنے کا ارادہ رکھتے ہیں تو یہ وہی ہے.
> اگر یہ ایرر برقرار رہے تو ہمارے ہیلپ ڈیسک سے رابطہ کریں. غلط استعمال کی اطلاع دیتے ہوئے ایرر آ گیا ہے.
### [مفید روابط] (Useful-links-for-further-learning.md)
یہ دستاویز تمام بلاگز خطوط، مددگار سائٹس، تجاویز اور چالوں کی ویب سائٹوں کے لئے وقف ہے جو ہماری جانوں کو آسان بنا دیتا ہے. کہ ہم اپنی تمام ضروریات کے لئے حوالہ دیتے ہیں، یہ ایک ابتدائی یا ایک ماہر بنیں. یہ صفحہ ان تمام مفید لنکس کی ایک انڈیکس کے طور پر کام کرنا چاہیے جو ہر فرد کو کھلے منبع ڈومین میں یا کسی کو مزید جاننے کے لئے مدد کرے گا.

51
additional-material/translations/Urdu/amending-a-commit.ur.md Normal file
View File

@ -0,0 +1,51 @@
کمانڈر ترمیم #
اگر آپ اپنے دور دراز ذخیرہ میں تبدیلی کرتے ہیں تو صرف اس کے بعد احساس کرنے کے لۓ آپ کے پاس وعدہ کردہ پیغام میں ٹائپو ہے یا آپ کو اپنے حالیہ حاکموں میں ایک لائن شامل کرنا بھول گیا ہے.
تم اس میں کیسے ترمیم کرتے ہو؟ یہ وہی ہے جو سبق کا احاطہ کرتا ہے.
## آپ Github کے لئے دھکیل دیا ہے کے بعد ایک حالیہ پیغام کا ارتکاب تبدیل کرنا.
کسی فائل کو کھولنے کے بغیر ایسا کرنے کے لئے:
* میں ٹائپ کریں `` `git commit --amend -m "اپنا نیا ارتکاب کے بعد پیغام "` `` ارتکاب
* ذخیرہ کرنے کے لئے تبدیل کرنے کے لئے چلائیں `` `git push origin <branch-name>` ``.
نوٹ: اگر آپ صرف ``` git commit --amend ``` میں ٹائپ کریں تو، آپ کے ٹیکسٹ ایڈیٹر آپ کو وعدہ پیغام میں ترمیم کرنے کے لئے فوری طور پر کھولیں گے.
`` -m`` جھگڑے کو شامل کرنے سے روکتا ہے.
## ایک واحد پر ترمیم کا ارتکاب
لہذا، اگر ہم ایک ہی لفظ کو تبدیل کرنے کی طرح ایک فائل میں ایک معمولی تبدیلی کرنے کے لئے بھول گئے ہیں اور ہم نے پہلے سے ہی ہمارے دور دراز ذخیرہ کرنے کے لئے وعدے کو دھکا دیا ہے؟
یہاں وضاحت کرنے کے لئے میری اقلیت کی لاگت ہے:
`` `
g56123f create file bot file
a2235d updated contributor.md
a5da0d modified bot file
`` `
آتے ہیں کہ میں بوٹ فائل میں ایک ہی لفظ شامل کرنے کے لئے بھول گیا
اس کے بارے میں جانے کے لۓ 2 طریقے ہیں. سب سے پہلے ایک مکمل طور پر نیا وعدہ ہے جو اس طرح کی تبدیلی پر مشتمل ہے:
`` `
g56123f create file botfile
a2235d updated contributor.md
a5da0d modified botfile
b0ca8f added single word to botfile
`` `
دوسرا طریقہ 5da0d وعدہ میں ترمیم کرنا ہے، اس نئے لفظ کو شامل کریں اور یہ ایک عہد کے طور پر جتھوٹ کو دھکا دیں.
دوسری آواز بہتر ہے کیونکہ یہ صرف ایک معمولی تبدیلی ہے.
اس کو حاصل کرنے کے لئے، ہم مندرجہ ذیل کریں گے:
* فائل میں ترمیم کریں. اس صورت میں، میں نے پہلے ہی اتار دیا گیا لفظ شامل کرنے کے لئے میں botfile میں ترمیم کریں گے.
* اگلا، فیلڈ اسٹینج علاقے میں `` `git add <filename>` ``
عام طور پر اسٹینجنگ علاقے میں فائلوں کو شامل کرنے کے بعد، ہمارا اگلا کام ہمارا وعدہ ہے - ہمارا وعدہ پیغام "صحیح ہے؟
لیکن چونکہ ہم یہاں حاصل کرنا چاہتے ہیں اس سے پچھلے وعدوں میں ترمیم کرنا ہے، ہم اس کے بجائے چلائیں گے:
* `` `git commit --amend ` ``
 اس کے بعد ٹیکسٹ ایڈیٹر کو لانے اور پیغام کو ترمیم کرنے کے لئے آپ کو فوری طور پر کریں گے. آپ پیغام کو چھوڑنے کا فیصلہ کر سکتے ہیں کیونکہ اس سے پہلے تھا یا اسے تبدیل کر دیا گیا تھا.
* ایڈیٹر سے باہر نکلیں
* اپنی تبدیلیوں کو دھکا دیں `` `git push origin <branch-name>` ``
اس طرح، دونوں تبدیلیاں ایک ہی انجام میں ہو گی.

45
additional-material/translations/Useful-links-for-further-learning.id.md Normal file
View File

@ -0,0 +1,45 @@
# 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)
Keep adding more links, that you find helpful.

33
additional-material/translations/Vietnamese/resolving-merge-conflicts.vi.md Normal file
View File

@ -0,0 +1,33 @@
# Mâu Thuẫn Khi Tích Hợp là gì?
Khi bạn cố gắng tích hợp một nhánh khác vào nhánh làm việc hiện tại của bạn, bạn đang thực hiện các thay đổi từ bối cảnh khác và kết hợp chúng với các tệp tin hiện tại bạn đang làm việc.
Nếu hai người đã thay đổi cùng một dòng trong cùng một tệp hoặc nếu một người quyết định xóa nó trong khi người kia quyết định sửa đổi nó, Git không thể xác định đâu là phiên bản chính xác. Git sau đó sẽ đánh dấu tệp là có xung đột - điều mà bạn sẽ phải giải quyết trước khi bạn có thể tiếp tục công việc của mình.
# Làm thế nào để giải quyết xung đột khi tích hợp?
Khi đối mặt với việc xảy ra xung đột khi tích hợp, git sẽ đánh dấu khu vực có vấn đề trong tệp bằng cách đặt nó vào trong "<<<<<<<<< HEAD" và ">>>>>>>>>>[other branch name]"
Các nội dung sau điểm đánh dấu đầu tiên bắt nguồn từ nhánh làm việc hiện tại của bạn. Sau dấu ngoặc nhọn, Git cho chúng ta biết những thay đổi đến từ đâu (từ nhánh nào). Dòng có "=======" phân tách hai thay đổi xung đột. Công việc của chúng tôi bây giờ là giải quyết những dòng này: khi chúng ta hoàn thành, tệp sẽ trông chính xác như chúng ta muốn. Nên tham khảo ý kiến của người đồng đội đã viết những thay đổi mâu thuẫn để quyết định phiên bản nào sẽ là bản cuối cùng. Nó có thể là của bạn - hoặc có thể là hỗn hợp giữa hai người.
Ví dụ:
```
<<<<<<< HEAD:mergetest
This is my third line
=======
This is a fourth line I am adding
>>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest
```
`<<<<<<<`: Cho biết nơi bắt đầu của các dòng có xung đột khi tích hợp. Những dòng đầu tiên là các dòng từ tệp tin mà bạn đang thử tích hợp các thay đổi vào.
`=======`: Cho biết điểm phân chia được sử dụng để so sánh các thay đổi. Phân chia các thay đổi mà người dùng đã cam kết (ở trên) đối với các thay đổi đến từ nhánh tích hợp (bên dưới) để thấy rõ sự khác biệt.
`>>>>>>>`: Cho biết kết thúc của các dòng có xung đột khi tích hợp.
Bạn giải quyết xung đột bằng cách chỉnh sửa tệp và sau đó tích hợp thủ công các phần của tệp mà git gặp sự cố khi tích hợp. Điều này có thể có nghĩa là loại bỏ các thay đổi của bạn hoặc của người khác hoặc đi tới việc kết hợp thay đổi của cả hai. Bạn cũng sẽ cần xóa '<<<<<<<', '=======' và '>>>>>>>' trong tệp.
Một khi bạn đã giải quyết xung đột, chạy lệnh `git add`. Đừng quên chạy thử nghiệm, vì bạn phải chắc chắn rằng bạn đã giải quyết được xung đột.
Bạn cũng có thể tải xuống các plugin khác nhau tùy thuộc vào IDE bạn đang sử dụng để có cách dễ dàng hơn để giải quyết xung đột hợp nhất.
# Làm thế nào để hoàn tác lại tích hợp?
Nếu bạn muốn hoàn tác lại tích hợp thì bạn có thể thực hiện `git merge —abort`

48
additional-material/translations/additional-material.np.md Normal file
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 परियोजनाहरूमा प्रयोग गरिन्छ। यसले कमिटहरूमा मात्र आवश्यक फाइलहरू विचार गर्न मद्दत गर्दछ।

50
additional-material/translations/amending-a-commit.np.md Normal file
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>``` सँग पुश गर्नुहोस्
यसरी दुबै परिवर्तनहरू एउटै कमिटमा छन्।

77
additional-material/translations/configuring-git.np.md Normal file
View File

@ -0,0 +1,77 @@
# Git वातावरण सेट अप गर्दै
पहिलो पटक तपाईंले Git सँग कमिट गर्ने प्रयास गर्नुभयो, तपाईंले निम्न सन्देश देख्न सक्नुहुन्छ:
```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.
config --global to set the identity only in this repository.
```
Git लाई कमिट सिर्जना गर्न को लागी तपाई को हुनुहुन्छ भनेर जान्न आवश्यक छ। जब तपाइँ धेरै व्यक्तिहरूसँग समूहमा काम गर्नुहुन्छ, तपाइँलाई सधैं थाहा हुनुपर्छ कि कसले परियोजनामा ​​​​कुन परिवर्तन गर्यो र उनीहरूले यो कहिले गरे। यस अन्तको लागि, Git सिर्जना गरिएको थियो ताकि कमिटहरू नाम र ईमेलमा बाँधिएका छन्।
त्यहाँ 'git कमिट' आदेशमा तपाईंको नाम र इमेल प्रदान गर्ने धेरै तरिकाहरू छन्, र हामी ती मध्ये केहीलाई निम्न लाइनहरूमा जानेछौं।
### ग्लोबल कन्फिगरेसन
जब हामीले ग्लोबल कन्फिगरेसन (ग्लोबल कन्फिगरेसन) मा केहि बचत गर्छौं, यो सेटिङ तपाईंले काम गर्ने सबै भण्डारहरूमा उपलब्ध हुन्छ। यो विधि सिफारिस गरिएको छ र अधिकतर अवस्थामा काम गर्दछ।
ग्लोबल कन्फिगरेसनमा केहि बचत गर्न, 'config' आदेश प्रयोग गर्नुहोस्:
`$ git config --global <variable name> <value>`
प्रयोगकर्ता डेटा को मामला मा:
```
$ git config --global user.email "you@example.com"
$ git config --global user.name "Your Name"
```
### भण्डार कन्फिगरेसन
नामले नै हामीलाई बताउँछ, यी कन्फिगरेसनहरू केवल एउटा भण्डारमा सीमित छन्। यदि तपाइँ एक विशेष भण्डारमा प्रतिबद्ध गर्न चाहनुहुन्छ भने, तपाइँको कामको इ-मेलको साथ कार्य परियोजना भन्नुहोस्, त्यसपछि हामी यो विधि प्रयोग गर्दछौं।
भण्डार कन्फिगरेसनमा केहि बचत गर्न, `config` आदेश प्रयोग गर्नुहोस् र `--global` झण्डा छोड्नुहोस्:
`$ git config <variable name> <value>`
प्रयोगकर्ता डेटा को मामला मा:
```
$ git config user.email "you@alternate.com"
$ git config user.name "Your Name"
```
### कमाण्ड लाइन कन्फिगरेसन
यी कन्फिगरेसनहरू हालको आदेश रेखामा मात्र सीमित छन्। सबै Git आदेशहरूले आदेश क्रियाको अगाडि `-c` उपसर्ग स्वीकार गर्दछ। यसले अस्थायी कन्फिगरेसन सिर्जना गर्दछ।
आदेश रेखा कन्फिगरेसनमा केहि बचत गर्न:
`$ 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`. यसको मतलब यदि चर कमाण्ड लाइन र ग्लोबलमा भण्डार गरिएको छ भने, कमाण्ड लाइन कन्फिगरेसनमा मान प्रयोग गरिनेछ।
## साथै
अहिलेसम्म हामीले प्रयोगकर्ता सेटिङहरूमा मात्र काम गरेका छौं, तर त्यहाँ केही अन्य कन्फिगरेसनहरू छन्। ती मध्ये केही हुन्:
1. `core.editor` - टिप्पणी लेख्न प्रयोग गर्न पाठ सम्पादक निर्दिष्ट गर्न, आदि।
2. `commit.template` - प्रारम्भिक कमिट टेम्प्लेटको रूपमा प्रयोग गर्न प्रणालीमा फाइल निर्दिष्ट गर्न
3. `color.ui` - Git को आउटपुटमा रङहरू प्रयोग गर्न बुलियन मान निर्दिष्ट गर्न।
हामीले सजिलै बुझ्नको लागि केही विवरणहरू सरलीकृत गरेका छौं। तपाईं मा थप पढ्न सक्नुहुन्छ [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration).

19
additional-material/translations/delete-branch-locally.fa.md Normal file
View File

@ -0,0 +1,19 @@
# حذف کردن شاخه که به صورت محلی ایجاد شده است
این در زمانی سودمند خواهد بود که شما نام یک شاخه (برنچ) را اشتباه نوشته اید.
این کار به *3* روش قابل انجام است
```
git branch -D <branch_name>
```
```
git branch --delete --force <branch_name> # Same as -D
```
```
git branch --delete <branch_name> # Error on unmerge
```
پرچم `D-` مخفف `delete --force--` است که شاخه را حتی اگر مرج نشده باشد حذف میکند. (حذف اجباری)، ولی شما میتوانید از پرچم `d-` استفاده کنید که مخفف `delete--` است که با توجه با وضعیت مرج شاخه ارور خواهد داد.

129
cli-tool-tutorials/git-bash-windows-tutorial.md Normal file
View File

@ -0,0 +1,129 @@
[![Open Source Love](https://badges.frapsoft.com/os/v1/open-source.svg?v=103)](https://github.com/ellerbrock/open-source-badges/)
[<img align="right" width="150" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/join-slack-team.png">](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA)
[![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)
# First Contributions
| <img alt="Git Bash" src="https://cdn.icon-icons.com/icons2/2699/PNG/512/git_scm_logo_icon_170096.png" width="200"> | Git Bash Edition |
| ---------------------------------------------------------------------------------------------------------------------- | ---------------- |
It's hard. It's always hard the first time you do something. Especially when you are collaborating, making mistakes isn't a comfortable thing. But open source is all about collaboration & working together. We wanted to simplify the way new open-source contributors learn & contribute for the first time.
Reading articles & watching tutorials can help, but what comes better than actually doing the stuff without messing up anything. This project aims at providing guidance & simplifying the way rookies make their first contribution. Remember the more relaxed you are the better you learn. If you are looking for making your first contribution just follow the simple steps below. We promise you, it will be fun.
If you don't have Git Bash on your windows machine, [install it](https://git-scm.com/download/win).
<img align="right" width="300" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/fork.png" alt="fork this repository" />
## Fork this repository
Fork this repo by clicking on the fork button on the top right of this page.
This will create a copy of this repository in your account.
## Clone the repository
Now clone this repo to your machine.
IMPORTANT: DO NOT CLONE THE ORIGINAL REPO. Go to your fork and clone it.
To clone the repo, click on "Code" and then copy the string down below.
`<img style="left" src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-clone-1.png" alt="copy string" />`
Open the git bash application you just downloaded. It should look like the image down below if its on a windows machine.
`<img style="left" src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-terminal-1.png" alt="open git bash terminal" />`
Go to the folder that you want to save this project on by uisng this command
`cd <folder>`
`<img style="left" src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-terminal-2.png" alt="cd into a folder" />`
Use the string you copied in the step above to clone the repository using this command
`git clone <repo-url>`
`<img style="left" src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-clone-2.png" alt="clone the repository" />`
Go to the directory where the repo is and open it up on vs code to make your changes.
`<img style="left" src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-terminal-3.png" alt="cd into the newly cloned repo" />`
## Create a branch
Now create a branch by uing this simple command. This command not only creates a branch for you but also lets you switch to that branch.
```
git checkout -b <branch-name>
```
Name your branch `<add-your-name>`. For example, "add-james-smith"
`<img style="left" src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-branch.png" alt="create a branch" />`
## Make necessary changes and commit those changes
Now open `Contributors.md` file in a text editor, scroll to the bottom of the page and add your name to it, then save the file.
Example: If your name is James Smith, It should look like this.
\[James Smith](https://github.com/jamessmith)
You can see that there are changes to Contributors.md by simply running this command
`git status`
`<img style="left" src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-status.png" alt="check the status" />`
Now commit those changes:
First add the change you made to the staging area by using
`git add file-name`
Then write a commit message by sing this command
`git commit -m "Add your-name to Contributors list"`
Replace `<your-name>` with your name.
`<img style="left" src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-commit.png" alt="commit changes" />`
To see if your commit has been made you can run a simple `git log --oneline` command.
## Push changes to github
Once you are done with the above steps you can push your changes by using this command
`git push origin <branch-name>`
`<img style="left" src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-push.png" alt="push changes" />`
## Submit your changes for review
If you go to your repository on github, you'll see `Compare & pull request` button. click on that button.
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/compare-and-pull.png" alt="create a pull request" />
Now submit the pull request.
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/submit-pull-request.png" alt="submit pull request" />
Soon I'll be merging all your changes into the master 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 -> PR_ workflow that you'll encounter often 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 can join our slack team in case you need any help or have any questions. [Join slack team](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA).
### [Additional material](../additional-material/git_workflow_scenarios/additional-material.md)
## Tutorials Using Other Tools
[Back to main page](https://github.com/firstcontributions/first-contributions#tutorials-using-other-tools)

101
cli-tool-tutorials/github-cli-tutorial.md Normal file
View File

@ -0,0 +1,101 @@
[![Open Source Love](https://badges.frapsoft.com/os/v1/open-source.svg?v=103)](https://github.com/ellerbrock/open-source-badges/)
[<img align="right" width="150" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/join-slack-team.png">](https://join.slack.com/t/firstcontributors/shared_invite/enQtNjkxNzQwNzA2MTMwLTVhMWJjNjg2ODRlNWZhNjIzYjgwNDIyZWYwZjhjYTQ4OTBjMWM0MmFhZDUxNzBiYzczMGNiYzcxNjkzZDZlMDM)
[![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)
# First Contributions
| <img alt="GitHub Desktop" src="https://cdn.icon-icons.com/icons2/2157/PNG/512/github_git_hub_logo_icon_132878.png" width="200"> | GitHub Command Line Interface (CLI) |
|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------|
This is a guide for us the terminal nerds who wants to do everything in the terminal, and thanks to the [Github-CLI](https://cli.github.com/) we can achieve it, remember your first contribution should be fun, rewarding and a motivator just to keep going!
This guide is a bit more challenging since we are not using any graphical interface at all, but still it's really fun and you can totally follow it!
The first requisite is to have:
- Git installed (how to install [git](https://git-scm.com/downloads))
- Github account
Now we need to install the github-cli tool in our system by following the [official documentation](https://github.com/cli/cli#installation)
After that, we need to login in the CLI so enter this command:
```bash
gh auth login
```
Follow the instructions and we are ready!
# Fork this repository
It's just as easy as running this command:
```bash
gh repo fork firstcontributions/first-contributions
```
**Important: It will prompt you if you want to clone it as well, select the "yes" option**
# Create your branch
We will do this step with git, so we enter this command replacing the name with your name, for example:
```bash
git switch -c add-john-doe
```
# Make necessary changes and commit those changes
Now you can open `Contributors.md` file in a text editor, add your name to it. Put your name anywhere between the beginning and the end, now save the file.
In the project directory execute `git status` and you will see the changes.
![image-git](https://camo.githubusercontent.com/a35c4722d7aab337eefc655d1488f7b4dc038508e6adaf5e88e2e052a976f010/68747470733a2f2f6669727374636f6e747269627574696f6e732e6769746875622e696f2f6173736574732f526561646d652f6769742d7374617475732e706e67)
Add those changes to the branch you just created using the `git add` command:
`git add Contributors.md`
Now commit those changes using the `git commit` command:
`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`:
```
git push origin -u 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.
</details>
# Submit your changes for review
Now running this command in our repo's directory will let us create a pull request for review:
```bash
gh pr create --repo firstcontributions/first-contributions
```
After that submit the pull request.
You can use the command `gh status` to see your mentioned pull request in action.
## 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-vchl8cde-S0KstI_jyCcGEEj7rSTQiA).
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](additional-material/git_workflow_scenarios/additional-material.md)
## Tutorials Using Other Tools
[Back to main page](https://github.com/firstcontributions/first-contributions#tutorials-using-other-tools)

108
gui-tool-tutorials/github-desktop-old-version-tutorial.md Normal file
View File

@ -0,0 +1,108 @@
[![Open Source Love](https://badges.frapsoft.com/os/v1/open-source.svg?v=103)](https://github.com/ellerbrock/open-source-badges/)
[<img align="right" width="150" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/join-slack-team.png">](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA)
[![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)
# First Contributions
|<img alt="GitHub Desktop" src="https://desktop.github.com/images/desktop-icon.svg" width="200">|GitHub Desktop Edition|
|---|---|
It's hard. It's always hard the first time you do something. Especially when you are collaborating, making mistakes isn't a comfortable thing. But open source is all about collaboration & working together. We wanted to simplify the way new open-source contributors learn & contribute for the first time.
Reading articles & watching tutorials can help, but what comes better than actually doing the stuff without messing up anything. This project aims at providing guidance & simplifying the way rookies make their first contribution. Remember the more relaxed you are, the better you learn. If you are looking for making your first contribution just follow the simple steps below. We promise you, it will be fun.
<img align="right" width="300" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/fork.png" alt="fork this repository" />
If you don't have GitHub Desktop on your machine, [install it](https://desktop.github.com/).
## Fork this repository
Fork this repo by clicking on the fork button on the top of this page.
This will create of copy of this repository in your account.
## Clone the repository
Now clone this repo to your machine.
Open the GitHub Desktop app and click on the `+` on the top left.
<img style="float: right;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/dt-clone1.png" alt="clone this repository" />
If it is not already selected, click on `Clone`. Then choose first-contributions and then click on `Clone first-contributions`
<img style="float: right;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/dt-clone2.png" alt="clone this repository" />
Choose the directory on your machine you would like to clone first-contributions into
<img style="float: right;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/dt-clone3.png" alt="clone this repository" />
Now you have copied the contents of the first-contributions repository in github to your computer.
## Create a branch
Now create a branch by clicking on the branch icon at the top left:
<img style="float: right;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/dt-branch1.png" alt="make a branch" />
Name your branch add-your-name. For example, add-crawleya
Click on `Create new branch`
<img style="float: right;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/dt-branch2.png" alt="name your branch" />
## Make necessary changes and commit those changes
Now open `Contributors.md` file in a text editor and add your name to it, then save the file.
You can see that there are changes to Contributors.md and they have been added.
<img style="float: right;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/dt-status.png" alt="check status" />
Now commit those changes:
Write the message "Add `<your-name>` to Contributors list" in the *summary* field
Replace `<your-name>` with your name
Click on the button that says `Commit to add-your-name`
<img style="float: right;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/dt-commit1.png" alt="commit your changes" />
At the bottom, you can see that the commit has been created.
<img style="float: right;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/dt-commit2.png" alt="commit your changes" />
## Push changes to github
Click the `Publish` button on the top right.
<img style="float: right;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/dt-publish1.png" alt="push your changes" />
## Submit your changes for review
If you go to your repository on github, you'll see `Compare & pull request` button. click on that button.
<img style="float: right;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/compare-and-pull.png" alt="create a pull request" />
Now submit the pull request.
<img style="float: right;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/submit-pull-request.png" alt="submit pull request" />
Soon I'll be merging all your changes into the master 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 -> PR_ workflow that you'll encounter often 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 in case you need any help or have any questions. [Join slack team](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA).
### [Additional material](../additional-material/git_workflow_senarios/additional-material.md)
## Tutorials Using Other Tools
[Back to main page](https://github.com/firstcontributions/first-contributions#tutorials-using-other-tools)

119
gui-tool-tutorials/github-desktop-tutorial.md Normal file
View File

@ -0,0 +1,119 @@
[![Open Source Love](https://badges.frapsoft.com/os/v1/open-source.svg?v=103)](https://github.com/ellerbrock/open-source-badges/)
[<img align="right" width="150" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/join-slack-team.png">](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA)
[![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)
# First Contributions
|<img alt="GitHub Desktop" src="https://desktop.github.com/images/desktop-icon.svg" width="200">|GitHub Desktop Edition|
|---|---|
It's hard. It's always hard the first time you do something. Especially when you are collaborating, making mistakes isn't a comfortable thing. But open source is all about collaboration & working together. We wanted to simplify the way new open-source contributors learn & contribute for the first time.
Reading articles & watching tutorials can help, but what comes better than actually doing the stuff without messing up anything. This project aims at providing guidance & simplifying the way rookies make their first contribution. Remember the more relaxed you are the better you learn. If you are looking for making your first contribution just follow the simple steps below. We promise you, it will be fun.
If you don't have GitHub Desktop on your machine, [install it](https://desktop.github.com/).
If you're using a version of GitHub desktop before 1.0, [refer this tutorial](github-desktop-old-version-tutorial.md).
<img align="right" width="300" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/fork.png" alt="fork this repository" />
## Fork this repository
Fork this repo by clicking on the fork button on the top right of this page.
This will create a copy of this repository in your account.
## Clone the repository
Now clone this repo to your machine.
IMPORTANT: DO NOT CLONE THE ORIGINAL REPO. Go to your fork and clone it.
To clone the repo, click on "Clone or Download" and then click on "Open in Desktop".
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/dt1-clonetodesktop.png" alt="clone this repository" />
A pop up window will open. Click on "Open GitHubDesktop.exe".
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/dt1-open-githubdesktop.png" alt="clone this repository" />
After you click on "Open GitHubDesktop.exe" the contents will be downloaded to your computer.
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/dt1-downloaded.png" alt="clone this repository" />
Now you have copied the contents of the first-contributions repository in github to your computer.
## Create a branch
Now create a branch by clicking on the "Current branch" icon at the top and then click on "New branch":
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/dt1-create-branch.png" alt="make a branch" />
Name your branch <add-your-name>. For example, "add-james-smith"
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/dt1-create-branch-name.png" alt="name your branch" />
Click on `Create branch`
## Make necessary changes and commit those changes
Now, go to history tab and open `Contributors.md` file in a text editor by right clicking and open in text editor. Scroll to the bottom of the page and add your name to it, then save the file.
Example: If your name is James Smith, It should look like this.
\[James Smith](https://github.com/jamessmith)
You can see that there are changes to Contributors.md and they have been added to the Github Desktop.
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/dt1-status.png" alt="check status" />
Now commit those changes:
Write the message "Add `<your-name>` to Contributors list" in the *summary* field.
Replace `<your-name>` with your name.
Click on the button that says `Commit to add-your-name`.
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/dt1-commit1.png" alt="commit your changes" />
At the bottom, you can see that the commit has been created.
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/dt1-commit2.png" alt="commit your changes" />
## Push changes to github
Click on File->Options and sign-in to Github.com. Type in your Github username and password.
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/dt1-sign-in.png" alt="log-in to Github" />
Click the `Publish` button on the top right.
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/dt1-publish1.png" alt="push your changes" />
## Submit your changes for review
If you go to your repository on github, you'll see `Compare & pull request` button. click on that button.
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/compare-and-pull.png" alt="create a pull request" />
Now submit the pull request.
<img style="left;" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/submit-pull-request.png" alt="submit pull request" />
Soon I'll be merging all your changes into the master 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 -> PR_ workflow that you'll encounter often 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 can join our slack team in case you need any help or have any questions. [Join slack team](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA).
### [Additional material](../additional-material/git_workflow_scenarios/additional-material.md)
## Tutorials Using Other Tools
[Back to main page](https://github.com/firstcontributions/first-contributions#tutorials-using-other-tools)

112
gui-tool-tutorials/github-windows-intellij-tutorial.md Normal file
View File

@ -0,0 +1,112 @@
[![Open Source Love](https://badges.frapsoft.com/os/v1/open-source.svg?v=103)](https://github.com/ellerbrock/open-source-badges/)
[<img align="right" width="150" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/join-slack-team.png">](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA)
[![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)
# First Contributions
| <img alt="IntelliJ IDEA" src="https://upload.wikimedia.org/wikipedia/commons/9/9c/IntelliJ_IDEA_Icon.svg" width="40"> | IntelliJ IDEA |
| ------------------------------------------------------------------------------------------------------------------------------------ | ------------------ |
It's hard. It's always hard the first time you do something. Especially when you are collaborating, making mistakes isn't a comfortable thing. But open source is all about collaboration & working together. We wanted to simplify the way new open-source contributors learn & contribute for the first time.
Reading articles & watching tutorials can help, but what comes better than actually doing the stuff without messing up anything. This project aims at providing guidance & simplifying the way rookies make their first contribution. Remember the more relaxed you are, the better you learn. If you are looking for making your first contribution, just follow the simple steps below. We promise you, it will be fun.
If you don't have IntelliJ IDEA on your machine, [install it](https://www.jetbrains.com/idea/download/#section=windows).
**Notice:** This tutorial was made using IntelliJ IDEA (Version 2019.3.2) on a Windows 10 machine. Later in this tutorial we will make use of some keyboard shortcuts. These may differ on other operating systems (macOS/Linux).
## Fork this repository
<img align="right" width="300" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/fork.png" alt="fork this repository" />
Fork this repo by clicking on the fork button on the top right of this page. This will create a copy of this repository in your GitHub account.
GitHub keeps track of the relationship between your repo and the one you have forked it from. You can think of your repo as a working copy.
Most top-level GitHub Repos (i.e. ones not forked from any other repo) have a small core team of people who can directly commit changes. All other contributors must fork the repo and make changes in the fork, then create a Pull Request to request to merge back their changes into the top-level repo. If the top-level repo administrator approves the changes they will be merged, and you will gain instant fame and fortune! More on how to do that later.
## Clone your repository
<img align="right" width="300" src="https://firstcontributions.github.io/assets/Readme/clone.png" alt="clone this repository" />
The next step is to clone your repo down to your machine so you can begin making changes. IntelliJ IDEA needs the URL of your repo, so click the "clone" button and then click the "copy to clipboard" icon.
**CAREFUL:** One mistake that new contributors often make is to clone the repo you forked _from_ rather than cloning your repo. Check your browser's address bar and make sure you are cloning your repo.
Now open up IntelliJ IDEA.
IntelliJ IDEA allows you to check out (in Git terms clone) an existing repository and create a new project based on the data you've downloaded.
From the main menu, choose VCS | Get from Version Control, or, if no project is currently opened, click Get from Version Control on the Welcome screen.
In the Get from Version Control dialog, specify the URL of the remote repository you want to clone (you can click Test to make sure that connection to the remote can be established) or select one of the VCS hosting services on the left. If you are already logged in to the selected hosting service, completion will suggest the list of available repositories that you can clone.
Click Clone. If you want to create an IntelliJ IDEA project based on the sources you have cloned, click Yes in the confirmation dialog. Git root mapping will be automatically set to the project root directory.
If your project contains submodules, they will also be cloned and automatically registered as project roots.
**Important**: Make sure it is the forked repository and not the original one, otherwise it won't work.
## Create a branch
In Git, branching is a powerful mechanism that allows you to diverge from the main development line, for example, when you need to work on a feature or freeze a certain state of a codebase for a release, and so on.
In IntelliJ IDEA, all operations with branches are performed in the Git Branches popup. To invoke it, click the Git widget in the Status bar or press Ctrl+Shift+`.
The name of the branch that is currently checked out is displayed in the Git widget in the Status bar.
In the Branches popup, choose New Branch.
In the dialog that opens, specify the branch name, and make sure the Checkout branch option is selected if you want to switch to that branch.
The new branch will start from the current HEAD. If you want to start a branch from a previous commit instead of the current branch HEAD, select this commit in the Log tab of the Version Control tool window Alt+9 and choose New Branch from the context menu.
## Make necessary changes
Open `Contributors.md` and add your name anywhere in the file. This file contains GFM (GitHub Flavored Markdown) which is a proprietary flavor of the <a href="https://en.wikipedia.org/wiki/Markdown">markdown</a> syntax.
Copy one of the other contributors&apos; lines and modify it with your name to make sure you get the syntax right - it can be picky.
## Commit & Push changes to GitHub
Select the files you want to commit or an entire changelist in the Local Changes tab of the Version Control tool window Alt+9 and press Ctrl+K or click Commit Commit button on the toolbar.
The Commit Changes dialog that opens lists all files that have been modified since the last commit, as well as all newly added unversioned files.
Enter a meaningful commit message.
You can click Commit Message history Commit Message history Ctrl+M to choose from the list of recent commit messages.
You can also edit the commit message later before you've pushed the commit.
Press Ctrl+Shift+K or choose VCS | Git | Push from the main menu. The Push Commits dialog opens showing all Git repositories (for multi-repository projects) and listing all commits made in the current branch in each repository since the last push.
## Submit your changes for review
At this point you have completed your change but it still only resides in your repo. This step will show you how to submit a request to the administrator of the top-level repo to merge your change.
In your repo on GitHub you'll see the `Compare & pull request` button next to the new branch notification. Click on that button.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/compare-and-pull.png" alt="create a pull request" />
Now submit the pull request.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/submit-pull-request.png" alt="submit pull request" />
Soon I'll be merging all your changes into the master branch of this project. You will get a notification email once the changes have been merged.
## Where to go from here?
Congrats! You have just completed the standard _fork -> clone -> edit -> PR_ workflow that you'll encounter often 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 can join our slack team in case you need any help or have any questions. [Join slack team](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA).
### [Additional material](../additional-material/git_workflow_scenarios/additional-material.md)
## Tutorials Using Other Tools
[Back to main page](https://github.com/firstcontributions/first-contributions#tutorials-using-other-tools)

118
gui-tool-tutorials/github-windows-vs-code-tutorial.md Normal file
View File

@ -0,0 +1,118 @@
[![Open Source Love](https://badges.frapsoft.com/os/v1/open-source.svg?v=103)](https://github.com/ellerbrock/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-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA)
[![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)
# First Contributions
| <img alt="Visual Studio Code" src="https://upload.wikimedia.org/wikipedia/commons/2/2d/Visual_Studio_Code_1.18_icon.svg" width="40"> | Visual Studio Code |
| ------------------------------------------------------------------------------------------------------------------------------------ | ------------------ |
It's hard. It's always hard the first time you do something. Especially when you are collaborating, making mistakes isn't a comfortable thing. But open source is all about collaboration & working together. We wanted to simplify the way new open-source contributors learn & contribute for the first time.
Reading articles & watching tutorials can help, but what comes better than actually doing the stuff without messing up anything. This project aims at providing guidance & simplifying the way rookies make their first contribution. Remember the more relaxed you are, the better you learn. If you are looking for making your first contribution, just follow the simple steps below. We promise you, it will be fun.
If you don't have Visual Studio Code on your machine, [install it](https://code.visualstudio.com/download).
**Notice:** This tutorial was made using Visual Studio Code (Version 1.27.2) on a Windows 10 machine. Later in this tutorial we will make use of some keyboard shortcuts. These may differ on other operating systems (macOS/Linux) as well as keyboard language (UK, DE, etc). You can go through your list of shortcuts by searching "shortcut" in the Command Palette.
## Fork this repository
<img align="right" width="300" src="https://firstcontributions.github.io/assets/Readme/fork.png" alt="fork this repository" />
Fork this repo by clicking on the fork button on the top right of this page. This will create a copy of this repository in your GitHub account.
GitHub keeps track of the relationship between your repo and the one you have forked it from. You can think of your repo as a working copy.
Most top-level GitHub repos (i.e. ones not forked from any other repo) have a small core team of people who can directly commit changes. All other contributors must fork the repo and make changes in the fork, then create a Pull Request to ask for their changes to be merged back into the top-level repo. If the top-level repo administrator likes the changes they will be merged and you will gain instant fame and fortune! More on how to do that later.
## Clone your repository
<img align="right" width="300" src="https://firstcontributions.github.io/assets/Readme/clone.png" alt="clone this repository" />
The next step is to clone your repo down to your machine so you can begin making changes. VS Code needs the URL of your repo, so click the code button and then click the "copy to clipboard" icon.
**CAREFUL:** One mistake that new contributors often make is to clone the repo you forked _from_ rather than cloning your repo. Check your browser's address bar and make sure you are cloning your repo.
Now open up Visual Studio Code. The welcome page of VS Code will pop up. From there press `F1` to open up the bar shown below. Notice that there is already a `>` (greater than) sign in the text field. You can also get to the input prompt by pressing `CTRL-P` and then type the `>` character.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs-code-tutorial/vscode-2018-08-clone.png" alt="Clone Popup (Command Popup)" />
You may notice that there are already some obscure commands listed below. Those are my recently used commands. So just don't care about them.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs-code-tutorial/vscode-2018-08-clone1.png" alt="Clone repo" />
Now type in `git clone`, only `git` or `clone` (it works like a search).
Select the Entry `Git: Clone` and press `Enter`
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs-code-tutorial/vscode-2018-08-clone2.png" alt="Paste Repository URL in" />
Paste the URL of your repository and press `Enter`. This will open up a File Explorer where you can then choose where the Git repository should be stored.
**Important**: Make sure it is the forked repository and not the original one, otherwise it won't work.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs-code-tutorial/vscode-2018-08-clone3.png" alt="Status popup" />
You should see a status popup on the bottom right of Visual Studio Code. After it has finished, you can open up the cloned repository (now a folder on your machine) using the buttons in the dialog.
## Create a branch
Open up the command palette again by pressing `F1`. Type in `branch` and select the `create branch` command from there. In the next step type in the name of your new branch, for example `add-david-kroell`. Press enter and the branch will be created. The branch is also already checked out. [What does checkout mean?](https://www.git-scm.com/docs/git-checkout)
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs-code-tutorial/vscode-2018-08-branch.png" alt="Branches Command Palette" />
## Make necessary changes
Open `Contributors.md` and add your name anywhere in the file. This file contains GFM (GitHub Flavored Markdown) which is a proprietary flavor of the <a href="https://en.wikipedia.org/wiki/Markdown">markdown</a> syntax.
Copy one of the other contributors&apos; lines and modify it with your name to make sure you get the syntax right - it can be picky.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs-code-tutorial/vscode-2018-08-changes.png" alt="Add your name" />
## Commit & Push changes to GitHub
On the left side of VS Code is a menu with 5 icons displayed. Select the version control/Source Control icon.
(Shortcut : Ctrl + Shift + G)
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs-code-tutorial/vscode-2018-08-commit.png" alt="Commit changes" />
The file explorer displays all files which were changed after the last commit. By hovering the files and clicking the `+` (plus) the files are staged.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs-code-tutorial/vscode-2018-08-commit1.png" alt="Stashed Files">
Type something in the line on top of the explorer and press the checkmark. The changes are now committed to your local copy. Now the changes have to be pushed back to GitHub.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs-code-tutorial/vscode-2018-08-push.png" alt="Stashed Files">
Use the three-dot icon to open up the menu where you select the `Publish Branch` option. This should open up a dialog to put your GitHub credentials in.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs-code-tutorial/vscode-2018-08-gh-auth.png" alt="Stashed Files">
## Submit your changes for review
At this point you have completed your change but it still only resides in your repo. This step will show you how to submit a request to the administrator of the top-level repo to merge your change.
In your repo on GitHub you'll see the `Compare & pull request` button next to the new branch notification. Click on that button.
<img src="https://firstcontributions.github.io/assets/Readme/compare-and-pull.png" alt="create a pull request" />
Now submit the pull request.
<img 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 master branch of this project. You will get a notification email once the changes have been merged.
## Where to go from here?
Congrats! You have just completed the standard _fork -> clone -> edit -> PR_ workflow that you'll encounter often 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 can join our slack team in case you need any help or have any questions. [Join slack team](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA).
### [Additional material](../additional-material/git_workflow_scenarios/additional-material.md)
## Tutorials Using Other Tools
[Back to main page](https://github.com/firstcontributions/first-contributions#tutorials-using-other-tools)

140
gui-tool-tutorials/github-windows-vs2017-tutorial.md Normal file
View File

@ -0,0 +1,140 @@
[![Open Source Love](https://badges.frapsoft.com/os/v1/open-source.svg?v=103)](https://github.com/ellerbrock/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-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA)
[![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)
# First Contributions
|<img alt="Visual Studio 2017" src="https://upload.wikimedia.org/wikipedia/commons/thumb/6/61/Visual_Studio_2017_logo_and_wordmark.svg/2000px-Visual_Studio_2017_logo_and_wordmark.svg.png" width="200">|Visual Studio 2017 Edition|
|---|---|
It's hard. It's always hard the first time you do something. Especially when you are collaborating, making mistakes isn't a comfortable thing. But open source is all about collaboration & working together. We wanted to simplify the way new open-source contributors learn & contribute for the first time.
Reading articles & watching tutorials can help, but what comes better than actually doing the stuff without messing up anything. This project aims at providing guidance & simplifying the way rookies make their first contribution. Remember the more relaxed you are the better you learn. If you are looking for making your first contribution just follow the simple steps below. We promise you, it will be fun.
If you don't have Visual Studio 2017 on your machine, [install it](https://www.visualstudio.com/downloads/).
## Fork this repository
<img align="right" width="300" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/fork.png" alt="fork this repository" />
Fork this repository by clicking on the fork button on the top of this page. This will create of copy of this repository in your GitHub account.
GitHub keeps track of the relationship between your repo and the one you forked it from. You can think of your repo as a working copy.
Most top-level GitHub repos (i.e. ones not forked from any other repo) have a small core team of people who can directly commit changes. All other contributors must fork the repo and make changes in the fork, then create a Pull Request to ask for their changes to be merged back into the top-level repo. If the top-level repo administrator likes the changes they will be merged and you will gain instant fame and fortune! More on how to do that later.
## Clone your repository
<img align="right" width="300" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/clone.png" alt="clone this repository" />
The next step is to clone your repo down to your machine so you can begin making changes. Visual Studio needs the URL of your repo, so click the "clone" button and then click the "copy to clipboard" icon.
**CAREFUL:** One mistake that new contributors often make is to clone the repo you forked *from* rather than cloning your repo. Check your browser's address bar and make sure you are cloning your repo.
It is now time to jump in to Visual Studio 2017! You will be working in the Team Explorer tab for most of this tutorial. If it is not open by default, click `View > Team Explorer` to open it.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-01-clone1.png" alt="Team Explorer" />
Team Explorer has many views and there are navigation buttons located at the top to help you find the different areas. To clone a repo, you need to be on the Connect view, which should be the default. If you do not see the 'clone' button, click the green plug at the top.
Click the `Clone` option under **Local Git Repositories** and paste the URL to your repo in the text box. This should be the URL you copied to your clipboard from GitHub previously.
Click the `Clone` button to initiate the process.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-02-clone2.png" alt="Clone repo" />
When the process is complete you will be moved over to the Solution Explorer tab where you can see the contents of your repo. Yours will look different than the screenshot below because things change!
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-03-clone3.png" alt="Solution Explorer" />
## Create a branch
Click back to the Team Explorer tab and use the main navigation dropdown to open the Branches view.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-04-branch1.png" alt="Branches view" />
You should see the **first-contributions** repo and the default branch, which is called `master`. Right-click on `master` and choose `New Local Branch From...`.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-05-branch2.png" alt="New branch" />
Give your branch a name like `add-<your_name_here>`, for example: `add-alonzo-church`.
Leave the `Checkout branch` box checked and click the `Create Branch` button.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-06-branch3.png" alt="Create branch" />
You should see your new branch in the list.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-07-branch4.png" alt="See new branch" />
## Make necessary changes
Open `Contributors.md` and add your name to the end of the list. This file contains GFM (GitHub Flavored Markdown) which is a proprietary flavor of the <a href="https://en.wikipedia.org/wiki/Markdown">markdown</a> syntax.
Copy one of the other contributors&apos; lines and modify it with your name to make sure you get the syntax right - it can be picky.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-08-change1.png" alt="Add your name" />
## Commit & Push changes to GitHub
Switch back to Team Explorer and navigate to the Changes view.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-09-commit1.png" alt="Changes" />
Enter the information you want to post with your commit and click `Save`. Visual Studio will remember it for future commits.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-10-commit2.png" alt="Git user information" />
**NOTE:** Visual Studio uses a hidden folder called `.vs` to store your personal settings and preferences. The contents of this folder **should not be saved in Git**.
If it has not been ignored already, you may need to tell Git to ignore this folder so it does not send it up to the repo.
This folder has already been ignored in this repo, so you should not have to perform this step...it is just here for your reference for future projects.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-11-commit3.png" alt="Ignore vs folder" />
Now you should see a list of changed files and a textbox to type a commit comment. Comments should be in brief but thorough. There is nothing worse than reading through commit comments and seeing this: `"I updated some stuff"`. Take a few seconds to outline your commit. Your team will thank you later, and you might even thank yourself!
Click `Commit All and Push` to perform a local commit and push your changes back up to your repo, all in one step.
**NOTE:** Commit can be performed separately from Push. We do both here for convenience. Commit logs your changes locally but they will not be reflected in your GitHub repo until you Push.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-12-commit4.png" alt="Commit and Push" />
The first time you Push to GitHub, Visual Studio will ask for your GitHub credentials. They will be cached so you should not see this very often.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-13-commit5.png" alt="Login" />
After the Push operation completes, open your repo in GitHub and you should see a message indicating a recently pushed branch.
You can view your changes by opening the `Branch: master` dropdown and selecting your new branch. Congratulations, you can share the branch URL with the world to show your progress!
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/vs2017-14-commit6.png" alt="View pushed branch on GitHub" />
## Submit your changes for review
At this point you have completed your change but it still only resides in your repo. This step will show you how to submit a request to the administrator of the top-level repo to merge your change.
In your repo on GitHub you'll see the `Compare & pull request` button next to the new branch notification. Click on that button.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/compare-and-pull.png" alt="create a pull request" />
Now submit the pull request.
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-windows-vs2017-tutorial/submit-pull-request.png" alt="submit pull request" />
Soon I'll be merging all your changes into the master branch of this project. You will get a notification email once the changes have been merged.
## Where to go from here?
Congrats! You have just completed the standard _fork -> clone -> edit -> PR_ workflow that you'll encounter often 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 can join our slack team in case you need any help or have any questions. [Join slack team](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA).
### [Additional material](../additional-material/git_workflow_scenarios/additional-material.md)
## Tutorials Using Other Tools
[Back to main page](https://github.com/firstcontributions/first-contributions#tutorials-using-other-tools)

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