Remotes और GitHub

docs.scrimba.com

इस handbook में अब तक हर repository एक जगह पर रही है: आपकी अपनी machine पर। यह तब तक ठीक है जब तक आप एक backup नहीं चाहते जो एक मरी हुई laptop को survive करे, दूसरी computer से project pick up नहीं करना चाहते, या किसी और को code को touch करने नहीं देना चाहते। आपको जो चाहिए वह repository की एक copy है जो कहीं hosted हो जहाँ शामिल हर machine reach कर सके। उस copy को remote कहा जाता है, और GitHub वह जगह है जहाँ ज्यादातर developers इसे रखते हैं।

Remote क्या है (और GitHub इसमें कहाँ फिट होता है)

एक remote आपकी repository की एक copy है जो आपकी अपनी machine के अलावा कहीं hosted है, अक्सर GitHub पर। जब आप कोई repository clone करते हैं, तो Git पहले से ही आपके लिए एक setup कर देता है, जिसका नाम default रूप से origin होता है। git remote -v चलाएँ (यह -v names के साथ URLs भी दिखाने के लिए कहता है):

$ git remote -v
origin  https://github.com/mara-chen/weather-app.git (fetch)
origin  https://github.com/mara-chen/weather-app.git (push)

हर remote जो Git को पता है, दो बार listed है, एक बार fetching के लिए और एक बार pushing के लिए, क्योंकि सिद्धांत रूप से दोनों अलग-अलग addresses को point कर सकते हैं। व्यावहारिक रूप से वे लगभग हमेशा एक ही होते हैं। origin वह nickname है जो Git automatically clone पर assign करता है। आप इसे rename कर सकते हैं या एक दूसरा remote जोड़ सकते हैं जो कहीं और point करता हो, लेकिन लगभग हर project जिसे आप touch करते हैं अपने main remote को origin कहेगा।

यह एक अच्छा moment है उस distinction को दोहराने के लिए जो शुरुआत करने वाले लगभग हर किसी को confuse करती है: Git और GitHub एक ही चीज़ नहीं हैं। Git आपकी machine पर चलने वाला version-control tool है, commits को record करता है चाहे आप कुछ से connected हों या नहीं। GitHub एक website है जो आपकी repository की एक copy host करता है और आपको push करने और pull करने के लिए एक remote देता है। git remote, git push, और git pull वे commands हैं जो दोनों को connect करते हैं: वे यह हैं कि आपकी laptop पर चलने वाला Git कैसे GitHub के servers पर बैठी एक repository से बात करता है।

एक remote कुछ नहीं बल्कि एक नाम है जो एक URL से mapped है, आपकी repository के config में stored। इसके साथ, Git एक remote-tracking branch रखता है: एक local bookmark जो record करता है कि उस remote पर एक branch कहाँ था जब आपकी machine ने आखिरी बार check किया। origin/main बिल्कुल यही है। यह GitHub पर बैठी actual main branch नहीं है। यह आपकी repository की वह memory है कि GitHub की main आपके आखिरी fetch या pull के अनुसार कहाँ था। उन remote-tracking branches को list करें जो Git currently hold करता है git branch -r के साथ:

$ git branch -r
origin/main

सब कुछ जो एक remote करता है वह उस config entry plus इन tracking bookmarks के through चलता है। कोई background connection नहीं है और कुछ भी नहीं है जो changes को देख रहा हो। Git केवल अपनी remote की picture को update करता है जब आप उसे बताते हैं, fetch या pull के साथ, जो बिल्कुल यही है जो यह chapter cover करता है।

JunoRemote क्या है एक remote आपकी repository की एक copy है जो कहीं और hosted है, आमतौर पर GitHub पर, और Git default वाले को origin कहता है। किसी भी समय git remote -v चलाएँ अपनी repository के बारे में देखने के लिए कि कौन से remotes को Git जानता है। Git और GitHub एक ही चीज़ नहीं हैं: Git आपकी machine पर tool है, GitHub वह जगह है जहाँ आपका remote अक्सर रहता है। यह distinction शुरुआत में ही clear करने से बाद में बहुत confusión बचता है।

