├── .prettierignore ├── additional-material ├── git_workflow_scenarios │ ├── delete-branch-locally.md │ ├── check-commit-log.md │ ├── resetting-a-commit.md │ ├── removing-a-file.md │ ├── moving-a-commit-to-a-different-branch.md │ ├── resetting-a-branch.md │ ├── removing-branch-from-your-repository.md │ ├── storing-credentials.md │ ├── reverting-a-commit.md │ ├── undoing-a-commit.md │ ├── resolving-merge-conflicts.md │ ├── keeping-your-fork-synced-with-this-repository.md │ ├── creating-a-gitignore-file.md │ ├── squashing-commits.md │ ├── configuring-git.md │ └── amending-a-commit.md └── translations │ ├── Farsi │ ├── delete-branch-locally.fa.md │ └── amending-a-commit.fa.md │ ├── Greek │ └── git_workflow_scenarios │ │ ├── delete-branch-locally.gr.md │ │ ├── check-commit-log.gr.md │ │ ├── creating-a-gitignore-file.gr.md │ │ └── configuring-git.gr.md │ ├── Hindi │ ├── resetting-a-commit.hi.md │ ├── add-file.hi.md │ ├── moving-a-commit-to-a-different-branch.hi.md │ ├── removing-a-file.hi.md │ ├── resetting-a-branch.hi.md │ ├── removing-branch-from-your-repository.hi.md │ └── Amending a Commit │ ├── Indonesian │ ├── resetting-a-commit.id.md │ ├── removing-a-file.id.md │ ├── removing-branch-from-your-repository.id.md │ └── additional-material.id.md │ ├── Korean │ ├── moving-a-commit-to-a-different-branch.ko.md │ ├── removing-branch-from-your-repository.ko.md │ ├── reverting-a-commit.ko.md │ ├── amending-a-commit.ko.md │ ├── resolving-merge-conflicts.ko.md │ ├── keeping-your-fork-synced-with-this-repository.ko.md │ ├── undoing-a-commit.ko.md │ └── additional-material.ko.md │ ├── Sinhala │ └── removing-a-file.sin.md │ ├── Slovenian │ ├── removing-a-file.sl.md │ ├── moving-a-commit-to-a-different-branch.sl.md │ ├── removing-branch-from-your-repository.sl.md │ ├── reverting-a-commit.sl.md │ ├── undoing-a-commit.sl.md │ ├── resolving-merge-conflicts.sl.md │ ├── amending-a-commit.sl.md │ ├── keeping-your-fork-synced-with-this-repository.sl.md │ ├── additional-material.sl.md │ ├── configuring-git.sl.md │ └── squashing-commits.sl.md │ ├── Marathi │ ├── Removing-a-file.ma.md │ └── additional-material.ma.md │ ├── Portugues │ ├── removing-a-file.pt_br.md │ ├── moving-a-commit-to-a-different-branch.pt_br.md │ ├── removing-branch-from-your-repository.pt_br.md │ ├── keeping-your-fork-synced-with-this-repository.pt_br.md │ ├── amending-a-commit.pt_br.md │ ├── additional-material.pt_br.md │ └── confinguring-git.pt-br.md │ ├── Belarusian │ ├── removing-a-file.by.md │ ├── moving-a-commit-to-a-different-branch.by.md │ ├── removing-branch-from-your-repository.by.md │ ├── reverting-a-commit.by.md │ ├── undoing-a-commit.by.md │ ├── resolving-merge-conflicts.by.md │ ├── keeping-your-fork-synced-with-this-repository.by.md │ ├── amending-a-commit.by.md │ ├── squashing-commits.by.md │ ├── Useful-links-for-further-learning.by.md │ ├── additional-material.by.md │ └── configuring-git.by.md │ ├── Bengali │ └── add-file.bn.md │ ├── Italian │ ├── removing-a-file.it.md │ └── reverting-a-commit.it.md │ ├── Ukrainian │ └── removing-a-file.ua.md │ ├── Russian │ ├── removing-a-file.ru.md │ ├── moving-a-commit-to-a-different-branch.ru.md │ ├── amending-a-commit.ru.md │ └── additional-material.ru.md │ ├── Chinese │ ├── additional-material.zh-cn.md │ └── addtional-material.cht.md │ ├── Nepali │ ├── amending-a-commit.np.md │ ├── configuring-git.np.md │ └── additional-material.np.md │ ├── Urdu │ ├── amending-a-commit.ur.md │ └── additional-material.ur.md │ ├── Spanish │ ├── amending-a-commit.es.md │ ├── amending-a-commit.sp_mx.md │ ├── additional-material.es.md │ ├── additional-material.sp_mx.md │ └── configuring-git.sp_mx.md │ ├── Vietnamese │ └── resolving-merge-conflicts.vi.md │ └── French │ └── amending-a-commit.fr.md ├── .github ├── FUNDING.yml ├── ISSUE_TEMPLATE.md └── ISSUE_TEMPLATE │ └── issue-template.md └── LICENSE /.prettierignore: -------------------------------------------------------------------------------- 1 | # Ignore Contributors.md(to prevent future merge conflicts): 2 | Contributors.md -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/delete-branch-locally.md: -------------------------------------------------------------------------------- 1 | # Deleting a locally created Branch 2 | 3 | This will be handy when you accidentally misspelled a branch name. 4 | 5 | This can be done in *3* ways 6 | 7 | ``` 8 | git branch -D 9 | ``` 10 | 11 | ``` 12 | git branch --delete --force # Same as -D 13 | ``` 14 | 15 | ``` 16 | git branch --delete # Error on unmerge 17 | ``` 18 | 19 | -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... -------------------------------------------------------------------------------- /additional-material/translations/Farsi/delete-branch-locally.fa.md: -------------------------------------------------------------------------------- 1 | # حذف کردن شاخه که به صورت محلی ایجاد شده است 2 | 3 | این در زمانی سودمند خواهد بود که شما نام یک شاخه (برنچ) را اشتباه نوشته اید. 4 | 5 | این کار به *3* روش قابل انجام است 6 | 7 | ``` 8 | git branch -D 9 | ``` 10 | 11 | ``` 12 | git branch --delete --force # Same as -D 13 | ``` 14 | 15 | ``` 16 | git branch --delete # Error on unmerge 17 | ``` 18 | 19 | پرچم `D-` مخفف `delete --force--` است که شاخه را حتی اگر مرج نشده باشد حذف میکند. (حذف اجباری)، ولی شما میتوانید از پرچم `d-` استفاده کنید که مخفف `delete--` است که با توجه با وضعیت مرج شاخه ارور خواهد داد. -------------------------------------------------------------------------------- /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | # These are supported funding model platforms 2 | 3 | github: [firstcontributions] 4 | open_collective: [firstcontributions] 5 | ko_fi: # Replace with a single Ko-fi username 6 | tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel 7 | community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry 8 | liberapay: # Replace with a single Liberapay username 9 | issuehunt: # Replace with a single IssueHunt username 10 | otechie: # Replace with a single Otechie username 11 | lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry 12 | custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2'] 13 | -------------------------------------------------------------------------------- /additional-material/translations/Greek/git_workflow_scenarios/delete-branch-locally.gr.md: -------------------------------------------------------------------------------- 1 | # Διαγραφή ενός τοπικά δημιουργημένου κλαδιού 2 | 3 | Αυτό θα είναι χρήσιμο όταν κάνετε κατά λάθος λάθος το όνομα ενός κλαδιού. 4 | 5 | Αυτό μπορεί να γίνει με *3* τρόπους 6 | 7 | ``` 8 | git branch -D <όνομα_κλαδιού> 9 | ``` 10 | 11 | ``` 12 | git branch --delete --force <όνομα_κλαδιού> # Ίδιο με το -D 13 | ``` 14 | 15 | ``` 16 | git branch --delete <όνομα_κλαδιού> # Σφάλμα κατά την ανενοχλησία 17 | ``` 18 | 19 | Το -D σημαίνει --delete --force, το οποίο θα διαγράψει το κλαδί ακόμα και αν δεν έχει συγχωνευτεί (αναγκαστική διαγραφή), αλλά μπορείτε επίσης να χρησιμοποιήσετε -d που σημαίνει --delete το οποίο θα εμφανίσει ένα σφάλμα ανάλογα με την κατάσταση συγχώνευσης του κλαδιού... -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 🐞 **Problem** 4 | 5 | 6 | 7 | 🎯 **Goal** 8 | 9 | 10 | 11 | 💡 **Possible solutions** 12 | 13 | 14 | 📋 **Steps to solve the problem** 15 | 16 | * Comment below about what you've started working on. 17 | * Add, commit, push your changes. 18 | * Submit a pull request and add this in comments - `Addresses #` 19 | * Ask for reviews in comments section of pull request. 20 | * Celebrate your contribution to this project. 🎉 21 | -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/check-commit-log.md: -------------------------------------------------------------------------------- 1 | # Check commit log 2 | 3 | In order to check commits log for a branch, or, a file, following command can be used: 4 | 5 | `git log [options] [path]` 6 | 7 | The output of this command is given in reverse chronological order by default. 8 | 9 | ## Command variations and options 10 | - In order to prform the commits reachable from a particular commit ids: (In this case, `foo` and `bar`)
11 | `git log foo bar ` 12 | - It is also possible to remove the commits reachable from a given commit id by adding a `^` in front of commit id: (In this case, `baz`)
13 | `git log foo bar ^baz` 14 | - Commit log for a particular file
15 | `git log --all ` 16 | - Limit number of commits in log (In this case, `5`)
17 | `git log -n 5` 18 | 19 | ## Refer 20 | - [Official documentation](https://git-scm.com/docs/git-log) 21 | -------------------------------------------------------------------------------- /additional-material/translations/Hindi/resetting-a-commit.hi.md: -------------------------------------------------------------------------------- 1 | # कमिट रीसेट करें 2 | 3 | 4 | ```reset``` वह कमांड है जिसका उपयोग तब किया जा सकता है जब हम रिपॉजिटरी को पिछली कमिट में वापस ले जाना चाहते हैं, उस कमिट के बाद किए गए किसी भी बदलाव को छोड़कर।
5 | किसी कमिट को रीसेट करने और वापस लाने के बीच मुख्य अंतर यह है कि git रीसेट ```फ़ाइल को अनस्टेज करता है और हमारे परिवर्तनों को कार्यशील निर्देशिका में वापस लाता है``` और git revert ```रिमोट रिपॉजिटरी से कमिट्स को हटा देता है```।
6 | 7 | ```git reset``` निम्नलिखित कमांड का उपयोग करके प्राप्त किया जा सकता है: 8 | - निम्नलिखित कमांड निम्नलिखित दो मापदंडों का उपयोग करके सभी कमिटों का सारांश देगा: 9 | 10 | - कमिट हैश के पहले सात अक्षर - यही वह है जिसे हमें अपने **reset** कमांड में संदर्भित करना होगा। 11 | - प्रतिबद्ध संदेश 12 | 13 | ``` 14 | git log --oneline 15 | ``` 16 | 17 | - कोई निम्नलिखित कमांड का उपयोग करके रिपॉजिटरी को विशिष्ट कमिट पर वापस रीसेट कर सकता है:
18 | ```गिट रीसेट कमिटहैश``` 19 | जहां कमिटहैश कमिट हैश के पहले 7 अक्षर हैं जो हमें लॉग में मिले| -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/resetting-a-commit.md: -------------------------------------------------------------------------------- 1 | # Reset a commit 2 | 3 | ```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.
4 | 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``` 5 | and git revert ```removes the commits from the remote repository```.
6 | 7 | ```git reset``` can be achieved using following commands: 8 | - The following command will give summary of all the commits using following two parameters: 9 | 10 | - The first seven characters of the commit hash - this is what we need to refer to in our **reset** command. 11 | - the commit message 12 | 13 | ``` 14 | git log --oneline 15 | ``` 16 | 17 | 18 | - One can reset repository back to the specific commit using following command:
19 | ```git reset commithash``` 20 | where commithash being the first 7 characters of the commit hash we found in the log 21 | -------------------------------------------------------------------------------- /additional-material/translations/Indonesian/resetting-a-commit.id.md: -------------------------------------------------------------------------------- 1 | # Mengatur Ulang Sebuah commit 2 | 3 | `reset` adalah perintah yang dapat digunakan ketika kita ingin memindahkan repositori kembali ke commit sebelumnya, membuang semua perubahan yang dibuat setelah commit tersebut.
4 | Perbedaan utama antara mengatur ulang dan mengembalikan commit adalah bahwa git reset `unstages a file and bring our changes back to the working directory` 5 | dan git revert `removes the commits from the remote repository`.
6 | 7 | `git reset` dapat dicapai dengan menggunakan perintah berikut: 8 | 9 | - Perintah berikut ini akan memberikan ringkasan dari semua commit dengan menggunakan dua parameter berikut: 10 | 11 | - Tujuh karakter pertama dari commit hash - inilah yang perlu kita rujuk dalam perintah **reset**. 12 | - Pesan commit 13 | 14 | ``` 15 | git log --oneline 16 | ``` 17 | 18 | - Seseorang dapat mengatur ulang repositori kembali ke commit tertentu menggunakan perintah berikut:
19 | `git reset commithash` 20 | di mana commithash adalah 7 karakter pertama dari hash commit yang kami temukan di log 21 | -------------------------------------------------------------------------------- /additional-material/translations/Greek/git_workflow_scenarios/check-commit-log.gr.md: -------------------------------------------------------------------------------- 1 | # Έλεγχος καταγραφής αλλαγών (commit log) 2 | 3 | Για να ελέγξετε την καταγραφή αλλαγών (commit log) για ένα κλαδί ή ένα αρχείο, μπορείτε να χρησιμοποιήσετε την ακόλουθη εντολή: 4 | 5 | ```bash 6 | git log [επιλογές] [διαδρομή] 7 | ``` 8 | 9 | Η έξοδος αυτής της εντολής παρέχεται με την προεπιλεγμένη σειρά αναστροφής χρονολογίας. 10 | 11 | ## Παραλλαγές και επιλογές της εντολής 12 | 13 | - Για να καταγράψετε τις αλλαγές που είναι προσβάσιμες από συγκεκριμένα αναγνωριστικά αλλαγών (π.χ. foo και bar), χρησιμοποιήστε: 14 | ` 15 | git log foo bar 16 | ` 17 | - Είναι επίσης δυνατό να αφαιρέσετε τις αλλαγές που είναι προσβάσιμες από ένα συγκεκριμένο αναγνωριστικό αλλαγών (π.χ. baz), προσθέτοντας ένα ^ μπροστά από το αναγνωριστικό: 18 | `git log foo bar ^baz` 19 | 20 | - Για να δείτε την καταγραφή αλλαγών για ένα συγκεκριμένο αρχείο, χρησιμοποιήστε: 21 | `git log --all <όνομα_αρχείου>` 22 | - Περιορίστε τον αριθμό των αλλαγών στην καταγραφή (π.χ. `5`) χρησιμοποιώντας: 23 | `git log -n 5` 24 | ## Αναφορές 25 | - [Επίσημη τεκμηρίωση](https://git-scm.com/docs/git-log) 26 | -------------------------------------------------------------------------------- /additional-material/translations/Korean/moving-a-commit-to-a-different-branch.ko.md: -------------------------------------------------------------------------------- 1 | ## 커밋을 다른 브랜치로 옮기기 2 | 3 | What if you commit a change, and then realize that you committed to a different branch? 4 | How can you change that? This is what this tutorial covers. 5 | 만일 변경사항을 반영했는데 전혀 다른 브랜치에 커밋한 사실을 알았다면 어떻게할까요? 6 | 이걸 어떻게 바로잡을 수 있을까요? 바로 이 장에서 다룰 내용입니다. 7 | 8 | ### 가장 최근 커밋들을 기존에 있는 브랜치로 이동시키기 9 | 사용예: 10 | 11 | ```git reset HEAD~ --soft``` - 마지막 커밋을 되돌립니다. 물론 수정한 내용은 그대로 남아있습니다. 12 | ```git stash``` - 현재까지 수정한 모든 작업내용들의 상태를 저장합니다. 13 | 14 | ```git checkout name-of-the-correct-branch``` - 실제 반영하고자하는 브랜치를 체크아웃합니다. 15 | ```git stash pop``` - 마지막으로 저장한(stash) 변경내역들을 현재 브랜치에 반영하고 저장한 내역에서 삭제합니다. 16 | ```git add .``` - 또는 커밋에 반영할 변경내역들을 개별적으로 추가합니다. 17 | ```git commit -m "your message here"``` - 저장하고 변경내역을 커밋합니다. 18 | 19 | 자 이제 변경사항이 올바른 브랜치에 반영되었습니다. 20 | 21 | ### 가장 최근 커밋들을 신규 브랜치를 생성하여 이동시키기 22 | 23 | 사용예: 24 | ```git branch newbranch``` - 신규 브랜치를 생성하고 모든 커밋들을 저장합니다. 25 | ```git reset --hard HEAD~#``` - master 브랜치의 #번째 커밋을 되돌립니다. 되돌린 커밋들은 master에서 완전히 삭제되므로 주의하세요. 26 | ```git checkout newbranch``` - 생성한 브랜치로 이동합니다. 모든 커밋들을 가지고 있을겁니다. 27 | 28 | 주의: 커밋하지 않은 변경사항들은 사라집니다. 29 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2016 - present Roshan Jossey 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /additional-material/translations/Sinhala/removing-a-file.sin.md: -------------------------------------------------------------------------------- 1 | # GIT වෙතින් ගොනුවක් ඉවත් කිරීම 2 | 3 | සමහර විට, ඔබට Git වෙතින් ගොනුවක් ඉවත් කිරීමට අවශ්ය විය හැකි නමුත් එය ඔබේ පරිගණකයෙන් මකා නොදමන්න. පහත දැක්වෙන විධානය භාවිතා කිරීමෙන් ඔබට මෙය සාක්ෂාත් කරගත හැකිය: 4 | 5 | ``git rm --cached`` 6 | 7 | ## ඉතින්, මොකද වුණේ? 8 | 9 | ඉවත් කරන ලද ගොනුවේ වෙනස්කම් ගැන GIT තවදුරටත් අවධානය යොමු නොකරනු ඇත. GIT දන්නා පරිදි, එය ඔබ ගොනුව මකා දැමුවාක් මෙනි. ඔබ ඔබේ ගොනු පද්ධතියේ ගොනුව සොයාගත්තේ නම්, එය තවමත් පවතින බව ඔබට පෙනෙනු ඇත. 10 | 11 | ඉහත උදාහරණයෙන්, ධජය ඛණ්ඩාංක භාවිතා කරන බව සැලකිල්ලට ගන්න. අපි මෙම ධජය එක් නොකළේ නම්, GIT විසින් නැවත ප්රකාශිත හෝ ඔබේ ගොනු පද්ධතියෙන් ද ගොනුව ඉවත් කරනු ඇත. 12 | 13 | 'GIT CONEM "Read1.js" `ඉවත් කරන්න .js" සමඟ වෙනස ඔබ කළහොත්, "ගිට් තල්ලු සම්භවය මාස්ටර්', දුරස්ථ ගබඩාව ගොනුව ඉවත් කරයි. 14 | 15 | ## අතිරේක විශේෂාංග 16 | 17 | - ඔබට ගොනුවකට වඩා ඉවත් කිරීමට අවශ්ය නම්, ඔබට ඒවා සියල්ලම එකම විධානයකින් ඇතුළත් කළ හැකිය: 18 | 19 | `git rm fine1.js fine2.js fine3.js --cched` 20 | 21 | - සමාන ලිපිගොනු ඉවත් කිරීම සඳහා ඔබට ආදේශක කාඩ්පතක් (*) භාවිතා කළ හැකිය. උදාහරණයක් ලෙස, ඔබේ දේශීය ගබඩාවෙන් සියලුම .txt ගොනු ඉවත් කිරීමට ඔබ කැමති නම්: 22 | 23 | `git rm * .txt --cached` 24 | -------------------------------------------------------------------------------- /additional-material/translations/Slovenian/removing-a-file.sl.md: -------------------------------------------------------------------------------- 1 | # Odstranjevanje datoteke 2 | 3 | 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: 4 | 5 | ``git rm --cached`` 6 | 7 | ## Kaj se je zgodilo? 8 | 9 | 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. 10 | 11 | V zgornjem primeru smo uporabili zastavico `--cached`. Če je ne bi uporabili, bi Git odstranil datoteko tudi z našega diska. 12 | 13 | Č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. 14 | 15 | ## Dodatne možnosti 16 | 17 | - Če želiš odstraniti več datotek, jih lahko vse vljučiš v en ukaz: 18 | 19 | `git rm file1.js file2.js file3.js --cached` 20 | 21 | - 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: 22 | 23 | `git rm *.txt --cached` 24 | -------------------------------------------------------------------------------- /additional-material/translations/Hindi/add-file.hi.md: -------------------------------------------------------------------------------- 1 | ## एक नई फ़ाइल जोड़ने का ट्यूटोरियल 2 | 3 | यदि आप एक नई फ़ाइल को अपने Git रिपॉज़िटरी में जोड़ना चाहते हैं, तो यह ट्यूटोरियल आपकी मदद करेगा। 4 | 5 | 1. **नई फ़ाइल बनाएं**: 6 | - अपने प्रोजेक्ट फ़ोल्डर में जाएं। 7 | - नई फ़ाइल बनाने के लिए अपने पसंदीदा टेक्स्ट संपादक का उपयोग करें या आपका कोई IDE हो तो वहां से नई फ़ाइल बना सकते हैं। 8 | - फ़ाइल को विशेष नाम दें और सहेजें। 9 | 10 | 2. **फ़ाइल को स्टेज करें**: 11 | - टर्मिनल खोलें और रिपॉज़िटरी फ़ोल्डर में जाएं। 12 | - नई फ़ाइल को स्टेज करने के लिए निम्नलिखित कमांड का उपयोग करें: 13 | ``` 14 | git add नया_फ़ाइल.एक्शन 15 | ``` 16 | 17 | 3. **कमिट करें**: 18 | - फ़ाइल को स्टेज करने के बाद, एक कमिट बनाएं। 19 | - निम्नलिखित कमांड का उपयोग करें: 20 | ``` 21 | git commit -m "नई फ़ाइल जोड़ी गई" 22 | ``` 23 | 24 | 4. **रिमोट रिपॉज़िटरी में पुश करें**: 25 | - आपकी फ़ाइल अब आपके लोकल रिपॉज़िटरी में है। अब इसे रिमोट रिपॉज़िटरी में भेजने के लिए निम्नलिखित कमांड का उपयोग करें: 26 | ``` 27 | git push दूरस्थ_शाखा 28 | ``` 29 | - यहाँ "दूरस्थ_शाखा" वह नाम है जिसमें आप फ़ाइल जोड़ना चाहते हैं। 30 | 31 | अब आपने एक नई फ़ाइल अपने रिपॉज़िटरी में जोड़ दी है। 32 | -------------------------------------------------------------------------------- /additional-material/translations/Korean/removing-branch-from-your-repository.ko.md: -------------------------------------------------------------------------------- 1 | ## 여러분의 저장소에서 브랜치 삭제하기 2 | 3 | 지금까지의 튜토리얼을 수행했다면, 우리의 `` 브랜치가 목적을 완료했습니다. 이제는 로컬 저장소에서 삭제할 차례입니다. 필수사항은 아니지만 이 브랜치의 이름은 다소 특별한 목적을 나타내므로 이미 병합되었다면 그 수명을 다했다고 할 수 있습니다. 4 | First, let's merge your `` to your master, so to go your master branch: 5 | 먼저, ``을 마스터에 합쳐야합니다. 마스터 브랜치로 이동합니다.: 6 | ``` 7 | git checkout master 8 | ``` 9 | 10 | ``를 마스터에 병합합니다.: 11 | ``` 12 | git merge master 13 | ``` 14 | 15 | ``를 로컬 저장소에서 삭제합니다.: 16 | ``` 17 | git branch -d 18 | ``` 19 | 20 | 이제 로컬 머신의 ``브랜치를 삭제했고 모든 것이 깔끔하게 보입니다. 21 | 이 시점에서 GitHub 포크에 여전히 `` 브랜치가 있어야합니다. 그러나 이것을 삭제하기 전에 이 원격지의 브랜치에서 상위 저장소로 "PR(Pull request)"을 보냈음을 기억하십시오. 따라서 아직 병합되지 않았다면이 브랜치를 삭제하지 마십시오. 22 | 그러나 해당 브래치를 이미 병합했고 원격 브랜치를 삭제하려면 다음을 사용하십시오.: 23 | ``` 24 | git push origin --delete 25 | ``` 26 | 27 | 자, 여러분은 이제 자신의 브래치를 정리하는 법을 배웠습니다. 28 | 시간이 지나면 많은 커밋이 저장소에 추가됩니다. 그리고 로컬 머신과 GitHub 포크의 마스터 브랜치는 최신 버전이 아닙니다. 따라서 저장소를 내 것과 동기화 된 상태로 유지하려면 아래 단계를 따르십시오. 29 | 30 | #### [여러분이 포크한 저장소와 싱크상태 유지하기](keeping-your-fork-synced-with-this-repository.ko.md) 31 | -------------------------------------------------------------------------------- /additional-material/translations/Marathi/Removing-a-file.ma.md: -------------------------------------------------------------------------------- 1 | # गिटमधून फाइल काढून टाकणे 2 | कधीकधी, आपण कुठलीक फाइल गिटमधून काढून टाकायला इच्छिता, परंतु ती आपल्या संगणकावरून काढून टाकायला इच्छित नाही. आपण खालील आदेशाचा वापर करून ती मिळवू शकता: 3 | 4 | ``git rm --cached`` 5 | 6 | ## तर काय झालं? 7 | Git आता काढून टाकलेल्या फाइलमधील बदलांची ट्रॅकिंग करत नाही. ज्यामुळे Gitला वाटतं, आपण फाइल काढून टाकली आहे. आपल्याला जर आपल्या फाइल सिस्टिममध्ये त्याची स्थिती शोधायची होती, तर आपण पाहील की ती आत्ता तेथी आहे. 8 | 9 | यात द्यान द्या की उपरोक्त उदाहरणात, ``--cached`` ध्वज वापरला गेला आहे. जर आपल्याला हे ध्वज जोडण्यात येत नसेल, तर Gitला केवळ रेपोमधून नविन दूरस्थ, तर आपल्या फाइल सिस्टिममध्ये फाइल काढून टाकेल. 10 | 11 | जर आप git commit ``-m "Remove file1.js"`` साठी बदल करता आणि हे ``git push origin master`` वापरून दूरस्थ रेपॉजिटरीमध्ये दाखविता तर दूरस्थ रेपॉजिटरी तुमच्या फाइलला काढून टाकेल. 12 | 13 | ## अतिरिक्त सुविधा 14 | - जर आपल्या अनेक फाइल नकाल करायला इच्छिता, तर आप त्यांची सर्व एकाच कमांडमध्ये समाविष्ट करू शकता: 15 | 16 | ``git rm file1.js file2.js file3.js --cached`` 17 | 18 | - तुम्ही वाइल्डकार्ड (*) वापरून एकसारख्या फाइल काढू शकता. उदाहरणार्थ, जर तुम्हाला आपल्या स्थानिक संग्रहामध्ये सर्व .txt फाइल काढू शकता: 19 | 20 | ``git rm *.txt --cached`` 21 | -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/removing-a-file.md: -------------------------------------------------------------------------------- 1 | # Removing a file from Git 2 | 3 | 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: 4 | 5 | ``git rm --cached`` 6 | 7 | ## So what happened? 8 | 9 | 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. 10 | 11 | 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. 12 | 13 | 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. 14 | 15 | ## Additional features 16 | 17 | - If you want to remove more than one file, you can include them all in the same command: 18 | 19 | `git rm file1.js file2.js file3.js --cached` 20 | 21 | - You can use a wildcard (*) to remove similar files. For example, if you would like to remove all .txt files from your local repository: 22 | 23 | `git rm *.txt --cached` 24 | -------------------------------------------------------------------------------- /additional-material/translations/Indonesian/removing-a-file.id.md: -------------------------------------------------------------------------------- 1 | # Menghapus file 2 | 3 | Terkadang Anda ingin menghapus file dari Git, tetapi Anda tidak ingin menghapusnya dari komputer Anda. Anda dapat melakukan ini dengan menggunakan perintah berikut: 4 | 5 | `git rm --cached` 6 | 7 | ## Apa yang terjadi? 8 | 9 | Git tidak akan lagi melacak perubahan pada file yang dihapus. Bagi Git, file ini sudah tidak ada lagi. Jika Anda mencari file tersebut di disk Anda, Anda melihat bahwa file itu masih ada. 10 | 11 | Pada contoh di atas, kita menggunakan flag `--cached`. Jika kita tidak menggunakannya, Git juga akan menghapus file tersebut dari disk kita. 12 | 13 | Jika sekarang kita membuat komit dengan `git commit -m "Hapus file1.js"` dan mengirimkannya ke repositori jarak jauh dengan perintah `git push origin master`, file tersebut juga akan dihapus dari repositori jarak jauh. 14 | 15 | ## Opsi tambahan 16 | 17 | - Jika Anda ingin menghapus beberapa file, Anda dapat menyertakan semuanya dalam satu perintah: 18 | 19 | `git rm file1.js file2.js file3.js --cached` 20 | 21 | - Anda dapat menggunakan wildcard (\*) untuk menghapus file serupa. Misalnya, untuk menghapus semua file .txt dari repositori Anda, gunakan perintah: 22 | 23 | `git rm *.txt --cached` 24 | -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/moving-a-commit-to-a-different-branch.md: -------------------------------------------------------------------------------- 1 | # Moving a commit to a different branch 2 | What if you commit a change, and then realize that you committed to a different branch? 3 | How can you change that? This is what this tutorial covers. 4 | 5 | ## Moving the latest commits to an existing branch 6 | To do this, type: 7 | 8 | ```git reset HEAD~ --soft``` - Undoes the last commit, but leaves the changes available. 9 | ```git stash``` - Records the state of the directory. 10 | 11 | ```git checkout name-of-the-correct-branch``` - Switches to another branch. 12 | ```git stash pop``` - Removes latest stashed state. 13 | ```git add .``` - Or try adding individual files. 14 | ```git commit -m "your message here"``` - Saves and Commits the changes. 15 | 16 | Now your changes are on the correct branch 17 | 18 | 19 | ### Moving the latest commits to a new Branch 20 | To do this, type: 21 | ```git branch newbranch``` - Creates a new Branch. Saving all the Commits. 22 | ```git reset --hard HEAD~#``` - Move master back by # commits. Remember, these commits will be gone from master 23 | ```git checkout newbranch``` - Goes to the branch you created. It will have all the commits. 24 | 25 | Remember: Any changes not committed will be LOST. 26 | -------------------------------------------------------------------------------- /additional-material/translations/Portugues/removing-a-file.pt_br.md: -------------------------------------------------------------------------------- 1 | # Removendo um arquivo do Git 2 | 3 | À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: 4 | 5 | ``git rm --cached`` 6 | 7 | ## Então o que aconteceu? 8 | 9 | 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á. 10 | 11 | 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. 12 | 13 | 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. 14 | 15 | 16 | ## Características adicionais 17 | 18 | - Se você deseja remover mais de um arquivo, pode incluí-los todos no mesmo comando: 19 | 20 | `git rm file1.js file2.js file3.js --cached` 21 | 22 | - 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: 23 | 24 | `git rm *.txt --cached` 25 | -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/removing-a-file.by.md: -------------------------------------------------------------------------------- 1 | # Выдаленне файла з-пад GIT кантролю 2 | 3 | Часам можа ўзнікнуць неабходнасць выдаліць файл з-пад GIT кантролю, але захаваць яго на кампутары. Гэта можа быць дасягнута з дапамогай наступнай каманды: 4 | 5 | `` git rm <файл> --cached`` 6 | 7 | ## Што ж адбылося? 8 | 9 | GIT больш не кантралюе змены ў аддаленым файле. З пункту гледжання GIT, гэты файл адсутнічае, але калі вы паспрабуеце лакалізаваць гэты файл у файлавай сістэме, то вы ўбачыце, што ён усё яшчэ на месцы. 10 | 11 | Звярніце ўвагу, што ў прыведзеным вышэй прыкладзе выкарыстоўваецца сцяг `--cached`. Калі мы не дадамо гэты сцяг, Git выдаліць файл не толькі з сховішча, але і з вашай файлавай сістэмы. 12 | 13 | Калі вы здзейсніце змяненне з дапамогай `git commit -m" Remove file1.js "` і перанеслі яго ў аддаленае сховішча з дапамогай `git push origin master`, выдалены рэпазітар выдаліць файл. 14 | 15 | ## Дадатковая інфармацыя 16 | 17 | - Калі вы хочаце выдаліць больш за адзін файл, гэта можна зрабіць, пералічыўшы ўсе файлы ў адной камандзе: 18 | 19 | `git rm file1.js file2.js file3.js --cached` 20 | 21 | - Вы можаце выкарыстоўваць шаблон (*) для выдалення файлаў з блізкімі імёнамі, напрыклад, калі вы хочаце выдаліць усе .txt файлы з лакальнага рэпазітара, набярыце: 22 | 23 | `git rm * .txt --cached` -------------------------------------------------------------------------------- /additional-material/translations/Bengali/add-file.bn.md: -------------------------------------------------------------------------------- 1 | ## একটি নতুন ফাইল সংযুক্ত করার টিউটোরিয়াল 2 | 3 | আপনি যদি নতুন একটি ফাইল আপনার Git রিপোজিটরিতে সংযুক্ত করতে চান, তাহলে এই টিউটোরিয়ালটি আপনার সাহায্য করতে পারে। 4 | 5 | 1. **নতুন ফাইল তৈরি করুন**: 6 | - আপনি যে প্রজেক্ট ফোল্ডারে চান, তাতে যান। 7 | - নতুন ফাইল তৈরি করতে আপনি যে টেক্সট সম্পাদক বা IDE ব্যবহার করে যেতে পারেন, বা যদি আপনার কোন আইডি থাকে তাহলে তার মাধ্যমেও ফাইল তৈরি করতে পারেন। 8 | - ফাইলটির একটি নির্দিষ্ট নাম দিন এবং সংরক্ষণ করুন। 9 | 10 | 2. **ফাইলটি স্থানান্তর করুন**: 11 | - টার্মিনাল খুলুন এবং রিপোজিটরি ফোল্ডারে চলে যান। 12 | - নতুন ফাইলটি স্থানান্তর করতে আপনি নিম্নলিখিত কমান্ডটি ব্যবহার করুন: 13 | ``` 14 | git add নতুন_ফাইল.এক্সটেনশন 15 | ``` 16 | 17 | 3. **কমিট করুন**: 18 | - ফাইলটি স্থানান্তর করার পরে, একটি কমিট তৈরি করুন। 19 | - নিম্নলিখিত কমান্ডটি ব্যবহার করুন: 20 | ``` 21 | git commit -m "নতুন ফাইল সংযুক্ত করা হয়েছে" 22 | ``` 23 | 24 | 4. **রিমোট রিপোজিটরিতে পুশ করুন**: 25 | - এখন আপনার ফাইলটি আপনার লোকাল রিপোজিটরিতে রয়েছে। এটি রিমোট রিপোজিটরিতে পাঠাতে হলে নিম্নলিখিত কমান্ডটি ব্যবহার করুন: 26 | ``` 27 | git push দূরস্থ_শাখা 28 | ``` 29 | - এখানে "দূরস্থ_শাখা" তা হলো সে নাম যেখানে আপনি ফাইলটি সংযুক্ত করতে চান। 30 | 31 | এখন আপনি নতুন একটি ফাইলকে আপনার রিপোজিটরিতে সংযুক্ত করেছেন। 32 | -------------------------------------------------------------------------------- /additional-material/translations/Italian/removing-a-file.it.md: -------------------------------------------------------------------------------- 1 | # Rimuovere un file da Git 2 | 3 | Può succedere che tu voglia rimuovere un file da Git, mantenendolo comunque nel tuo computer. Lo puoi fare eseguendo questo comando: 4 | 5 | ``git rm --cached`` 6 | 7 | ## Cosa fa questo comando? 8 | 9 | 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ì. 10 | 11 | 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. 12 | 13 | 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. 14 | 15 | ## Funzioni aggiuntive 16 | 17 | - Per rimuovere più di un file, puoi aggiungerli tutti allo stesso comando in questo modo: 18 | 19 | `git rm file1.js file2.js file3.js --cached` 20 | 21 | - 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ì: 22 | 23 | `git rm *.txt --cached` 24 | -------------------------------------------------------------------------------- /additional-material/translations/Ukrainian/removing-a-file.ua.md: -------------------------------------------------------------------------------- 1 | # Видалення файлу з-під GIT контролю 2 | 3 | Іноді може виникнути необхідність видалити файл з-під GIT контролю, але зберегти його на комп'ютері. Це може бути досягнуто за допомогою наступної команди: 4 | 5 | `` Git rm <файл> --cached`` 6 | 7 | ## Що ж сталося? 8 | 9 | GIT більш не контролює зміни у віддаленому файлі. З точки зору GIT'а, його немає, але якщо ви спробуєте локалізувати цей файл в файловій системі, то ви побачите, що він все ще на місці. 10 | 11 | Зауважте, що в наведеній вище комманде використовується ключ `--cached`. Якби ми не додали цей ключ, GIT знищив би файл не тільки зі сховищ, але також і з файлової системи. 12 | 13 | Якщо ви зробите Комміт за допомогою команди `git commit -m" Видалити file1.js "` і потім запущено його в віддалений репозиторій командою `git push origin master`, файл буде стертий також і з віддаленого сховища. 14 | 15 | ## Додаткова інформація 16 | 17 | - Якщо ви хочете видалити більше одного файлу, це можна зробити, перерахувавши всі файли в одній команді: 18 | 19 |     `Git rm file1.js file2.js file3.js --cached` 20 | 21 | - Ви можете використовувати шаблон (*) для видалення файлів з близькими іменами, наприклад, якщо ви хочете видалити всі .txt файли з локального сховища, наберіть: 22 | 23 |     `Git rm * .txt --cached` 24 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/issue-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Suggest changes 3 | about: If you want to report a bug or suggest improvements, please open an issue. 4 | title: '' 5 | labels: discussion, question 6 | assignees: Roshanjossey 7 | 8 | --- 9 | 10 | 11 | 12 | 13 | 🐞 **Problem** 14 | 15 | 16 | 17 | 🎯 **Goal** 18 | 19 | 20 | 21 | 💡 **Possible solutions** 22 | 23 | 24 | 📋 **Steps to solve the problem** 25 | 26 | * Comment below about what you've started working on. 27 | * Add, commit, push your changes. 28 | * Submit a pull request and add this in comments - `Addresses #` 29 | * Ask for reviews in comments section of pull request. 30 | * Celebrate your contribution to this project. 🎉 31 | -------------------------------------------------------------------------------- /additional-material/translations/Hindi/moving-a-commit-to-a-different-branch.hi.md: -------------------------------------------------------------------------------- 1 | # एक कमिट शाखा को एक अलग शाखा में ले जाना 2 | क्या होगा यदि आप कोई बदलाव कमिट करते हैं, और फिर महसूस करें कि आप एक अलग शाखा में हैं? 3 | आप इसे कैसे बदल सकते हैं? यह ट्यूटोरियल कवर करता है। 4 | 5 | ## सबसे मौजूदा काम को मौजूदा शाखा में ले जाना 6 | इस काम को करने के लिए, निम्नलिखित कदमों का पालन करें: 7 | 8 | ``` git reset HEAD~ --soft ``` - आपकी आखिरी कमिट को पूर्ववत करेगा, लेकिन उपलब्ध परिवर्तनों को छोड़ देगा। 9 | ``` git stash ``` - आपके निर्देशिका की स्थिति को बचाएगा। 10 | ``` git checkout name-of-the-correct-branch ``` - दूसरी शाखा में स्विच करेगा। 11 | ``` git stash pop ``` - आखिरी स्टेशेड स्टेटस को हटा देगा। 12 | ``` git add ``` - या अलग-अलग फाइलों को एक साथ स्टेज करने का प्रयास करेगा। 13 | ``` git commit -m "आपका संदेश यहां" ``` - परिवर्तनों को सुरक्षित करेगा और कमिट करेगा। 14 | 15 | अब आपके परिवर्तन सही शाखा पर हैं 16 | 17 | ### सबसे पुराना काम एक नई शाखा में ले जाना 18 | इस काम को करने के लिए, निम्नलिखित कदमों का पालन करें: 19 | ``` git branch newbranch``` - एक नई शाखा बनाएगा। सभी कमिट को सुरक्षित कर देगा। 20 | ``` git reset --hard HEAD~#``` - मास्टर को वापस # कमिट में ले जाएगा। याद रखें, यह काम मास्टर से जा चुका होगा। 21 | ``` git checkout newbranch``` - आपके द्वारा बनाई गई शाखा में जाएगा। इसमें सभी कमिट होंगे। 22 | 23 | याद रखें: कोई भी बदलाव कमिट नहीं किया गया होगा तो वह खो जाएगा। -------------------------------------------------------------------------------- /additional-material/translations/Russian/removing-a-file.ru.md: -------------------------------------------------------------------------------- 1 | # Удаление файла из-под GIT контроля 2 | 3 | Иногда может возникнуть необходимость удалить файл из-под GIT контроля, но сохранить его на компьютере. Это может быть достигнуто с помощью следующей команды: 4 | 5 | ``git rm <файл> --cached`` 6 | 7 | ## Что же произошло? 8 | 9 | GIT более не контролирует изменения в удалённом файле. С точки зрения GIT'а, этот файл отсутствует, но если вы попробуете локализовать этот файл в файловой системе, то вы увидите, что он всё еще на месте. 10 | 11 | Заметьте, что в приведенной выше комманде используется ключ `--cached`. Если бы мы не добавили этот ключ, GIT уничтожил бы файл не только из репозитория, но также и из файловой системы. 12 | 13 | Если вы сделаете коммит при помощи команды `git commit -m "Удалить file1.js"` и затем запушите его в удалённый репозиторий командой `git push origin master`, файл будет стёрт также и из удалёного репозитория. 14 | 15 | ## Дополнительная информация 16 | 17 | - Если вы хотите удалить более одного файла, это можно сделать, перечислив все файлы в одной команде: 18 | 19 | `git rm file1.js file2.js file3.js --cached` 20 | 21 | - Вы можете использовать шаблон (*) для удаления файлов с близкими именами, например, если вы хотите удалить все .txt файлы из локального репозитория, наберите: 22 | 23 | `git rm *.txt --cached` 24 | -------------------------------------------------------------------------------- /additional-material/translations/Slovenian/moving-a-commit-to-a-different-branch.sl.md: -------------------------------------------------------------------------------- 1 | # Premikanje commita v drugo vejo 2 | 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. 3 | 4 | ## Premikanje zadnjega commita v obstoječo vejo 5 | To storiš z naslednjimi ukazi: 6 | 7 | ```git reset HEAD~ --soft``` - Razveljavi zadnji commit, spremembe ostanejo na voljo. 8 | ```git stash``` - Posname stanje direktorija in ga shrani v `stash`. 9 | 10 | ```git checkout name-of-the-correct-branch``` - Prestavi v drugo vejo. 11 | ```git stash pop``` - Vzame zadno shranjeno stanje iz `stash-a`. 12 | ```git add .``` - Ali dodaš posamezne datoteke. 13 | ```git commit -m "your message here"``` - Shrani in izvede commit sprememb. 14 | 15 | Sedaj so tvoje spremembe na pravi veji. 16 | 17 | 18 | ### Premikanje zadnjih nekaj commitov v novo vejo 19 | To storiš z naslednjimi ukazi: 20 | ```git branch newbranch``` - Ustvariš novo vejo. Nova veja ima vse prej ustvarjene commite. 21 | ```git reset --hard HEAD~#``` - Premakni glavno vejo ( master ) nazaj za # commit-ov. Ti commit-i bodo izbrisani z glavne veje! 22 | ```git checkout newbranch``` - Prestaviš se v novo vejo, ki ima vse prej ustvarjene commit-e. 23 | 24 | Pomembno: Vse spremembe, ki niso bile commit-ane, bodo IZGUBLJENE! -------------------------------------------------------------------------------- /additional-material/translations/Portugues/moving-a-commit-to-a-different-branch.pt_br.md: -------------------------------------------------------------------------------- 1 | # Movendo um commit para outra branch 2 | E se apenas depois de ter realizado o commit de uma alteração, vocẽ perceber que fez esse commit na branch errada? 3 | Como você poderia corrigir isso? É sobre isso que este tutorial se trata. 4 | 5 | ## Movendo os últimos commits para uma branch existente 6 | Para fazer isso, digite: 7 | 8 | 9 | ```git reset HEAD~ --soft``` - Desfaz o último commit, mas mantém as alterações disponíveis. 10 | ```git stash``` - Grava o estado do diretório. 11 | 12 | ```git checkout name-of-the-correct-branch``` - Alterna para a outra branch. 13 | ```git stash pop``` - Recupera o último estado salvo. 14 | ```git add .``` - Ou tente adicionar arquivos individualmente. 15 | ```git commit -m "your message here"``` - Faça o commit das alterações. 16 | 17 | Agora suas alterações estão na branch correta 18 | 19 | ### Movendo o último commit para uma branch nova 20 | Para fazer isso, digite: 21 | ```git branch newbranch``` - Cria uma nova branch, mantendo todos os commits. 22 | ```git reset --hard HEAD~#``` - Retrocede a branch uma quantidade # de commits. Atenção, estes commits serão removidos da branch. 23 | ```git checkout newbranch``` - Vá para a nova branch que você criou, ela possuíra todos os commits. 24 | 25 | Lembre-se: Qualquer alteração não comitada será PERDIDA. 26 | -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/moving-a-commit-to-a-different-branch.by.md: -------------------------------------------------------------------------------- 1 | # Перамяшчэнне камітаў ў іншую галінку 2 | Што рабіць, калі вы здзяйсняеце змены, а потым разумееце, што вы здзейснілі іншую галіну? 3 | Як вы можаце гэта змяніць? Вось што ахоплівае гэты падручнік. 4 | 5 | ## Перамяшчэнне апошніх камітаў ў існуючую галінку 6 | Для такога перамяшчэння, набярыце: 7 | 8 | `` `git reset HEAD ~ --soft` `` - Адмяняе апошняе commit, але пакідае даступныя змены. 9 | `` `git stash` `` - Захоўвае стан дырэкторыі. 10 | 11 | `` `git checkout <імя правільнай галінкі>` `` - Перамыкаецца на іншую галінку. 12 | `` `git stash pop` `` - Вяртае апошняе захаванае стан. 13 | `` `git add .` `` - Дадае індывідуальныя файлы. 14 | `` `git commit -m "your message here"``` - Захоўвае і ўносіць змены. 15 | 16 | Зараз вашы змены - у правільнай галінцы. 17 | 18 | 19 | ### Перамяшчэнне апошніх камітаў ў новую галінку 20 | Для такога перамяшчэння, набярыце: 21 | `` `git branch newbranch` `` - Стварае новую галінку, захоўваючы ўсе камітаў. 22 | `` `git reset --hard HEAD ~ [n]` `` - Вяртае галінку master назад на n камітаў. Майце на ўвазе, што змены змяшчаюцца ў гэтых камітаў будуць цалкам выдалены з галінкі master. 23 | `` `git checkout newbranch` `` - Перамыкаецца на галінку, якую вы стварылі. Гэтая галінка цяпер змяшчае ўсе commits. 24 | 25 | Запомніце: Любыя змены, якія не былі ўключаныя ў commit, будуць цалкам страчаныя. -------------------------------------------------------------------------------- /additional-material/translations/Hindi/removing-a-file.hi.md: -------------------------------------------------------------------------------- 1 | Here's the corrected README.md file with improved grammar: 2 | 3 | # गिट से एक फाइल को हटाना 4 | कभी-कभी, आपको किसी फ़ाइल को Git से हटाने की आवश्यकता होती है, लेकिन आप नहीं चाहते कि यह आपके कंप्यूटर से हटा दिया जाए। आप निम्नलिखित कमांड का उपयोग करके इसे प्राप्त कर सकते हैं: 5 | 6 | ``git rm --cached`` 7 | 8 | ## इसका क्या मतलब है? 9 | Git अब हटाई गई फ़ाइल में किए गए परिवर्तनों का ट्रैकिंग नहीं करेगा। जैसा कि Git को पता होगा, आपने इस फ़ाइल को हटा दिया है। यदि आपने अपने फ़ाइल सिस्टम में फ़ाइल का पता लगाने का प्रयास किया हो, तो आप देखेंगे कि यह अभी भी वहीं है। 10 | 11 | यह ध्यान दें कि ऊपर के उदाहरण में, ``--cached`` फ़्लैग का प्रयोग किया गया है। अगर हमने इस ध्वज को नहीं जोड़ा होता, तो Git न केवल रेपोसिटरी से, बल्कि आपके फ़ाइल सिस्टम से भी फ़ाइल को हटा देता। 12 | 13 | यदि आप ``git commit -m "Remove file1.js"`` के साथ इस परिवर्तन को करते हैं और फिर ``git push origin master`` का उपयोग करके दूरस्थ रेपोसिटरी में पुश करते हैं, तो दूरस्थ रेपोसिटरी में फ़ाइल को हटा दिया जाएगा। 14 | 15 | ## अतिरिक्त विशेषताएँ 16 | - यदि आपको एक से अधिक फ़ाइलों को हटाना है, तो आप उन सभी को एक ही कमांड में शामिल कर सकते हैं: 17 | 18 | ``git rm file1.js file2.js file3.js --cached`` 19 | 20 | - आप वाइल्डकार्ड (*) का उपयोग करके समान प्रकार की फ़ाइलों को हटाने के लिए उपयोग कर सकते हैं। उदाहरण के लिए, यदि आप अपने स्थानीय भंडार से सभी .txt फ़ाइलों को हटाना चाहते हैं: 21 | 22 | ``git rm *.txt --cached`` -------------------------------------------------------------------------------- /additional-material/translations/Russian/moving-a-commit-to-a-different-branch.ru.md: -------------------------------------------------------------------------------- 1 | # Перемещение коммита в другую ветку 2 | Что если вы сделали коммит, а затем поняли, что изменили неправильную ветку? 3 | Как исправить такую ошибку? На этот вопрос отвечает данная инструкция. 4 | 5 | ## Перемещение последних коммитов в существующую ветку 6 | Для такого перемещения, наберите: 7 | 8 | ```git reset HEAD~ --soft``` - Отменяет последний коммит, но сохраняет сделанныые изменения. 9 | ```git stash``` - Сохраняет состояние директории. 10 | 11 | ```git checkout <имя правильной ветки>``` - Переключается на другую ветку. 12 | ```git stash pop``` - Возвращает последнее сохраненное состояние. 13 | ```git add .``` - Добавляет индивидуальные файлы. 14 | ```git commit -m "ваш комментарий"``` - Сохраняет и делает коммит изменений. 15 | 16 | Теперь ваши изменения - в правильной ветке. 17 | 18 | 19 | ### Перемещение последних коммитов в новую ветку 20 | Для такого перемещения, наберите: 21 | ```git branch newbranch``` - Создает новую ветку, сохраняя все коммиты. 22 | ```git reset --hard HEAD~[n]``` - Возвращает ветку master назад на n коммитов. Имейте в виду, что изменения содержащиеся в этих коммитах будут полностью удалены из ветки master. 23 | ```git checkout newbranch``` - Переключается на ветку, которую вы создали. Эта ветка теперь содержит все коммиты. 24 | 25 | Запомните: Любые изменения, которые не были включены в коммит, будут полностью ПОТЕРЯНЫ. 26 | -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/resetting-a-branch.md: -------------------------------------------------------------------------------- 1 | # Reset a branch 2 | 3 | ```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.
4 | 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. 5 | 6 | ## The Command 7 | 8 | Its very easy to execute a git reset for branch. 9 | ``` 10 | git reset 11 | ``` 12 | 13 | An example could be: 14 | ``` 15 | git reset stage master --hard 16 | ``` 17 | The above command will reset the `stage` branch with `master` and therefore make `stage` exactly same as `master`. 18 | 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. 19 | -------------------------------------------------------------------------------- /additional-material/translations/Hindi/resetting-a-branch.hi.md: -------------------------------------------------------------------------------- 1 | # एक शाखा रीसेट करें 2 | 3 | ```reset``` वह कमांड है जिसका उपयोग तब किया जा सकता है जब हम किसी कमिट या शाखा के संबंध में रिपॉजिटरी को रीसेट करना चाहते हैं। एक रीसेट, जैसा कि नाम से पता चलता है, वर्तमान शाखा पर सब कुछ त्याग देता है और इसे उस शाखा के समान बना देता है जिसके साथ हमने आधार शाखा को रीसेट करना चुना (इसे मूल शाखा भी कहा जाता है)। इसका अनिवार्य रूप से मतलब यह है कि हमारे पास मूल शाखा के नाम के साथ मूल शाखा की एक कॉपी होगी।
4 | हालाँकि, सवाल यह है कि हम आधार शाखा को क्यों नहीं हटा देते हैं और मूल शाखा से आधार शाखा के नाम से एक नई शाखा क्यों नहीं चेकआउट कर देते हैं। तकनीकी रूप से, इसका प्रभाव रीसेट करने जैसा ही होगा लेकिन कुछ औद्योगिक स्थितियों में हमारे पास किसी शाखा को हटाने की पहुंच नहीं है, या हम किसी शाखा को हटा नहीं सकते हैं क्योंकि यह सीआई/सीडी पाइपलाइन या शायद चल रहे वर्कफ़्लो को बाधित/बाधित कर देगा। इसलिए, ऐसी स्थितियों से बचने के लिए जो डाउनटाइम का कारण बन सकती हैं, हम सुझाव देते हैं कि जब भी हम किसी विशेष शाखा को रीसेट करना चाहते हैं तो `git reset` का उपयोग करें। 5 | 6 | ## कम्मांड 7 | 8 | शाखा के लिए गिट रीसेट निष्पादित करना बहुत आसान है। 9 | ``` 10 | git reset 11 | ``` 12 | 13 | उदाहरण के तौर पर: 14 | ``` 15 | git reset stage master --hard 16 | ``` 17 | उपरोक्त कमांड `stage` शाखा को `master` के साथ रीसेट कर देगा और इसलिए `stage` को बिल्कुल `master` के समान बना देगा। 18 | आप सोच रहे होंगे कि `--hard` फ्लैग का उपयोग क्यों किया जाता है? इसका उद्देश्य उन सभी परिवर्तनों को अनदेखा करना है जो रीसेट से पहले/बाद में होंगे या होंगे। -------------------------------------------------------------------------------- /additional-material/translations/Korean/reverting-a-commit.ko.md: -------------------------------------------------------------------------------- 1 | ## 커밋 되돌리기 2 | 3 | 커밋을 되돌리려면 이전 커밋에서 수행 된 모든 변경 사항을 취소하는 새로운 커밋을 만드는 것입니다. 그것은 git에서 ```CTRL + Z ``` 를 실행하는 것과 같습니다. 4 | 5 | 원격 저장소에 푸시하는 모든 커밋에는 SHA(Secure Hash Algorithm)라고 하는 고유한 알파벳 키가 있으므로 git에서 되돌리기가 쉬워집니다. 즉, SHA를 사용하는 한 언제든지 커밋을 되돌릴 수 있습니다. 하지만 그렇게 하면, 당신의 저장소가 엉망이 되지 않도록 조심스럽게 순서대로 배열해야 합니다. 6 | 7 | 실행 취소하려는 특정 커밋의 SHA를 선택하려면 지금까지 작성한 모든 커밋의 로그가 도움이 될 것입니다. 8 | 이를 위해 다음 명령을 실행합니다: 9 | ```git log --oneline ``` 10 | ```git log``` 명령만 실행하면 SHA(긴 형식)을 얻을 수 있지만 ```--oneline ``` 플래그를 사용하면 보다 가독성이 좋은(한줄) 방식으로 표시할 수 있습니다. 11 | 12 | 이 명령을 실행할 때 표시되는 첫번째 7개의 문자는 축약 커밋 해시라고 합니다. 13 | 14 | 예를 들어, 이 저장소에서 ```git log --oneline ``` 을 실행하면 다음과 같은 결과를 얻을 수 있습니다: 15 | For example, here is what I get when I run ```git log --oneline ``` on this repository: 16 | ``` 17 | 389004d added spacing in title 18 | c1b9fc1 Merge branch 'master' into tutorials 19 | 77eaafd added tutorial for reverting a commit 20 | ``` 21 | 22 | 따라서 ```git log --oneline``` 을 사용하면 SHA의 처음 7개의 문자와 함께 저장소에서 작성한 모든 커밋 목록을 가져올 수 있습니다. 23 | 24 | 이제 "added spacing in title"에 대한 커밋을 취소하고 싶다고 가정하고, 다음 단계를 수행하겠습니다. 25 | 26 | * 커밋의 SHA를 복사합니다. 여기서는 ```389004d``` 입니다. 27 | * 그리고 나서 ```git revert 389004d``` 명령을 싱행합니다. 28 | 29 | 이렇게 하면 텍스트 편집기가 열리고 커밋 메시지를 편집하라는 메시지가 표시됩니다. 커밋 메시지를 `Revert` 라는 단어로 시작하는 기본 git 메시지로 남겨두거나 원하는대로 메시지를 작성할 수도 있습니다. 30 | 31 | * 다음으로, 텍스트 편집기를 저장하고 닫습니다. 32 | * 커맨드 라인으로 돌아갑니다. 33 | * ```git push origin ``` 을 실행하여 되돌린 변경사항을 Github에 푸시하십시오. 34 | 35 | 그리고 바로 변경사항이 원상태로 돌아갈 것입니다. 이 경우에 저장소가 ```c1b9fc1``` 의 상태로 되돌아갑니다. 36 | -------------------------------------------------------------------------------- /additional-material/translations/Chinese/additional-material.zh-cn.md: -------------------------------------------------------------------------------- 1 | # 附加资料 2 | 3 | 我们认为你在来到这里之前已经完成基本教学。附加资料会给你关于 Git 进阶技术的信息。 4 | 5 | ### [从你的 repository 删除分支](../removing-branch-from-your-repository.md) 6 | 这份文件教你如何从 repository 删除分支。 7 | > 在做这些步骤前确定你的 pull request 是被合并的。 8 | 9 | ### [保持你的分叉与 repository 同步](../keeping-your-fork-synced-with-this-repository.md) 10 | 这份文件提供保持分叉与原始 repository 同步的资料。这件事情是很重要的，因为有其他人会对 project 做出贡献。 11 | > 如果你的分叉没有对原始 repository 做改变，根据这些步骤操作。 12 | 13 | ### [回滚 commit](../reverting-a-commit.md) 14 | 这份文件提供如何对远端 repository 回滚 commit。这项操作在需要回滚 commit，但已经 push 到 Github时适用。 15 | > 如果你想要回滚 commit，根据这些步骤操作。 16 | 17 | ### [修改 commit](../amending-a-commit.md) 18 | 这份文件教你如何在修改在远端的 commit。 19 | > 在你需要调整 commit 的时候使用这个。 20 | 21 | ### [恢复本地的 commit](../undoing-a-commit.md) 22 | 这份文件教你如何恢复本地的 commit。在你觉得你搞砸了本地的 repository，并且希望重置你的 repository时，照着做就对了。 23 | > 如果你需要回复/重置 commit 时，跟着做吧。 24 | 25 | ### [解决合并冲突](../resolving-merge-conflicts.md) 26 | 这份文件教你解决合并时的冲突。 27 | > 跟着这些步骤来解决烦人的冲突。 28 | 29 | ### [删除文件](../removing-a-file.md) 30 | 这份文件教你从本地 repository 中删除文件。 31 | > 跟着这些步骤学习如何从之前的 commit 中删除文件。 32 | 33 | ### [移动 commit 到另一个分支](../moving-a-commit-to-a-different-branch.md) 34 | 这份文件教你如何移动 commit 到另一个分支。 35 | > 跟着步骤移动 commit 到另一个分支。 36 | 37 | ### [配置 git](../configuring-git.md) 38 | 这份文件教你设置 git 的用户资料与其他选项。 39 | > 阅读这份文件让你对 git 配置更有掌握。 40 | 41 | ### [好用的链接](../Useful-links-for-further-learning.md) 42 | 这份文件包含许多好用的博文、网站、提示和小技巧，了解这些让我们可以更容易上手。这一页应该当做好用链接的索引，让开源的新手还有想认识开源的人可以了解更多。 43 | 44 | ### [挤压 commits](../squashing-commits.md) 45 | 这份文件教你如何通过交互式 rebase 挤压 commits。 46 | > 如果你想要发出一个 PR，但检阅者要求你将一部分 commits 挤压成一个 commits 通过交互式 rebase。 47 | -------------------------------------------------------------------------------- /additional-material/translations/Slovenian/removing-branch-from-your-repository.sl.md: -------------------------------------------------------------------------------- 1 | # Odstrani vejo s svojega repository-ja 2 | 3 | Če si sledil vodiču do tukaj, sedaj tvoja veja `` 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š. 4 | 5 | Najprej združiš `` z glavno ( master ) vejo, zato se postavi vanjo: 6 | ``` 7 | git checkout master 8 | ``` 9 | 10 | Združi `` z master: 11 | ``` 12 | git merge master 13 | ``` 14 | 15 | Odstrani `` z lokalnega repository-ja: 16 | ``` 17 | git branch -d 18 | ``` 19 | 20 | Sedaj si zbrisal `` 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! 21 | 22 | Če pa je tvoja GitHub veja že združena v moj projekt, in jo želiš zbrisati, uporabi naslednji ukaz: 23 | ``` 24 | git push origin --delete 25 | ``` 26 | 27 | Sedaj veš kako počistiti neuporabne veje s svojega repository-ja. 28 | 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: 29 | 30 | #### [Kako imeti svojo različico sinhronizirano z oddaljenim repository-em](keeping-your-fork-synced-with-this-repository.sl.md) 31 | -------------------------------------------------------------------------------- /additional-material/translations/Korean/amending-a-commit.ko.md: -------------------------------------------------------------------------------- 1 | ## 커밋 수정하기 2 | 3 | 만약 커밋 메시지에 오타가 있거나 가장 최근의 커밋에서 몇줄을 빼먹은 걸 나중에 깨닫고 원격 저장소로 커밋을 수정하고자 하는 경우 어떻게 할까요? 이 자습서는 이러한 내용을 다룹니다. 4 | 5 | ### Github에 이미 푸시한 후에 최근 커밋 메시지 변경하기 6 | 파일을 열지 않고 수행할 경우: 7 | * 다음을 타이핑합니다. ```git commit --amend -m "followed by your new commit message"``` 8 | * 변경사항을 저장소에 커밋하려면 다음을 실행합니다. ```git push origin ``` 9 | 10 | 참고: 단지 ```git commit --amend``` 이것만 입력한다면, 텍스트 편집기가 커밋 메시지를 입력하라고 할 것입니다. ``-m`` 플래그를 추가하면 이것을 막을 수 있습니다. 11 | 12 | ### Modifying on a single commit 13 | 14 | 그럼 한 단어를 변경하는 것과 같이 사소한 변경사항을 깜빡하고 커밋을 이미 원격 저장소에 푸시했다면 어떻게 해야 할까요? 15 | 16 | 이를 설명하기 위해 여기 제 커밋 로그가 있습니다: 17 | ``` 18 | g56123f create file bot file 19 | a2235d updated contributor.md 20 | a5da0d modified bot file 21 | ``` 22 | 봇 파일에 한 단어를 추가하는 것을 깜빡했다고 해 봅시다. 23 | 24 | 이 경우 두가지 방법이 있습니다. 첫번째는 다음과 같이 변경사항을 포함하는 완전히 새로운 커밋을 수행하는 것입니다: 25 | ``` 26 | g56123f create file botfile 27 | a2235d updated contributor.md 28 | a5da0d modified botfile 29 | b0ca8f added single word to botfile 30 | ``` 31 | 두번째 방법은 a5da0d 커밋을 수정하고, 새 단어를 추가하고 이를 하나의 커밋으로 Github에 푸시하는 것 입니다. 32 | 이 방법은 사소한 변화이기 때문에 더 나을수도 있습니다. 33 | 34 | 이를 위해 다음을 수행하십시오: 35 | * 파일을 수정하십시오. 이 경우, 이전에 빠뜨린 단어를 포함하여 봇 파일을 수정합니다. 36 | * 그 다음, ```git add ``` 을 실행하여 파일을 스테이징 영역으로 추가합니다. 37 | 38 | 보통 파일을 스테이징 영역에 추가하고 나면, 다음으로 우리가 해야할 일은 git commit -m "our commit message" 입니다. 39 | 그러나 여기서 우리가 원하는 것은 이전 커밋을 수정하는 것이므로, 다음을 실행합니다: 40 | 41 | * ```git commit --ammend``` 42 | 그러면 텍스트 편집기가 뜨고 메시지를 수정하라는 프롬프트가 뜰 것입니다. 이전 그대로 메시지를 두거나 변경할 수 있습니다. 43 | * 에디터를 빠져나오십시오. 44 | * ```git push origin ` 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. 4 | 5 | First, let's merge your `` to your master, so to go to your master branch: 6 | ``` 7 | git checkout master 8 | ``` 9 | 10 | Merge `` to master: 11 | ``` 12 | git merge master 13 | ``` 14 | 15 | Remove `` on your local machine's repo: 16 | ``` 17 | git branch -d 18 | ``` 19 | 20 | You have now deleted your local machine's `` branch and everything looks neat and tidy. 21 | Though, at this point, you should still have the `` 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. 22 | 23 | However, if I have merged your branch and you want to delete the remote branch, use: 24 | ``` 25 | git push origin --delete 26 | ``` 27 | 28 | Now, you know how to tidy your branches. 29 | 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. 30 | 31 | #### [Keeping your fork synced with the repository](keeping-your-fork-synced-with-this-repository.md) 32 | -------------------------------------------------------------------------------- /additional-material/translations/Indonesian/removing-branch-from-your-repository.id.md: -------------------------------------------------------------------------------- 1 | # Remove a branch from your repository 2 | 3 | If you have followed the tutorial up-to-now, our `` 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. 4 | 5 | First, let's merge your `` to your master, so to go to your master branch: 6 | ``` 7 | git checkout master 8 | ``` 9 | 10 | Merge `` to master: 11 | ``` 12 | git merge master 13 | ``` 14 | 15 | Remove `` on your local machine's repo: 16 | ``` 17 | git branch -d 18 | ``` 19 | 20 | You have now deleted your local machine's `` branch and everything looks neat and tidy. 21 | Though, at this point, you should still have the `` 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. 22 | 23 | However, if I have merged your branch and you want to delete the remote branch, use: 24 | ``` 25 | git push origin --delete 26 | ``` 27 | 28 | Now, you know how to tidy your branches. 29 | 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. 30 | 31 | #### [Keeping your fork synced with the repository](keeping-your-fork-synced-with-this-repository.md) 32 | -------------------------------------------------------------------------------- /additional-material/translations/Korean/resolving-merge-conflicts.ko.md: -------------------------------------------------------------------------------- 1 | # 병합 충돌이 무엇인가요? 2 | 3 | 여러분이 또 다른 브랜치에서 현재 작업중인 브랜치로 병합하고자할 때, 또 다른 변경사항들도 같이 반영되어야 하므로 여러분의 현재 작업중인 파일들에 같이 결합이 이루어지게 됩니다. 4 | 만일 이때 두 사람이 같은 파일의 똑 같은 라인을 (각자 다르게)변경했거나 다른 사람이 수정 반영한 곳을 삭제하려고 한다면 Git은 어느 변경사항이 옳은 것인지 쉽게 판단할 수 없습니다. 5 | 이때 Git은 여러분 스스로 이 문제를 반드시 해결하도록 충돌이 있음을 파일에 표시합니다. 6 | 7 | 8 | # 병합 충돌은 어떻게 해결하나요? 9 | 10 | 병합 충돌이 발생하면 Git은 문제가 되는 부분에 “<<<<<<<< HEAD” 와 “>>>>>>>>>>[other branch name]” 으로 감싸서 표시합니다. 11 | 12 | 이때 여러분이 현재 작업중인 브랜치가 먼저 표기됩니다. 꺽쇠기호 뒤를 보면 어느 브랜치에서 변경사항이 반영되었는지 알 수 있습니다. 13 | "=======" 기호는 충돌이 발생한 부분을 각각 구분해줍니다. 14 | 여러분이 해야할 일은 바로 위와 같은 충돌표시들을 원하는 코드만 보이도록 깨끗하게 정리하는 것입니다. 15 | 따라서 충돌을 발생케한 여러분의 동료와 어느 변경사항이 옳은 것인지 서로 이야기를 나눠야합니다. 16 | 여러분의 변경사항이 옳을 수도 있고 그렇지 않을 수도 있습니다. 아니면 양자 모두의 변경사항을 합쳐야만 하는 경우도 있을 수 있겠죠. 17 | 18 | 19 | 예시: 20 | ``` 21 | <<<<<<< HEAD:mergetest 22 | This is my third line 23 | ======= 24 | This is a fourth line I am adding 25 | >>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest 26 | ``` 27 | 28 | <<<<<<<: 병합 충돌이 시작되는 곳을 표시합니다. 여러분이 병합하고자하는 변경한 라인들로 이루어진 부분이 첫번째로 표기됩니다. 29 | =======: 비교하기 위한 구분선을 나타냅니다. 쉽게 차이를 파악할 수 있도록 사용자가 커밋한 변경사항(위)과 병합을 위해 로드된 부분(아래)으로 구분되어 있습니다. 30 | >>>>>>>: 병합 충돌이 발생한 마지막 위치를 표시합니다. 31 | 32 | 33 | Git에서 병합하는 것에 문제가 있는 부분을 일일이 수작업으로 편집해서 병합하면서 충돌문제를 해결합니다. 34 | 이는 여러분의 수정사항을 삭제하거나 다른 누군가의 변경사항을 지우는 일이며 또는 이 두 부분을 하나로 합치는 것을 의미합니다. 35 | 그리고 해당 파일에서 '<<<<<<<', '=======', 그리고 '>>>>>>>'을 지워야합니다. 36 | 37 | 일단 충돌을 해결했다면 `git add`를 실행합니다. 38 | 아울러 충돌이 올바르게 해결되었는지 확인하기 위해 반드시 테스트를 수행하는 것을 잊지마십시요. 39 | 40 | 병합 충돌을 보다 쉽게 해결하려면 여러분이 사용하는 각각의 IDE에 맞는 적절한 플러그인을 다운로드 받아 설치하세요. 41 | 42 | # 병합을 어떻게 되돌리나요? 43 | 병합을 취소하려면 `git merge —abort` 명령을 실행하세요. 44 | -------------------------------------------------------------------------------- /additional-material/translations/Hindi/removing-branch-from-your-repository.hi.md: -------------------------------------------------------------------------------- 1 | # अपने रिपॉजिटरी से एक शाखा निकालें 2 | 3 | यदि आपने अब तक ट्यूटोरियल का पालन किया है, तो हमारी `` शाखा ने अपना उद्देश्य पूरा कर लिया है, अब यह आपके स्थानीय मशीन के रेपो से इसे हटाने का समय है। यह आवश्यक नहीं है, लेकिन इस शाखा का नाम इसके बजाय विशेष उद्देश्य दिखाता है। इसका जीवन संगत रूप से छोटा हो सकता है। 4 | 5 | सबसे पहले, अपने मास्टर में अपने `` को मर्ज करें, इसलिए अपनी मास्टर शाखा पर जाएं: 6 | ``` 7 | git checkout master 8 | ``` 9 | 10 | उसके बाद मास्टर में ``मर्ज करें: 11 | ``` 12 | git merge master 13 | ``` 14 | 15 | फिर अपने स्थानीय मशीन के रेपो से `` निकालें: 16 | ``` 17 | git branch -d 18 | ``` 19 | 20 | अब आपने अपनी स्थानीय मशीन की `` शाखा हटा दी है और सब कुछ साफ़ सुथरा लग रहा है। 21 | हालांकि, इस समय, आपके पास अभी भी आपके गिटहब फोर्क में `` शाखा होनी चाहिए। हालांकि, इससे पहले कि आप इसे हटा दें, याद रखें कि आपने इस रिमोट शाखा से अपने रेपो को "पुल रिक्वेस्ट" भेजा है। इसलिए जब तक कि मैं इसे मर्ज नहीं करता हूं, इस शाखा को न हटाएं। 22 | 23 | हालांकि, अगर मैंने आपकी शाखा मर्ज कर ली है और आप रिमोट शाखा को हटाना चाहते हैं, तो इसका उपयोग करें: 24 | ``` 25 | git push origin --delete 26 | ``` 27 | 28 | अब, आप जानते हैं कि अपनी शाखाओं को कैसे साफ किया जाए। 29 | समय के साथ, मेरे सार्वजनिक रिपो में कई रेपो जोड़े जाएंगे। और आपकी स्थानीय मशीन और आपके गिटहब फर्क की मास्टर शाखाएं अद्यतित नहीं होंगी। तो अपने रेपोसिटोरिएस को मेरे साथ सिंक्रनाइज़ करने के लिए, नीचे दिए गए चरणों का पालन करें। 30 | 31 | #### [अपने फोर्क को रिपॉजिटरी के साथ सिंक रखना] (keeping-your-fork-synced-with-this-repository.md) -------------------------------------------------------------------------------- /additional-material/translations/Portugues/removing-branch-from-your-repository.pt_br.md: -------------------------------------------------------------------------------- 1 | ## Removendo o Branch do seu repositório 2 | 3 | Se você seguiu o tutorial até agora, seu Branch `` 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. 4 | 5 | Primeiro, vamos mesclar o Branch `` ao seu Branch principal (master), então vamos para ela: 6 | ``` 7 | git checkout master 8 | ``` 9 | 10 | Mescle `` ao master: 11 | ``` 12 | git merge master 13 | ``` 14 | 15 | Remova `` do seu repositório local: 16 | ``` 17 | git branch -d 18 | ``` 19 | 20 | Agora você deletou seu Branch local `` e tudo está limpo e arrumado. 21 | Nesse ponto, você ainda deve ter o Branch `` 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. 22 | 23 | Porém, se eu já tiver mesclado seu Branch e você quer deletar o Branch remoto, use: 24 | ``` 25 | git push origin --delete 26 | ``` 27 | 28 | Agora, você sabe como arrumar seus Branches. 29 | 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. 30 | 31 | #### [Mantendo o seu Fork sincronizado com este repositório](keeping-your-fork-synced-with-this-repository.pt_br.md) 32 | -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/removing-branch-from-your-repository.by.md: -------------------------------------------------------------------------------- 1 | # Выдаленне галінкі з вашага рэпазітара 2 | 3 | Калі вы да гэтага часу выконвалі ўрок, то наша галіна `` скончыла сваё прызначэнне, прыйшоў час выдаліць яго з рэпазітара вашай лакальнай машыны. Гэта не абавязкова, але назва гэтай галіны паказвае сваё даволі спецыяльнае прызначэнне. Яго жыццё можа быць адпаведна кароткім. 4 | 5 | Спачатку давайце аб'яднаем ваша `` з вашым майстрам, каб перайсці да вашай галіны: 6 | ``` 7 | git checkout master 8 | ``` 9 | 10 | Зліце `` у майстар: 11 | ``` 12 | git merge master 13 | ``` 14 | 15 | Выдаліце `` у сховішчах вашай лакальнай машыны: 16 | ``` 17 | git branch -d 18 | ``` 19 | 20 | Цяпер вы выдалілі галінку лакальнай машыны `` і ўсё выглядае акуратна і акуратна. 21 | Хоць, у гэты момант у вашай раздзеле GitHub усё яшчэ павінна быць аддзяленне ``. Тым не менш, перш чым выдаліць гэта, памятайце, што вы адправілі "Pull request" у маё сховішча з гэтага аддаленага аддзялення. Таму, калі я ўжо аб'яднаў гэта, не выдаляйце гэтую галінку. 22 | 23 | Аднак калі я аб'яднаў вашу галіну і вы хочаце выдаліць аддаленую галінку, выкарыстоўвайце: 24 | ``` 25 | git push origin --delete 26 | ``` 27 | 28 | Цяпер вы ведаеце, як прывесці ў парадак свае галіны. 29 | З часам у маім публічным сховішчы будзе дададзена шмат камісій. І галоўныя галіны мясцовай машыны і вашага відэльца GitHub не будуць актуальнымі. Такім чынам, каб захаваць вашыя сховішча сінхранізаванымі з маімі, выканайце наступныя дзеянні. 30 | 31 | #### [Захоўваючы відэлец сінхранізаваным з сховішчам](keeping-your-fork-synced-with-this-repository.md) 32 | -------------------------------------------------------------------------------- /additional-material/translations/Korean/keeping-your-fork-synced-with-this-repository.ko.md: -------------------------------------------------------------------------------- 1 | # 여러분이 포크한 저장소와 싱크상태 유지하기 2 | 3 | 먼저, 전체 싱크과정을 이해해야합니다. 본 스키마에는 3개의 저장소들이 있습니다. 저의 GitHub에 있는 제 공개저장소인 `github.com/Roshanjossey/first-contributions/`와 여러분의 포크된 저장소인 `github.com/Your-Name/first-contributions/`, 그리고 로컬 머신에 위치해서 현재 작업중인 저장소가 있습니다. 오픈 소스 프로젝트에 특화된 이러한 조합을 `트라이앵글 워크플로우`라고 부릅니다. 4 | 5 | triangle workflow 6 | 7 | 여러분의 두 개의 저장소들을 제 공개 저장소의 최신 상태와 싱크상태를 유지하기 위해서는 제일 먼저여러분의 로컬머신에 위치한 저장소를 제 공개 저장소와 fetch와 merge를 해야합니다. 8 | 두번째는 여러분의 로컬 저장소를 포크된 GitHub의 저장소에 push하는 것 입니다. 이전 과정에서 봤듯이 "pull request"를 요청할 수 있는 곳은 오직 포크된 저장소에서만 가능합니다. 따라서 마지막으로 업데이트 되어야하는 저장소는 포크된 GitHub입니다. 9 | 자, 어떻게하는지 보겠습니다: 10 | 먼저 여러분은 master 브랜치에 위치해 있어야합니다. 현재 어떤 브래치에 있는지 확인합니다.: 11 | ``` 12 | git status 13 | ``` 14 | 현재 master 브랜치가 아니라면 변경합니다.: 15 | ``` 16 | git checkout master 17 | ``` 18 | 19 | 제 공개 저장소를 아직 여러분의 git에 추가하지 않았다면 다음 명령으로 추가합니다. `add upstream remote-url`: 20 | ``` 21 | git remote add upstream https://github.com/Roshanjossey/first-contributions 22 | ``` 23 | 지정한 URL을 이용해 현재 프로젝트의 또 다른 최신 버전이 있는지 git에게 확인을 요청하는 방법입니다. 그리고 우리는 이를 `upstream` 이라고 부르기로합니다. 일단 git이 이러한 이름을 가지고 있다면 다음과 같이 공개 저장소의 최진 버전을 가지고 옵니다. : 24 | ``` 25 | git fetch upstream 26 | ``` 27 | 28 | 여러분은 이제 제 포크(upstream remote)에서 최신 버전을 내려 받았습니다. 이제 공개 저장소의 변경된 내용을 여러분의 master 브랜치에 병합해야합니다. 29 | ``` 30 | git rebase upstream/master 31 | ``` 32 | 33 | 여러분의 master 브랜치와 공개 저장소를 병합하고 나면 이제 여러분의 로컬머신의 master 브랜치는 최신 상태입니다. 마지막으로 여러분의 master 브랜치를 여러분의 포크에 push하게 되면 포크한 GitHub 또한 변경사항들이 반영됩니다.: 34 | ``` 35 | git push origin master 36 | ``` 37 | origin으로 명명된 리모트에 push하는 것에 주의하세요. 38 | 이제 여러분의 모든 저장소가 최신 상태를 유지하게 되었습니다. 39 | 잘 하셨습니다! GitHub 저장소에 커밋이 추가적으로 발생할 때마다 이러한 작업을 해야합니다. 40 | 41 | 42 | -------------------------------------------------------------------------------- /additional-material/translations/Chinese/addtional-material.cht.md: -------------------------------------------------------------------------------- 1 | # 附加資料 2 | 3 | 我們認為你在來到這裡以前已經完成基本教學。附加資料會給你關於 Git 進階技術的資訊。 4 | 5 | ### [從你的 repository 刪除分支](../../git_worklow_scenarios/removing-branch-from-your-repository.md) 6 | 這份文件教你如何從 repository 刪除分支。 7 | > 在做這些步驟前確定你的 pull request 是被合併的。 8 | 9 | ### [保持你的分叉與 repository 同步](../../git_workflow_scenarios/keeping-your-fork-synced-with-this-repository.md) 10 | 這份文件提供保持分叉與原始 repository 同步的資料。這件事情是很重要的，因為有其他人會對 project 做出貢獻。 11 | > 如果你的分叉沒有對原始 repository 做改變，根據這些步驟做操作。 12 | 13 | ### [回復 commit](../../git_workflow_scenarios/reverting-a-commit.md) 14 | 這份文件提供如何對遠端 repository 回復 commit。這項操作適用在你需要回復 commit，但你已經 push 到 Github。 15 | > 如果你想要回復 commit，根據這些步驟操作。 16 | 17 | ### [修訂 commit](../../git_workflow_scenarios/amending-a-commit.md) 18 | 這份文件教你如何在修訂在遠端的 commit。 19 | > 在你需要調整 commit 的時候使用這個。 20 | 21 | ### [回復本地的 commit](../../git_workflow_scenarios/undoing-a-commit.md) 22 | 這份文件教你如何回復本地的 commit。在你覺得你搞砸了本地的 repository，並且希望重置你的 repository時，照著做就對了。 23 | > 如果你需要回復/重置 commit 時，跟著做吧。 24 | 25 | ### [解決合併時的衝突](../../git_workflow_scenarios/resolving-merge-conflicts.md) 26 | 這份文件教你解決合併時的衝突。 27 | > 跟著這些步驟來解決煩人的衝突。 28 | 29 | ### [刪除檔案](../../git_workflow_scenarios/removing-a-file.md) 30 | 這份文件教你從本地 repository 中刪除檔案。 31 | > 跟著這些步驟學習如何從之前的 commit 中刪除檔案。 32 | 33 | ### [移動 commit 到另一個分支](../../git_workflow_scenarios/moving-a-commit-to-a-different-branch.md) 34 | 這份文件教你如何移動 commit 到另一個分支。 35 | > 跟著步驟移動 commit 到另一個分支。 36 | 37 | ### [配置 git](../../git_workflow_scenarios/configuring-git.md) 38 | 這份文件教你設定 git 的使用者資料與其他選項。 39 | > 閱讀這份文件讓你對 git 配置更有掌握。 40 | 41 | ### [好用的連結](../../git_workflow_scenarios/Useful-links-for-further-learning.md) 42 | 這份文件包含許多好用的部落格文章、網站、提示和小技巧，了解這些讓我們可以更容易上手。這一頁應該當做好用連結的索引，讓開源的新手還有想認識開源的人可以了解更多。 43 | 44 | ### [擠壓 commits](../../git_workflow_scenarios/squashing-commits.md) 45 | 這份文件教你如何藉由互動式 rebase 擠壓 commits。 46 | > 如果你想要發出一個 PR，但檢閱者要求你將一部份 commits 擠壓成一個 commits 藉由互動式 rebase。 47 | -------------------------------------------------------------------------------- /additional-material/translations/Korean/undoing-a-commit.ko.md: -------------------------------------------------------------------------------- 1 | ## 로컬 커밋 되돌리기 2 | 3 | 로컬에서 커밋을 위해 스테이징 영역에 추가한 작업 내용을 되돌리기 위해서는 다음 명령을 실행합니다. 4 | ``` 5 | git reset 6 | ``` 7 | 8 | 위 명령어는 수정한 코드가 반영된 스테이징 영역을 가장 최근에 반영한 커밋상태로 되돌립니다. 9 | 하지만 여러분의 작업 디렉토리에 수정한 내용들은 변경되지 않습니다. 따라서 여러분이 수정한 소스를 다시 커밋할 수 있습니다. 10 | 만일 이미 스테이징 영역에 반영된 수정한 파일들 중에서 하나의 파일만 커밋에서 제거하기를 원할 경우, 아래 명령을 실행합니다. 11 | 12 | ``` 13 | git reset 14 | ``` 15 | 이 명령어는 스테이징 영역에서 해당 파일만 제거합니다. 그러나 작업 디렉토리에는 변경된 파일 상태 그대로 남아 있습니다. 16 | 17 | 다음은 ```git reset``` 사용법에 관한 예제입니다. 18 | ``` 19 | # 먼저 index.php 와 tutorial.php 파일을 수정합니다. 20 | # 스테이징 영역에 파일을 추가합니다. 21 | $ git add . 22 | # 두 파일을 각각 커밋해야하므로 23 | # tutorial.php 파일을 스테이징 영역에서 제거합니다. 24 | $ git reset tutorial.php 25 | # index.php 파일을 먼저 커밋합니다. 26 | $ git commit -m "Changed index.php" 27 | # 다음으로 tutorial.php 파일을 커밋합니다. 28 | $ git add tutorial.php 29 | $ git commit -m "Changed tutorial.php" 30 | ``` 31 | 32 | 로컬 저장소에 문제가 생겨 여러분의 코드를 마지막 커밋 상태로 모두 되돌리고 싶다면 아래 명령을 실행할 수 있습니다. 33 | ``` 34 | git reset --hard 35 | ``` 36 | 37 | 이 명령어는 스테이징 영역을 마지막 커밋 상태로 되돌리는 것 뿐만 아니라 여러분의 로컬에 변경된 파일도 되돌릴 수 있습니다. 38 | ```--hard``` 모드는 Git으로 하여금 작업 디렉토리에 대한 변경들도 되돌릴 수 있도록 합니다. 39 | 따라서 로컬에서 개발한 모든 개발 내용을 초기화해도 되는지 반드시 확인 후 실행하셔야 합니다. 40 | 41 | 다음은 ```git reset --hard``` 사용에 관한 예제입니다. 42 | ``` 43 | # 엉뚱한 실험을 시작하기로 결정했습니다. 44 | # 먼저 'crazy.php' 파일을 만들고 코드를 추가합니다. 45 | # 그리고 crazy.php 파일을 커밋합니다. 46 | $ git add crazy.php 47 | $ git commit -m "Started a crazy dev" 48 | # crazy.php 파일을 다시 수정하고 기타 여러 파일들을 생성하고 수정합니다. 49 | # 그리고 수정한 모든 파일을 스테이징 영역에 추가하고 커밋합니다. 50 | $ git add . 51 | $ git commit -m "Continued dev" 52 | # 테스트하고 마칩니다. 53 | # 실험하기 전 상태로 되돌리기 위해 모든 수정사항을 제거합니다. 54 | $ git reset --hard HEAD~2 55 | ``` 56 | ```git reset --hard HEAD~2``` 명령어는 현재 브랜치에서 여러분이 수정한 이전의 커밋들 중에 2번째 커밋 포인트 상태로 이동함과 동시에 해당 커밋들에 대한 변경사항들이 이전 상태로 복구됩니다. 그리고 프로젝트 히스토리에서 이전에 추가된 2개의 스냅샷이 제거됩니다. 57 | 58 | P.s. 만일 여러분의 공유 저장소로 이미 push를 완료한 상태에서 ```git reset --hard``` 명령을 실행할 경우, 해당 저장소를 사용하는 모든 사람들에게 문제를 일으킬 수 있으므로 절대 실행해서는 안됩니다. 59 | 60 | -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/storing-credentials.md: -------------------------------------------------------------------------------- 1 | # Storing Credentials 2 | 3 | You might have complained about this before - entering your username and password each time you access the repository can be a hassle and can interrupt your workflow if it takes too long. But it doesn't need to be that way. 4 | 5 | We will be covering one of the methods available to us - [git credential cache](https://git-scm.com/docs/git-credential-cache). 6 | 7 | **Note:** Please follow the security policies of your place of work/study. 8 | 9 | ## Caching 10 | 11 | We can use git credential cache to store our username and password. 12 | 13 | **Attention:** This method saves the credentials in *plaintext* on your PC's disk. Everyone on your computer can access it, e.g. malicious NPM modules. 14 | 15 | ### Global Credential Cache 16 | 17 | If we wish to, we can store the credentials for every repository we are working with using one simple command: 18 | 19 | ``` 20 | $ git config --global credential.helper cache 21 | ``` 22 | 23 | **Reminder:** Please follow the security policies of your place of work/study. 24 | 25 | ### Repository Credential Cache 26 | 27 | We can store the credentials for the repository we are working with using one simple command, similar to before: 28 | 29 | ``` 30 | $ git config credential.helper cache 31 | ``` 32 | 33 | **Reminder:** Please follow the security policies of your place of work/study. 34 | 35 | ### Cache Timeout 36 | 37 | If we do not specify a length of time to store our credentials, they can potentially be stored forever. However, we can determine how long they will be kept in memory using this command: 38 | 39 | ``` 40 | git config credential.helper 'cache --timeout=' 41 | ``` 42 | 43 | Using the helper, the credentials will never touch the disk and will be erased after the specified timeout. The default value is 900 seconds (15 minutes). 44 | 45 | #### References 46 | [Stack Overflow](https://stackoverflow.com/questions/35942754/how-can-i-save-username-and-password-in-git) 47 | 48 | ### [Additional Material](additional-material.md) -------------------------------------------------------------------------------- /additional-material/translations/Slovenian/reverting-a-commit.sl.md: -------------------------------------------------------------------------------- 1 | # Povrnitev commit-a 2 | 3 | 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. 4 | 5 | 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. 6 | To pomeni da lahko povrnemu vsak commit, če le imamo njegov SHA. 7 | V vsakem primeru pa moramo biti previdni pri povračanju, ker si lahko poškodujemo repository. 8 | 9 | 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. 10 | Ta seznam dobimo s tem ukazom: 11 | ```git log --oneline ``` 12 | Ukaz ```git log``` bi nam prav tako vrnil SHA, vendar v daljši obliki izpisa. 13 | Uporaba zastavice ```--oneline ``` Git-u pove da hočemo pregleden izpis v eni vrstici. 14 | 15 | Prvih 7 znakov v vsaki vrstici izpisa se imenuje skrajšani hash commit-a. 16 | 17 | Za primer, to je izpis ```git log --oneline ``` za ta repository: 18 | ``` 19 | 389004d added spacing in title 20 | c1b9fc1 Merge branch 'master' into tutorials 21 | 77eaafd added tutorial for reverting a commit 22 | ``` 23 | 24 | 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. 25 | 26 | No, sedaj lahko poskusimo zbrisati commit "added spacing in title" z naslednjimi koraki: 27 | 28 | * Kopiraj SHA commit-a, v tem primeru ```389004d``` 29 | * Potem uporabi ukaz ```git revert 389004d``` 30 | 31 | Sedaj se zažene naš urejevalnik besedila in nas pozove naj uredimo komentar commit-a. 32 | 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. 33 | 34 | * Nato shranimo in zapremo urejevalnik besedila. 35 | * Vrnemo se v ukazno vrstico. 36 | * Uporabimo ukaz ```git push origin ``` da pošljemo spremembe na GitHub. 37 | 38 | In to je to, spremembe bodo odstranjene. V tem primeru bi se moj repository povrnil na stanje v commit-u ```c1b9fc1```. -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/reverting-a-commit.md: -------------------------------------------------------------------------------- 1 | # Revert a commit 2 | 3 | To revert a commit simply means to create a brand new commit that undoes all 4 | the changes made in a previous one. It is like doing a ```CTRL + Z ``` on git. 5 | 6 | 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. 7 | So this means you can revert any commit as long as you have the SHA. 8 | But then, you have to be careful to reverse orderly so as not to mess your repository up. 9 | 10 | 11 | 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. 12 | To get this, we would run the command: 13 | ```git log --oneline ``` 14 | Running the ```git log``` command alone would also give us the SHAs (in long form) 15 | However using the ```--oneline ``` flag tells git that we want it displayed in a concise (one line) manner for easy read. 16 | 17 | The first 7 characters displayed when you run this command is called the abbreviated commit hash. 18 | 19 | For example, here is what I get when I run ```git log --oneline ``` on this repository: 20 | ``` 21 | 389004d added spacing in title 22 | c1b9fc1 Merge branch 'master' into tutorials 23 | 77eaafd added tutorial for reverting a commit 24 | ``` 25 | 26 | 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. 27 | 28 | Now, Let's assume I want to undo my commit of "added spacing in title", here are the steps I would take: 29 | 30 | * Copy the SHA of the commit which, in this case is ```389004d``` 31 | * Then, run the command ```git revert 389004d``` 32 | 33 | This would pop open my text editor and prompt me to edit the commit message. 34 | You can decide to leave the commit message as the default git message which starts with the word `Revert` 35 | or you can also decide to customize the message to your liking. 36 | 37 | * Next, I will save and close the text editor. 38 | * Return to the command line. 39 | * Run ```git push origin ``` to push the reverted changes to Github. 40 | 41 | And that is it, the change would be undone. In this case, my repository would be reverted to how it looked like in ```c1b9fc1``` 42 | -------------------------------------------------------------------------------- /additional-material/translations/Slovenian/undoing-a-commit.sl.md: -------------------------------------------------------------------------------- 1 | # Razveljavljanje lokalnega commit-a 2 | 3 | Vse kar rabiš storiti, da razveljaviš lokalni commit, je: 4 | ``` 5 | git reset 6 | ``` 7 | 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. 8 | Lahko pa tudi odstraniš samo eno datoteko s svojega prejšnjega commit-a. Uporabiš ukaz: 9 | ``` 10 | git reset 11 | ``` 12 | Ukaz bo odstranil samo določeno datoteko s čakalnice, vendar bodo spremembe narejene na datoteki ostale. 13 | 14 | Primer uporabe ```git reset```: 15 | ``` 16 | # Make changes in index.php and tutorial.php 17 | # Add files into the staging area 18 | $ git add . 19 | # Remembered both files need to be committed separately 20 | # Unstage tutorial.php 21 | $ git reset tutorial.php 22 | # Commit index.php first 23 | $ git commit -m "Changed index.php" 24 | # Commit tutorial.php now 25 | $ git add tutorial.php 26 | $ git commit -m "Changed tutorial.php" 27 | ``` 28 | 29 | Predpostavimo da si pokvaril svoj lokalni repository in ga želiš resetirati na svoj zadnji commit. 30 | Lahko uporabiš spodnji ukaz: 31 | ``` 32 | git reset --hard 33 | ``` 34 | Ukaz bo izpraznil čakalnico in tudi povrnil vse spremembe v datotekah na stanje v zadnjem commit-u. 35 | Možnost ```--hard``` pove Git-u da mora odstraniti tudi vse spremembe v delovnem okolju. 36 | Ta ukaz uporabi samo takrat, ko si prepričan da želiš odstraniti vse spremembe nastale od zadnjega commit-a! 37 | 38 | Primer uporabe ukaza ```git reset --hard```: 39 | ``` 40 | # Decided to start a crazy experiment 41 | # Create a new file 'crazy.php' and add some code to it 42 | # Commit crazy.php 43 | $ git add crazy.php 44 | $ git commit -m "Started a crazy dev" 45 | # Edit crazy.php file again and changed a lot other files 46 | # Commit all tracked files 47 | $ git add . 48 | $ git commit -m "Continued dev" 49 | # Tested and things went out of hand 50 | # Decided to remove the whole thing 51 | $ git reset --hard HEAD~2 52 | ``` 53 | 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. 54 | 55 | 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! 56 | -------------------------------------------------------------------------------- /additional-material/translations/Slovenian/resolving-merge-conflicts.sl.md: -------------------------------------------------------------------------------- 1 | # Kaj je spor pri združevanju? 2 | 3 | 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š. 4 | Č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. 5 | 6 | # Kako razrešiti spor pri združevanje? 7 | 8 | Ko Git zazna spor pri združevanju, bo mesto problema v datoteku označil tako, da ga bo obdal z: 9 | “<<<<<<<< HEAD” and “>>>>>>>>>>[other branch name]” 10 | 11 | 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. 12 | 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. 13 | 14 | Primer: 15 | ``` 16 | <<<<<<< HEAD:mergetest 17 | This is my third line 18 | ======= 19 | This is a fourth line I am adding 20 | >>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest 21 | ``` 22 | 23 | `<<<<<<<`: Nakazuje začetek vrstic, kjer je spor. Te vrstice so iz tvoje datoteke, ki si jo poskusil združiti. 24 | `=======`: Nakazuje prelomno točko za primerjavo. Razdeli spremembe iz tvojega commit-a (zgoraj) in spremembe nekoga drugega (spodaj) za lažjo predstavo. 25 | `>>>>>>>`: Nakazuje konec vrstic, kjer je spor. 26 | 27 | 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 '>>>>>>>'. 28 | 29 | 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. 30 | 31 | Lahko si tudi namestiš različne plugine, ki so odvisni od tvojega IDE-ja, za lažje reševanje sporov. 32 | 33 | # Kako razveljaviti združitev ( merge )? 34 | Če želiš razveljaviti združitev uporabi ukaz `git merge —abort`. 35 | -------------------------------------------------------------------------------- /additional-material/translations/Farsi/amending-a-commit.fa.md: -------------------------------------------------------------------------------- 1 | # اصلاح یک کامیت 2 | 3 | چه کار باید بکنی اگر یک تغییر را به مخزن کامیت کردی ولی بعدا متوجه شدی که پیام کامیت مشکل داشته و یا فراموش کردی یک خط به آخرین کامیتت اضافه کنی. 4 | چجوری میشود این را اصلاح کرد؟ 5 | این موضوعی است که در این آموزش به آن پرداخته میشود. 6 | 7 | ## تغییر دادن پیام یک کامیت که اخیرا به گیت هاب ارسال کردی 8 | برای این کار بدون باز کردن فایلی: 9 | 10 | 1.تایپ کنید: 11 | 12 | ``` 13 | git commit --amend -m "پیام جدید برای این کامیت" 14 | ``` 15 | 16 | 2.دستور 17 | 18 | ``` 19 | git push origin <نام-شاخه> 20 | ``` 21 | 22 | را اجرا کنید تا تغییرات در مخزن ثبت شوند 23 | 24 |
25 | 26 | نکته: اگر فقط تایپ کنی 27 | ```git commit --amend```، ویرایشگر متنت باز خواهد شد و درخواست تغییر پیام کامیت را خواهد داشت. 28 | اضافه کردن ```m-``` از این پیشگیری می کند. 29 | 30 | ## اصلاح کردن یک کامیت 31 | 32 | حالا اگر فراموش کرده باشی که یک تغییر کوچک مثل اضافه کردن یک کلمه به یک فایل را انجام بدی، و قبلا تغییرات را ثبت و به مخزن ارسال کرده باشی، چیکار باید انجام بدی؟ 33 | 34 | مثلا این لاگ (log) کامیت هاست: 35 | ``` 36 | g56123f create botfile 37 | a2235d updated contributor.md 38 | a5da0d modified botfile 39 | ``` 40 | 41 | برای مثال فراموش کردی که یک کلمه به (botfile) اضافه کنی. 42 | 43 | از دو روش میشود این کار را انجام داد. 44 | 45 | راه اول این است که یک کامیت جدید ایجاد کرد که شامل این تغییرات هست: 46 | ``` 47 | g56123f create botfile 48 | a2235d updated contributor.md 49 | a5da0d modified botfile 50 | b0ca8f added single word to botfile 51 | ``` 52 | 53 | راه دوم این است که کامیت (a5da0d) را اصلاح کنی، کلمه جدید را اضافه کنی و به عنوان "یک" کامیت به مخزن ارسال کنی. 54 | این راه به نسبت بهتر است برای اینکه فقط یک تغییر کوچک است. 55 | 56 | برای این کار به ترتیب: 57 | 58 | 1.فایل را اصلاح کن. در این مثال فایل (botfile) را اصلاح میکنیم تا کلمه جدید را اضافه کنیم. 59 | 60 | 2.فایل را به تغییرات اضافه کنید: 61 | 62 | ``` 63 | git add <اسم-فایل> 64 | ``` 65 | 66 | معمولا بعد از اضافه کردن تغییرات، با دستور 67 | 68 | ``` 69 | git commit -m "our commit message" 70 | ``` 71 | 72 | تغییرات را ثبت میکنیم، ولی به خاطر اینکه می خواهیم کامیت قبلی را اصلاح کنیم، این دستور را اجرا کنیم: 73 | 74 | ``` 75 | git commit --amend 76 | ``` 77 | با اجرای این دستور ویرایشگر متن باز خواهد شد و تا پیام کامیت را تغییر بدی 78 | 79 | ویرایشگر متن را ببند 80 | تغییرات رو به مخزن ارسال کن.. 81 | ``` 82 | git push origin <اسم-شاخه> 83 | ``` 84 | 85 | تمام شد. الان هر دو تغییر در یک کامیت ثبت شده اند. -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/undoing-a-commit.md: -------------------------------------------------------------------------------- 1 | # Undo local commits 2 | 3 | To undo a local commit, all you need to do is 4 | ``` 5 | git reset 6 | ``` 7 | 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. 8 | Or, if you only want to remove one file from your previous commit. Then, you can do the command below 9 | ``` 10 | git reset 11 | ``` 12 | The command will remove only the specified file from the staging area, but changes made on the file will still remain. 13 | 14 | Example of ```git reset``` usage 15 | ``` 16 | # Make changes in index.php and tutorial.php 17 | # Add files into the staging area 18 | $ git add . 19 | # Remembered both files need to be committed separately 20 | # Unstage tutorial.php 21 | $ git reset tutorial.php 22 | # Commit index.php first 23 | $ git commit -m "Changed index.php" 24 | # Commit tutorial.php now 25 | $ git add tutorial.php 26 | $ git commit -m "Changed tutorial.php" 27 | ``` 28 | 29 | Let's say if you have messed up your local repository and you just want to reset it to your last commit. 30 | Then, you can run the command below. 31 | ``` 32 | git reset --hard 33 | ``` 34 | The command will not only reset your staging area, but also revert all your changes on the files to your last commit. 35 | The mode ```--hard``` tells Git to undo all the changes in the working directory too. 36 | You should only run this when you are really sure of throwing your whole local development out. 37 | 38 | Example of ```git reset --hard``` usage 39 | ``` 40 | # Decided to start a crazy experiment 41 | # Create a new file 'crazy.php' and add some code to it 42 | # Commit crazy.php 43 | $ git add crazy.php 44 | $ git commit -m "Started a crazy dev" 45 | # Edit crazy.php file again and changed a lot of other files 46 | # Commit all tracked files 47 | $ git add . 48 | $ git commit -m "Continued dev" 49 | # Tested and things went out of hand 50 | # Decided to remove the whole things 51 | $ git reset --hard HEAD~2 52 | ``` 53 | 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. 54 | 55 | 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. 56 | -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/reverting-a-commit.by.md: -------------------------------------------------------------------------------- 1 | # Вярнуць каміт 2 | 3 | Скасаваць абавязацельства проста азначае стварыць зусім новы дакумент, які адмяняе ўсе 4 | змены, унесеныя ў папярэдні. Гэта як рабіць `` CTRL + Z `` `на git. 5 | 6 | У Git пераўтварэнне палягчаецца, таму што кожны ўклад, які вы commit на свой аддалены сховішча, мае ўнікальны алфавітна-лічбавы ключ, вядомы пад назвай SHA (Secure Hash Algorithm). 7 | Такім чынам, гэта азначае, што вы можаце вярнуць любыя абавязацельствы, пакуль у вас ёсць SHA. 8 | Але потым, вы павінны быць асцярожныя, каб змяніць упарадкаванасць, каб не сапсаваць ваша сховішча. 9 | 10 | Каб выбраць SHA канкрэтнага абавязацельства, якое мы хочам адмяніць, зручны быў бы часопіс усіх дасягнутых намі абавязкаў. 11 | Каб атрымаць гэта, мы запусцім каманду: 12 | `` `git log --oneline` `` 13 | Адзінае выкананне каманды `` git log`` таксама дасць нам SHA (у доўгай форме) 14 | Аднак выкарыстанне сцяга `` --oneline `` кажа git, што мы хочам, каб ён быў адлюстраваны ў сціслым (адным радку) парадку для зручнага чытання. 15 | 16 | Першыя 7 знакаў, якія адлюстроўваюцца пры выкананні гэтай каманды, называюцца скарочаным хэшам фіксацыі. 17 | 18 | Напрыклад, вось што я атрымліваю, калі ў гэтым рэпазітары запускаю `` git log --oneline ``: 19 | ``` 20 | 389004d added spacing in title 21 | c1b9fc1 Merge branch 'master' into tutorials 22 | 77eaafd added tutorial for reverting a commit 23 | ``` 24 | 25 | Гэта паказвае, што з дапамогай `` git log --oneline``, мы можам атрымаць спіс усіх абавязацельстваў, зробленых у сховішча, разам з першымі 7 сімваламі яго SHA. 26 | 27 | Давайце выкажам здагадку, што я хачу адмяніць здзяйсненне "дадання прамежкаў у загалоўку". Вось наступныя дзеянні: 28 | 29 | * Скапіруйце SHA дакумента, які ў дадзеным выпадку з'яўляецца `` 389004d `` 30 | * Затым запусціце каманду ```git revert 389004d``` 31 | 32 | Гэта адкрые мой тэкставы рэдактар і прапануе мне адрэдагаваць паведамленне пра commit. 33 | Вы можаце вырашыць пакінуць паведамленне commit як паведамленне па змаўчанні git, якое пачынаецца са слова `Revert` 34 | альбо вы таксама можаце вырашыць наладзіць паведамленне па сваім гусце. 35 | 36 | * Далей я буду захоўваць і закрываць тэкставы рэдактар. 37 | * Вярнуцца да каманднага радка. 38 | * Запусціце `` `git push origin ` ``, каб націснуць на зваротныя змены ў Github. 39 | 40 | І гэта ўсё, змены будуць адменены. У гэтым выпадку маё сховішча будзе зменена на тое, як яно выглядала ў `` c1b9fc1`` 41 | -------------------------------------------------------------------------------- /additional-material/translations/Korean/additional-material.ko.md: -------------------------------------------------------------------------------- 1 | # 추가 정보 2 | 3 | 여러분이 여기에 오기 전에 기본실습 과정을 이미 완료했다고 가정합니다. 이 문서는 고급 Git 기술에 대한 추가적인 정보를 제공합니다. 4 | 5 | ### [커밋 수정하기](amending-a-commit.ko.md) 6 | 이 문서는 원격 저장소의 커밋을 수정하는 방법에 대한 정보를 제공합니다. 커밋을 수정하는 것은 당신의 현재 브랜치 내 가장 최근의 커밋을 변경하는 한 방법입니다. 이는 커밋 메세지를 수정해야 하거나 커밋에 변경사항을 포함하지 않은 경우에 유용합니다. 당신은 원격 저장소에 커밋을 푸시하기 전까지 커밋을 계속해서 수정할 수 있습니다. 7 | > 당신이 만든 커밋을 수정해야 할 경우 사용하십시오. 8 | 9 | ### [git 설정하기](configuring-git.md) 10 | 이 문서는 git에서 사용자 정보 및 기타 옵션을 구성하는 방법에 대한 정보를 제공합니다. 11 | > git 설정을 더 잘 다루려면 이 단계를 수행하십시오. 12 | 13 | ### [여러분이 포크한 저장소와 싱크상태 유지하기](keeping-your-fork-synced-with-this-repository.ko.md) 14 | 이 문서는 포크 된 저장소를 기본 저장소로 최신 상태로 유지하는 방법에 대한 정보를 제공합니다. 여러분과 다른 많은 사람들이 프로젝트에 기여하기를 바랍니다. 15 | > 포크 된 상위 저장소가 변경되지 않은 경우 다음 단계를 수행하십시오. 16 | 17 | ### [커밋을 다른 브랜치로 이동하기](moving-a-commit-to-a-different-branch.ko.md) 18 | 이 문서는 커밋을 다른 브랜치로 이동하는 방법에 대한 정보를 제공합니다. 19 | > 이 단계를 수행하여 커밋을 다른 브랜치로 이동하십시오. 20 | 21 | ### [파일 삭제하기](removing-a-file.ko.md) 22 | 이 문서는 로컬 저장소에서 파일을 지우는 방법에 대한 정보를 제공합니다. 23 | > 커밋 전에 파일을 삭제하는 방법을 배우려면 다음의 과정을 수행하십시오. 24 | 25 | ### [여러분의 저장소에서 브랜치 삭제하기](removing-branch-from-your-repository.ko.md) 26 | 이 문서는 저장소에서 브랜치를 삭제하는 방법에 대한 정보를 제공합니다. 27 | > PR(pull request) 요청이 병합 된 후에 본 단계를 수행하십시오. 28 | 29 | ### [병합 충돌 해결하기](resolving-merge-conflicts.ko.md) 30 | 이 문서는 병합 충돌을 해결하는 방법에 대한 정보를 제공합니다. 31 | > 이 단계를 수행하여 곤란한 병합 충돌을 해결하십시오. 32 | 33 | ### [커밋 되돌리기](reverting-a-commit.ko.md) 34 | 이 문서는 원격 저장소에서 커밋을 되돌리는 방법에 대한 정보를 제공합니다. 이미 Github에 푸시 된 커밋을 되돌리려는 경우 유용합니다. 35 | > 커밋을 되돌리려면 이 단계를 수행하십시오. 36 | 37 | ### [스쿼시 커밋하기](../squashing-commits.md) 38 | 이 문서는 대화형 리베이스로 커밋을 스쿼시하는 방법에 대한 정보를 제공합니다. 39 | > 오픈 소스 프로젝트에서 PR을 보낼 때 리뷰어가 모든 커밋을 하나로 스쿼시하도록 요청하는 경우 유익한 커밋 메시지와 함께 이것을 사용하십시오. 40 | 41 | ### [로컬 커밋 되돌리기](undoing-a-commit.ko.md) 42 | 이 문서는 로컬 저장소에서 커밋을 실행 취소하는 방법에 대한 정보를 제공합니다. 로컬 저장소가 엉망이라고 느껴 당신이 로컬 저장소를 리셋하고자 할 때 당신이 해야 할 일입니다. 43 | > 로컬 커밋을 취소하려면 이 단계를 수행하십시오. 44 | 45 | ### [유용한 링크](../Useful-links-for-further-learning.md) 46 | 이 문서는 모든 블로그 게시물, 유용한 사이트, 유용한 정보 및 웹 사이트에 대한 내용을 담고 있습니다. 우리가 모든 필요를 위해 참조하는 것은 초심자 또는 전문가 일 것입니다. 이 페이지는 오픈 소스 도메인을 처음 접하거나 더 많은 것을 배우고자 하는 사람들을 돕는 지표 역할을 해야 합니다. 47 | 48 | ### [.gitignore 파일 생성하기](creating-a-gitignore-file.ko.md) 49 | 이 문서는 .gitignore 파일의 역할, 사용 이유 및 .gitignore 파일 생성 방법을 설명합니다. 이 파일은 거의 모든 git 프로젝트에 사용됩니다. 이는 필요한 파일만 git에 커밋하도록 돕습니다. 50 | 51 | ### [크리덴셜 저장하기](storing-credentials.ko.md) 52 | 이 문서는 저장소들의 크리덴셜을 저장하는 방법을 설명합니다. 이는 보안 관련 문제가 될 수 있으므로, 당신의 직장/ 학업 에 알맞은 보안 정책을 따르십시오. -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/undoing-a-commit.by.md: -------------------------------------------------------------------------------- 1 | # Адмяніць мясцовыя каміты 2 | 3 | Каб адмяніць мясцовыя каміты, усё, што вам трэба зрабіць, гэта 4 | ``` 5 | git reset 6 | ``` 7 | 8 | Гэтая каманда прывядзе да скіду staging вобласці да апошні каміт, але змены, якія ўнесены ў ваш працоўны каталог, не зменіцца. Такім чынам, вы ўсё яшчэ можаце зноў камітаць тое, што вы змянілі. 9 | Ці, калі вы хочаце выдаліць толькі адзін файл з папярэдняга каміту. Затым вы можаце зрабіць каманду ніжэй 10 | 11 | ``` 12 | git reset 13 | ``` 14 | Каманда выдаліць толькі пазначаны файл з staging вобласці, але змены, унесеныя ў файл, усё яшчэ застануцца. 15 | 16 | Прыклад выкарыстання ```git reset``` 17 | ``` 18 | # Make changes in index.php and tutorial.php 19 | # Add files into the staging area 20 | $ git add . 21 | # Remembered both files need to be committed separately 22 | # Unstage tutorial.php 23 | $ git reset tutorial.php 24 | # Commit index.php first 25 | $ git commit -m "Changed index.php" 26 | # Commit tutorial.php now 27 | $ git add tutorial.php 28 | $ git commit -m "Changed tutorial.php" 29 | ``` 30 | 31 | Дапусцім, калі вы пераблыталі сваё лакальнае сховішча і проста хочаце скінуць яго на апошні ўдзел. 32 | Затым вы можаце запусціць каманду ніжэй. 33 | ``` 34 | git reset --hard 35 | ``` 36 | 37 | Каманда не толькі скіне ваша staging вобласць, але і верне ўсе вашы змены ў файлах да вашай апошняй commit. 38 | Рэжым `` --hard `` загадвае Git таксама адмяняць усе змены ў працоўным каталогу. 39 | Вы павінны запускаць гэта толькі тады, калі вы сапраўды ўпэўненыя ў тым, што выкінеце цэлае local development. 40 | 41 | Прыклад выкарыстання ```git reset --hard``` 42 | ``` 43 | # Decided to start a crazy experiment 44 | # Create a new file 'crazy.php' and add some code to it 45 | # Commit crazy.php 46 | $ git add crazy.php 47 | $ git commit -m "Started a crazy dev" 48 | # Edit crazy.php file again and changed a lot other files 49 | # Commit all tracked files 50 | $ git add . 51 | $ git commit -m "Continued dev" 52 | # Tested and things went out of hand 53 | # Decided to remove the whole things 54 | $ git reset --hard HEAD~2 55 | ``` 56 | 57 | ```git reset --hard HEAD~2``` перамяшчае бягучую галінку назад на 2 commits адначасова, аднаўляючы ўсе зробленыя вамі змены і выдаляючы 2 здымкі, якія мы толькі што стварылі з гісторыі праектаў. 58 | 59 | P.s. Ніколі не выконвайце `` git reset --hard```, калі вы ўжо перанеслі свае commits ў агульнае сховішча, паколькі гэта прывядзе да праблем з усімі рэпазітарамі. 60 | -------------------------------------------------------------------------------- /additional-material/translations/Slovenian/amending-a-commit.sl.md: -------------------------------------------------------------------------------- 1 | # Popravljanje Commita 2 | 3 | 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. 4 | Kako to popraviti? O tem govori ta vodič. 5 | 6 | ## Spreminjanje komentarja commit-a, ki je bil pred kratkim poslan na GitHub 7 | To lahko naredimo brez da bi odprli datoteko: 8 | * V terminal vpiši ```git commit --amend -m "followed by your new commit message"``` 9 | * Zaženi ```git push origin ``` da pošlješ commit s spremembo v repository. 10 | 11 | Opomba: Če vtipkaš samo ```git commit --amend```, se odpre tvoj urejevalnik besedil in te pozove da spremeniš komentar commit-a. 12 | Zastavica ``-m`` to prepreči. 13 | 14 | ## Sprememba enega commit-a 15 | 16 | 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? 17 | 18 | Prikaz praktičnega primera (zgodovina commit-ov tega repository-a): 19 | ``` 20 | g56123f create file botfile 21 | a2235d updated contributor.md 22 | a5da0d modified botfile 23 | ``` 24 | Recimo da smo pozabili dodati eno samo besedo datoteki botfile. 25 | 26 | Obstajata dva načina kako se stvari lotiti. Prvi primer je da naredimo nov commit, ki vsebuje spremembo: 27 | ``` 28 | g56123f create file botfile 29 | a2235d updated contributor.md 30 | a5da0d modified botfile 31 | b0ca8f added single word to botfile 32 | ``` 33 | Drugi način je, da spremenimo commit a5da0d, mu dodamo pozabljeno besedo in ga pošljemo v GitHub, vse skupaj kot en commit. 34 | Drugi način nam je bolj všeč, ker imamo opravka z manjšo spremembo. 35 | 36 | Da to dosežemo, storimo naslednje: 37 | * Spremenimo datoteko. V tem primeru bomo spremenili datoteko botfile in ji dodali spuščeno besedo. 38 | * Nato bomo dodali datoteko v čakalnico z ```git add ```. 39 | 40 | Običajno ko dodamo datoteke v čakalnico, je naslednji korak, da naredimo commit s komentarjem ( git commit -m "our commit message" ). 41 | V tem primeru pa želimo popraviti že narejen commit, zato namesto tega izvedemo: 42 | 43 | * ```git commit --amend``` 44 | 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. 45 | * Zapustimo urejevalnik besedil. 46 | * Pošljemo spremembe z `` `git push origin ` ``. 47 | 48 | Na ta način bosta obe spremembi združeni v enem commit-u. 49 | -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/resolving-merge-conflicts.by.md: -------------------------------------------------------------------------------- 1 | # Што такое канфлікт зліцця? 2 | 3 | Пры спробе аб'яднаць іншую галінку з вашай бягучай працоўнай галіной, вы ўносіце змены ў іншы кантэкст і аб'ядноўваючы іх з вашымі бягучымі файламі. 4 | Калі два чалавекі змянілі аднолькавыя радкі ў адным файле альбо калі адзін чалавек вырашыў выдаліць яго, а другі вырашыў змяніць яго, Git не зможа вызначыць, якая версія з'яўляецца правільнай. Затым Git пазначыць файл як канфлікт - які вам давядзецца вырашыць, каб працягнуць працу. 5 | 6 | # Як вырашыць канфлікт аб аб'яднанні? 7 | 8 | Сутыкнуўшыся з канфліктам зліцця, git пазначыць праблемную вобласць у файле, уключыўшы яе ў “<<<<<<<< HEAD” and “>>>>>>>>>>[other branch name]” 9 | 10 | Змесціва пасля першага маркера паходзіць з вашай бягучай галіны. Пасля кутніх дужак, Git паведамляе нам, адкуль (з якой галіны) адбыліся змены. Радок з "=======" падзяляе два супярэчлівыя змены. 11 | Наша задача складаецца ў тым, каб ачысціць гэтыя радкі: калі мы скончым, файл павінен выглядаць так, як мы хочам, каб ён выглядаў. Пажадана звярнуцца да таварыша па камандзе, які напісаў супярэчлівыя змены, каб вырашыць, якая версія павінна быць канчатковай. Гэта можа быць альбо ваша - альбо можа быць сумесь паміж імі. 12 | 13 | напрыклад: 14 | ``` 15 | <<<<<<< HEAD:mergetest 16 | This is my third line 17 | ======= 18 | This is a fourth line I am adding 19 | >>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest 20 | ``` 21 | 22 | `<<<<<<<`: Пазначае пачатак радкоў, якія мелі канфлікт аб'яднання. Першы набор радкоў - гэта радкі з файла, у які вы спрабавалі аб'яднаць змены. 23 | `=======`: Паказвае кропку перапынку, якая выкарыстоўваецца для параўнання. Разбівае змены, якія карыстальнік здзейсніў (вышэй) да зменаў, якія адбываюцца ад аб'яднання (унізе), каб візуальна ўбачыць адрозненні. 24 | `>>>>>>>`: Пазначае канец радкоў, якія мелі канфлікт зліцця. 25 | 26 | Вы можаце вырашыць канфлікт, адрэдагаваўшы файл, а затым злучыўшы яго ўручную. Гэта можа азначаць адмену альбо змены альбо чыё-небудзь ці далейшае спалучэнне двух. Вам таксама трэба выдаліць файлы <<<<<<<< ',' ======= 'і' >>>>>>> '. 27 | 28 | Пасля развязання канфлікту зрабіце `git add`. Не забудзьцеся запусціць тэсты, бо вы павінны пераканацца, што вы вырашылі канфлікт. 29 | 30 | Вы таксама можаце загрузіць розныя плагіны ў залежнасці ад IDE, які вы выкарыстоўваеце для больш простага спосабу ўрэгулявання канфліктаў аб'яднання. 31 | 32 | # Як адмяніць зліццё? 33 | Калі вы хочаце адмяніць зліццё, то можаце зрабіць `git merge —abort` 34 | -------------------------------------------------------------------------------- /additional-material/translations/Nepali/amending-a-commit.np.md: -------------------------------------------------------------------------------- 1 | # प्रतिबद्धता सम्पादन गर्नुहोस् 2 | 3 | मानौं कि तपाईंले आफ्नो रिमोट डाइरेक्टरीमा प्रतिबद्धता गर्नुभयो र पछि यो महसुस गर्नुहोस् कमिट सन्देशमा टाइपो छ वा तपाईंले आफ्नो अन्तिम कमिटमा लाइन थप्न बिर्सनुभयो। यो त्रुटि कसरी सच्याउने? यो यस ट्यूटोरियल को विषय हो। 4 | 5 | ## Github मा धक्का दिए पछि भर्खरको प्रतिबद्ध सन्देश परिवर्तन गर्नुहोस् 6 | फाइल नखोली नै यो गर्नका लागि: 7 | * आदेश टाइप गर्नुहोस् ```git कमिट --amend -m "तपाईँको नयाँ प्रतिबद्ध सन्देश पछि"``` 8 | * निर्देशिकामा कमिट गर्न ```git push origin ``` आदेश चलाउनुहोस्। 9 | 10 | NB: यदि तपाइँ केवल ```git कमिट --amend``` टाइप गर्नुहुन्छ भने, पाठ सम्पादक खुल्छ र तपाइँलाई परिमार्जन गर्न सोध्छ। 11 | सन्देश पठाउनुहोस्। पाठ सम्पादक प्रयोग गर्नबाट बच्न ``-m`` विकल्प थप्नुहोस्। 12 | 13 | ## एक विशिष्ट प्रतिबद्धता परिमार्जन गर्नुहोस् 14 | 15 | त्यसोभए के हुन्छ यदि तपाईंले फाइलमा सानो परिवर्तन गर्न बिर्सनुभयो, जस्तै शब्द परिवर्तन गर्नुहोस् र 16 | तपाईंले पहिले नै हाम्रो रिमोट डाइरेक्टरीमा यो प्रतिबद्धता पुश गरिसक्नुभएको छ? 17 | 18 | यस बिन्दुलाई चित्रण गर्न, यहाँ मेरो प्रतिबद्धताहरूको लग छ; 19 | ``` 20 | g56123f बोट फाइल सिर्जना गर्दै 21 | contributor.md बाट a2235d अपडेट 22 | a5da0d बोट फाइल सम्पादन गर्नुहोस् 23 | ``` 24 | कल्पना गरौं कि मैले बोट फाइलमा एउटा शब्द थप्न बिर्सें। 25 | 26 | यो समस्या समाधान गर्न दुई तरिकाहरू छन्। पहिलो भनेको नयाँ प्रतिबद्धता बनाउनु हो जसमा परिवर्तन समावेश छ: 27 | ``` 28 | g56123f बोट फाइल सिर्जना गर्दै 29 | contributor.md बाट a2235d अपडेट 30 | a5da0d बोट फाइल सम्पादन गर्नुहोस् 31 | b0ca8f बोट फाइलमा शब्द थप्नुहोस् 32 | ``` 33 | दोस्रो तरिका भनेको a5da0d कमिट परिमार्जन गर्नु हो र यो नयाँ शब्द थप्नुहोस् र यसलाई Github मा सबै एक कमिटमा पुश गर्नुहोस्। 34 | यो दोस्रो विकल्प बढी उपयुक्त देखिन्छ, यो एक सानो परिवर्तन हो। 35 | 36 | त्यसो गर्न, यी चरणहरू पालना गर्नुहोस्: 37 | * फाइल सम्पादन गर्नुहोस्। हाम्रो अवस्थामा, हामी बिर्सिएको शब्द समावेश गर्न बोट फाइल परिमार्जन गर्छौं। 38 | * त्यसपछि फाइललाई स्टेजिङ क्षेत्रमा ```git add ``` आदेशको साथ थप्नुहोस् 39 | 40 | सामान्यतया, स्टेजिङ क्षेत्रमा फाइलहरू थपेपछि, अर्को चरण आदेश चलाउन हो 41 | git कमिट -एम "हाम्रो प्रतिबद्ध सन्देश", हैन? तर हामी यहाँ के चाहन्छौं भने प्रतिबद्धता परिमार्जन गर्नु हो 42 | अघिल्लो, हामी यसको सट्टा आदेशहरू चलाउनेछौं: 43 | 44 | * ``git कमिट -- amend``` 45 | यसले पाठ सम्पादक ल्याउनेछ जसले तपाईंलाई सन्देश सम्पादन गर्न सोध्छ। तपाईं छोड्ने निर्णय गर्न सक्नुहुन्छ 46 | सन्देश जस्तो छ वा परिवर्तन गर्नुहोस्। 47 | * सम्पादकबाट बाहिर निस्कनुहोस् 48 | * आफ्ना परिवर्तनहरूलाई ```git push origin ``` सँग पुश गर्नुहोस् 49 | 50 | यसरी दुबै परिवर्तनहरू एउटै कमिटमा छन्। 51 | -------------------------------------------------------------------------------- /additional-material/translations/Urdu/amending-a-commit.ur.md: -------------------------------------------------------------------------------- 1 | کمانڈر ترمیم # 2 | 3 | اگر آپ اپنے دور دراز ذخیرہ میں تبدیلی کرتے ہیں تو صرف اس کے بعد احساس کرنے کے لۓ آپ کے پاس وعدہ کردہ پیغام میں ٹائپو ہے یا آپ کو اپنے حالیہ حاکموں میں ایک لائن شامل کرنا بھول گیا ہے. 4 | تم اس میں کیسے ترمیم کرتے ہو؟ یہ وہی ہے جو سبق کا احاطہ کرتا ہے. 5 | 6 | ## آپ Github کے لئے دھکیل دیا ہے کے بعد ایک حالیہ پیغام کا ارتکاب تبدیل کرنا. 7 | 8 | کسی فائل کو کھولنے کے بغیر ایسا کرنے کے لئے: 9 | * میں ٹائپ کریں `` `git commit --amend -m "اپنا نیا ارتکاب کے بعد پیغام "` `` ارتکاب 10 | * ذخیرہ کرنے کے لئے تبدیل کرنے کے لئے چلائیں `` `git push origin ` ``. 11 | 12 | نوٹ: اگر آپ صرف ``` git commit --amend ``` میں ٹائپ کریں تو، آپ کے ٹیکسٹ ایڈیٹر آپ کو وعدہ پیغام میں ترمیم کرنے کے لئے فوری طور پر کھولیں گے. 13 | `` -m`` جھگڑے کو شامل کرنے سے روکتا ہے. 14 | 15 | ## ایک واحد پر ترمیم کا ارتکاب 16 | 17 | لہذا، اگر ہم ایک ہی لفظ کو تبدیل کرنے کی طرح ایک فائل میں ایک معمولی تبدیلی کرنے کے لئے بھول گئے ہیں اور ہم نے پہلے سے ہی ہمارے دور دراز ذخیرہ کرنے کے لئے وعدے کو دھکا دیا ہے؟ 18 | 19 | یہاں وضاحت کرنے کے لئے میری اقلیت کی لاگت ہے: 20 | 21 | `` ` 22 | g56123f create file bot file 23 | a2235d updated contributor.md 24 | a5da0d modified bot file 25 | `` ` 26 | آتے ہیں کہ میں بوٹ فائل میں ایک ہی لفظ شامل کرنے کے لئے بھول گیا 27 | 28 | اس کے بارے میں جانے کے لۓ 2 طریقے ہیں. سب سے پہلے ایک مکمل طور پر نیا وعدہ ہے جو اس طرح کی تبدیلی پر مشتمل ہے: 29 | 30 | `` ` 31 | g56123f create file botfile 32 | a2235d updated contributor.md 33 | a5da0d modified botfile 34 | b0ca8f added single word to botfile 35 | `` ` 36 | دوسرا طریقہ 5da0d وعدہ میں ترمیم کرنا ہے، اس نئے لفظ کو شامل کریں اور یہ ایک عہد کے طور پر جتھوٹ کو دھکا دیں. 37 | دوسری آواز بہتر ہے کیونکہ یہ صرف ایک معمولی تبدیلی ہے. 38 | 39 | اس کو حاصل کرنے کے لئے، ہم مندرجہ ذیل کریں گے: 40 | * فائل میں ترمیم کریں. اس صورت میں، میں نے پہلے ہی اتار دیا گیا لفظ شامل کرنے کے لئے میں botfile میں ترمیم کریں گے. 41 | * اگلا، فیلڈ اسٹینج علاقے میں `` `git add ` `` 42 | 43 | عام طور پر اسٹینجنگ علاقے میں فائلوں کو شامل کرنے کے بعد، ہمارا اگلا کام ہمارا وعدہ ہے - ہمارا وعدہ پیغام "صحیح ہے؟ 44 | لیکن چونکہ ہم یہاں حاصل کرنا چاہتے ہیں اس سے پچھلے وعدوں میں ترمیم کرنا ہے، ہم اس کے بجائے چلائیں گے: 45 | 46 | * `` `git commit --amend ` `` 47 |  اس کے بعد ٹیکسٹ ایڈیٹر کو لانے اور پیغام کو ترمیم کرنے کے لئے آپ کو فوری طور پر کریں گے. آپ پیغام کو چھوڑنے کا فیصلہ کر سکتے ہیں کیونکہ اس سے پہلے تھا یا اسے تبدیل کر دیا گیا تھا. 48 | * ایڈیٹر سے باہر نکلیں 49 | * اپنی تبدیلیوں کو دھکا دیں `` `git push origin ` `` 50 | 51 | اس طرح، دونوں تبدیلیاں ایک ہی انجام میں ہو گی. -------------------------------------------------------------------------------- /additional-material/translations/Italian/reverting-a-commit.it.md: -------------------------------------------------------------------------------- 1 | # ripristinare una commit 2 | 3 | Ripristinare (*revert) una commit significa creare una nuova commit che elimina tutti 4 | i cambiamenti apportati da quella precedente. È come fare un ```ctrl + Z``` su git. 5 | 6 | Il ripristino è reso più semplice in git perchè ogni commit che invii (*push) nella tua repository remota ha un'unica chiave alfanumerica associata, questa chiave è chiamata SHA (Secure Hash Algorithm). 7 | questo significa che puoi ripristinare una commit fintanto che possiedi la sua chiave SHA. 8 | ad ogni modo, bisogna prestare attenzione a ripristinare le commit in modo ordinato in modo da non mettere in disordine la tua repository. 9 | 10 | Per ottenere la chiave SHA della commit che vuoi ripristinare, viene in aiuto il log di tutte le commit che sono state fatte. 11 | per ottenere questo log possiamo utilizzare il comando: 12 | ```git log --oneline ``` 13 | Usando il comando ```git log``` da solo si ottengono comunque le SHA (in formato lungo) 14 | utilizzando però la flag ```--oneline ``` diciamo a git che vogliamo stampare a video un formato conciso (una linea) per facilitare la lettura. 15 | 16 | I primi 7 caratteri stampati quando esegui questo comando rappresentano un abbreviazione dell'hash della commit. 17 | 18 | Per esempio, questo è quello che ottengo quando eseguo ```git log --oneline ``` su questa repository: 19 | ``` 20 | 389004d added spacing in title 21 | c1b9fc1 Merge branch 'master' into tutorials 22 | 77eaafd added tutorial for reverting a commit 23 | ``` 24 | 25 | Questo esempio dimostra come con ```git log --oneline```, possiamo ottenere la lista di commit fatte sulla repository assieme ai primi 7 caratteri del suo SHA. 26 | 27 | Supponiamo ora che io voglia ripristinare la commit "added spacing in title", per fare questo seguirei questi passaggi: 28 | 29 | * Copio lo SHA della commit che, in questo caso è ```389004d``` 30 | * poi, eseguo il comando ```git revert 389004d``` 31 | 32 | Facendo questo si apre il mio editor di testo e mi viene chiesto di modificare il messaggio di commit. 33 | Puoi decidere di lasciare il messaggio di default che inizia con la parola `Revert` 34 | oppure puoi anche decidere di personalizzare il messaggio come preferisci. 35 | 36 | * In seguito, salvo il messaggio e chiudo l'editor di testo. 37 | * Vengo mandato nella linea di comando. 38 | * eseguo ```git push origin ``` per inviare i cambiamenti ripristinati su Github. 39 | 40 | E questo è tutto, i cambiamenti vengono eliminati. Nel mio caso, la repository viene ripristinata allo stesso stato di com'era in ```c1b9fc1``` -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/keeping-your-fork-synced-with-this-repository.by.md: -------------------------------------------------------------------------------- 1 | # Сінхранізацыя вашага адгалінаванні з асноўным рэпазітаром 2 | 3 | Па-першае, варта разумець паток для поўнай сінхранізацыі, што важна. У гэтай схеме ёсць 3 розныя рэпазітары: мае адкрытыя сховішча ў Github `github.com / firstcontributions / first-doprino.git`, ваш відэлец сховішча на GitHub` github.com / Your-Name / first-donates / ` і сховішча мясцовай машыны, на якой вы павінны працаваць. Такі від супрацоўніцтва характэрны для праектаў з адкрытым зыходным кодам і называецца `Triangle Workflows`. 4 | 5 | triangle workflow 6 | 7 | Каб захаваць вашыя два сховішчы ў актуальным стане з маім адкрытым сховішчам, мы спачатку павінны здабыць і аб'яднаць агульнае сховішча з рэпазітарам вашай лакальнай машыны. 8 | Наш другі крок - перанесці ваша мясцовае сховішча ў відэлец GitHub. Як вы ўжо бачылі раней, толькі "з відэльцам" вы можаце папрасіць "pull request". Такім чынам, відэлец GitHub - апошняе сховішча, якое трэба абнавіць. 9 | 10 | Зараз давайце паглядзім, як гэта зрабіць: 11 | 12 | Па-першае, вы павінны быць на сваім вядучым аддзяленні. Каб даведацца, на якой філіяле вы знаходзіцеся, праверце першы радок: 13 | ``` 14 | git status 15 | ``` 16 | калі вы яшчэ не на майстры: 17 | ``` 18 | git checkout master 19 | ``` 20 | 21 | Затым вы павінны дадаць маё агульнадаступнае сховішча ў свой git з `add addstream stream-url`: 22 | ``` 23 | git remote add upstream https://github.com/firstcontributions/first-contributions.git 24 | ``` 25 | 26 | Гэта спосаб сказаць Git, што іншая версія гэтага праекта існуе ў паказаным URL-адресе, і мы называем яго "вышэй". Пасля таго, як ваш git мае імя, давайце пазнаём апошнюю версію грамадскага сховішча: 27 | ``` 28 | git fetch upstream 29 | ``` 30 | 31 | Вы толькі што атрымалі апошнюю версію майго відэльца (`upstream` remote). Зараз вам трэба аб'яднаць агульнадаступнае сховішча ў ваша галоўнае аддзяленне. 32 | ``` 33 | git rebase upstream/master 34 | ``` 35 | Тут вы аб'яднаеце грамадскае сховішча з вашай галоўнай галіной. Галоўнае аддзяленне вашай мясцовай машыны зараз актуальнае. І, нарэшце, калі вы націснеце галоўную галінку на відэлец, ваша відэлец GitHub таксама будзе змяняць: 36 | ``` 37 | git push origin master 38 | ``` 39 | 40 | Звярніце ўвагу, вы націскаеце на remote імя `origin`. 41 | 42 | Такім чынам, да гэтага часу альбо ў гэты момант усе вашыя сховішчы актуальныя. Добра зроблена! Вы павінны рабіць гэта кожны раз, калі ваш сховішча GitHub паведамляе вам, што вы здзяйсняеце некалькі commits. -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/resolving-merge-conflicts.md: -------------------------------------------------------------------------------- 1 | # What is a merge conflict? 2 | 3 | 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. 4 | 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. 5 | 6 | # How to resolve a merge conflict? 7 | 8 | When faced with a merge conflict, git will mark the problematic area in the file by enclosing it in “<<<<<<<< HEAD” and “>>>>>>>>>>[other branch name]” 9 | 10 | 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. 11 | Our job is now to clean up these lines: when we're done, the file should look exactly as we want it to look. It is advisable to consult the teammate who wrote the conflicting changes to decide which version should be final. It could be either one of yours - or maybe a mixture between the two. 12 | 13 | e.g. : 14 | ``` 15 | <<<<<<< HEAD:mergetest 16 | This is my third line 17 | ======= 18 | This is a fourth line I am adding 19 | >>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest 20 | ``` 21 | 22 | `<<<<<<<`: 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. 23 | `=======`: 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. 24 | `>>>>>>>`: Indicates the end of the lines that had a merge conflict. 25 | 26 | 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. 27 | 28 | 29 | 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. 30 | 31 | You can also download different plugins depending on the IDE you are using for an easier way to resolve merge conflicts. 32 | 33 | 34 | # How to undo a merge? 35 | If you want to undo a merge then you can do `git merge —abort` 36 | -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/keeping-your-fork-synced-with-this-repository.md: -------------------------------------------------------------------------------- 1 | # Keeping your fork synced with this repository 2 | 3 | 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`. 4 | 5 | triangle workflow 6 | 7 | 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. 8 | 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. 9 | 10 | Now, let's see how to do it: 11 | 12 | First, you must be on your master branch. To know which branch you are on, check the first line of: 13 | ``` 14 | git status 15 | ``` 16 | if you are not already on master: 17 | ``` 18 | git checkout master 19 | ``` 20 | 21 | Then you should add my public repo to your git with `add upstream remote-url`: 22 | ``` 23 | git remote add upstream https://github.com/firstcontributions/first-contributions.git 24 | ``` 25 | 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: 26 | ``` 27 | git fetch upstream 28 | ``` 29 | 30 | You've just fetched the latest version of my fork (`upstream` remote). Now, you need to merge the public repository into your master branch. 31 | ``` 32 | git rebase upstream/master 33 | ``` 34 | 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: 35 | ``` 36 | git push origin master 37 | ``` 38 | Notice here you're pushing to the remote named `origin`. 39 | 40 | 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: 41 | ``` 42 | git pull upstream master 43 | ``` 44 | 45 | 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. 46 | -------------------------------------------------------------------------------- /additional-material/translations/Slovenian/keeping-your-fork-synced-with-this-repository.sl.md: -------------------------------------------------------------------------------- 1 | # Kako imeti svojo različico sinhronizirano z oddaljenim repository-em 2 | 3 | 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`. 4 | 5 | triangle workflow 6 | 7 | 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 ). 8 | 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. 9 | 10 | No pa poglejmo kako se to naredi: 11 | 12 | Najprej moraš biti v svoji glavni veji ( master branch ). Da izveš na kateri veji si trenutno, izvedi ta ukaz in poglej prvo vrstico odgovora: 13 | ``` 14 | git status 15 | ``` 16 | Če nisi na glavni veji uporabi: 17 | ``` 18 | git checkout master 19 | ``` 20 | 21 | Potem dodaš moj javni repository svojemu git-u z ukazom `add upstream remote-url`: 22 | ``` 23 | git remote add upstream https://github.com/Roshanjossey/first-contributions 24 | ``` 25 | 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`: 26 | ``` 27 | git fetch upstream 28 | ``` 29 | 30 | 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). 31 | ``` 32 | git rebase upstream/master 33 | ``` 34 | 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: 35 | ``` 36 | git push origin master 37 | ``` 38 | Tukaj lahko vidiš da pošiljaš v oddaljeni repository imenovan `origin`. 39 | 40 | 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. 41 | -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/creating-a-gitignore-file.md: -------------------------------------------------------------------------------- 1 | # .gitignore 2 | 3 | The .gitignore file is a text file that tells Git which files or folders to ignore in a project. 4 | 5 | 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. 6 | 7 | ## Why .gitignore 8 | 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. 9 | 10 | ## Getting started 11 | 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. 12 | 13 | The entries in this file can also follow a matching pattern. 14 | 15 | ``` 16 | * is used as a wildcard match 17 | / is used to ignore path names relative to the .gitignore file 18 | # is used to add comments to a .gitignore file 19 | 20 | This is an example of what the .gitignore file could look like: 21 | 22 | # Ignore Mac system files 23 | .DS_store 24 | 25 | # Ignore node_modules folder 26 | node_modules 27 | 28 | # Ignore all text files 29 | *.txt 30 | 31 | # Ignore files related to API keys 32 | .env 33 | 34 | # Ignore SASS config files 35 | .sass-cache 36 | 37 | ``` 38 | To add or change your global .gitignore file, run the following command: 39 | 40 | ``` 41 | git config --global core.excludesfile ~/.gitignore_global 42 | 43 | ``` 44 | 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. 45 | 46 | ## How to Untrack Files Previously Committed from New Gitignore 47 | 48 | To untrack a single file, ie stop tracking the file but not delete it from the system use: 49 | 50 | ``` 51 | git rm --cached filename 52 | ``` 53 | 54 | To untrack every file in .gitignore: 55 | 56 | First, commit any outstanding code changes, and then run: 57 | 58 | ``` 59 | git rm -r --cached 60 | ``` 61 | 62 | This removes any changed files from the index(staging area), then run: 63 | 64 | ``` 65 | git add . 66 | ``` 67 | Commit it: 68 | 69 | ``` 70 | git commit -m ".gitignore is now working" 71 | ``` 72 | 73 | To undo ```git rm --cached filename```, use ```git add filename``` 74 | -------------------------------------------------------------------------------- /additional-material/translations/Portugues/keeping-your-fork-synced-with-this-repository.pt_br.md: -------------------------------------------------------------------------------- 1 | ## Mantendo o seu Fork sincronizado com este repositório 2 | 3 | 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`. 4 | 5 | triangle workflow 6 | 7 | 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. 8 | 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. 9 | 10 | Agora, vamos ver como fazer isso: 11 | 12 | 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: 13 | ``` 14 | git status 15 | ``` 16 | Se você não está no master, vá para ele: 17 | ``` 18 | git checkout master 19 | ``` 20 | 21 | Em seguida, você deve adicionar meu repositório público ao seu git com `add upstream url-remoto`: 22 | ``` 23 | git remote add upstream https://github.com/Roshanjossey/first-contributions 24 | ``` 25 | 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: 26 | ``` 27 | git fetch upstream 28 | ``` 29 | 30 | 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. 31 | ``` 32 | git rebase upstream/master 33 | ``` 34 | 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: 35 | ``` 36 | git push origin master 37 | ``` 38 | Note que aqui você está fazendo um Push para o repositório remoto chamado `origin`. 39 | 40 | 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. 41 | -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/amending-a-commit.by.md: -------------------------------------------------------------------------------- 1 | # Выпраўленні ў каміты 2 | 3 | Уявіце, што вы зрабілі commit ў выдалены рэпазітар, а потым зразумелі, што дапусцілі памылку друку ў каментары да commit або забыліся ўставіць радок у гэты апошні па часе commit. Як паступіць у гэтай сітуацыі? Менавіта пра гэта і пойдзе гаворка ў гэтым дакуменце. 4 | 5 | ## Як змяніць каментар да нядаўняга камітаў пасля таго, як ён быў пасланы на Github (pushed) 6 | Каб зрабіць гэта, не адкрываючы файл для рэдагавання, 7 | * Набярыце ```git commit --amend -m "followed by your new commit message"``` 8 | * А затым выканаеце ```git push origin ``` для таго, каб паслаць змены на Github. 9 | 10 | Заўвага: Калі вы набярэце, толькі ```git commit --amend```, то адкрыецца тэкставы рэдактар і прапануе адрэдагаваць каментар да commit. 11 | Выкарыстанне ключа `` -m`` адмяняе запуск рэдактара. 12 | 13 | ## Як зрабіць змены ў адным commit 14 | 15 | Што калі мы забыліся зрабіць невялікае змяненне ў файле, напрыклад, замяніць адно слова ў commit, які ўжо пасланы ў выдалены рэпазітар? 16 | 17 | Хай, для прыкладу, запісы ў часопісе маіх commit выглядаюць наступным чынам: 18 | `` ` 19 | g56123f create file bot file 20 | a2235d updated contributor.md 21 | a5da0d modified bot file 22 | `` ` 23 | Дапусцім, я забыўся дадаць адно слова ў файл bot file 24 | 25 | Ёсць два спосабу выправіць гэта. Першы заключаецца ў стварэнні новага commit, які змяшчае гэта змена, напрыклад, так: 26 | `` ` 27 | g56123f create file botfile 28 | a2235d updated contributor.md 29 | a5da0d modified botfile 30 | b0ca8f added single word to botfile 31 | `` ` 32 | Другі спосаб складаецца ў выпраўленні камітаў a5da0d, даданні гэтага прапушчанага слова і запушивании гэтых змяненняў на Github ў выглядзе аднаго камітаў. 33 | Другі спосаб ўяўляецца пераважнай, паколькі справа ідзе толькі аб нязначным змене. 34 | 35 | Каб дамагчыся гэтага, мы паступім наступным чынам: 36 | * Зменім файл. У дадзеным выпадку я змяню файл botfile, дадаўшы да яго слова, якое я прапусціў раней. 37 | * Далей, праіндэксуем гэты файл пры дапамозе каманды ```git add ``` 38 | 39 | У звычайным выпадку адразу пасля індэксавання мы робім `` `git commit -m" коментар да нашага commit "` ``, правільна? Але паколькі ў дадзеным выпадку наша задача - выправіць папярэдні commit, - то замест гэтага мы выканаем такую каманду: 40 | 41 | * ```git commit --amend``` 42 | У выніку адкрыецца акно тэкставага рэдактара, у якім мы маем магчымасць зрабіць змены ў каментары. Мы можам на самай справе адрэдагаваць каментар, ці пакінуць яго без зменаў. 43 | * Выйдзем з рэдактара 44 | * Запушим нашы змены пры дапамозе каманды ```git push origin ``` 45 | 46 | Такім чынам, абодва выпраўлення апынуцца ў адным commit. -------------------------------------------------------------------------------- /additional-material/translations/Spanish/amending-a-commit.es.md: -------------------------------------------------------------------------------- 1 | # Modificar un commit 2 | 3 | Imaginemos que has realizado un commit en tu repositorio remoto y luego te das cuenta de que hay un error tipográfico en el mensaje del commit o que olvidaste agregar una línea en tu commit más reciente. ¿Cómo corregir este error? Ese es el tema de este tutorial. 4 | 5 | ## Cambiar un mensaje de commit reciente después de haberlo enviado a GitHub 6 | Para hacerlo sin siquiera abrir un archivo: 7 | * Escribe el comando ```git commit --amend -m "seguido de tu nuevo mensaje de commit"``` 8 | * Lanza el comando ```git push origin ``` para realizar un commit en el repositorio. 9 | 10 | Nota: Si solo escribes ```git commit --amend```, se abrirá el editor de texto y te pedirá que modifiques el mensaje del commit. Agrega la opción ``-m`` para evitar pasar por el editor de texto. 11 | 12 | ## Modificar un commit específico 13 | 14 | Entonces, ¿qué sucede si olvidas hacer un cambio menor en un archivo, como cambiar una palabra, y ya has enviado ese commit a nuestro repositorio remoto? 15 | 16 | Para ilustrar esto, aquí tienes un registro de mis commits; 17 | ``` 18 | g56123f creación de un archivo bot 19 | a2235d actualización de contributeur.md 20 | a5da0d modificación del archivo bot 21 | ``` 22 | Imaginemos que olvidé agregar una palabra en el archivo bot. 23 | 24 | Hay dos formas de resolver este problema. La primera es hacer un nuevo commit que contenga el cambio de esta manera: 25 | ``` 26 | g56123f creación de un archivo bot 27 | a2235d actualización de contributeur.md 28 | a5da0d modificación del archivo bot 29 | b0ca8f agregado de una palabra en el archivo bot 30 | ``` 31 | La segunda forma es modificar el commit a5da0d y agregar esta nueva palabra, luego enviarlo a GitHub, todo en un solo commit. Esta segunda opción parece más adecuada, ya que es un cambio menor. 32 | 33 | Para hacer esto, sigue estos pasos: 34 | * Modifica el archivo. En nuestro caso, modifica el archivo bot para incluir la palabra olvidada. 35 | * Luego, agrega el archivo a la zona de preparación con el comando ```git add ``` 36 | 37 | Normalmente, después de agregar archivos a la zona de preparación, ¿la siguiente etapa es ejecutar el comando git commit -m "nuestro mensaje de commit", verdad? Pero como lo que queremos aquí es modificar el commit anterior, en su lugar ejecutaremos los comandos: 38 | 39 | * ```git commit --amend``` 40 | Esto abrirá el editor de texto que te pedirá que modifiques el mensaje. Puedes decidir si dejar el mensaje tal como está o cambiarlo. 41 | * Sal del editor 42 | * Envía tus cambios con el comando ```git push origin ``` 43 | 44 | De esta manera, ambos cambios se encuentran en un solo commit. -------------------------------------------------------------------------------- /additional-material/translations/Spanish/amending-a-commit.sp_mx.md: -------------------------------------------------------------------------------- 1 | # Arreglando un compromiso (Commit) 2 | 3 | ¿Qué sucede si confirma un cambio en su repositorio remoto y luego se da cuenta de que tiene un error en el mensaje de confirmación o si olvidó agregar una línea de código en su confirmación más reciente? 4 | ¿Cómo editarías esto? Eso es lo que cubre este tutorial. 5 | 6 | ## Cambiar un mensaje de confirmación reciente después de enviarlo a Github 7 | 8 | Para hacer esto sin abrir un archivo: 9 | * Ingrese el comando ```git commit --amend -m "seguido de su nuevo mensaje de confirmación"``` 10 | * Ejecute ```git push origin ``` para confirmar los cambios en el repositorio. 11 | 12 | Nota: Si simplemente escribe ```git commit --amend```, se abrirá su editor de texto y le pedirá que edite el mensaje de confirmación. 13 | Agregar el indicador ``-m`` evita esto. 14 | 15 | ## Realizar cambios en una sola confirmación 16 | 17 | ¿Qué pasa si nos olvidamos de hacer un pequeño cambio en un archivo, como agregar una sola palabra, pero ya hemos enviado la confirmación a nuestro repositorio remoto? 18 | 19 | Para ilustrar, aquí hay un registro de mis confirmaciones: 20 | ```bash 21 | g56123f creó el archivo bot 22 | a2235d actualizado colaborador.md 23 | archivo bot modificado a5da0d 24 | ``` 25 | 26 | Supongamos que olvidé agregar una palabra en el bot. 27 | 28 | Hay 2 formas de resolver este problema. La primera es hacer una nueva confirmación que contenga el cambio, como esta: 29 | 30 | ```bash 31 | g56123f creó el archivo bot 32 | a2235d actualizado colaborador.md 33 | archivo bot modificado a5da0d 34 | b0ca8f agregó una palabra en el archivo bot 35 | ``` 36 | 37 | La segunda forma es corregir la confirmación a5da0d, agregar esta nueva palabra y enviarla a Github como una confirmación única. 38 | Esta acción suena mejor ya que es sólo un pequeño cambio. 39 | 40 | Para ello haríamos lo siguiente: 41 | * Modificar el archivo. En ese caso, modificaré el archivo del bot para incluir la palabra que omití antes. 42 | * A continuación, agregue el archivo al área de preparación (*staging area*) con el comando ```git add ``` 43 | 44 | Normalmente, después de agregar archivos al área de preparación, lo siguiente que hacemos es ingresar el comando ```git commit -m "our commit message"```, ¿verdad? 45 | Pero como lo que queremos hacer aquí es arreglar la confirmación anterior, ejecutaremos en su lugar: 46 | 47 | * ```git commit --amend``` 48 | Esto iniciará el editor de texto para que podamos editar el mensaje. Tú decides si dejar el mensaje como estaba antes o editarlo. 49 | * Salir del editor guardando los cambios 50 | * Empuja tus cambios con el comando ```git push origin ``` 51 | 52 | De esa manera, ambos cambios ahora estarán en una sola confirmación. -------------------------------------------------------------------------------- /additional-material/translations/Vietnamese/resolving-merge-conflicts.vi.md: -------------------------------------------------------------------------------- 1 | # Mâu Thuẫn Khi Tích Hợp là gì? 2 | 3 | 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. 4 | 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. 5 | 6 | # Làm thế nào để giải quyết xung đột khi tích hợp? 7 | 8 | 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]` 9 | 10 | 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. 11 | 12 | Ví dụ: 13 | ``` 14 | <<<<<<< HEAD:mergetest 15 | This is my third line 16 | ======= 17 | This is a fourth line I am adding 18 | >>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest 19 | ``` 20 | 21 | `<<<<<<<`: 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. 22 | `=======`: 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. 23 | `>>>>>>>`: Cho biết kết thúc của các dòng có xung đột khi tích hợp. 24 | 25 | 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. 26 | 27 | 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. 28 | 29 | 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. 30 | 31 | # Làm thế nào để hoàn tác lại tích hợp? 32 | 33 | 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` 34 | -------------------------------------------------------------------------------- /additional-material/translations/Portugues/amending-a-commit.pt_br.md: -------------------------------------------------------------------------------- 1 | # Corrigindo um Commit 2 | 3 | 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? 4 | Como você editaria isso? É isso que esse tutorial cobre. 5 | 6 | ## Alterando uma mensagem de commit recente após ter dado push para o Github 7 | 8 | Para fazer isto sem abrir um arquivo: 9 | * Digite o comando ```git commit --amend -m "seguido da sua nova mensagem de commit"``` 10 | * Execute ```git push origin ``` para fazer o commit das mudanças para o repositório. 11 | 12 | Nota: Se você digitar apenas ```git commit --amend```, seu editor de texto abrirá te pedindo para editar a mensagem de commit. 13 | Adicionar a flag ``-m`` previne isso. 14 | 15 | ## Fazendo modificações em um único commit 16 | 17 | 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? 18 | 19 | Para ilustrar, aqui está um log dos meus commits: 20 | ``` 21 | g56123f arquivo bot criado 22 | a2235d atualizado contributor.md 23 | a5da0d arquivo bot modificado 24 | ``` 25 | 26 | Supomos que eu esqueci de adicionar uma palavra no arquivo bot. 27 | 28 | Há 2 modos de resolver esse problema. O primeiro é fazer um novo commit que contém a mudança, dessa forma: 29 | 30 | ``` 31 | g56123f arquivo bot criado 32 | a2235d atualizado contributor.md 33 | a5da0d arquivo bot modificado 34 | b0ca8f adicionada palavra no arquivo bot 35 | ``` 36 | 37 | O segundo modo é corrigir o commit a5da0d, adicionar essa nova palavra e dar push para o Github como um único commit. 38 | Essa ação soa melhor, já que é apenas uma pequena alteração. 39 | 40 | Para fazer isso, nós faríamos o seguinte: 41 | * Modificar o arquivo. Nesse caso, modificarei o arquivo bot para incluir a palavra que eu esqueci anteriormente. 42 | * Em seguida, adicionar o arquivo para a área de preparação (*staging area*) com o comando ```git add ``` 43 | 44 | 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? 45 | Mas, como o que nós queremos fazer aqui é corrigir o commit anterior, nós ao invés disso iremos rodar: 46 | 47 | * ```git commit --amend``` 48 | 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. 49 | * Sair do editor salvando as alterações 50 | * Dar push nas suas alterações com o comando ```git push origin ``` 51 | 52 | Dessa forma, ambas as alterações agora estarão em um único commit. 53 | -------------------------------------------------------------------------------- /additional-material/translations/Russian/amending-a-commit.ru.md: -------------------------------------------------------------------------------- 1 | # Исправления в коммите 2 | 3 | Представьте, что вы сделали коммит в удаленный репозиторий, а потом поняли, что допустили опечатку в комментарии к коммиту или забыли вставить строку в этот последний по времени коммит. Как поступить в такой ситуации? Именно об этом и пойдет речь в этом документе. 4 | 5 | ## Как изменить комментарий к недавнему коммиту после того, как он был послан на Github (pushed) 6 | Чтобы сделать это, не открывая файл для редактирования, 7 | * наберите ```git commit --amend -m "здесь следует текст нового комментария"``` 8 | * а затем исполните ```git push origin <имя-ветки>``` для того, чтобы послать изменения на Github. 9 | 10 | Примечание: Если вы наберете, только ```git commit --amend```, то откроется текстовый редактор и предложит отредактировать комментарий к коммиту. Использование ключа ``-m`` отменяет запуск редактора. 11 | 12 | ## Как сделать изменения в одном коммите 13 | 14 | Что если мы забыли сделать небольшое изменение в файле, например, заменить одно слово в коммите, который уже послан в удаленный репозиторий? 15 | 16 | Пусть, для примера, записи в журнале моих коммитов выглядят следующим образом: 17 | ``` 18 | g56123f создай файл bot file 19 | a2235d исправлен contributor.md 20 | a5da0d изменен bot file 21 | ``` 22 | Допустим, я забыл добавить одно слово в файл bot file 23 | 24 | Есть два способа исправить это. Первый заключается в создании нового коммита, содержащего это изменение, например, так: 25 | ``` 26 | g56123f создай файл bot file 27 | a2235d исправлен contributor.md 28 | a5da0d изменен botfile 29 | b0ca8f добавлено одно слово в botfile 30 | ``` 31 | Второй способ состоит в исправлении коммита a5da0d, добавлении этого пропущенного слова и запушивании этих изменений на Github в виде одного коммита. 32 | Второй способ представляется предпочтительным, поскольку дело идёт лишь о незначительном изменении. 33 | 34 | Чтобы добиться этого, мы поступим следующим образом: 35 | * Изменим файл. В данном случае я изменю файл botfile, добавив к нему слово, которое я пропустил ранее. 36 | * Далее, проиндексируем этот файл при помощи команды ```git add <имяфайла>``` 37 | 38 | В обычном случае сразу после индексирования мы делаем ```git commit -m "комментраий к нашему коммиту"```, правильно? Но поскольку в данном случае наша задача - исправить предыдущий коммит, - то вместо этого мы выполним такую команду: 39 | 40 | * ```git commit --amend``` 41 | В результате откроется окно текстового редактора, в котором мы имеем возможность сделать изменения в комментарии. Мы можем в самом деле отредактировать комментарий, или оставить его без изменений. 42 | * Выйдем из редактора 43 | * Запушим наши изменения при помощи команды ```git push origin <имя-ветки>``` 44 | 45 | Таким образом, оба исправления окажутся в одном коммите. 46 | -------------------------------------------------------------------------------- /additional-material/translations/French/amending-a-commit.fr.md: -------------------------------------------------------------------------------- 1 | # Modifier un commit 2 | 3 | Imaginons que vous avez effectué un commit sur votre répertoire distant et que vous vous rendez compte plus tard qu'il 4 | y a une coquille dans le message de commit ou que vous avez oublié d'ajouter une ligne dans votre tout dernier commit. 5 | Comment faire pour rectifier cette erreur ? C'est le sujet de ce tutoriel. 6 | 7 | ## Changer un message de commit récent après l'avoir poussé sur Github 8 | Pour se faire sans même ouvrir un fichier : 9 | * Taper la commande ```git commit --amend -m "suivi de votre nouveau message de commit"``` 10 | * Lancer la commande ```git push origin ``` pour effectuer un commit vers le répertoire. 11 | 12 | NB : Si vous tapez uniquement ```git commit --amend```, l'éditeur de texte s'ouvre et vous demande de modifier le 13 | message de commit. Ajoutez l'option ``-m`` pour éviter de passer par l'éditeur de texte. 14 | 15 | ## Modifier un commit précis 16 | 17 | Donc, qu'est-ce qu'il se passe si vous oubliez de faire un changement mineur sur un fichier, comme changer un mot et 18 | que vous avez déjà poussé ce commit vers notre répertoire distant ? 19 | 20 | Pour illustrer ce propos, voici un log de mes commits ; 21 | ``` 22 | g56123f création d'un fichier bot 23 | a2235d mise à jour de contributeur.md 24 | a5da0d modification du fichier bot 25 | ``` 26 | Imaginons que j'ai oublié d'ajouter un mot dans le fichier bot. 27 | 28 | 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 : 29 | ``` 30 | g56123f création d'un fichier bot 31 | a2235d mise à jour de contributeur.md 32 | a5da0d modification du fichier bot 33 | b0ca8f ajout d'un mot dans le fichier bot 34 | ``` 35 | 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. 36 | Cette deuxième option semble plus adaptée, étant donné qu'il s'agit d'un changement mineur. 37 | 38 | Pour se faire, il faut suivre les étapes suivantes : 39 | * Modifier le fichier. Dans notre cas, on modifie le fichier bot pour y inclure le mot oublié. 40 | * Ensuite, ajouter le fichier dans la zone de transit avec la commande ```git add ``` 41 | 42 | D'habitude, après avoir ajouté des fichiers dans la zone de transit, l'étape suivante est d'exécuter la commande 43 | git commit -m "notre message de commit", n'est-ce pas ? Mais comme ce qu'on veut ici c'est modifier le commit 44 | précédent, on va plutôt lancer les commandes : 45 | 46 | * ```git commit --amend``` 47 | Cela va faire apparaître l'éditeur de texte qui vous demande de modifier le message. Vous pouvez décider de laisser le 48 | message tel quel ou bien le changer. 49 | * Quitter l'éditeur 50 | * Pousser vos changements avec la commande ```git push origin ``` 51 | 52 | De cette façon, les deux changements se trouvent dans un même commit. 53 | -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/squashing-commits.md: -------------------------------------------------------------------------------- 1 | # What is squashing? 2 | 3 | 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. 4 | 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. 5 | 6 | # How do you squash commits? 7 | 8 | First, perform a git log to review the commits you would like to merge in your current branch. 9 | 10 | ``` 11 | git log 12 | ``` 13 | 14 | You should see a series of your commits like so: 15 | 16 | ``` 17 | commit blablabla 18 | Author: omguhh 19 | Date: 10/10/20 20 | Commit message 1 21 | 22 | commit blablabla2 23 | Author: omguhh 24 | Date: 10/10/20 25 | Commit message 2 26 | ``` 27 | 28 | 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: 29 | 30 | ``` 31 | git rebase -i 32 | ``` 33 | 34 | Now, with interactive rebasing you can specify the starting and end point of how far back you want to go with commits like so: 35 | 36 | ``` 37 | git rebase -i HEAD~2 38 | ``` 39 | 40 | Running this command will show you something like the following: 41 | 42 | ``` 43 | pick blablabla Changing test01.txt file 44 | pick blablabla2 Adding dummy01.txt file 45 | 46 | # 47 | # Commands: 48 | # p, pick = use commit 49 | # r, reword = use commit, but edit the commit message 50 | # e, edit = use commit, but stop for amending 51 | # s, squash = use commit, but meld into previous commit 52 | # f, fixup = like "squash", but discard this commit's log message 53 | # x, exec = run command (the rest of the line) using shell 54 | # 55 | # These lines can be re-ordered; they are executed from top to bottom. 56 | # 57 | # If you remove a line here THAT COMMIT WILL BE LOST. 58 | # 59 | # However, if you remove everything, the rebase will be aborted. 60 | # 61 | # Note that empty commits are commented out 62 | ``` 63 | 64 | So if you want to squash ```blablabla2``` into ```blablablabla```, you would change the following : 65 | 66 | ``` 67 | pick blablabla Changing test01.txt file 68 | squash blablabla2 Adding dummy01.txt file 69 | 70 | ``` 71 | 72 | If all goes well, you'd get a result that looks like this: 73 | 74 | ``` 75 | # This is a combination of 2 commits. 76 | # The first commit's message is: 77 | commit message 1 78 | 79 | # This is the 2nd commit message: 80 | 81 | commit message 2 82 | ``` 83 | 84 | That you can freely change before you decide to exit the editor to save these changes. 85 | 86 | Running git log again should show you the commit message you entered before exiting the screen with the commits combined into one. 87 | -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/squashing-commits.by.md: -------------------------------------------------------------------------------- 1 | # Што такое squashing? 2 | 3 | У git, squashing маецца на ўвазе перапісванне гісторыі вашых учынкаў, таму вы ў канчатковым выніку займаецеся апісаннем зробленых змяненняў. 4 | Звычайна гэта робіцца ў праектах з адкрытым зыходным кодам, таму што шмат гісторыяў філіялаў у праектах з адкрытым зыходным кодам мае дачыненне толькі да распрацоўшчыка, які іх стварыў, і гэта дае больш просты спосаб апісаць унесеныя змены, а таксама пры неабходнасці аднавіць іх. 5 | 6 | # Як вы робіце squash камітаў? 7 | 8 | Па-першае, выканаць часопіс git, каб прааналізаваць каміт, якія вы хацелі б аб'яднаць у вашай бягучай галіны. 9 | 10 | ``` 11 | git log 12 | ``` 13 | 14 | Вы павінны ўбачыць шэраг сваіх абавязацельстваў так: 15 | 16 | ``` 17 | commit blablabla 18 | Author: omguhh 19 | Date: 10/10/20 20 | Commit message 1 21 | 22 | commit blablabla2 23 | Author: omguhh 24 | Date: 10/10/20 25 | Commit message 2 26 | ``` 27 | 28 | Такім чынам, зараз, калі вы бачыце каміты, якія вы хочаце злучыць з адным, мы можам перайсці да гэтага з `` git rebase `` . Зыходзячы з таго, што вы ўжо знаёмыя з `` git rebase `` , мы можам пачаць squashing камітаў ў інтэрактыўным рэжыме git rebase, які можна актываваць так: 29 | 30 | ``` 31 | git rebase -i 32 | ``` 33 | 34 | Цяпер, пры дапамозе інтэрактыўнага rebasing вы можаце вызначыць пачатковую і канчатковую кропку таго, як далёка вы хочаце ісці з такімі ўчынкамі: 35 | 36 | ``` 37 | git rebase -i HEAD~2 38 | ``` 39 | 40 | Запуск гэтай каманды пакажа вам нешта падабаецца наступнае: 41 | 42 | ``` 43 | pick blablabla Changing test01.txt file 44 | pick blablabla2 Adding dummy01.txt file 45 | 46 | # 47 | # Commands: 48 | # p, pick = use commit 49 | # r, reword = use commit, but edit the commit message 50 | # e, edit = use commit, but stop for amending 51 | # s, squash = use commit, but meld into previous commit 52 | # f, fixup = like "squash", but discard this commit's log message 53 | # x, exec = run command (the rest of the line) using shell 54 | # 55 | # These lines can be re-ordered; they are executed from top to bottom. 56 | # 57 | # If you remove a line here THAT COMMIT WILL BE LOST. 58 | # 59 | # However, if you remove everything, the rebase will be aborted. 60 | # 61 | # Note that empty commits are commented out 62 | ``` 63 | 64 | Такім чынам, калі вы хочаце squash ``` blablabla2``` на ``` blablablabla```, вы змяніце наступнае: 65 | 66 | ``` 67 | pick blablabla Changing test01.txt file 68 | squash blablabla2 Adding dummy01.txt file 69 | 70 | ``` 71 | 72 | Калі ўсё пойдзе добра, вы атрымаеце такі вынік: 73 | 74 | ``` 75 | # This is a combination of 2 commits. 76 | # The first commit's message is: 77 | commit message 1 78 | 79 | # This is the 2nd commit message: 80 | 81 | commit message 2 82 | ``` 83 | 84 | Што вы можаце свабодна змяніць, перш чым вырашыць выйсці з рэдактара, каб захаваць гэтыя змены. 85 | 86 | Запуск часопіса git павінен паказаць вам паведамленне аб здзяйсненні, якое вы ўвялі перад выхадам на экран, з абавязацельствамі, аб'яднанымі ў адзін. 87 | -------------------------------------------------------------------------------- /additional-material/translations/Slovenian/additional-material.sl.md: -------------------------------------------------------------------------------- 1 | # Dodatne informacije 2 | 3 | Predvidevamo da ste že končali osnovni vodič. Sedaj boste dobili dodatne informacije o napredni uporabi Git-a. 4 | 5 | ### [Popravljanje commita](amending-a-commit.sl.md) 6 | Informacije o tem kako spremeniti commit v oddaljenem repositoryu. 7 | > Uporabi, ko moraš spremeniti že narejeni commit. 8 | 9 | ### [Nastavljanje Git-a](configuring-git.sl.md) 10 | Informacije o tem kako nastaviti uporabnika in druge možnosti v Git-u. 11 | > Uporabi za boljši nadzor nad svojo Git konfiguracijo. 12 | 13 | ### [Kako imeti svojo različico sinhronizirano z oddaljenim repository-em](keeping-your-fork-synced-with-this-repository.sl.md) 14 | 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. 15 | > Sledi tem korakom, če tvoja verzija nima nobenih sprememb v nadrejenem imeniku (parent directory). 16 | 17 | ### [Premikanje commita v drugo vejo](moving-a-commit-to-a-different-branch.sl.md) 18 | Informacije o tem kako premakniti commit v drugo vejo. 19 | > Sledi tem korakom in premakni commit v drugo vejo. 20 | 21 | ### [Odstranjevanje datoteke](removing-a-file.sl.md) 22 | Informacije o tem kako odstraniti datoteko z svojega lokalnega repository-ja. 23 | > Sledi tem korakom in odstrani datoteko pred commitom. 24 | 25 | ### [Odstrani vejo s svojega repository-ja](removing-branch-from-your-repository.sl.md) 26 | Informacije o tem kako zbrisati vejo s svojega repository-ja. 27 | > Sledi tem korakom šele potem, ko je bil tvoj pull-request že združen. 28 | 29 | ### [Razreševanje sporov pri združevanju](resolving-merge-conflicts.sl.md) 30 | Informacije o tem kako razrešiti spore pri združevanju (resolve merge conflicts). 31 | > Sledi tem korakom pri razreševanju nadležnih sporov pri združevanju. 32 | 33 | ### [Povrnitev commita](reverting-a-commit.sl.md) 34 | 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. 35 | > sledi tem korakom, če želiš povrniti commit v prejšnje stanje. 36 | 37 | ### [Stiskanje commit-ov](squashing-commits.sl.md) 38 | Informacije o tem kako stisnite commite z interaktivnim rebase-om. 39 | > 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. 40 | 41 | ### [Razveljavljanje lokalnega commita](undoing-a-commit.sl.md) 42 | 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. 43 | > Sledi korakom, ko želiš razveljaviti lokalni commit. 44 | 45 | ### [Uporabne povezave](../git_workflow_scenarios/Useful-links-for-further-learning.md) 46 | 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. 47 | -------------------------------------------------------------------------------- /additional-material/translations/Greek/git_workflow_scenarios/creating-a-gitignore-file.gr.md: -------------------------------------------------------------------------------- 1 | # .gitignore 2 | 3 | Το αρχείο .gitignore είναι ένα αρχείο κειμένου που λέει στο Git ποια αρχεία ή φάκελοι πρέπει να αγνοούνται σε ένα έργο. 4 | 5 | Ένα τοπικό αρχείο .gitignore τοποθετείται συνήθως στον ριζικό φάκελο ενός έργου. Μπορείτε επίσης να δημιουργήσετε ένα παγκόσμιο .gitignore αρχείο και οποιεσδήποτε καταχωρίσεις σε αυτό το αρχείο θα αγνοούνται σε όλα τα αποθετήρια Git σας. 6 | 7 | ## Γιατί .gitignore 8 | Τώρα μπορείτε να αναρωτηθείτε γιατί θέλετε το git να αγνοήσει ορισμένα αρχεία και φακέλους. Αυτό συμβαίνει διότι δεν θέλετε αρχεία όπως αρχεία κατασκευής, αρχεία cache, άλλα τοπικά αρχεία διαμόρφωσης όπως τα node modules, αρχεία μεταγλώττισης, προσωρινά αρχεία που δημιουργούνται από IDE, κ.λπ. να παρακολουθούνται από το git. Συνήθως χρησιμοποιείται για να αποφύγετε την δέσμευση προσωρινών αρχείων από τον τρέχοντα κατάλογο εργασίας που δεν είναι χρήσιμα για άλλους συνεργάτες. 9 | 10 | ## Ξεκινώντας 11 | Για να δημιουργήσετε ένα τοπικό αρχείο .gitignore, δημιουργήστε ένα αρχείο κειμένου και ονομάστε το .gitignore (να θυμάστε να συμπεριλάβετε το . στην αρχή). Στη συνέχεια, επεξεργαστείτε αυτό το αρχείο όπως χρειάζεται. Κάθε νέα γραμμή πρέπει να αναφέρει ένα επιπλέον αρχείο ή φάκελο που θέλετε το Git να αγνοεί. 12 | 13 | Οι καταχωρίσεις σε αυτό το αρχείο μπορούν να ακολουθούν και μοτίβα αντιστοίχισης. 14 | 15 | ``` 16 | * χρησιμοποιείται ως παντοτινή αντιστοιχία 17 | / χρησιμοποιείται για να αγνοήσετε ονόματα διαδρομών σχετικά με το αρχείο .gitignore 18 | # χρησιμοποιείται για να προσθέσετε σχόλια σε ένα αρχείο .gitignore 19 | 20 | Αυτό είναι ένα παράδειγμα του πώς μπορεί να φαίνεται το αρχείο .gitignore: 21 | 22 | # Αγνόησε τα αρχεία συστήματος Mac 23 | .DS_store 24 | 25 | # Αγνόησε το φάκελο node_modules 26 | node_modules 27 | 28 | # Αγνόησε όλα τα αρχεία κειμένου 29 | 30 | 31 | *.txt 32 | 33 | # Αγνόησε αρχεία που σχετίζονται με κλειδιά API 34 | .env 35 | 36 | # Αγνόησε αρχεία ρυθμίσεων SASS 37 | .sass-cache 38 | 39 | ``` 40 | Για να προσθέσετε ή να αλλάξετε το παγκόσμιο αρχείο .gitignore, εκτελέστε την ακόλουθη εντολή: 41 | 42 | ``` 43 | git config --global core.excludesfile ~/.gitignore_global 44 | 45 | ``` 46 | Αυτό θα δημιουργήσει το αρχείο ~/.gitignore_global. Τώρα μπορείτε να επεξεργαστείτε αυτό το αρχείο με τον ίδιο τρόπο με ένα τοπικό αρχείο .gitignore. Όλα τα αποθετήριά σας Git θα αγνοήσουν τα αρχεία και τους φακέλους που αναφέρονται στο παγκόσμιο αρχείο .gitignore. 47 | 48 | ## Πώς να Απεξαρτήσετε Αρχεία που Είχατε Ήδη Δεσμεύσει με νέο .gitignore 49 | 50 | Για να απεξαρτήσετε ένα μεμονωμένο αρχείο, δηλαδή να σταματήσετε την παρακολούθηση του αρχείου αλλά να μην το διαγράψετε από το σύστημα, χρησιμοποιήστε: 51 | 52 | ``` 53 | git rm --cached filename 54 | ``` 55 | 56 | Για να απεξαρτήσετε όλα τα αρχεία στο .gitignore: 57 | 58 | Πρώτα, κάντε commit σε οποιεσδήποτε εκκρεμείς αλλαγές κώδικα και στη συνέχεια εκτελέστε: 59 | 60 | ``` 61 | git rm -r --cached 62 | ``` 63 | 64 | Αυτό αφαιρεί οποιαδήποτε αλλαγμένα αρχεία από τον δείκτη (staging area), στη συνέχεια εκτελέστε: 65 | 66 | ``` 67 | git add . 68 | ``` 69 | 70 | Κάντε commit: 71 | 72 | ``` 73 | git commit -m ".gitignore δουλεύει τώρα" 74 | ``` 75 | 76 | Για να αναιρέσετε ```git rm --cached filename```, χρησιμοποιήστε ```git add filename```. -------------------------------------------------------------------------------- /additional-material/translations/Nepali/configuring-git.np.md: -------------------------------------------------------------------------------- 1 | # Git वातावरण सेट अप गर्दै 2 | 3 | पहिलो पटक तपाईंले Git सँग कमिट गर्ने प्रयास गर्नुभयो, तपाईंले निम्न सन्देश देख्न सक्नुहुन्छ: 4 | 5 | ```bash 6 | $ git commit 7 | *** Please tell me who you are. 8 | 9 | Run 10 | 11 | git config --global user.email "you@example.com" 12 | git config --global user.name "Your Name" 13 | 14 | to set your account's default identity. 15 | config --global to set the identity only in this repository. 16 | ``` 17 | 18 | Git लाई कमिट सिर्जना गर्न को लागी तपाई को हुनुहुन्छ भनेर जान्न आवश्यक छ। जब तपाइँ धेरै व्यक्तिहरूसँग समूहमा काम गर्नुहुन्छ, तपाइँलाई सधैं थाहा हुनुपर्छ कि कसले परियोजनामा ​​​​कुन परिवर्तन गर्यो र उनीहरूले यो कहिले गरे। यस अन्तको लागि, Git सिर्जना गरिएको थियो ताकि कमिटहरू नाम र ईमेलमा बाँधिएका छन्। 19 | 20 | त्यहाँ 'git कमिट' आदेशमा तपाईंको नाम र इमेल प्रदान गर्ने धेरै तरिकाहरू छन्, र हामी ती मध्ये केहीलाई निम्न लाइनहरूमा जानेछौं। 21 | 22 | ### ग्लोबल कन्फिगरेसन 23 | 24 | जब हामीले ग्लोबल कन्फिगरेसन (ग्लोबल कन्फिगरेसन) मा केहि बचत गर्छौं, यो सेटिङ तपाईंले काम गर्ने सबै भण्डारहरूमा उपलब्ध हुन्छ। यो विधि सिफारिस गरिएको छ र अधिकतर अवस्थामा काम गर्दछ। 25 | 26 | ग्लोबल कन्फिगरेसनमा केहि बचत गर्न, 'config' आदेश प्रयोग गर्नुहोस्: 27 | 28 | `$ git config --global ` 29 | 30 | प्रयोगकर्ता डेटा को मामला मा: 31 | 32 | ``` 33 | $ git config --global user.email "you@example.com" 34 | $ git config --global user.name "Your Name" 35 | ``` 36 | 37 | ### भण्डार कन्फिगरेसन 38 | 39 | नामले नै हामीलाई बताउँछ, यी कन्फिगरेसनहरू केवल एउटा भण्डारमा सीमित छन्। यदि तपाइँ एक विशेष भण्डारमा प्रतिबद्ध गर्न चाहनुहुन्छ भने, तपाइँको कामको इ-मेलको साथ कार्य परियोजना भन्नुहोस्, त्यसपछि हामी यो विधि प्रयोग गर्दछौं। 40 | 41 | भण्डार कन्फिगरेसनमा केहि बचत गर्न, `config` आदेश प्रयोग गर्नुहोस् र `--global` झण्डा छोड्नुहोस्: 42 | 43 | 44 | `$ git config ` 45 | 46 | प्रयोगकर्ता डेटा को मामला मा: 47 | 48 | ``` 49 | $ git config user.email "you@alternate.com" 50 | $ git config user.name "Your Name" 51 | ``` 52 | 53 | ### कमाण्ड लाइन कन्फिगरेसन 54 | 55 | यी कन्फिगरेसनहरू हालको आदेश रेखामा मात्र सीमित छन्। सबै Git आदेशहरूले आदेश क्रियाको अगाडि `-c` उपसर्ग स्वीकार गर्दछ। यसले अस्थायी कन्फिगरेसन सिर्जना गर्दछ। 56 | 57 | आदेश रेखा कन्फिगरेसनमा केहि बचत गर्न: 58 | 59 | `$ git -c = -c = ` 60 | 61 | हाम्रो उदाहरणमा, हामी कमिट आदेशलाई यसरी प्रयोग गर्नेछौं: 62 | 63 | `git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"` 64 | 65 | ### फाइदाको बारेमा 66 | 67 | माथि उल्लिखित विधिहरू बीच प्रयोगको क्रम निम्नानुसार छ `command-line > repository > global`. यसको मतलब यदि चर कमाण्ड लाइन र ग्लोबलमा भण्डार गरिएको छ भने, कमाण्ड लाइन कन्फिगरेसनमा मान प्रयोग गरिनेछ। 68 | 69 | ## साथै 70 | 71 | अहिलेसम्म हामीले प्रयोगकर्ता सेटिङहरूमा मात्र काम गरेका छौं, तर त्यहाँ केही अन्य कन्फिगरेसनहरू छन्। ती मध्ये केही हुन्: 72 | 73 | 1. `core.editor` - टिप्पणी लेख्न प्रयोग गर्न पाठ सम्पादक निर्दिष्ट गर्न, आदि। 74 | 2. `commit.template` - प्रारम्भिक कमिट टेम्प्लेटको रूपमा प्रयोग गर्न प्रणालीमा फाइल निर्दिष्ट गर्न 75 | 3. `color.ui` - Git को आउटपुटमा रङहरू प्रयोग गर्न बुलियन मान निर्दिष्ट गर्न। 76 | 77 | हामीले सजिलै बुझ्नको लागि केही विवरणहरू सरलीकृत गरेका छौं। तपाईं मा थप पढ्न सक्नुहुन्छ [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration). 78 | -------------------------------------------------------------------------------- /additional-material/translations/Urdu/additional-material.ur.md: -------------------------------------------------------------------------------- 1 | # اضافی معلومات 2 | 3 | ہم سمجھتے ہیں کہ آپ یہاں آنے سے پہلے بنیادی سبق کے ساتھ پہلے ہی ختم ہو چکے ہیں. اضافی معلومات آپ کو اعلی درجے کی گیٹ کی تکنیک کے بارے میں کچھ معلومات دے گی. 4 | 5 | ### [ایک ارتکاب ترمیم] (amending-a-commit.md) 6 | یہ دستاویز دور دراز ذخیرہ پر ایک عہد میں ترمیم کے بارے میں معلومات فراہم کرتا ہے. 7 | > اس کا استعمال کریں جب آپ نے ایک عہد کو ایڈجسٹ کرنے کی ضرورت ہے. 8 | 9 | ### [Git ترتیب دیں] (configuring-git.md) 10 | یہ دستاویز صارف کی تفصیلات اور Git میں دیگر اختیارات کو ترتیب دینے کے بارے میں معلومات فراہم کرتا ہے. 11 | > اپنی گیٹ ترتیب کو بہتر بنانے کے لئے اس کا استعمال کریں. 12 | 13 | ### [آپ کانٹا مخزن کے ساتھ موافقت پذیر رکھنا] (keeping-your-fork-synced-with-this-repository.md) 14 | یہ دستاویزی معلومات فراہم کرتی ہے کہ بیس ذخیرہ کے ساتھ اپ ڈیٹ شدہ ذخیرہ رکھنے کی تاریخ کیسے برقرار رکھے گی. یہ ضروری ہے، امید ہے کہ آپ اور بہت سے دوسرے منصوبے میں حصہ لیں گے. 15 | > ان مرحلے پر عمل کریں اگر آپ کے والدین والدین کی ذخیرہ میں کوئی تبدیلی نہیں ہے. 16 | 17 | ### [چلتی ایک مختلف برانچ کا ارتکاب] (moving-a-commit-to-a-different-branch.md) 18 | یہ دستاویز کسی اور برانچ میں کمیٹی منتقل کرنے کے بارے میں معلومات فراہم کرتا ہے. 19 | > دوسری شاخ کو انجام دینے کے لۓ ان اقدامات کریں. 20 | 21 | ### [ایک فائل اتارنے] (removing-a-file.md) 22 | یہ دستاویز آپ کے مقامی ذخیرہ سے ایک فائل کو ہٹانے کے بارے میں معلومات فراہم کرتا ہے. 23 | > ایک وعدہ سے پہلے ایک فائل کو ہٹانے کے بارے میں سیکھنے کے لئے ان اقدامات پر عمل کریں 24 | 25 | ### [آپ مخزن سے شاخ ہٹا رہا ہے] (removing-branch-from-your-repository.md) 26 | یہ دستاویز آپ کے ذخیرہ سے ایک شاخ کو کیسے خارج کرنے کے بارے میں معلومات فراہم کرتا ہے. 27 | > آپ کے پل کی درخواست مل گئی ہے کے بعد صرف ان اقدامات کریں. 28 | 29 | ### [حل تنازعات کو ضم کریں] (resolving-merge-conflicts.md) 30 | یہ دستاویز مرگ تنازعات کو حل کرنے کے بارے میں معلومات فراہم کرتا ہے. 31 | > پریشانی مر تنازعات کو حل کرنے کے لئے ان اقدامات کریں. 32 | 33 | ### [ایک ارتکاب لوٹا رہا ہے] (reverting-a-commit.md) 34 | یہ دستاویز دور دراز ذخیرہ پر ایک عہد کو واپس کرنے کے بارے میں معلومات فراہم کرتا ہے. یہ کام میں آتا ہے اس صورت میں جب آپ کو کسی ایسے وعدے کو رد کرنے کی ضرورت ہوتی ہے جو پہلے ہی گیتوب کو منتقل کردی گئی ہے. 35 | > اگر آپ کسی وعدے کو ریورس کرنا چاہتے ہیں تو ان اقدامات کریں. 36 | 37 | ### [اسکواشنگ کمیٹیاں] (squashing-commits.md) 38 | یہ دستاویز ایک انٹرایکٹو بغاوت کے ساتھ کام کرتا ہے کس طرح اسکواش کس طرح کے بارے میں معلومات فراہم کرتا ہے. 39 | > اس کا استعمال کریں اگر آپ ایک کھلی منبع پراجیکٹ میں پی آر کھولنا چاہتے ہیں اور تجزیہ کار آپ کو ہر ایک کو ایک باضابطہ وعدہ پیغام کے ساتھ اسکواش کرنے سے پوچھتا ہے. 40 | 41 | ### [کالعدم کنڈ ایک مقامی ارتکاب] (undoing-a-commit.md) 42 | یہ دستاویز آپ کے مقامی ذخیرہ پر ایک وعدے کو کس طرح رد کرنے کے بارے میں معلومات فراہم کرتا ہے. جب آپ محسوس کرتے ہیں کہ آپ نے اپنے مقامی ذخیرہ کو مسلط کیا ہے اور مقامی ذخیرہ کو ری سیٹ کرنے کا ارادہ رکھتے ہیں تو یہ وہی ہے. 43 | > اگر یہ ایرر برقرار رہے تو ہمارے ہیلپ ڈیسک سے رابطہ کریں. غلط استعمال کی اطلاع دیتے ہوئے ایرر آ گیا ہے. 44 | 45 | ### [مفید روابط] (Useful-links-for-further-learning.md) 46 | یہ دستاویز تمام بلاگز خطوط، مددگار سائٹس، تجاویز اور چالوں کی ویب سائٹوں کے لئے وقف ہے جو ہماری جانوں کو آسان بنا دیتا ہے. کہ ہم اپنی تمام ضروریات کے لئے حوالہ دیتے ہیں، یہ ایک ابتدائی یا ایک ماہر بنیں. یہ صفحہ ان تمام مفید لنکس کی ایک انڈیکس کے طور پر کام کرنا چاہیے جو ہر فرد کو کھلے منبع ڈومین میں یا کسی کو مزید جاننے کے لئے مدد کرے گا. -------------------------------------------------------------------------------- /additional-material/translations/Slovenian/configuring-git.sl.md: -------------------------------------------------------------------------------- 1 | # Nastavljanje Git okolja 2 | 3 | Ko si prvič poskusil narediti commit z Git-om, je možno da se je prikazalo naslednje sporočilo: 4 | 5 | ```bash 6 | $ git commit 7 | *** Please tell me who you are. 8 | 9 | Run 10 | 11 | git config --global user.email "you@example.com" 12 | git config --global user.name "Your Name" 13 | 14 | to set your account's default identity. 15 | Omit --global to set the identity only in this repository. 16 | ``` 17 | 18 | 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. 19 | 20 | Obstaja več načinov kako ukazu `git commit` podati svoje ime in e-pošto in nekaj jih bomo pregledali v naslednjih vrsticah. 21 | 22 | ### Globalna konfiguracija 23 | 24 | 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. 25 | 26 | Da nekaj shranimo v globalno konfiguracijo, uporabimo ukaz `config`: 27 | 28 | `$ git config --global ` 29 | 30 | V primeru uporabniških podatkov: 31 | 32 | ``` 33 | $ git config --global user.email "you@example.com" 34 | $ git config --global user.name "Your Name" 35 | ``` 36 | 37 | ### Konfiguracija repository-ja 38 | 39 | 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. 40 | 41 | Da nekaj shranimo v konfiguracijo repository-ja, uporabimo ukaz `config` in spustimo zastavico `--global`: 42 | 43 | 44 | `$ git config ` 45 | 46 | V primeru uporabniških podatkov: 47 | 48 | ``` 49 | $ git config user.email "you@alternate.com" 50 | $ git config user.name "Your Name" 51 | ``` 52 | 53 | ### Konfiguracija ukazne vrstice 54 | 55 | Te konfiguracije so omejene samo na trenutno ukazno vrstico. Vsi Git ukazi sprejmejo predpono `-c` pred glagolom ukaza. S tem ustvarimo začasno konfiguracijo. 56 | 57 | Da nekaj shranimo v konfiguracijo ukazne vrstice: 58 | 59 | `$ git -c = -c = ` 60 | 61 | V našem primeru bi ukaz commit uporabili takole: 62 | 63 | `git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"` 64 | 65 | ### O prednosti 66 | 67 | 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. 68 | 69 | ## Dodatno 70 | 71 | Do sedaj smo delali samo z nastavitvami uporabnika, vendar obstaja še nekaj drugih konfiguracij. Nekatere med njimi so: 72 | 73 | 1. `core.editor` - za določitev urejevalnika besedila, ki se uporabi za pisanje komentarjev, itd. 74 | 2. `commit.template` - za določitev datoteke v sistemu, ki se uporabi kot začetna predloga za commit 75 | 3. `color.ui` - za določitev boolean vrednosti za uporabo barv v Git-ovem izpisu. 76 | 77 | 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). 78 | -------------------------------------------------------------------------------- /additional-material/translations/Marathi/additional-material.ma.md: -------------------------------------------------------------------------------- 1 | # अतिरिक्त माहिती 2 | 3 | येथे आपण असे गृहीत धरू की आपण आधीच मूलभूत सूचनांमध्ये प्रभुत्व मिळवले आहे. पूरक माहितीमध्ये GIT आदेशांबद्दल काही माहिती असते, जी अधिक जटिल परिस्थितींमध्ये आवश्यक असते. 4 | 5 | ### [कमिटमधील बदल](amending-a-commit.md) 6 | दस्तऐवजात रिमोट रिपॉझिटरीमध्ये कमिट कसे सुधारायचे याबद्दल माहिती आहे. 7 | > तुम्ही पूर्वी केलेली वचनबद्धता बदलायची असेल तेव्हा ते आवश्यक असते. 8 | 9 | ### [गिट कॉन्फिगर करणे](configuring-git.md) 10 | दस्तऐवजात वापरकर्ता माहिती आणि इतर GIT सेटिंग्ज कशी बदलायची याबद्दल माहिती आहे. 11 | > जीआयटी इन्स्टॉलेशन अधिक सोयीस्कर बनवायचे असल्यास ते उपयुक्त ठरेल. 12 | 13 | ### [तुमचा फोर्क मुख्य रेपॉजिटरीसह सिंक्रोनाइझ करणे](keeping-your-fork-synced-with-this-repository.md) 14 | दस्तऐवज मुख्य रेपॉजिटरीसह आपला काटा कसा समक्रमित ठेवायचा याबद्दल बोलतो. सिंक्रोनाइझेशन आवश्यक आहे कारण, आशा आहे की, तुम्ही एकट्या प्रकल्पावर काम करणार नाही, तर इतर योगदानकर्त्यांसह त्यात बदल कराल. 15 | > तुमच्या शाखेत रिपॉझिटरीच्या मास्टर शाखेत कोणतेही बदल नसल्यास या चरणांचे अनुसरण करा. 16 | 17 | ### [कमिट दुसऱ्या शाखेत हलवणे](moving-a-commit-to-a-different-branch.md) 18 | दस्तऐवजात कमिट दुसर्‍या शाखेत कसे हलवायचे याबद्दल माहिती आहे. 19 | > कमिट दुसर्‍या शाखेत हलवण्यासाठी दिलेल्या स्टेप्स फॉलो करा. 20 | 21 | ### [फाइल काढून टाकत आहे](removing-a-file.md) 22 | दस्तऐवज तुमच्या स्थानिक भांडारातून फाइल कशी काढायची याचे वर्णन करते. 23 | > कमिट करण्यापूर्वी फाइल कशी काढायची हे समजून घेण्यासाठी या कमांडचे पुनरावलोकन करा. 24 | 25 | ### [तुमच्या भांडारातून शाखा काढून टाकत आहे](removing-branch-from-your-repository.md) 26 | दस्तऐवजात तुमच्या भांडारातून शाखा कशी काढायची याबद्दल माहिती आहे. 27 | > तुमची पुल विनंती मंजूर झाल्यानंतरच या कमांड्स वापरा. 28 | 29 | ### [शाखा विलीन करताना संघर्ष सोडवणे](resolving-merge-conflicts.md) 30 | दस्तऐवजात शाखांचे विलीनीकरण करताना उद्भवणारे संघर्ष कसे सोडवायचे याबद्दल माहिती आहे. 31 | > येथे सुचविलेल्या पायर्‍या शाखांचे विलीनीकरण करताना उद्भवणाऱ्या संघर्षाच्या किरकोळ प्रकरणांना सामोरे जाण्यास मदत करतील. 32 | 33 | ### [कमिट परत करणे](reverting-a-commit.md) 34 | दस्तऐवज रिमोट रिपॉजिटरीमध्ये कमिट कसे पूर्ववत करायचे याचे निर्देश देते. असे ऑपरेशन अशा प्रकरणांमध्ये उपयुक्त ठरेल जेव्हा तुम्हाला गिथबवर आधीच ढकललेले कमिट प्ले बॅक करावे लागेल. 35 | > कमिट पूर्ववत करण्यासाठी येथे चरणांचे अनुसरण करा. 36 | 37 | ### [स्क्वॅशिंग कमिट (स्क्वॅशिंग)](squashing-commits.md) 38 | दस्तऐवज परस्परसंवादी रीबेसेस वापरून कमिट कसे एकत्र करायचे याचे वर्णन करते. 39 | > तुम्ही ओपन सोर्स प्रोजेक्टवर पुल रिक्वेस्ट तयार केली असल्यास या सूचना वापरा, परंतु प्रोजेक्ट एक्सपर्ट तुम्हाला तुमच्या सर्व कमिट एका अर्थपूर्ण टिप्पणीसह एकत्र करण्यास सांगतात. 40 | 41 | ### [स्थानिक कमिट पूर्ववत करणे](undoing-a-commit.md) 42 | दस्तऐवज तुम्हाला तुमच्या स्थानिक रेपॉजिटरीमध्ये कमिट कसे परत करायचे याची माहिती देतो. जर तुम्ही ठरवले की तुम्ही तुमच्या भांडारात गडबड केली आहे आणि त्यातील मजकूर त्यांच्या मूळ स्थितीत पुनर्संचयित करू इच्छित असाल तर तुम्हाला या माहितीची आवश्यकता असेल. 43 | > तुम्हाला शेवटच्या स्थानिक कमिटने केलेले बदल पूर्ववत करायचे असल्यास या सूचनांचे अनुसरण करा. 44 | 45 | ### [उपयोगी दुवे](उपयोगी-लिंक-फॉर-further-learning.md) 46 | या फाइलमध्ये ब्लॉग पोस्ट्स, उपयुक्त वेबसाइट्स, वेबसाइट्सची सूची असलेल्या टिप्स आणि युक्त्या आहेत ज्या अनेकदा आमचे जीवन सुलभ करतात. नवशिक्यांसाठी आणि तज्ञांसाठी, आवश्यकतेनुसार आम्ही त्यांच्याशी संपर्क साधण्याची शिफारस करतो. या फाइलमध्ये उपयुक्त लिंक्सची सूची आहे जी ओपन सोर्समध्ये पहिले पाऊल टाकणाऱ्यांना आणि या क्षेत्रातील त्यांचे ज्ञान वाढवू इच्छिणाऱ्यांना नक्कीच मदत करेल. -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/configuring-git.md: -------------------------------------------------------------------------------- 1 | # Configuring git 2 | 3 | The first time you tried to commit using git, you might have gotten a prompt like the one below: 4 | 5 | ```bash 6 | $ git commit 7 | *** Please tell me who you are. 8 | 9 | Run 10 | 11 | git config --global user.email "you@example.com" 12 | git config --global user.name "Your Name" 13 | 14 | to set your account's default identity. 15 | Omit --global to set the identity only in this repository. 16 | ``` 17 | 18 | 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. 19 | 20 | There are multiple ways to provide the `git commit` command with your email and name, and we'll go through some of them below. 21 | 22 | ### Global Config 23 | 24 | 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. 25 | 26 | To store something in the global config, you use the `config` command as follows: 27 | 28 | `$ git config --global ` 29 | 30 | In the case of user details, we run it as follows: 31 | 32 | ``` 33 | $ git config --global user.email "you@example.com" 34 | $ git config --global user.name "Your Name" 35 | ``` 36 | 37 | ### Repository Config 38 | 39 | 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. 40 | 41 | To store something in the repository config, you use the `config` command by omitting the `--global` flag as follows: 42 | 43 | `$ git config ` 44 | 45 | In the case of user details, we run it as follows: 46 | 47 | ``` 48 | $ git config user.email "you@alternate.com" 49 | $ git config user.name "Your Name" 50 | ``` 51 | 52 | ### Command-line Config 53 | 54 | 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. 55 | 56 | To store something in the command line config, run your command as follows: 57 | 58 | `$ git -c = -c = ` 59 | 60 | In our example, we would run the commit command as follows: 61 | 62 | `git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"` 63 | 64 | ### Note on Precedence 65 | 66 | 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. 67 | 68 | ## Beyond User Details 69 | 70 | 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: 71 | 72 | 1. `core.editor` - to specify the name of the editor used for writing commit messages, etc. 73 | 2. `commit.template` - to specify a file on the system as the initial commit template. 74 | 3. `color.ui` - to specify a boolean value for using colors in git's output. 75 | 76 | 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). 77 | -------------------------------------------------------------------------------- /additional-material/translations/Slovenian/squashing-commits.sl.md: -------------------------------------------------------------------------------- 1 | # Kaj je stiskanje? 2 | 3 | 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. 4 | 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. 5 | 6 | # Kako stisneš commit-e? 7 | 8 | Najprej uporabimo ukaz `git log` da lahko pregledamp commit-e v svoji veji, ki bi jih rad združili ( merge ). 9 | 10 | ``` 11 | git log 12 | ``` 13 | 14 | Videti bi morali serijo commit-ov, kot na primer: 15 | 16 | ``` 17 | commit blablabla 18 | Author: omguhh 19 | Date: 10/10/20 20 | Commit message 1 21 | 22 | commit blablabla2 23 | Author: omguhh 24 | Date: 10/10/20 25 | Commit message 2 26 | ``` 27 | 28 | 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: 29 | 30 | ``` 31 | git rebase -i 32 | ``` 33 | 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: 34 | 35 | ``` 36 | git rebase -i HEAD~2 37 | ``` 38 | 39 | Ko uporabimo ta ukaz, se nam bo prikazalo nekaj podobnega tem vrsticam: 40 | 41 | ``` 42 | pick blablabla Changing test01.txt file 43 | pick blablabla2 Adding dummy01.txt file 44 | 45 | # 46 | # Commands: 47 | # p, pick = use commit 48 | # r, reword = use commit, but edit the commit message 49 | # e, edit = use commit, but stop for amending 50 | # s, squash = use commit, but meld into previous commit 51 | # f, fixup = like "squash", but discard this commit's log message 52 | # x, exec = run command (the rest of the line) using shell 53 | # 54 | # These lines can be re-ordered; they are executed from top to bottom. 55 | # 56 | # If you remove a line here THAT COMMIT WILL BE LOST. 57 | # 58 | # However, if you remove everything, the rebase will be aborted. 59 | # 60 | # Note that empty commits are commented out 61 | ``` 62 | 63 | Ukazi navedeni v zgornjem sporočilu: 64 | - p, pick = uporabi commit 65 | - r, reword = uporabi commit, vendar uredi komentar 66 | - e, edit = uporabi commit, vendar se ustavi za spremembo 67 | - s, squash = uporabi commit, vendar ga stisni v prejšnji commit 68 | - f, fixup = enak kot "squash", vendar zavrzi komentar tega commit-a 69 | - x, exec = zaženi ukaz ( preostanek vrstice ) v shell-u 70 | 71 | To pomeni da, če želimo stisniti ```blablabla2``` v ```blablablabla```, bi zgornje sporočilo spremenili tako: 72 | 73 | ``` 74 | pick blablabla Changing test01.txt file 75 | squash blablabla2 Adding dummy01.txt file 76 | 77 | ``` 78 | 79 | Če gre vse po planu, dobimo rezultat, ki zgleda takole: 80 | 81 | ``` 82 | # This is a combination of 2 commits. 83 | # The first commit's message is: 84 | commit message 1 85 | 86 | # This is the 2nd commit message: 87 | 88 | commit message 2 89 | ``` 90 | 91 | To sporočilo lahko po želji spremenimo preden zapremo urejevalnik besedila, kar shrani spremembe. 92 | 93 | Č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. 94 | 95 | -------------------------------------------------------------------------------- /additional-material/git_workflow_scenarios/amending-a-commit.md: -------------------------------------------------------------------------------- 1 | # Amending a Commit 2 | 3 | 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. 4 | How do you edit that? This is what this tutorial covers. 5 | 6 | ## Changing a recent commit message after you have pushed to Github. 7 | To do this without opening a file: 8 | * Type in the ```git commit --amend -m "followed by your new commit message"``` 9 | * Run ```git push origin ``` to commit the changes to the repository. 10 | 11 | Note: If you type in just ```git commit --amend```, your text editor would open up prompting you to edit the commit message. 12 | Adding the ``-m`` flags prevents it. 13 | 14 | ## Modifying on a single commit 15 | 16 | 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? 17 | 18 | To illustrate here is a log of my commits: 19 | ``` 20 | g56123f create file bot file 21 | a2235d updated contributor.md 22 | a5da0d modified bot file 23 | ``` 24 | Let's say I forgot to add a single word to the bot file 25 | 26 | There are 2 ways to go about this. The first is to have an entirely new commit that contains the change like so: 27 | ``` 28 | g56123f create file botfile 29 | a2235d updated contributor.md 30 | a5da0d modified botfile 31 | b0ca8f added single word to botfile 32 | ``` 33 | The second way is to amend the a5da0d commit, add this new word and push it to Github as one commit. 34 | The second sounds better since it is just a minor change. 35 | 36 | To achieve this, we would do the following: 37 | * Modify the file. In this case, I will modify the botfile to include the word I omitted previously. 38 | * Next, add the file to the staging area with ```git add ``` 39 | 40 | Usually after adding files to the staging area, the next thing we do is git commit -m "our commit message" right? 41 | But since what we want to achieve here is to amend the previous commit, we would instead run: 42 | 43 | * ```git commit --amend``` 44 | 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. 45 | * Exit the editor 46 | * Push your changes with ```git push origin ``` 47 | 48 | That way, both changes would be in one single commit. 49 | 50 | ## Modifying commits on remote 51 | 52 | If the commit that you like to amend has been already pushed to the remote, amending this commit will lead to your local history being diverged from the remote (since you basically create a new commit and replace the amended one). Since you want to change the commit on the remote, you need to overwrite the remotes history on your branch. To achieve that, follow the same procedure as described above, but use force push when pushing your commit to the remote. 53 | 54 | > **Warning** 55 | > Force pushing to the remote will overwrite (and discard) changes on the remote and only keep your pushed commits. Changes on the remote, that other team members did in the meantime, will be overwritten as well. 56 | 57 | This is how you modify the last recent commit on the remote: 58 | 59 | ```bash 60 | git add 61 | git commit --amend -m "followed by your new commit message" 62 | git push --force 63 | ``` 64 | 65 | > Using `--force-with-lease` is a safer option instead of `--force` which avoids overwriting other people's changes on the remote branch (if you do not intend to do so). 66 | -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/Useful-links-for-further-learning.by.md: -------------------------------------------------------------------------------- 1 | # Карысныя спасылкі 2 | 3 | Гэты дакумент прысвечаны ўсіх сайтаў з парадамі і рэкамендацыямі, паведамленнях у блогах і карысным сайтам, якія палягчаюць наша жыццё. Яны з'яўляюцца выдатным арыенцірам для задавальнення ўсіх нашых патрэбаў, няхай гэта будзе пачатковец або эксперт. Гэтая старонка павінна служыць індэксам ўсіх тых карысных спасылак, якія дапамогуць усім, хто пачатковец у вобласці адкрытага зыходнага кода, ці каму-небудзь, хто хоча даведацца больш. 4 | 5 | ## Спіс 6 | 1. [Interactive tutorial to git](https://try.github.io) 7 | 2. [git - the simple guide](http://rogerdudler.github.io/git-guide/) 8 | 3. [On undoing, fixing, or removing commits in git](http://sethrobertson.github.io/GitFixUm/fixup.html) 9 | 4. [Git and GitHub tutorial translated to many languages](https://github.com/Roshanjossey/first-contributions) 10 | 5. [Merge Conflicts](https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/merge-conflicts) 11 | 6. [Resolving Merge Conflicts](https://githowto.com/resolving_conflicts) 12 | 7. [Basics of Git - The Simple Quick Start Guide](https://blog.praveen.science/basics-of-git-the-quick-start-guide/) 13 | 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/) 14 | 9. [Git Shortcuts](https://blog.praveen.science/git-shortcuts/) 15 | 10. [Official Git cheat sheet in many languages](https://services.github.com/on-demand/resources/cheatsheets) 16 | 11. [Git cheat sheet from Tower](https://www.git-tower.com/learn/cheat-sheets/git) 17 | 12. [Common Git Problems](https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd) 18 | 13. [Git Rebase](https://blog.gitprime.com/git-rebase-an-illustrated-guide/) 19 | 14. [Beginner's Guide to Rebasing and Squashing](https://github.com/servo/servo/wiki/Beginner%27s-guide-to-rebasing-and-squashing) 20 | 15. [Git Cheatsheet that shows correlations between commands and files](http://ndpsoftware.com/git-cheatsheet.html) 21 | 16. [How to contribute](https://opensource.guide/how-to-contribute/) 22 | 17. [Getting started with Open Source](https://github.com/OpenSourceHelpCommunity/Getting-Started-With-Contributing-to-Open-Sources) 23 | 18. [How to contribute](https://github.com/freeCodeCamp/how-to-contribute-to-open-source) 24 | 19. [Atlassians Git Tutorials](https://www.atlassian.com/git) 25 | 20. [Pull request reviews](https://help.github.com/articles/about-pull-request-reviews/) 26 | 21. [Another Interactive tutorial for git](https://learngitbranching.js.org/) 27 | 22. [Git commandline cheat-sheet](https://gist.github.com/davfre/8313299) 28 | 23. [Programming Books](https://github.com/EbookFoundation/free-programming-books) 29 | 24. [E-Book of professional tip and secrets](https://goalkicker.com/GitBook/GitProfessionalTipsSecrets.pdf) 30 | 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) 31 | 26. [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) 32 | 27. [5 Useful Tips For A Better Commit Message](https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message) 33 | 28. [Version Control using Git](https://ourcodingclub.github.io/2017/02/27/git.html) 34 | 29. [Version Control with Git](https://www.udacity.com/course/version-control-with-git--ud123) 35 | 36 | Працягвайце дадаваць больш спасылак, якія вам падаюцца карыснымі. 37 | -------------------------------------------------------------------------------- /additional-material/translations/Hindi/Amending a Commit: -------------------------------------------------------------------------------- 1 | # Amending a Commit 2 | 3 | आपके दूरस्थ संग्रहालय में एक परिवर्तन करते हैं, फिर बाद में पता चलता है कि आपके कमिट संदेश में त्रुटि है या आपने अपने सबसे हाल के कमिट में एक पंक्ति जोड़ना भूल दी है। 4 | आप ऐसा कैसे संपादित करेंगे? इस पर यह ट्यूटोरियल विस्तार से बताता है। 5 | 6 | ##Github पर अपलोड करने के बाद हाल के कमिट संदेश को संशोधित करना। 7 | इसे फ़ाइल खोले बिना करने के लिए: 8 | * निम्नलिखित कमांड का उपयोग करें ```git commit --amend -m "followed by your new commit message"``` 9 | * चलाना ```git push origin ``` संग्रहालय में परिवर्तन को कमिट (commit) करने के लिए क्या होगा। 10 | 11 | नोट: यदि आप केवल ```git commit --amend```टाइप करते हैं, तो आपका पाठ संपादित करने के लिए आपके पाठ संपादक खुलेगा। ``-m`` फ़्लैग जोड़ने से इसे रोका जा सकता है। 12 | 13 | ## एक सिंगल कमिट पर संशोधन करना 14 | 15 | तो, यदि हम एक फ़ाइल में एक छोटे से बदलाव को करना भूल जाते हैं, जैसे एक शब्द को बदलना, और हमने पहले से ही उस कमिट को हमारे रिमोट रिपॉजिटरी में पुश कर दिया है? 16 | 17 | इसे व्यक्त करने के लिए यहां मेरे कमिट की एक लॉग है: 18 | ``` 19 | g56123f create file bot file 20 | a2235d updated contributor.md 21 | a5da0d modified bot file 22 | ``` 23 | चलिए मान लें कि मुझसे एक शब्द बदलने को भूल गया हूँ बॉट फ़ाइल में 24 | 25 | इसके लिए दो तरीके हैं। पहला है कि इसमें परिवर्तन को शामिल करने वाला एक नया कमिट हो, जैसे: 26 | ``` 27 | g56123f create file botfile 28 | a2235d updated contributor.md 29 | a5da0d modified botfile 30 | b0ca8f added single word to botfile 31 | ``` 32 | दूसरा तरीका है a5da0d कमिट को संशोधित करना, इस नए शब्द को जोड़ना और इसे एक कमिट के रूप में गिटहब पर पुश करना। दूसरा तरीका बेहतर लगता है क्योंकि यह केवल एक छोटे से बदलाव है। 33 | 34 | इसे प्राप्त करने के लिए, हम निम्नलिखित करेंगे: 35 | 36 | * फ़ाइल में संशोधन करें। इस मामले में, मैं बॉट फ़ाइल को संशोधित करके पिछले समय छूट गया शब्द शामिल करूंगा। 37 | * आगे बढ़ें, git add के साथ फ़ाइल को स्टेजिंग क्षेत्र में जोड़ें| 38 | 39 | आम तौर पर स्टेजिंग क्षेत्र में फ़ाइलें जोड़ने के बाद, अगला काम होता है git commit -m "हमारा कमिट संदेश" सही? 40 | लेकिन क्योंकि हम यहां पिछले कमिट को संशोधित करना चाहते हैं, इसलिए हम इसके बजाय निम्नलिखित कमांड चलाएंगे: 41 | 42 | * ```git commit --amend``` 43 | इससे पाठ संपादक खुलेगा और आपको संदेश संपादित करने के लिए कहेगा। आप पिछले जैसा संदेश छोड़ सकते हैं या इसे बदल सकते हैं। 44 | * संपादक(Editor) से बाहर निकलें 45 | * git push origin के साथ अपने बदलावों को पुश करें 46 | 47 | इस तरह, दोनों बदलावों को एक ही सिंगल कमिट में रखा जाएगा। 48 | 49 | ## रिमोट पर कमिट संशोधित करना 50 | 51 | यदि वह कमिट जिसे आप संशोधित करना चाहते हैं पहले से ही रिमोट पर पुश किया गया है, तो इसे संशोधित करने से आपका स्थानीय इतिहास रिमोट से अलग हो जाएगा (क्योंकि आप तदनुसार एक नया कमिट बनाते हैं और संशोधित कमिट को बदल देते हैं)। रिमोट पर कमिट को बदलने के लिए, अपनी शाखा पर रिमोट का इतिहास अधिलेखित करने की आवश्यकता होगी। इसे प्राप्त करने के लिए, ऊपर वर्णित प्रक्रिया का पालन करें, लेकिन जब आप अपनी कमिट को रिमोट पर पुश करें तो फ़ोर्स पुश का उपयोग करें। 52 | 53 | 54 | > **Warning** 55 | > फ़ोर्स पुश करने से रिमोट परिवर्तन (और उसे छोड़ देने) को अधिलेखित कर देगा और केवल आपके पुश किए गए कमिट रखेगा। रिमोट पर, टीम के अन्य सदस्यों द्वारा उस बीच में किए गए बदलावों को भी अधिलेखित कर देगा। 56 | 57 | इस तरह आप रिमोट परिवर्तन को संशोधित करते हैं: 58 | 59 | ```bash 60 | git add <आपकी बदली हुई फ़ाइलें> 61 | git commit --amend -m "आपका नया कमिट संदेश के बाद" 62 | git push --force 63 | ``` 64 | 65 | >उपयोग करने के लिए `--force` के बजाय `--force-with-lease` सुरक्षित विकल्प है जो रिमोट शाखा पर दूसरे लोगों के बदलावों को अधिलेखित करने से बचाता है (यदि ऐसा आपकी इच्छा नहीं है)। 66 | 67 | 68 | श्री-कृष्ण-वी द्वारा अनुवादित 69 | -------------------------------------------------------------------------------- /additional-material/translations/Portugues/additional-material.pt_br.md: -------------------------------------------------------------------------------- 1 | # Informações Adicionais 2 | 3 | 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. 4 | 5 | ### [Emendando um commit](../git_workflow_scenarios/amending-a-commit.md) 6 | Esse documento provê informações sobre como emendar um commit no repositório remoto. 7 | > Use isso quando você precisar ajustar um commit que você tenha feito. 8 | 9 | ### [Configurando o git](../git_workflow_scenarios/configuring-git.md) 10 | Esse documento provê informações sobre como configurar detalhes de usuário e outras opções do git. 11 | > Use isso para melhor controlar as suas configurações do git. 12 | 13 | ### [Mantendo o seu fork em sincronia com o repositório](../git_workflow_scenarios/keeping-your-fork-synced-with-this-repository.md) 14 | 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. 15 | > Siga esses passos se o seu fork não possui as mesmas alterações do repositório pai. 16 | 17 | ### [Movendo um Commit para um Branch diferente](../git_workflow_scenarios/moving-a-commit-to-a-different-branch.md) 18 | Esse documento provê informações sobre como mover um Commit para outro Branch. 19 | > Siga esses passos para mover um commit para outro branch. 20 | 21 | ### [Removendo um arquivo](../git_workflow_scenarios/removing-a-file.md) 22 | Esse documento provê informações sobre como remover um arquivo do seu repositório local. 23 | > Siga esses passos para aprender como remover um arquivo do seu repositório local. 24 | 25 | ### [Removendo um Branch do seu repositório](../git_workflow_scenarios/removing-branch-from-your-repository.md) 26 | Esse documento provê informações sobre como deletar um Branch do seu repositório. 27 | > Apenas siga esses passos após o seu pull request ter sido mesclado. 28 | 29 | ### [Resolvendo conflitos de Merge](../git_workflow_scenarios/resolving-merge-conflicts.md) 30 | Esse documento provê informações sobre como resolver conflitos de Merge. 31 | > Siga esses passos para resolver conflitos de Merge irritantes. 32 | 33 | ### [Revertendo um commit](../git_workflow_scenarios/reverting-a-commit.md) 34 | 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. 35 | > Siga esses passos se você quiser reverter um commit. 36 | 37 | ### [Comprimir Commits juntos](../git_workflow_scenarios/squashing-commits.md) 38 | Esse documento provê informações sobre como esmagar commits juntos em um só realizando um rebase. 39 | > 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. 40 | 41 | ### [Desfazendo um commit local](../git_workflow_scenarios/undoing-a-commit.md) 42 | Esse documento provê informações sobre como desfazer um commit no seu repositório local. Isso é o que você precisa fazer quando sente que fez alguma besteira no seu repositório e deseja desfazer. 43 | > Take these steps if you want to undo/reset a local commit. 44 | 45 | ### [Links úteis](../git_workflow_scenarios/Useful-links-for-further-learning.md) 46 | Esse documento é dedicado a todos os blogs, 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. 47 | -------------------------------------------------------------------------------- /additional-material/translations/Portugues/confinguring-git.pt-br.md: -------------------------------------------------------------------------------- 1 | # Configurando GIT 2 | 3 | A primeira vez que você tentar fazer um commit usando git, deve ter recebido uma como esta: 4 | 5 | ```bash 6 | $ git commit 7 | *** Please tell me who you are. 8 | 9 | Rode: 10 | 11 | git config --global user.email "you@example.com" 12 | git config --global user.name "Your Name" 13 | 14 | Para definir a identidade padrão da sua conta. 15 | Omita “--global” para definir a identidade apenas nesse repositório 16 | ``` 17 | 18 | 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. 19 | 20 | Existem várias maneiras de fornecer o comando `git commit` com seu email e nome. Veremos algumas delas a seguir. 21 | 22 | 23 | ### Configuração global 24 | 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. 25 | 26 | Para armazenar algo na configuração use o comando `config` da seguinte maneira: 27 | 28 | `$ git config --global ` 29 | 30 | No caso dos detalhes do usuário, nós os executamos da seguinte maneira: 31 | 32 | ``` 33 | $ git config --global user.email "you@example.com" 34 | $ git config --global user.name "Your Name" 35 | ``` 36 | 37 | ### Configuração do repositório 38 | 39 | 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. 40 | 41 | Para armazenar algo na configuração do repositório, você usa o comando `config` omitindo a sinalização `--global`, da seguinte forma: 42 | 43 | `$ git config ` 44 | 45 | No caso dos detalhes do usuário, nós o executamos da seguinte maneira: 46 | 47 | ``` 48 | $ git config user.email "you@alternate.com" 49 | $ git config user.name "Your Name" 50 | ``` 51 | 52 | ### Configuração da linha de comando 53 | 54 | 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 55 | 56 | Para armazenar algo na configuração da linha de comando. Execute seu comando da seguinte maneira: 57 | 58 | `$ git -c = -c = ` 59 | 60 | No exemplo citado, executaríamos o comando commit da seguinte forma: 61 | 62 | `git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"` 63 | 64 | ### Nota sobre precedência 65 | 66 | 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. 67 | 68 | ## Além dos detalhes do usuário: 69 | 70 | 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: 71 | 72 | 1. `core.editor` - para especificar o nome do editor usado para escrever mensagens de commit etc 73 | 2. `commit.template` - para especificar um arquivo no sistema como o modelo de commit inicial 74 | 3. `color.ui` - para especificar um valor booleano para usar cores na saída do git 75 | 76 | Nós abstraimos alguns detalhes para facilitar o entendimento. Para ler mais, acesse: 77 | 78 | [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration). -------------------------------------------------------------------------------- /additional-material/translations/Nepali/additional-material.np.md: -------------------------------------------------------------------------------- 1 | # थप जानकारी 2 | हामी मान्दछौं कि तपाईंले यहाँ जानु अघि आधारभूत ट्यूटोरियल पढिसक्नुभएको छ। यो कागजातले तपाईंलाई Git प्रविधिहरूमा थप जानकारी दिनेछ उन्नत । 3 | 4 | ### [प्रतिबद्धता सम्पादन गर्नुहोस्](amending-a-commit.np.md) 5 | यो पृष्ठले तपाईंलाई रिमोट डाइरेक्टरीमा कमिट परिमार्जन गर्न आवश्यक जानकारी दिनेछ: 6 | > तपाईंले गर्नुभएको प्रतिबद्धता ठीक गर्न यो प्रयोग गर्नुहोस्। 7 | 8 | ### [git कन्फिगर गर्नुहोस्](configuring-git.np.md) 9 | यो पृष्ठले तपाइँलाई तपाइँको प्रयोगकर्ता विवरणहरू र git मा अन्य विकल्पहरू कन्फिगर गर्न आवश्यक जानकारी दिनेछ: 10 | > तपाईंको git कन्फिगरेसनको राम्रो नियन्त्रणको लागि प्रयोग गर्नुहोस्। 11 | 12 | ### [डाइरेक्टरी संग सिंक मा आफ्नो फोर्क राख्नुहोस्](keeping-your-fork-synced-with-this-repository.np.md) 13 | यो कागजातले तपाईंलाई स्रोत डाइरेक्टरीसँग "फोर्क" डाइरेक्टरीलाई अद्यावधिक राख्नको लागि जानकारी दिन्छ। यो महत्त्वपूर्ण छ र हामी आशा गर्छौं कि तपाईं र अरू धेरैले यस परियोजनामा ​​योगदान गर्नुहुनेछ। 14 | > यदि तपाईंले अभिभावक डाइरेक्टरीमा आफ्नो शाखामा कुनै परिवर्तनहरू देख्नुभएन भने यी चरणहरू पालना गर्नुहोस्। 15 | 16 | ### [एउटा कमिटलाई फरक शाखामा सार्नुहोस्](moving-a-commit-to-a-different-branch.np.md) 17 | यो पृष्ठले तपाईंलाई फरक शाखामा प्रतिबद्धता सार्न आवश्यक जानकारी दिनेछ: 18 | > कमिटलाई फरक खुट्टामा सार्न यी चरणहरू पालना गर्नुहोस्। 19 | 20 | ### [फाइल मेटाउनुहोस्](removing-a-file.np.md) 21 | यो पृष्ठले तपाईंलाई आफ्नो स्थानीय डाइरेक्टरीबाट फाइल मेटाउन आवश्यक जानकारी दिनेछ: 22 | > कमिट गर्नु अघि फाइल कसरी मेटाउने भनेर सिक्नको लागि यी चरणहरू पालना गर्नुहोस्। 23 | 24 | ### [तपाईंको डाइरेक्टरीमा एउटा शाखा मेटाउनुहोस्](removing-branch-from-your-repository.np.md) 25 | यस पृष्ठले तपाइँलाई तपाइँको निर्देशिकाबाट शाखा मेटाउन आवश्यक जानकारी दिनेछ: 26 | > तपाईंको पुल अनुरोध मर्ज भएपछि मात्र यी चरणहरू पालना गर्नुहोस्। 27 | 28 | ### [मर्ज विवादहरू समाधान गर्नुहोस्](resolving-merge-conflicts.np.md) 29 | यो पृष्ठले तपाईंलाई मर्ज मुद्दाहरूको समस्या निवारण गर्न आवश्यक जानकारी दिनेछ: 30 | > यी (प्रायः कष्टप्रद) मिश्रण समस्याहरू समाधान गर्न यी चरणहरू पालना गर्नुहोस्। 31 | 32 | ### [प्रतिबद्धतामा फर्कनुहोस्](reverting-a-commit.np.md) 33 | यदि तपाइँ रिमोट डाइरेक्टरीमा अघिल्लो कमिटमा फर्कन आवश्यक छ भने यो पृष्ठले तपाइँलाई मद्दत गर्नेछ। तपाईले पहिले नै Github मा धकेल्नु भएको कमिटलाई अन्डू गर्न आवश्यक छ भने यो उपयोगी छ। 34 | > यदि तपाइँ कमिट उल्टाउन चाहनुहुन्छ भने यी चरणहरू पालना गर्नुहोस्। 35 | 36 | ### [सपाट कमिटहरू](squashing-commits.np.md) 37 | यस पृष्ठले तपाइँलाई सिकाउनेछ कि कसरी एकमा धेरै कमिटहरू समतल गर्ने। 38 | > यदि तपाइँ पुल अनुरोध खोल्न चाहनुहुन्छ भने प्रयोग गर्नुहोस् र समीक्षकले तपाइँलाई समग्र जानकारी सन्देश सहित सबै कमिटहरूलाई "फ्लैट" गर्न सोध्छन्। 39 | 40 | ### [उपयोगी लिङ्कहरू](undoing-a-commit.np.md) 41 | यो पृष्ठले तपाइँलाई तपाइँको स्थानीय डाइरेक्टरीमा कमिट अनडू गर्न आवश्यक जानकारी दिन्छ। यदि तपाईंले आफ्नो स्थानीय डाइरेक्टरीमा गल्ती गरेको महसुस गर्नुभयो र अघिल्लो अवस्थामा फर्कन चाहनुहुन्छ भने तपाईंले यो गर्न आवश्यक छ। 42 | > यदि तपाइँ स्थानीय कमिटमा पूर्वस्थितिमा पूर्ववत/उल्टाउन चाहनुहुन्छ भने यी निर्देशनहरू पालना गर्नुहोस्। 43 | 44 | ### [उपयोगी लिङ्कहरू](Useful-links-for-further-learning.np.md) 45 | यो पृष्ठ सबै टिप्स र ट्रिक्स साइटहरू, ब्लगहरू, र सामान्य साइटहरूमा समर्पित छ जसले हामीलाई हाम्रो जीवन सजिलो बनाउन मद्दत गर्दछ। तिनीहरू तपाइँका सबै आवश्यकताहरू पूरा गर्न उत्कृष्ट सन्दर्भहरू हुन्, चाहे तपाइँ शुरुवात वा विशेषज्ञ हुनुहुन्छ। यो पृष्ठ ती सबै उपयोगी लिङ्कहरूको अनुक्रमणिका हुनुपर्छ जसले खुला स्रोतमा नयाँ भएका वा आफ्नो ज्ञानलाई अझ गहिरो बनाउन चाहने जो कोहीलाई मद्दत गर्नेछ। 46 | 47 | ### [एउटा .gitignore फाइल सिर्जना गर्नुहोस्](creating-a-gitignore-file.np.md) 48 | यो कागजातले .gitignore फाइल केका लागि हो, यसलाई किन प्रयोग गर्ने र कसरी सिर्जना गर्ने भनेर बताउँछ। यो फाइल लगभग सबै git परियोजनाहरूमा प्रयोग गरिन्छ। यसले कमिटहरूमा मात्र आवश्यक फाइलहरू विचार गर्न मद्दत गर्दछ। 49 | -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/additional-material.by.md: -------------------------------------------------------------------------------- 1 | # Дадатковая інфармацыя 2 | 3 | Тут мы мяркуем, што вы ўжо асвоілі асноўную інструкцыю. Дадатковая інфармацыя змяшчае некаторыя звесткі аб GIT камандах, необходимыж ў больш складаных сітуацыях. 4 | 5 | ### [Выпраўленні ў каміты](amending-a-commit.by.md) 6 | Дакумент змяшчае інфармацыю аб тым, як ўнесці выпраўлення ў commit ў аддаленым рэпазітары. 7 | > Яна неабходная для тых выпадкаў, калі вы хочаце змяніць commit, які вы зрабілі раней. 8 | 9 | ### [Канфігураванне GIT](configuring-git.by.md) 10 | Дакумент змяшчае сведния пра тое, як змяніць інфармацыю аб карыстальніку і іншыя налады GIT. 11 | > Ён будзе карысны, калі вы захочаце зрабіць ўстаноўкі GIT больш зручнымі. 12 | 13 | ### [Сінхранізацыя вашага адгалінаванні з асноўным рэпазітаром](keeping-your-fork-synced-with-this-repository.by.md) 14 | Дакумент распавядае аб тым, як забяспечыць сінхранізацыю вашага адгалінаванні з асноўным рэпазітаром. Забеспячэнне сінхранізацыі небходнасць, так як, наколькі можна спадзявацца, вы будзеце працаваць над праектам не ў адзіноце, а ўносіць змены ў яго, разам з іншымі ўдзельнікамі. 15 | > Выканайце гэтыя дзеянні, калі ваша адгалінаванне не мае змяненняў у master галінцы рэпазітара. 16 | 17 | ### [Перамяшчэнне камітаў ў іншую галінку](moving-a-commit-to-a-different-branch.by.md) 18 | Дакумент змяшчае звесткі аб тым, як перамясціць commit ў іншую галінку. 19 | > Выканайце названыя крокі, каб перамясціць комм ў іншую галінку. 20 | 21 | ### [Выдаленне файла](removing-a-file.by.md) 22 | Дакумент апісвае як выдаліць файл з вашага лакальнага рэпазітара. 23 | > Азнаёмцеся з гэтымі камандамі каб зразумець як выдаліць файл перад тым, як зрабіць commit. 24 | 25 | ### [Выдаленне галінкі з вашага рэпазітара](removing-branch-from-your-repository.by.md) 26 | Дакумент змяшчае інфармацыю аб тым, як выдаліць галінку з вашага рэпазітара. 27 | > Выкарыстоўвайце гэтыя каманды толькі пасля таго, як ваш pull-request быў задаволены. 28 | 29 | ### [Дазвол канфліктаў пры зліцці галінак](resolving-merge-conflicts.by.md) 30 | Дакумент змяшчае інфармацыю аб тым, як вырашаць канфлікты, якія ўзнікаюць пры зліцці галінак. 31 | > Прапанаваныя тут крокі дапамогуць вам разабрацца з вельмі непрыемнымі выпадкамі канфліктаў якія ўзнікаюць пры зліцці галінак. 32 | 33 | ### [Адмена камітаў](reverting-a-commit.by.md) 34 | Дакумент інструктуе як адмяніць commit ў аддаленым рэпазітары. Такая аперацыя будзе карысная ў тых выпадках, калі вам неабходна адыграць назад той commit, які ўжо быў пасланы на Github (pushed). 35 | > Выканайце названыя тут крокі каб адмяніць commit. 36 | 37 | ### [Сумяшчэнне камітаў (squashing)](squashing-commits.by.md) 38 | Дакумент апісвае, як сумяшчаць камітаў пры дапамозе інтэрактыўнага перабазавання. 39 | > Выкарыстоўвайце гэтыя інструкцыі, калі вы стварылі пул-реквест ў open source праекце, але эксперт праекта просіць вас сумясціць усе вашыя камітаў ў адзін комм з змястоўным каментаром. 40 | 41 | ### [Адмена лакальнага каміту](undoing-a-commit.by.md) 42 | Дакумент утрымлівае інфармацыю, як адыграць назад commit ў вашым лакальным рэпазітары. Вам спатрэбіцца гэтая інфармацыя ў тым выпадку, калі вы вырашыце, што вы сапсавалі ваш рэпазітар і захочаце вярнуць яго змесціва да першапачатковага стану. 43 | > Выконвайце гэтым інструкцыям, калі вы хочаце адмяніць тыя змены, якія былі зробленыя апошнім лакальным commit . 44 | 45 | ### [Карысныя спасылкі](Useful-links-for-further-learning.by.md) 46 | Гэты файл утрымлівае спасылкі на блог-пасты, карысныя вэб-сайты, вэб-сайты з пералікам рэкамендацыі і прыёмаў, якія часта палягчаюць наша жыццё. Як пачаткоўцам, так і экспертам мы рэкамендуем звяртацца да іх па меры неабходнасці. Гэты файл утрымлівае спіс карысных спасылак, якія напэўна дапамогуць і тым, хто робіць першыя крокі ў open source, і тым, хто захоча павялічыць свае веды ў гэтай галіне. -------------------------------------------------------------------------------- /additional-material/translations/Spanish/additional-material.es.md: -------------------------------------------------------------------------------- 1 | # Información Adicional 2 | 3 | Aquí asumimos que ya has dominado las instrucciones básicas. La información adicional contiene algunos detalles sobre comandos de Git que son necesarios en situaciones más complejas. 4 | 5 | ### [Corrección en Commits](corrigiendo-un-commit.es.md) 6 | Este documento contiene información sobre cómo corregir un commit en un repositorio remoto. 7 | > Esto es necesario en casos en los que deseas modificar un commit que hiciste anteriormente. 8 | 9 | ### [Configuración de Git](configurando-git.es.md) 10 | Este documento ofrece información sobre cómo cambiar la información del usuario y otras configuraciones de Git. 11 | > Será útil si deseas hacer que tu configuración de Git sea más conveniente. 12 | 13 | ### [Manteniendo tu Fork Sincronizado con este Repositorio](manteniendo-tu-fork-sincronizado-con-este-repositorio.es.md) 14 | Este documento explica cómo mantener sincronizado tu fork con este repositorio. Mantener la sincronización es importante ya que, en la medida en que esperamos, trabajarás en el proyecto no solo por ti mismo, sino con otros colaboradores. 15 | > Sigue estos pasos si tu fork no tiene cambios en la rama master del repositorio. 16 | 17 | ### [Mover un Commit a una Rama Diferente](moviendo-un-commit-a-una-rama-diferente.es.md) 18 | Este documento proporciona información sobre cómo mover un commit a una rama diferente. 19 | > Sigue los pasos indicados para mover un commit a otra rama. 20 | 21 | ### [Eliminando un Archivo](eliminando-un-archivo.es.md) 22 | Este documento describe cómo eliminar un archivo de tu repositorio local. 23 | > Familiarízate con estos comandos para entender cómo eliminar un archivo antes de realizar un commit. 24 | 25 | ### [Eliminando una Rama de tu Repositorio](eliminando-una-rama-de-tu-repositorio.es.md) 26 | Este documento ofrece información sobre cómo eliminar una rama de tu repositorio. 27 | > Utiliza estos comandos solo después de que tu pull request haya sido aceptado. 28 | 29 | ### [Resolviendo Conflictos de Fusión de Ramas](resolviendo-conflictos-de-fusion-de-ramas.es.md) 30 | Este documento proporciona información sobre cómo resolver conflictos que surgen al fusionar ramas. 31 | > Sigue estos pasos para manejar los conflictos que pueden ser muy incómodos al fusionar ramas. 32 | 33 | ### [Deshaciendo un Commit](deshaciendo-un-commit.es.md) 34 | Este documento describe cómo deshacer un commit en tu repositorio local. Esta operación es útil cuando necesitas revertir un commit después de que ya haya sido enviado a GitHub (pushed). 35 | > Sigue estos pasos para deshacer un commit. 36 | 37 | ### [Fusionar Commits (Squashing)](fusionando-commits.es.md) 38 | Este documento describe cómo fusionar commits mediante la rebase interactiva. 39 | > Sigue estas instrucciones si un experto del proyecto te pide que fusiones todos tus commits en uno con un comentario significativo. 40 | 41 | ### [Deshaciendo un Commit Local](deshaciendo-un-commit-local.es.md) 42 | Este documento proporciona información sobre cómo revertir un commit en tu repositorio local. Necesitarás esta información si decides que has dañado tu repositorio y deseas volver a su estado original. 43 | > Sigue estas instrucciones si deseas deshacer los cambios que hiciste en tu último commit local. 44 | 45 | ### [Enlaces Útiles](enlaces-utiles-para-aprender-mas.es.md) 46 | Este archivo contiene enlaces a publicaciones de blogs, sitios web útiles, sitios web con listas de recomendaciones y trucos que a menudo hacen nuestra vida más fácil. Tanto para principiantes como para expertos, recomendamos consultarlos según sea necesario. Este archivo contiene una lista de enlaces útiles que seguramente ayudarán a aquellos que dan sus primeros pasos en el código abierto y aquellos que desean expandir sus conocimientos en este campo. 47 | -------------------------------------------------------------------------------- /additional-material/translations/Indonesian/additional-material.id.md: -------------------------------------------------------------------------------- 1 | # Informasi tambahan 2 | 3 | Kami berasumsi Anda sudah menyelesaikan tutorial dasar sebelum datang ke sini. Dokumen ini akan memberikan beberapa informasi mengenai teknik Git yang lebih tinggi. 4 | 5 | ### [Hapus cabang dari repositori Anda](removing-branch-from-your-repository.id.md) 6 | 7 | Dokumen ini memberikan informasi mengenai bagaimana menghapus sebuah cabang dari repositori Anda. 8 | 9 | > Lakukan langkah ini setelah pull request Anda digabungkan (merge). 10 | 11 | ### [Agar fork Anda tetap sinkron dengan repositori](keeping-your-fork-synced-with-this-repository.md) 12 | 13 | Dokumen ini memberikan informasi mengenai bagaimana agar repositori yang kita fork tetap up-to-date dengan repositori dasar. Hal ini penting, karena bisa jadi Anda dan banyak kontributor lain berkontribusi dalam proyek tersebut. 14 | 15 | > Ikuti langkah-langkahnya jika fork Anda tidak punya perubahan dengan repositori induk. 16 | 17 | ### [Membatalkan commit](reverting-a-commit.md) 18 | 19 | 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. 20 | 21 | > Ikuti langkah-langkahnya untuk membatalkan sebuah commit. 22 | 23 | ### [Mengubah sebuah commit](amending-a-commit.md) 24 | 25 | Dokumen ini memberikan informasi mengenai cara mengubah sebuah commit di repositori remote. 26 | 27 | > Gunakan ini ketika kamu harus mengubah commit yang sudah dibuat. 28 | 29 | ### [Membatalkan commit lokal](undoing-a-commit.md) 30 | 31 | 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. 32 | 33 | > Lakukan cara ini jika ingin membatalkan/reset commit di lokal. 34 | 35 | ### [Mengatasi Merge Conflicts](resolving-merge-conflicts.md) 36 | 37 | Dokumen ini memberikan informasi mengenai cara mengatasi saat terjadi konflik ketika melakukan merge. 38 | 39 | > Lakukan langkah tersebut untuk mengatasi konflik merge yang mengganggu. 40 | 41 | ### [Menghapus sebuah berkas](removing-a-file.id.md) 42 | 43 | Dokumen ini memberikan informasi mengenai cara menghapus sebuah berkas dari repositori lokal. 44 | 45 | > Ikuti langkah tersebut untuk mempelajari bagaimana menghapus sebuah berkas sebelum di-commit. 46 | 47 | ### [Memindahkan Commit ke Cabang berbeda](moving-a-commit-to-a-different-branch.md) 48 | 49 | Dokumen ini memberikan informasi mengenai cara memindahkan sebuah commit ke cabang lain. 50 | 51 | > Ikuti langkah tersebut untuk memindahkan sebuah commit ke cabang lain. 52 | 53 | ### [Mengkonfigurasi git](configuring-git.md) 54 | 55 | Dokumen ini memberikan informasi mengenai cara mengkonfigurasi detail pengguna dan opsi lain di git. 56 | 57 | > Gunakan langkah ini agar konfigurasi git Anda menjadi lebih baik. 58 | 59 | ### [Tautan bermanfaat](Useful-links-for-further-learning.id.md) 60 | 61 | 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. 62 | 63 | ### [Menyatukan banyak Commit](squashing-commits.md) 64 | 65 | Dokumen ini menyediakan informasi mengenai bagaimana menyederhanakan banyak commit dengan rebase interaktif. 66 | 67 | > Gunakan ini jika Anda ingin membuka sebuah PR (Pull Request) dalam proyek open source dan periview meminta kamu untuk menyatukan setiap commit menjadi satu, dengan pesan commit yang informatif. 68 | -------------------------------------------------------------------------------- /additional-material/translations/Russian/additional-material.ru.md: -------------------------------------------------------------------------------- 1 | # Дополнительная информация 2 | 3 | Здесь мы предполагаем, что вы уже освоили основную инструкцию. Дополнительная информация содержит некоторые сведения о GIT командах, необходимыж в более сложных ситуациях. 4 | 5 | ### [Исправления в коммите](amending-a-commit.md) 6 | Документ содержит информацию о том, как внести исправления в коммит в удаленном репозитории. 7 | > Она необходима для тех случаев, когда вы хотите изменить коммит, который вы сделали ранее. 8 | 9 | ### [Конфигурирование GITа](configuring-git.md) 10 | Документ содержит сведния о том, как изменить информацию о пользователе и другие настройки GITа. 11 | > Он будет полезен, если вы захотите сделать установки GITа более удобными. 12 | 13 | ### [Синхронизация вашего ответвления с основным репозиторием](keeping-your-fork-synced-with-this-repository.md) 14 | Документ рассказывает о том, как обеспечить синхронизацию вашего ответвления с основным репозиторием. Обеспечение синхронизации небходимо, так как, насколько можно надеяться, вы будете работать над проектом не в одиночестве, а вносить изменения в него, наряду с другими участниками. 15 | > Выполните эти действия, если ваше ответвление не имеет изменений в master ветке репозитория. 16 | 17 | ### [Перемещение коммита в другую ветку](moving-a-commit-to-a-different-branch.md) 18 | Документ содержит сведения о том, как переместить коммит в другую ветку. 19 | > Выполните указанные шаги, чтобы переместить коммит в другую ветку. 20 | 21 | ### [Удаление файла](removing-a-file.md) 22 | Документ описывает как удалить файл из вашего локального репозитория. 23 | > Ознакомьтесь с этими командами чтобы понять как удалить файл перед тем, как сделать коммит. 24 | 25 | ### [Удаление ветки из вашего репозитория](removing-branch-from-your-repository.md) 26 | Документ содержит информацию о том, как удалить ветку из вашего репозитория. 27 | > Используйте эти команды только после того, как ваш пул-реквест был удовлетворен. 28 | 29 | ### [Разрешение конфликтов при слиянии веток](resolving-merge-conflicts.md) 30 | Документ содержит информацию о том, как разрешать конфликты, возникающие при слиянии веток. 31 | > Предложенные здесь шаги помогут вам разобраться с весьма неприятными случаями конфликтов возникающих при слиянии веток. 32 | 33 | ### [Отмена коммита](reverting-a-commit.md) 34 | Документ инструктирует как отменить коммит в удаленном репозитории. Такая операция будет полезна в тех случаях, когда вам необходимо отыграть назад тот коммит, который уже был послан на Github (pushed). 35 | > Выполните указанные здесь шаги чтобы отменить коммит. 36 | 37 | ### [Совмещение коммитов (squashing)](squashing-commits.md) 38 | Документ описывает, как совмещать коммиты при помощи интерактивного перебазирования. 39 | > Используйте эти инструкции, если вы создали пул-реквест в open source проекте, но эксперт проекта просит вас совместить все ваши коммиты в один коммит с содержательным комментарием. 40 | 41 | ### [Отмена локального коммита](undoing-a-commit.md) 42 | Документ информирует, как отыграть назад коммит в вашем локальном репозитории. Вам понадобится эта информация в том случае, если вы решите, что вы испортили ваш репозиторий и захотите вернуть его содержимое к первоначальному состоянию. 43 | > Следуйте этим инструкциям, если вы хотите отменить те изменения, котрые были сделаны последним локальным коммитом. 44 | 45 | ### [Полезные ссылки](Useful-links-for-further-learning.md) 46 | Этот файл содержит ссылки на блог-посты, полезные веб-сайты, веб-сайты с перечислением рекоммендаций и приемов, которые часто облегчают нашу жизнь. Как начинающим, так и экспертам мы рекомендуем обращаться к ним по мере необходимости. Этот файл содержит список полезных линьков, которые наверняка помогут и тем, кто делает первые шаги в open source, и тем, кто захочет рассширить свои знания в этой области. -------------------------------------------------------------------------------- /additional-material/translations/Spanish/additional-material.sp_mx.md: -------------------------------------------------------------------------------- 1 | # Información adicional 2 | 3 | Asumimos que ya has terminado el tutorial básico antes de venir aquí. La información adicional le dará una idea de las técnicas de Git más avanzadas. 4 | 5 | ### [Modificar una confirmación](../git_workflow_scenarios/amending-a-commit.md) 6 | Este documento proporciona información sobre cómo modificar una confirmación en el repositorio remoto. 7 | > Utilice esto cuando necesite modificar una confirmación que haya realizado. 8 | 9 | ### [Configurando git](../git_workflow_scenarios/configuring-git.md) 10 | Este documento proporciona información sobre cómo configurar los detalles del usuario y otras opciones de git. 11 | > Utilice esto para controlar mejor la configuración de Git. 12 | 13 | ### [Mantener tu bifurcación sincronizada con el repositorio](../git_workflow_scenarios/keeping-your-fork-synced-with-this-repository.md) 14 | Este documento proporciona información sobre cómo mantener su bifurcación actualizada con el repositorio base. Esto es importante ya que se espera que usted y muchas otras personas contribuyan al proyecto. 15 | > Siga estos pasos si su bifurcación no tiene los mismos cambios que el repositorio principal. 16 | 17 | ### [Mover un compromiso a una rama diferente](../git_workflow_scenarios/moving-a-commit-to-a- Different-branch.md) 18 | Este documento proporciona información sobre cómo mover un compromiso a otra rama. 19 | > Siga estos pasos para mover un compromiso a otra rama. 20 | 21 | ### [Eliminar un archivo](../git_workflow_scenarios/removing-a-file.md) 22 | Este documento proporciona información sobre cómo eliminar un archivo de su repositorio local. 23 | > Siga estos pasos para aprender cómo eliminar un archivo de su repositorio local. 24 | 25 | ### [Eliminar una rama de su repositorio](../git_workflow_scenarios/removing-branch-from-your-repository.md) 26 | Este documento proporciona información sobre cómo eliminar una rama de su repositorio. 27 | > Siga estos pasos solo después de que su solicitud de extracción se haya fusionado. 28 | 29 | ### [Resolver conflictos de fusión](../git_workflow_scenarios/resolving-merge-conflicts.md) 30 | Este documento proporciona información sobre cómo resolver conflictos de fusión. 31 | > Siga estos pasos para resolver los molestos conflictos de fusión. 32 | 33 | ### [Revertir una confirmación](../git_workflow_scenarios/reverting-a-commit.md) 34 | Este documento proporciona información sobre cómo revertir una confirmación realizada en el repositorio remoto. Esto es muy útil cuando necesita deshacer una confirmación que se publicó en GitHub. 35 | > Siga estos pasos si desea revertir una confirmación. 36 | 37 | ### [Aplastamiento de compromisos juntos] (../git_workflow_scenarios/squashing-commits.md) 38 | Este documento proporciona información sobre cómo combinar confirmaciones en una sola realizando una rebase. 39 | > Utilice estos pasos si desea hacer un PR en un proyecto de código abierto y el revisor le pide que combine todas las confirmaciones en una con un mensaje de confirmación informativo. 40 | 41 | ### [Deshacer una confirmación local](../git_workflow_scenarios/undoing-a-commit.md) 42 | Este documento proporciona información sobre cómo deshacer una confirmación en su repositorio local. Esto es lo que debes hacer cuando sientas que has arruinado tu repositorio y quieres deshacerlo. 43 | > Siga estos pasos si desea deshacer/restablecer una confirmación local. 44 | 45 | ### [Enlaces útiles](../git_workflow_scenarios/Useful-links-for-further-learning.md) 46 | Este documento está dedicado a todas las publicaciones de blogs, sitios web útiles, consejos y trucos que nos hacen la vida más sencilla. Ya sea un experto o un principiante, esta página debería servir como índice de todos estos enlaces útiles para ayudar a cualquiera que sea nuevo en el mundo de los proyectos de código abierto o a cualquiera que quiera aprender más al respecto. 47 | -------------------------------------------------------------------------------- /additional-material/translations/Belarusian/configuring-git.by.md: -------------------------------------------------------------------------------- 1 | # Канфігураванне GIT 2 | 3 | Калі вы ўпершыню паспрабавалі зрабіць commit, вы маглі ўбачыць такое паведамленне: 4 | 5 | ```bash 6 | $ git commit 7 | *** Please tell me who you are. 8 | 9 | Run 10 | 11 | git config --global user.email "you@example.com" 12 | git config --global user.name "Your Name" 13 | 14 | to set your account's default identity. 15 | Omit --global to set the identity only in this repository. 16 | ``` 17 | 18 | Каб стварыць commit, GIT павінен ведаць хто з'яўляецца яго аўтарам. Пры сумеснай працы, неабходна ведаць кім і калі былі змененыя тыя ці іншыя часткі праекта, таму GIT прадугледжвае, што кожны commits пры яго стварэнні асацыюецца з імем і емейл адрасам карыстальніка. 19 | 20 | Існуе некалькі спосабаў, якія дазваляюць асацыяваць каманду `git commit` з вашым емейл і імем, і тут мы пералічым некаторыя з іх. 21 | 22 | ### Глабальная канфігурацыя 23 | 24 | Інфармацыя, захаваная як частка глабальнай канфігурацыі, адносіцца да ўсёй сістэмы, г.зн. да ўсіх рэпазітароў, у якіх вы працуеце. Гэта пераважны спосаб, прыдатны для большасці з варыянтаў выкарыстання. 25 | 26 | Каб захаваць што-небудзь у глабальным канфігурацыі, вы выкарыстоўваеце каманду `config` наступным чынам: 27 | 28 | `$ git config --global ` 29 | 30 | Ва ўжыванні да інфармацыі пра карыстальніка, мы выконваем гэтыя каманды такім чынам: 31 | 32 | `` ` 33 | $ git config --global user.email "you@example.com" 34 | $ git config --global user.name "Your Name" 35 | `` ` 36 | 37 | ### Канфігурацыя рэпазітара 38 | 39 | Як вынікае з назвы, гэтыя канфігурацыі адносяцца да вашага бягучага сховішча. Калі вы хочаце прыняць удзел у пэўным сховішчы, скажам, на праекце, звязаным з працай, з электроннай поштай вашай кампаніі, то вы можаце скарыстацца гэтым метадам. 40 | 41 | Каб змяніць канфігурацыю на ўзроўні рэпазітара, варта апусціць ключ `--global` у камандзе` config` такім чынам: 42 | 43 | `$ git config ` 44 | 45 | Ва ўжыванні да інфармацыі пра карыстальніка, гэта выглядае наступным чынам: 46 | 47 | `` ` 48 | $ git config user.email "you@alternate.com" 49 | $ git config user.name "Your Name" 50 | `` ` 51 | 52 | ### Канфігурацыя ў камандным радку 53 | 54 | Гэты спосаб канфігурацыі адносіцца толькі да дадзенай камандзе. Усе каманды GIT дазваляюць выкарыстоўваць ключ `-c` перад дзеясловам ідэнтыфікуюць каманду для часовай ўстаноўкі канфігурацыйных параметеров. 55 | 56 | Для змены параметраў канфігурацыі, якія распаўсюджваюцца толькі на дадзеную каманду, карыстайцеся наступным фарматам каманд GIT: 57 | 58 | `$ git -c = -c = ` 59 | 60 | Для нашага выпадку Каманда для камітаў будзе вылядеть так: 61 | 62 | `git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"` 63 | 64 | ### Заўвага аб парадку предшествования 65 | 66 | Парадак предшествования сярод трох згаданых тыпаў каманд канфігурацыі вызначаецца як `command-line > repository > global`. Гэта азначае, што калі якая-небудзь пераменная вызначана, як у глабальнай канфігурацыі, так і ў камандным радку, то будзе выкарыстана значэнне, прысвоенае у камандным радку. 67 | 68 | ## Не толькі інфармацыя пра карыстальніка 69 | 70 | Да гэтага часу, абмяркоўваючы канфігурацыю GIT'а, мы дакраналіся толькі інфармацыі пра карыстальніка. Аднак GIT дазваляе канфігураваць яшчэ неслколько параметраў. Вось некторые з іх: 71 | 72 | 1. `core.editor` - паказвае назва рэдактара для рэдагавання каментар для камітаў і да т.п., 73 | 2. `commit.template` - паказвае файл, які змяшчае першапачатковы темплат для камітаў, 74 | 3. `color.ui` - лагічная зменная, якая ўказвае ці варта испольовать каляровыя шрыфты ў паведамленнях на тэрмінале GIT'а. 75 | 76 | Для прастаты мы апусцілі некаторыя дэталі. Для больш падрабязнага азнаямлення звярніцеся да [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration). -------------------------------------------------------------------------------- /additional-material/translations/Spanish/configuring-git.sp_mx.md: -------------------------------------------------------------------------------- 1 | # Configurando Git 2 | 3 | La primera vez que intentes comprometerte usando git, deberías obtener uno como este: 4 | 5 | ```bash 6 | $ git commit 7 | *** Por favor dime quién eres. 8 | 9 | Rode: 10 | 11 | git config --global usuario.correo electrónico "usted@ejemplo.com" 12 | git config --global user.name "Su nombre" 13 | 14 | Para configurar su identidad de cuenta predeterminada. 15 | Omita "--global" para establecer la identidad solo en ese repositorio 16 | ``` 17 | 18 | Git necesita saber quién es usted al crear una confirmación. Cuando trabajas en colaboración, deberías poder ver quién modificó qué partes del proyecto y cuándo, por lo que git está diseñado para crear confirmaciones vinculadas a un nombre y correo electrónico. 19 | 20 | Hay varias formas de proporcionar el comando `git commit` con su correo electrónico y nombre. Veremos algunos de ellos a continuación. 21 | 22 | 23 | ### Configuración global 24 | Cuando almacena algo en la configuración global, es accesible en todos los sistemas y repositorios en los que trabaja. Esta es la forma principal y funciona para la mayoría de los casos de uso. 25 | 26 | Para almacenar algo en la configuración use el comando `config` de la siguiente manera: 27 | 28 | `$ git config --global ` 29 | 30 | En el caso de los datos del usuario, los ejecutamos de la siguiente manera: 31 | 32 | ``` 33 | $ git config --global usuario.correo electrónico "usted@ejemplo.com" 34 | $ git config --global user.name "Su nombre" 35 | ``` 36 | 37 | ### Configuración del repositorio 38 | 39 | Como su nombre lo indica, estas configuraciones apuntan a su repositorio actual. Si desea comprometerse con un repositorio específico, por ejemplo, un proyecto relacionado con el trabajo, con el correo electrónico de su empresa, puede utilizar este método. 40 | 41 | Para almacenar algo en la configuración del repositorio, usa el comando `config` omitiendo el indicador `--global`, así: 42 | 43 | `$ git config ` 44 | 45 | En el caso de los datos del usuario, lo ejecutamos de la siguiente manera: 46 | 47 | ``` 48 | $ git config user.email "usted@alternate.com" 49 | $ git config user.name "Tu nombre" 50 | ``` 51 | 52 | ### Configuración de la línea de comando 53 | 54 | Este tipo de configuración solo tiene como objetivo el comando actual. Todos los comandos de git usan argumentos `-c` antes del verbo de acción para establecer datos de configuración temporales 55 | 56 | Para almacenar algo en la configuración de la línea de comando. Ejecute su comando de la siguiente manera: 57 | 58 | `$ git -c = -c = ` 59 | 60 | En el ejemplo anterior, ejecutaríamos el comando de confirmación de la siguiente manera: 61 | 62 | `git -c user.name='Su nombre' -c user.email='you@example.com' commit -m "Su mensaje de confirmación"` 63 | 64 | ### Nota sobre precedencia 65 | 66 | Entre los tres métodos descritos aquí, el orden de prioridad es "línea de comando > repositorio > global". Esto significa que si se establece una variable en la línea de comando y también globalmente, el valor de la línea de comando se usará para la operación. 67 | 68 | ## Además de los detalles del usuario: 69 | 70 | Hasta ahora solo nos hemos ocupado de los detalles del usuario mientras trabajamos en la configuración. Sin embargo, hay varias otras opciones disponibles. Algunos de ellos son: 71 | 72 | 1. `core.editor`: para especificar el nombre del editor utilizado para escribir mensajes de confirmación, etc. 73 | 2. `commit.template`: para especificar un archivo en el sistema como plantilla de confirmación inicial 74 | 3. `color.ui`: para especificar un valor booleano para usar colores en la salida de git 75 | 76 | Hemos resumido algunos detalles para facilitar la comprensión. Para leer más, visite: 77 | 78 | [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration). -------------------------------------------------------------------------------- /additional-material/translations/Greek/git_workflow_scenarios/configuring-git.gr.md: -------------------------------------------------------------------------------- 1 | # Διαμόρφωση του git 2 | 3 | Την πρώτη φορά που προσπαθήσατε να κάνετε commit χρησιμοποιώντας το git, πιθανόν να είδατε ένα παραθυράκι παρόμοιο με αυτό: 4 | 5 | ```bash 6 | $ git commit 7 | *** Παρακαλώ πείτε μου ποιός είστε. 8 | 9 | Εκτελέστε 10 | 11 | git config --global user.email "you@example.com" 12 | git config --global user.name "Your Name" 13 | 14 | για να ορίσετε την προεπιλεγμένη ταυτότητα του λογαριασμού σας. 15 | Παραλείψτε την επιλογή --global για να ορίσετε την ταυτότητα μόνο σε αυτό το αποθετήριο. 16 | ``` 17 | 18 | Το git χρειάζεται να γνωρίζει ποιός είστε κάθε φορά που δημιουργείτε ένα commit. Όταν εργάζεστε συνεργατικά, πρέπει να μπορείτε να δείτε ποιος έχει τροποποιήσει ποια μέρη του έργου και πότε. Επομένως, το git έχει σχεδιαστεί έτσι ώστε να δημιουργεί commits που συσχετίζονται με ένα όνομα και ένα email. 19 | 20 | Υπάρχουν πολλοί τρόποι για να παρέχετε το email και το όνομά σας στην εντολή `git commit`, και θα δούμε μερικούς από αυτούς παρακάτω. 21 | 22 | ### Παγκόσμια Διαμόρφωση 23 | 24 | Όταν αποθηκεύετε κάτι στην παγκόσμια διαμόρφωση (global config), είναι προσβάσιμο σε όλα τα αποθετήρια στα οποία εργάζεστε. Αυτός είναι ο προτιμώμενος τρόπος και λειτουργεί για τις περισσότερες περιπτώσεις. 25 | 26 | Για να αποθηκεύσετε κάτι στην παγκόσμια διαμόρφωση, χρησιμοποιείτε την εντολή `config` ως εξής: 27 | 28 | `$ git config --global <όνομα_μεταβλητής> <τιμή>` 29 | 30 | Στην περίπτωση των στοιχείων του χρήστη, το εκτελούμε ως εξής: 31 | 32 | ``` 33 | $ git config --global user.email "you@example.com" 34 | $ git config --global user.name "Your Name" 35 | ``` 36 | 37 | ### Διαμόρφωση Αποθετηρίου 38 | 39 | Όπως υποδηλώνει το όνομά τους, αυτές οι διαμορφώσεις εφαρμόζονται στο τρέχον αποθετήριο. Αν θέλετε να κάνετε commit σε ένα συγκεκριμένο αποθετήριο, για παράδειγμα, ένα έργο που σχετίζεται με την εργασία σας, μπορείτε να χρησιμοποιήσετε αυτήν τη μέθοδο. 40 | 41 | Για να αποθηκεύσετε κάτι στη διαμόρφωση αποθετηρίου, χρησιμοποιείτε την εντολή `config` αφήνοντας έξω τη σημαία `--global`, όπως εξής: 42 | 43 | `$ git config <όνομα_μεταβλητής> <τιμή>` 44 | 45 | Στην περίπτωση των στοιχείων του χρήστη, το εκτελούμε ως εξής: 46 | 47 | ``` 48 | $ git config user.email "you@alternate.com" 49 | $ git config user.name "Your Name" 50 | ``` 51 | 52 | ### Διαμόρφωση Μέσω Γρα 53 | 54 | μμής Εντολών 55 | 56 | Αυτού του τύπου διαμορφώσεις ισχύουν μόνο για την τρέχουσα εντολή. Όλες οι εντολές git δέχονται ορίσματα `-c` πριν το ρήμα δράσης για να ορίσουν προσωρινά δεδομένα διαμόρφωσης. 57 | 58 | Για να αποθηκεύσετε κάτι στη διαμόρφωση μέσω γραμμής εντολών, εκτελέστε την εντολή σας ως εξής: 59 | 60 | `$ git -c <μεταβλητή-1>=<τιμή> -c <μεταβλητή-2>=<τιμή> <εντολή>` 61 | 62 | Στο παράδειγμά μας, θα εκτελούσαμε την εντολή commit ως εξής: 63 | 64 | `git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"` 65 | 66 | ### Σημείωση για την Προτεραιότητα 67 | 68 | Ανάμεσα στις τρεις μεθόδους που περιγράφηκαν εδώ, η προτεραιότητα είναι `command-line > repository > global`. Αυτό σημαίνει ότι, αν μια μεταβλητή έχει διαμορφωθεί τόσο μέσω γραμμής εντολών όσο και παγκοσμίως, η τιμή που δόθηκε μέσω γραμμής εντολών θα χρησιμοποιηθεί για τη λειτουργία. 69 | 70 | ## Εκτός από τα Στοιχεία του Χρήστη 71 | 72 | Μέχρι στιγμής ασχοληθήκαμε μόνο με τα στοιχεία του χρήστη κατά τη διαμόρφωση. Ωστόσο, υπάρχουν πολλές άλλες διαθέσιμες επιλογές διαμόρφωσης. Ορισμένες από αυτές είναι: 73 | 74 | 1. `core.editor` - για να καθορίσετε το όνομα του επεξεργαστή που χρησιμοποιείται για τη σύνταξη μηνυμάτων commit κ.λπ. 75 | 2. `commit.template` - για να καθορίσετε ένα αρχείο στο σύστημα ως πρότυπο αρχικού commit. 76 | 3. `color.ui` - για να καθορίσετε μια λογική τιμή για τη χρήση χρωμάτων στην έξοδο του git. 77 | 78 | Απλοποιήσαμε κάποιες λεπτομέρειες για ευκολία κατανόησης. Για περισσότερες πληροφορίες, επισκεφθείτε το [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration). --------------------------------------------------------------------------------