പ്രൊഫൈലുകൾ ഒരേ സമയം രണ്ട് ആവശ്യങ്ങൾ നിർവഹിക്കുന്നു: അവ കണക്ഷൻ ക്രമീകരണങ്ങൾ രേഖപ്പെടുത്തുന്നു, പ്രവർത്തിക്കുന്ന ഒരു കൂട്ടം ക്രെഡൻഷ്യലുകളും വഹിക്കുന്നു. ഫയൽ എക്സ്റ്റൻഷൻ നിങ്ങളുടെ കൈയിൽ ഏതാണ് എന്ന് ഒന്നും പറയുന്നില്ല. അത് ഒരു റിപ്പോസിറ്ററിയുടേതാണെന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് ഉള്ളടക്കം വായിക്കുക.

താഴെയുള്ള ഘട്ടങ്ങൾ ഒരു ക്ലയന്റ് ടെംപ്ലേറ്റ് പതിപ്പ് നിയന്ത്രണത്തിനായി പരിഗണിക്കുന്നു എന്ന് അനുമാനിക്കുന്നു. അവ ക്രമത്തിൽ നടത്തുക, നിങ്ങൾക്ക് റദ്ദാക്കാൻ കഴിയാത്ത ഒന്നും കമ്മിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് നിർത്തുക.

നിങ്ങൾ സ്റ്റേജ് ചെയ്യാൻ പോകുന്ന ഫയൽ വായിക്കുക

യഥാർത്ഥ ബൈറ്റുകളിൽ നിന്ന് തുടങ്ങുക, കാരണം വെവ്വേറെ ഫയലുകളെ പരാമർശിക്കുന്ന പ്രൊഫൈൽ അവ ഉൾച്ചേർക്കുന്നതിൽ നിന്ന് തികച്ചും വ്യത്യസ്തമായി കാണപ്പെടുന്നു. PEM ബ്ലോക്ക് അടയാളങ്ങളും ca, cert, key, tls-auth, tls-crypt എന്നീ പേരുള്ള ഇൻലൈൻ ടാഗുകളും തിരയുക, അതേ പരിശോധന രണ്ട് സാഹചര്യങ്ങളും കാണിക്കും. എൻക്രിപ്റ്റ് ചെയ്ത സ്വകാര്യ കീ ഇപ്പോഴും സംവേദനക്ഷമമായ വസ്തുവായി കണക്കാക്കുന്നു, പങ്കിട്ട tls-auth അല്ലെങ്കിൽ tls-crypt കീ ഉപയോക്താവിന്റെ അടയാളമല്ലെങ്കിലും ക്രെഡൻഷ്യലാണ്. ക്രെഡൻഷ്യൽ ഫയലിനെ പരാമർശിക്കുന്ന ആർക്കൈവുകളും സെറ്റപ്പ് സ്ക്രിപ്റ്റുകളും ഉൾപ്പെടെ, പ്രൊഫൈലിനൊപ്പം സ്റ്റേജ് ചെയ്യുന്ന എല്ലാറ്റിനും അതേ പരിശോധന ബാധകമാക്കുക.

തുടർന്ന് പ്രവൃത്തി മരമല്ല, സ്റ്റേജ് ചെയ്ത കൂട്ടം നോക്കുക. git diff --cached കമ്മിറ്റിൽ യഥാർത്ഥത്തിൽ എന്ത് ഉണ്ടാകുമെന്ന് കാണിക്കുന്നു, ഈ തീരുമാനത്തിന് പ്രസക്തമായ ഏക പതിപ്പ് അതാണ്.

റിപ്പോസിറ്ററിക്ക് എന്ത് വിതരണം ചെയ്യാം എന്ന് തീരുമാനിക്കുക

ഒരു ടെംപ്ലേറ്റിന് പങ്കിട്ട, അവലോകനം ചെയ്ത ക്രമീകരണങ്ങളും ഒരാൾ രജിസ്ട്രേഷനിൽ ലഭിക്കുന്ന എല്ലാറ്റിനുമുള്ള പേരുള്ള പ്ലേസ്ഹോൾഡറുകളും വഹിക്കാം. വഹിക്കാൻ കഴിയാത്തത് ഉപയോഗയോഗ്യമായ അടയാളമാണ്, കാരണം റിപ്പോസിറ്ററി അത് വായിക്കാൻ കഴിയുന്ന എല്ലാവർക്കും വിതരണം ചെയ്യപ്പെടുന്നു, ഓട്ടോമേഷൻ ഉൾപ്പെടെ. സ്വകാര്യ റിപ്പോസിറ്ററി പ്രേക്ഷകരെ ചുരുക്കുന്നു, പക്ഷേ ഓരോ വായനക്കാരനും ആ ക്രെഡൻഷ്യലിന് അധികാരമുണ്ടോ എന്ന ചോദ്യം മാറ്റുന്നില്ല.