JunoRemote क्या हैorigin सिर्फ वह default नाम है जो Git remote को देता है जो वह clone पर setup करता है, इसलिए आप इसे rename कर सकते हैं या जब project को उन्हें चाहिए तो अधिक remotes add कर सकते हैं। git remote -v हर remote का URL दिखाता है fetch और push दोनों के लिए। Git बनाम GitHub split को याद रखें: जो commands आप locally चलाते हैं वह Git हैं, और GitHub उन commands के कई destinations में से एक है।

JunoRemote क्या है एक remote आपके config में एक नाम है जो एक URL से mapped है, remote-tracking branches जैसे origin/main के साथ paired, आपकी machine की वह memory कि वह branch आपके आखिरी fetch या pull पर कहाँ था। कुछ भी अपने आप update नहीं होता; Git केवल remote को check करता है जब asked जाता है। जो GitHub के पास actually है और जो आपकी remote-tracking branch याद करती है के बीच यह gap लगभग हर fetch-बनाम-pull surprise के पीछे है।

अपने remote को कहाँ host करें: GitHub और alternatives

सब कुछ जो एक remote करता है वह plain Git है, और इसका एक consequence है जो शुरुआत में ही जानने लायक है: दूसरे end पर host swappable है। Git के लिए, हर host आपके config में एक URL है, और git push, git pull, और git fetch सभी के साथ identically behave करते हैं। जो एक host add करता है वह एक layer up बैठता है: आपके code का एक web view, एक review flow, issue tracking, और access control। यहाँ landscape है, trade-offs स्पष्ट रूप से stated:

• GitHub अब तक सबसे बड़ा है और open-source work का बड़ा majority host करता है। इसकी strength network है: जो projects आप contribute करना चाहते हैं वह पहले से ही वहाँ हैं, tutorials इसे assume करते हैं, और employers आपकी profile को इस पर देखते हैं। Trade-off यह है कि यह एक closed platform है (Microsoft के ownership में), और जितना अधिक आप Git hosting से परे इसके extras पर lean करते हैं, उतना ही आप इसके लिए tied हो जाते हैं।
• GitLab सबसे करीबी full alternative है, जिसमें same core features अलग-अलग names के under हैं (pull requests को वहाँ "merge requests" कहा जाता है)। इसका standout एक self-managed edition है जो आप अपने servers पर चला सकते हैं, जिससे companies जो code in-house रखते हैं अक्सर इसे pick करते हैं। Trade-off यह है कि यह बहुत कुछ bundle करता है, और platform उससे भारी feel कर सकता है जो code hosting आप के लिए आए थे।
• Bitbucket Atlassian से host है, जो इसके project-tracking और documentation tools, Jira और Confluence के बगल में बैठने के लिए built है। अगर आपकी team पहले से ही उन tools में रहती है, तो यह directly slot में आता है। उस ecosystem के बाहर इसके पास big three में सबसे छोटा community है और little open-source presence है।
• Codeberg open-source projects के लिए एक nonprofit host है, open-source platform Forgejo पर run करते हुए। Draw यह है कि कोई company आपके host को own नहीं करता है और platform itself open source है। Trade-off scale है: fewer integrations, एक छोटा community, और open source के बजाय private team work पर focus।
• Self-hosting इन सभी के अंतर्निहित है: Forgejo या Gitea run करें, दोनों free और open source हैं, या GitLab के self-managed edition को hardware पर जो आप control करते हैं। आपको full control और privacy मिलता है; trade-off यह है कि इसे चलाना keep करना आपका job बन जाता है।

यह handbook अपने examples में GitHub use करता है क्योंकि यह most open-source work को host करता है और वह जगह है जहाँ आप सबसे पहले collaborate करने की संभावना रखते हैं। इस chapter में हर command बिना किसी बदलाव के किसी अन्य host में transfer होता है: URL को swap करें और daily loop same रहता है। Differences एक layer up में रहते हैं, हर site के web interface में reviewing और merging work के लिए, जहाँ अगले chapter का pull request flow आता है।

