Git Clone: ആദ്യ fetch-ന് മുമ്പ് proxy സജ്ജമാക്കുക

റിപ്പോസിറ്ററി ഉണ്ടാകുന്നതിന് മുമ്പ് റിപ്പോസിറ്ററി-ലോക്കൽ proxy അസ്വാഭാവികമായി തോന്നുന്നു. പരാജയപ്പെട്ട clone ചെയ്ത് config തിരുത്തി വീണ്ടും തുടങ്ങേണ്ടതില്ല.

Clone ആദ്യ fetch-ന് മുമ്പ് ഒരു ലോക്കൽ സെറ്റിംഗ് എഴുതാം:

git clone --config http.proxy=http://proxy.example.net:8080 \
  https://git.example.net/team/project.git project

ഈ endpoint-കൾ ഉദാഹരണങ്ങളാണ്. അനുവദനീയമായ പൊതു-proxy പാതയിലുള്ള പൊതു HTTPS റിപ്പോസിറ്ററിക്ക് HTTP proxy പട്ടികയിൽ നിന്ന് HTTP endpoint തിരഞ്ഞെടുക്കുക. പുതിയ റിപ്പോസിറ്ററി ആരംഭിച്ചതിന് ശേഷവും അതിന്റെ റിമോട്ട് ചരിത്രം fetch ചെയ്യുന്നതിന് മുമ്പും ഈ ഓപ്ഷൻ പ്രാബല്യത്തിൽ വരുമെന്ന് Git രേഖപ്പെടുത്തുന്നു. അതിനാൽ ഈ proxy സെറ്റിംഗ് ആദ്യ ഡൗൺലോഡ് ഉൾക്കൊള്ളുകയും പിന്നീട് പുതിയ റിപ്പോസിറ്ററിയിൽ തുടരുകയും ചെയ്യാം.

സമാനമായ രണ്ട് കമാൻഡുകൾ വ്യത്യസ്ത അടയാളങ്ങൾ വിടുന്നു

സെറ്റിംഗ് clone ചെയ്ത റിപ്പോസിറ്ററിയിൽ സൂക്ഷിക്കാതെ ഒരു invocation-ന് പാത നൽകാൻ subcommand-ന് മുമ്പ് -c ഇടുക:

git -c http.proxy=http://proxy.example.net:8080 \
  clone https://git.example.net/team/project.git project

git clone --config ..., git -c ... clone എന്നിവ പരസ്പരം മാറ്റാവുന്ന config പരിധികളല്ല. ആ റിപ്പോസിറ്ററിയിലെ ഭാവി പ്രവർത്തനങ്ങൾ proxy നിലനിർത്തണോ എന്ന് തിരഞ്ഞെടുക്കുക.

ഈ തിരഞ്ഞെടുപ്പ് പ്രധാനമാകുമ്പോൾ പുതിയ റിപ്പോസിറ്ററിയുടെ ലോക്കൽ config പരിശോധിക്കുക. മറ്റ് user, system അല്ലെങ്കിൽ URL-നിർദ്ദിഷ്ട സെറ്റിംഗുകൾക്ക് ഫലപ്രദമായ നയത്തിൽ ഇപ്പോഴും പങ്കെടുക്കാം.

പാത സൂക്ഷിക്കുമ്പോൾ ഈ ഉദാഹരണങ്ങളിൽ നിന്ന് പാസ്വേഡുകൾ അകറ്റി നിർത്തുക. clone-ന്റെ config ഓപ്ഷന് നൽകുന്ന ക്രെഡൻഷ്യലുള്ള മൂല്യം സ്ഥിരമായ റിപ്പോസിറ്ററി സെറ്റിംഗ് ആയി മാറാം.

ഇത് HTTP-transport config ആണ്, HTTPS റിമോട്ടുകൾ ഉൾപ്പെടെ. SSH റിമോട്ടിന് ഇപ്പോഴും അതിന്റെ SSH proxy പാത ആവശ്യമാണ്; SSH-നെ port 443-ലേക്ക് മാറ്റുന്നത് ഈ ഓപ്ഷൻ അത് config ചെയ്യാൻ ഇടയാക്കുന്നില്ല.