അവഗണനാ നിയമം ഭാവിയിലെ കൂട്ടിച്ചേർക്കലുകൾ തടയുന്നു, ഇതിനകം രേഖപ്പെടുത്തിയതിനെക്കുറിച്ച് ഒന്നും ചെയ്യുന്നില്ല. ഈ അസമത്വം പത്താമത്തെ കമ്മിറ്റിന് ശേഷമല്ല, ആദ്യത്തേതിന് മുമ്പ് ഉൾക്കൊള്ളേണ്ടതാണ്. ഇൻഫ്രാസ്ട്രക്ചറിന്റെ പേരുകളും വിലാസങ്ങളും വേറിട്ട ഒരു വിലയിരുത്തലാണ്: അവ പ്രാമാണീകരണ രഹസ്യങ്ങളല്ല, പക്ഷേ ഒരു സംഘം പ്രസിദ്ധീകരിക്കാൻ ഉദ്ദേശിക്കുന്നതിലും കൂടുതൽ വെളിപ്പെടുത്തിയേക്കാം. ഓരോ വരിയും പാസ്വേഡ് അല്ലെങ്കിൽ പൊതു എന്ന് തരംതിരിക്കുന്നതിന് പകരം ആ തീരുമാനം വ്യക്തമായി എടുക്കുക.

ഉള്ളടക്കം ഇതിനകം ചരിത്രത്തിലുണ്ടെങ്കിൽ

പുതിയ കമ്മിറ്റിൽ വരി നീക്കം ചെയ്യുന്നത് അത് എടുക്കുന്ന ആർക്കും പഴയ പതിപ്പ് അതേപടി നിലനിർത്തുന്നു. വെളിപ്പെടുത്തലിനെ യാഥാർത്ഥ്യമായി കാണുക: ക്രെഡൻഷ്യലിന്റെ തരം തിരിച്ചറിയുക, തുടർന്ന് അത് അസാധുവാക്കാൻ കഴിയുന്ന അധികാരിയെ കണ്ടെത്തുക. ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് റദ്ദാക്കപ്പെടുന്നു, റദ്ദാക്കൽ പട്ടിക വീണ്ടും സൃഷ്ടിക്കപ്പെടുന്നു; പങ്കിട്ട നിയന്ത്രണ ചാനൽ കീ സെർവറിലും അത് ഉപയോഗിക്കുന്ന ഓരോ ക്ലയന്റിലും മാറ്റപ്പെടുന്നു.

രണ്ടിന്റെയും സ്വാധീന പരിധി വളരെ വ്യത്യസ്തമാണ്, തുടങ്ങുന്നതിന് മുമ്പ് ഏതാണ് നടപ്പാക്കുന്നതെന്ന് പ്ലാൻ പറയണം. git log --all -S 'BEGIN PRIVATE KEY' പോലുള്ള ഒരു തിരയലിലൂടെ ഉള്ളടക്കം കൊണ്ടുവന്ന കമ്മിറ്റ് കണ്ടെത്തുക, വൃത്തിയാക്കലിന്റെ പരിധി ഊഹമല്ലാതെ അറിയപ്പെടുന്നതാകാൻ. സഹപ്രവർത്തകന്റെ ക്ലോൺ അല്ലെങ്കിൽ ഫോർക്ക് പഴയ ഒബ്ജക്റ്റ് ഇതിനകം കൈവശം വെച്ചേക്കാം, അതിനാൽ റദ്ദാക്കൽ ആദ്യവും വൃത്തിയാക്കൽ പിന്നീടും വരുന്നു.

നിയന്ത്രിച്ചതിന് ശേഷം മാത്രം വൃത്തിയാക്കുക

ചരിത്രം വീണ്ടും എഴുതുന്നത് നിങ്ങൾ തിരുത്തുന്ന കമ്മിറ്റിന് ശേഷമുള്ള ഓരോ കമ്മിറ്റും മാറ്റുന്നു, അതിനാൽ ആദ്യം റിപ്പോസിറ്ററി ഉടമയുടെയും അതിൽ ജോലി ചെയ്യുന്നവരുടെയും സമ്മതം വേണം. നിർബന്ധിത പുഷ് ഒരു അറ്റകുറ്റപ്പണിയല്ല; അതിന്റേതായ തിരിച്ചുപോക്ക് അപകടസാധ്യതയുള്ള ഒരു ഏകോപന സംഭവമാണ്. അത് ഷെഡ്യൂൾ ചെയ്യുക, ബാക്കപ്പ് എടുക്കുക, എപ്പോൾ സംഭവിക്കുമെന്ന് സംഘത്തെ അറിയിക്കുക.

അതിന് ശേഷം, ടൂളിന്റെ സംഗ്രഹം വിശ്വസിക്കുന്നതിന് പകരം നിലവിലെ മരവും ബാക്കിയുള്ള ചരിത്രവും പരിശോധിക്കുക.

ഫലം രണ്ട് നിർമ്മിതികളായി സൂക്ഷിക്കുക: പങ്കിടാൻ സുരക്ഷിതമായ ടെംപ്ലേറ്റ്, രജിസ്ട്രേഷൻ പ്രക്രിയയിൽ പുറപ്പെടുവിച്ച ക്രെഡൻഷ്യലുകളുടെ പട്ടിക. രണ്ടിനും റിപ്പോസിറ്ററിയിൽ ഉപയോഗയോഗ്യമായ അടയാളം ജീവിക്കണമെന്ന് ആവശ്യപ്പെടുന്നില്ല.

ആ വേർതിരിവാണ് യഥാർത്ഥ പരിഹാരം, അത് അടുത്തതായി പ്രൊഫൈൽ കമ്മിറ്റ് ചെയ്യാൻ ആഗ്രഹിക്കുന്ന വ്യക്തിക്ക് ശേഷവും നിലനിൽക്കുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