जब choice आपकी होती है, तो यह rarely Git features के बारे में होता है, क्योंकि core set (hosted repositories, reviews, issues, CI pipelines) everywhere exists करता है। यह context पर आता है: open source में contributing या एक public profile build करना GitHub की ओर point करता है, एक company जो Atlassian tools पर चलती है Bitbucket की ओर point करता है, code जो आपके own infrastructure पर रहना चाहिए GitLab self-managed या Forgejo की ओर point करता है, और एक values-driven open-source project Codeberg पर सबसे at home feel कर सकता है। Choice भी forever नहीं है। Repository को hosts के बीच move करना एक git remote set-url plus एक push है; migration का expensive part layer है Git के ऊपर, वह issues, wikis, और CI configuration जो commits के साथ travel नहीं करते।

Self-hosting को आप commit करने से पहले एक clear-eyed look की deserves है। Forgejo और Gitea एक छोटे server पर comfortably run करते हैं, लेकिन operational load real है: security updates, दोनों repositories और platform के अपने database के backups, account और SSH-key management, और uptime, क्योंकि एक down forge हर push और pull को blocks करता है जो आपकी team बनाती है। यह अपनी keep को earn करता है जब compliance rules code को third-party infrastructure से दूर रखते हैं, air-gapped environments में, या जब एक organization चाहता है कि अपनी tooling अपने control में रहे। Web layer के नीचे कुछ भी नहीं बदलता: इन hosts में से हर एक same Git protocol बोलता है, जिससे आपका push और fetch उन्हें अलग नहीं बता सकता।

Junoअपने remote को कहाँ host करें GitHub वह जगह है जहाँ ज्यादातर projects रहते हैं और default safest है जब आप शुरुआत कर रहे हों, लेकिन यह कई hosts में से एक है: GitLab, Bitbucket, और nonprofit Codeberg सभी same Git repositories store करते हैं। Push और pull same काम करते हैं जहाँ भी remote रहता है, इसलिए यहाँ आप जो कुछ सीखते हैं वह waste नहीं होता अगर project कहीं और रहता है।

Junoअपने remote को कहाँ host करें Hosts Git से एक layer up पर differ करते हैं: GitLab pull requests को merge requests कहता है और एक self-managed edition offer करता है, Bitbucket Atlassian के tools में plugs होता है, और Codeberg open-source Forgejo पर run करता है। Pick करें जहाँ आपके collaborators और tooling पहले से ही हैं, और याद रखें एक later move Git side पर cheap है; यह issues और CI हैं जो travel नहीं करते।

Junoअपने remote को कहाँ host करें चूँकि एक remote एक नाम है जो एक URL से mapped है, एक project को hosts के बीच move करना git remote set-url plus एक push है। Self-hosting Forgejo या Gitea control और privacy को buy करता है और आपको patching, backups, और uptime cost करता है; उस trade को लें जब policy उसे demand करता है, न कि fun के लिए, कहता है वह person जो एक के लिए pager carry करता है। सब कुछ host-specific Git protocol के ऊपर web layer में रहता है।

अपने काम को send और get करना: git push और git pull

एक remote होने के साथ, दो commands ज्यादातर daily work को cover करते हैं। git push आपके local commits को remote तक भेजता है। git pull commits को bring down करता है जो कहीं और बनाई गई हैं और उन्हें merge करता है जिस branch पर आप हैं।

$ git push origin main
Enumerating objects: 5, done.
Writing objects: 100% (3/3), 312 bytes | 312.00 KiB/s, done.
To https://github.com/mara-chen/weather-app.git
   9f8e7d6..a1b2c3d  main -> main

origin remote है, main वह branch है जो आप send कर रहे हैं। वह last line वह part है जो पढ़ने लायक है: यह दिखाता है main को remote पर एक commit से दूसरे में move करते हुए।

Pulling same तरीके से काम करता है, reverse में:

$ git pull origin main
remote: Enumerating objects: 4, done.
Unpacking objects: 100% (4/4), done.
Updating a1b2c3d..b7c9e21
Fast-forward
 src/index.js | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

यह पूरा loop है एक दूसरे के साथ एक project पर काम करने के लिए: pull down करें जो कुछ भी बदला है शुरु करने से पहले, अपना काम करें और commit करें, इसे वापस up push करें। जब भी आप एक branch को किसी और के साथ share करते हैं push से पहले pull करें। Pull को skip करें और आपका push उन commits पर land कर सकता है जिन्हें आपने कभी नहीं देखा, जिसे Git refuse करेगा rather than किसी के काम को lose करने का risk लेने के लिए।

पहली बार जब आप एक नई branch को push करते हैं, तो -u add करें (short for --set-upstream):

$ git push -u origin feature/add-forecast-icons
Enumerating objects: 5, done.
Writing objects: 100% (5/5), 412 bytes | 412.00 KiB/s, done.
To https://github.com/mara-chen/weather-app.git
 * [new branch]      feature/add-forecast-icons -> feature/add-forecast-icons
branch 'feature/add-forecast-icons' set up to track 'origin/feature/add-forecast-icons'.

यह feature/add-forecast-icons को record करता है tracking के रूप में origin/feature/add-forecast-icons को, एक link जिसे upstream कहा जाता है। एक बार यह set हो जाए, हर push और pull के बाद उस पर remote और branch name को drop कर सकते हैं और plain git push या git pull चला सकते हैं branch पर। अगर एक branch के पास कोई upstream configured नहीं है, तो Git कहता है और exact command print करता है इसे fix करने के लिए, इसलिए आप rarely को flag याद रखने की जरूरत है, बस message को recognize करें जब यह show up हो।

वह upstream link दो plain lines के रूप में रहता है जो आपकी repository के config में लिखी जाती हैं जैसे ही -u runs: branch.feature/add-forecast-icons.remote remote को names करता है, branch.feature/add-forecast-icons.merge इस पर branch को names करता है। git config --get branch.main.remote को एक branch पर run करें जिसे आपने पहले push किया है और आप बिल्कुल यह value back आते हुए देखेंगे। वे दो lines भी हैं जो git status आपको बताने के लिए read करता है कि आपकी branch origin/main से दो commits ahead है, या वह दोनों अलग हो गई हैं: comparison entirely आपकी remote-tracking branch के against चलता है, एक local check जिसमें कुछ भी fetch नहीं किया गया है GitHub से। Upstream को एक बार set करें, और हर ahead-behind count जो Git आपको उसके बाद दिखाता है उस ही pair of config lines को read कर रहा है।

Junoअपने काम को send और get करनाgit push आपके commits को remote तक भेजता है, और git pull commits को bring down करता है जो कहीं और बनाई गई हैं और उन्हें merge करता है आपकी branch में। काम करना शुरु करने से पहले pull करें और जब आप done हों तो push करें, और आप किसी और के साथ भी sync में रहते हैं जो project को touch करता है। Pull को skip करना सबसे common reason है जो push rejected होता है।

Junoअपने काम को send और get करनाgit push origin main commits भेजता है, git pull origin main fetch करता है और merge करता है, और एक बार एक branch के पास upstream set हो जाए git push -u के साथ, दोनों commands remote या branch को naming के बिना काम करते हैं। एक shared branch पर push से पहले pull करें, या आपका push rejected हो जाता है क्योंकि remote पहले ही आपके local history के past move चुका है।

Junoअपने काम को send और get करना Upstream जो आप git push -u के साथ set करते हैं दो config lines तक comes down करता है, branch.<name>.remote और branch.<name>.merge, लिखी गई जैसे ही flag runs। git status उस ही pair को पढ़ता है यह बताने के लिए कि आपकी branch origin/main से कितना far ahead या behind है, एक comparison जो यह entirely अपनी local remote-tracking branch के against बनाता है। इसे एक बार प्रति branch और हर shorthand push या pull, और हर ahead-behind count set करें, comes free।

git fetch बनाम git pull

git pull एक step में दो चीजें करता है: यह download करता है जो कुछ भी remote पर बदला है, फिर तुरंत उन changes को merge करता है branch में जो आप पर हैं। git fetch केवल पहला आधा करता है। यह नई commits को download करता है लेकिन कभी उन्हें merge नहीं करता है आपकी branch में। आपकी current branch, और आपकी working files, बिल्कुल वहीं रहती हैं जहाँ वह थीं जब तक आप Git को merge या pull करने के लिए नहीं बताते।

यह trip-up है जो लगभग हर किसी को कम से कम एक बार hit करता है: git fetch run करें, कहीं कोई visible change नहीं देखें, और assume करें कि remote पर कुछ नहीं हुआ। कुछ हुआ: fetch ने अभी तक आपकी working branch को touch नहीं किया है। देखने के लिए कि क्या नीचे आया है, इस chapter के शुरुआत के remote-tracking branch को देखें: git log origin/main commits को show करता है जो remote पर बैठी हैं जो आपके local main तक नहीं पहुँची हैं। जब आप उन्हें bring करने के लिए ready हों, git merge origin/main यह करता है, या git pull उस एक command में fetch और merge को run करता है।

Fetch को अपने पर reach करें जब आप merge करने से पहले look करना चाहते हैं। Say एक teammate, Priya, mention करती है उसने main को push किया: git fetch followed by git log origin/main या git diff main origin/main आपको read करने देता है कि बिल्कुल क्या बदला है जब तक यह land नहीं करता है आपकी working branch में। एक बार आप satisfied हों, git merge origin/main इसे bring करता है। Day to day, ज्यादातर लोग straight git pull के लिए reach करते हैं, क्योंकि seeing और merging एक step में वह होता है जो वे चाहते हैं। Fetch अपनी keep को earn करता है एक shared branch पर जहाँ आप rather incoming work को पहले read करें, या merge करने के लिए decide करने से पहले कि अब एक good moment है या नहीं।

जो fetch actually update करता है वह governed है एक refspec द्वारा: एक mapping, आपके remote के config में stored, जो Git को बताता है कि remote पर कौन सी branches को bring down करें और कौन से local names उन्हें store करने के लिए। Default refspec एक normal clone पर roughly +refs/heads/*:refs/remotes/origin/* को read करता है, meaning "take every branch remote के heads के under और इसे mirror करें मेरे remote-tracking branches में, भी move करें ताकि वह match करे even अगर यह overwrite करता है कि वह क्या point करते थे।" यह पूरा mechanism है origin/main के behind current रहने के पीछे: fetch remote की branches को read करता है और rewrites करता है आपकी remote-tracking branches को match करने के लिए, फिर stop करता है। आपके अपने main के बारे में कुछ भी नहीं बदलता जब तक एक अलग merge, rebase, या pull fetch को act नहीं करता है जो down लाया है।

Junogit fetch बनाम git pullgit pull नई commits को download करता है और एक step में उन्हें merge करता है आपकी branch में। git fetch केवल उन्हें download करता है और Git की memory को update करता है कि remote कहाँ stands; आपकी branch stay रहती है जब तक आप merge नहीं करते। Fetch के बाद अपनी files में कोई change देखना expected है, नई commits remote-tracking branch पर wait कर रहीं हैं।

Junogit fetch बनाम git pullgit fetch download करता है merging के बिना, git pull download करता है और एक step में merge करता है। Plain fetch को reach करें जब आप incoming commits को git log origin/main के साथ read करना चाहते हैं जब तक वे land नहीं करते आपकी branch में, और pull जब आप उन्हें merge करने के लिए ready हों right away। दोनों को mix up करना एक team पर most common Git mix-ups में से एक है।

Junogit fetch बनाम git pull एक refspec decide करता है कि fetch exactly क्या pull करता है और कौन सी remote-tracking branches यह update करता है, origin/main included, और default one mirror करता है हर branch को remote के heads के under। Fetch केवल ever move करता है आपकी remote-tracking branches को, कभी नहीं आपकी checked-out branch को, इसलिए merging या pulling एक अलग, deliberate step रहती है।

यह आपको कहाँ छोड़ता है

Push, pull, और fetch आपकी commits को एक shared remote पर और वापस लाते हैं, जो Git में day-to-day collaboration की most को cover करता है। सब कुछ यहाँ commit loop पर build करता है: आप अभी भी locally stage और commit करते हैं पहले, एक remote केवल यह बदलता है कि वे commits कहाँ travel कर सकते हैं। अगला piece GitHub itself के through collaboration कर रहा है, एक change को propose कर रहा है और merge करने से पहले इसे review किया जा रहा है। Pull request flow बिल्कुल वहाँ pick up करता है। अगर एक term इस chapter में अभी भी shaky feel करता है, remote-tracking branch, refspec, upstream, तो Glossary के पास हर एक के लिए एक plain definition है, और What is Git Git-बनाम-GitHub distinction पर अपने आप के लिए एक दूसरा look के लायक है।