🥇ഡോക്യുമെന്റേഷനായി GIT ഉപയോഗിക്കുക

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

സമീപനം ഇവിടെ വിവരിച്ചിരിക്കുന്നു, കൂടെ ഒരു നിർദ്ദിഷ്ട നടപ്പാക്കലിന്റെ ഉദാഹരണം, കുറഞ്ഞ പ്രവേശന തടസ്സമുണ്ട്. സാങ്കേതികമായി, നിങ്ങൾക്ക് നാളെ പുതിയ രീതിയിൽ പ്രവർത്തിക്കാൻ തുടങ്ങാം.

പ്രശ്ന പ്രസ്താവന

നിങ്ങൾ ഒരു പ്രമാണം അല്ലെങ്കിൽ പ്രമാണങ്ങളുടെ ഒരു കൂട്ടം സൃഷ്ടിക്കേണ്ടതുണ്ട്. ഒരുപക്ഷേ ഇത് പ്രോജക്റ്റ് ഡോക്യുമെന്റേഷൻ അല്ലെങ്കിൽ നിങ്ങളുടെ നെറ്റ്‌വർക്കിന്റെ ലോഗിംഗ് അല്ലെങ്കിൽ ലളിതമായ എന്തെങ്കിലും, ഉദാഹരണത്തിന്, നിങ്ങൾ കമ്പനിയിലോ നിങ്ങളുടെ വകുപ്പിലോ ഉള്ള പ്രക്രിയകൾ വിവരിക്കണം. പൊതുവേ, നമ്മൾ സംസാരിക്കുന്നത് വാചകം, ചിത്രങ്ങൾ, അടയാളങ്ങൾ എന്നിവയുള്ള ഏതെങ്കിലും പ്രമാണത്തെക്കുറിച്ചോ പ്രമാണങ്ങളുടെ സെറ്റിനെക്കുറിച്ചോ ആണ്...

ഈ ജോലിയിൽ സംയുക്ത ജോലി, ഒരു ഗ്രൂപ്പിന്റെ അല്ലെങ്കിൽ നിരവധി ജീവനക്കാരുടെ ഗ്രൂപ്പുകളുടെ പരിശ്രമം എന്നിവ ഉൾപ്പെടുന്നു
തൽഫലമായി, ഒരു പ്രത്യേക ടെംപ്ലേറ്റ് അനുസരിച്ച് സൃഷ്‌ടിച്ച കോർപ്പറേറ്റ് ശൈലി ആട്രിബ്യൂട്ടുകളുള്ള ഒരു പ്രത്യേക ഫോർമാറ്റിൽ ഒരു ഡോക്യുമെന്റ് ഉണ്ടായിരിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു. വ്യക്തമായി പറഞ്ഞാൽ, ഇത് MS Word (.docx) ആണെന്ന് ഞങ്ങൾ അനുമാനിക്കും.

10 വർഷം മുമ്പ്, സമീപനം നേരെയാകുമായിരുന്നു: ഞങ്ങൾ ഒരു എംഎസ് വേഡ് ഡോക്യുമെന്റോ ഡോക്യുമെന്റുകളോ സൃഷ്ടിക്കുകയും എങ്ങനെയെങ്കിലും മാറ്റുന്നതിനുള്ള പ്രവർത്തനങ്ങൾ സംഘടിപ്പിക്കുകയും ചെയ്യുമായിരുന്നു.

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

ഉദാഹരണം:
ഒരു വലിയ ഇന്റഗ്രേറ്ററിന് വേണ്ടി പ്രവർത്തിക്കുമ്പോൾ എനിക്ക് ഈ പ്രശ്നം വളരെ രൂക്ഷമായി അനുഭവപ്പെട്ടു. ഡിസൈൻ ഡോക്യുമെന്റേഷൻ മാറ്റുന്ന പ്രക്രിയ ഇപ്രകാരമായിരുന്നു:

എഞ്ചിനീയർ MS Word (.docx) ഡോക്യുമെന്റിന്റെ ഏറ്റവും പുതിയ പതിപ്പ് ഡൗൺലോഡ് ചെയ്യുന്നു

പേര് മാറ്റുന്നു

ഫാഷൻ ട്രാക്ക് ചെയ്യാൻ മാറ്റങ്ങൾ വരുത്തുന്നു

തിരുത്തലുകളുള്ള പ്രമാണം ആർക്കിടെക്റ്റിന് അയയ്ക്കുന്നു

അഭിപ്രായങ്ങൾക്കൊപ്പം എല്ലാ തിരുത്തലുകളുടെയും ഒരു ലിസ്റ്റും അയയ്ക്കുന്നു

ആർക്കിടെക്റ്റ് മാറ്റങ്ങൾ വിശകലനം ചെയ്യുന്നു

എല്ലാം ശരിയാണെങ്കിൽ, അത് ഈ മാറ്റങ്ങൾ ഏറ്റവും പുതിയ പതിപ്പുള്ള ഒരു ഫയലിലേക്ക് പകർത്തുകയും പതിപ്പ് മാറ്റുകയും പങ്കിട്ട ഉറവിടത്തിലേക്ക് അപ്‌ലോഡ് ചെയ്യുകയും ചെയ്യുന്നു

അഭിപ്രായങ്ങൾ ഉണ്ടെങ്കിൽ, ഒരു ചർച്ച ആരംഭിക്കും (ഇമെയിൽ അല്ലെങ്കിൽ മീറ്റിംഗുകൾ)

സമവായത്തിലെത്തി

കൂടുതൽ പോയിന്റുകൾ 3-9
ജോലി തീവ്രമായിരുന്നില്ലെങ്കിലും, അത് എങ്ങനെയോ ആയിരുന്നു, പക്ഷേ അത് ഇപ്പോഴും പ്രവർത്തിച്ചു. എന്നാൽ ഒരു പ്രത്യേക ഘട്ടത്തിൽ, ഈ പ്രക്രിയ മുഴുവൻ പദ്ധതിയുടെ തടസ്സമായി മാറുകയും പ്രശ്നങ്ങളിലേക്ക് നയിക്കുകയും ചെയ്തു. പല ടീമുകളും ഇടയ്ക്കിടെയും ഒരേസമയം മാറ്റങ്ങൾ വരുത്തുമ്പോൾ തന്നെ കാര്യങ്ങൾ മോശമാകും എന്നതാണ് കാര്യം.
അതിനാൽ, ഞങ്ങൾ പ്രാഥമിക പരിശോധനാ ഘട്ടത്തിലേക്ക് മാറിയപ്പോൾ, വിവിധ പ്രശ്നങ്ങൾ പ്രത്യക്ഷപ്പെടാൻ തുടങ്ങി, ചെറിയ രീതിയിൽ ആണെങ്കിലും, ഡോക്യുമെന്റേഷൻ പലപ്പോഴും മാറ്റേണ്ടത് ആവശ്യമാണ് - നാല് വ്യത്യസ്ത ടീമുകൾ, എല്ലാ ദിവസവും, ഏതാണ്ട് ഒരേസമയം, ചർച്ചകൾ. ഈ മാറ്റങ്ങളെല്ലാം സംഭവിച്ചത് ഒരു എഞ്ചിനീയർ വഴിയാണ് - ഒരു ആർക്കിടെക്റ്റ്. പ്രോജക്റ്റ് ഡിസൈൻ ഫയൽ വളരെ വലുതായിരുന്നു, തൽഫലമായി, ആർക്കിടെക്റ്റ് ധാരാളം പകർത്തൽ, എഡിറ്റിംഗ്, ധാരാളം തെറ്റുകൾ എന്നിവ ഉൾപ്പെടുന്ന പതിവ് ജോലികളിൽ മുഴുകി, എല്ലാം രണ്ടുതവണ പരിശോധിക്കുകയും വീണ്ടും അയയ്‌ക്കുകയും ചെയ്യേണ്ടിവന്നു. കുഴപ്പം.
ഈ സാഹചര്യത്തിൽ, ഈ സമീപനം, ഒരു എംഎസ് വേഡ് ഡോക്യുമെന്റിൽ ജോലി ചെയ്യുന്ന സമീപനം, വളരെ പ്രയാസത്തോടെ പ്രവർത്തിക്കുകയും പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുകയും ചെയ്തു.

ജിറ്റ്, മാർക്ക്ഡൗൺ

മുകളിലുള്ള ഉദാഹരണത്തിൽ വിവരിച്ച പ്രശ്നം അഭിമുഖീകരിച്ചപ്പോൾ, ഞാൻ ഈ പ്രശ്നം അന്വേഷിക്കാൻ തുടങ്ങി.
ഉപയോഗിക്കുന്നത് ഞാൻ കണ്ടു മര്ക്ദൊവ്ന് совестно с Git പ്രമാണങ്ങൾ സൃഷ്ടിക്കുമ്പോൾ.

Git ഒരു വികസന ഉപകരണമാണ്. എന്നാൽ ഡോക്യുമെന്റേഷൻ പ്രക്രിയയ്ക്കായി എന്തുകൊണ്ട് ഇത് ഉപയോഗിക്കരുത്? ഈ സാഹചര്യത്തിൽ, മൾട്ടി-യൂസർ വർക്കിന്റെ പ്രശ്നം പരിഹരിക്കപ്പെടും. എന്നാൽ Git ന്റെ കഴിവുകൾ പൂർണ്ണമായി പ്രയോജനപ്പെടുത്തുന്നതിന്, ഞങ്ങൾക്ക് ഒരു ടെക്സ്റ്റ് ഡോക്യുമെന്റ് ഫോർമാറ്റ് ആവശ്യമാണ്, MS Word അല്ലാതെ മറ്റൊരു ഉപകരണം കണ്ടെത്തേണ്ടതുണ്ട്, ഈ ആവശ്യങ്ങൾക്ക് Markdown മികച്ചതാണ്.

മാർക്ക്ഡൗൺ ഒരു ലളിതമായ ടെക്സ്റ്റ് മാർക്ക്അപ്പ് ഭാഷയാണ്. സാധാരണ TXT ഫയലുകളിൽ മനോഹരമായി രൂപകൽപ്പന ചെയ്‌ത ടെക്‌സ്‌റ്റുകൾ സൃഷ്‌ടിക്കാൻ ഇത് രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു. ഞങ്ങൾ മാർക്ക്ഡൗണിൽ ഞങ്ങളുടെ പ്രമാണങ്ങൾ സൃഷ്ടിക്കുകയാണെങ്കിൽ, മാർക്ക്ഡൗൺ - ജിറ്റ് കോമ്പിനേഷൻ സ്വാഭാവികമായി കാണപ്പെടുന്നു.

എല്ലാം ശരിയാകും, ഈ ഘട്ടത്തിൽ നമുക്ക് ഇത് അവസാനിപ്പിക്കാം, ഞങ്ങളുടെ രണ്ടാമത്തെ വ്യവസ്ഥയല്ലെങ്കിൽ: “തൽഫലമായി, ഞങ്ങൾക്ക് ഒരു പ്രത്യേക ഫോർമാറ്റിൽ ഒരു പ്രമാണം ആവശ്യമാണ്, ഒരു കോർപ്പറേറ്റ് ശൈലിയുടെ ആട്രിബ്യൂട്ടുകൾ, അനുസരിച്ച് സൃഷ്ടിച്ചത് ഒരു നിശ്ചിത ടെംപ്ലേറ്റ്" (തീർച്ചയായും അത് MS Word ആയിരിക്കുമെന്ന് ഞങ്ങൾ തുടക്കത്തിൽ സമ്മതിച്ചു). അതായത്, ഞങ്ങൾ മാർക്ക്ഡൗൺ ഉപയോഗിക്കാൻ തീരുമാനിക്കുകയാണെങ്കിൽ, ഈ ഫയൽ എങ്ങനെയെങ്കിലും ആവശ്യമായ തരത്തിലുള്ള .docx ആക്കി മാറ്റേണ്ടതുണ്ട്.

വ്യത്യസ്ത ഫോർമാറ്റുകൾക്കിടയിൽ പരിവർത്തനം ചെയ്യുന്നതിനുള്ള പ്രോഗ്രാമുകളുണ്ട്, ഉദാ. പണ്ടോക്.
ഈ പ്രോഗ്രാം ഉപയോഗിച്ച് നിങ്ങൾക്ക് Markdown ഫയൽ .docx ഫോർമാറ്റിലേക്ക് പരിവർത്തനം ചെയ്യാൻ കഴിയും.
എന്നിട്ടും, നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്, ഒന്നാമതായി, മാർക്ക്ഡൗണിലുള്ളതെല്ലാം എംഎസ് വേഡിലേക്ക് പരിവർത്തനം ചെയ്യപ്പെടില്ല, രണ്ടാമതായി, മെലിഞ്ഞതും എന്നാൽ ഇപ്പോഴും ചെറിയ പട്ടണമായ മാർക്ക്ഡൗണുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ എംഎസ് വേഡ് ഒരു രാജ്യമാണ്. മാർക്ക്ഡൗണിൽ ഒരു രൂപത്തിലും ഇല്ലാത്ത വേർഡിലുള്ള എല്ലാത്തിനും ഒരു വലിയ തുകയുണ്ട്. ചില Pandoc കീകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് മുന്നോട്ട് പോയി നിങ്ങളുടെ മാർക്ക്ഡൗൺ ഫോർമാറ്റ് ആവശ്യമുള്ള MS Word ഫോർമാറ്റിലേക്ക് പരിവർത്തനം ചെയ്യാൻ കഴിയില്ല. അതിനാൽ സാധാരണയായി, പരിവർത്തനത്തിന് ശേഷം, തത്ഫലമായുണ്ടാകുന്ന .docx പ്രമാണം നിങ്ങൾ സ്വമേധയാ "എഡിറ്റ്" ചെയ്യണം, അത് വീണ്ടും സമയമെടുക്കുകയും പിശകുകളിലേക്ക് നയിക്കുകയും ചെയ്യും.

Pandoc-ന് കൈകാര്യം ചെയ്യാൻ കഴിയാത്തത് സ്വയമേവ "പൂർത്തിയാക്കാൻ" കഴിയുന്ന ഒരു സ്ക്രിപ്റ്റ് ഞങ്ങൾക്ക് എഴുതാൻ കഴിയുമെങ്കിൽ, അത് അനുയോജ്യമായ ഒരു പരിഹാരമായിരിക്കും.

എംഎസ് വേഡിന്റെയും മാർക്ക്ഡൌണിന്റെയും പ്രവർത്തനക്ഷമതയുടെ ഐഡന്റിറ്റി ഇല്ലാത്തതിനാൽ, പൊതുവായി ഈ പ്രശ്നം പരിഹരിക്കുന്നത് അസാധ്യമാണ്, പക്ഷേ നിർദ്ദിഷ്ട സാഹചര്യങ്ങൾ, നിർദ്ദിഷ്ട ആവശ്യകതകൾ എന്നിവയുമായി ബന്ധപ്പെട്ട് ഇത് ചെയ്യാൻ കഴിയുമോ? അതെ, ഇത് സാധ്യമാണെന്നും മിക്കവാറും പലർക്കും അല്ലെങ്കിൽ മിക്ക സാഹചര്യങ്ങളിലും ഇത് സാധ്യമാണെന്നും എന്റെ അനുഭവം തെളിയിച്ചിട്ടുണ്ട്.

ഒരു പ്രത്യേക പ്രശ്നത്തിന്റെ പരിഹാരം

അതിനാൽ, എന്റെ കാര്യത്തിൽ, Pandoc ഉപയോഗിച്ച് ഫയൽ പരിവർത്തനം ചെയ്തതിന് ശേഷം, എനിക്ക് അധിക ഫയൽ പ്രോസസ്സിംഗ് സ്വമേധയാ ചെയ്യേണ്ടിവന്നു, അതായത്

പട്ടികകളുടെയും ചിത്രങ്ങളുടെയും തലക്കെട്ടുകളുടെ (അടിക്കുറിപ്പുകൾ) ഓട്ടോമാറ്റിക് നമ്പറിംഗ് ഉപയോഗിച്ച് Word-ലേക്ക് ഫീൽഡുകൾ ചേർക്കുക
പട്ടിക ശൈലി മാറ്റുക

സ്റ്റാൻഡേർഡ് (Pandoc) അല്ലെങ്കിൽ അറിയപ്പെടുന്ന മാർഗങ്ങൾ ഉപയോഗിച്ച് ഇത് എങ്ങനെ ചെയ്യാമെന്ന് ഞാൻ കണ്ടെത്തിയില്ല. അതിനാൽ ഞാൻ പൈത്തൺ സ്ക്രിപ്റ്റ് പ്രയോഗിച്ചു പൈവിൻ32 പാക്കേജ്. തൽഫലമായി, എനിക്ക് പൂർണ്ണ ഓട്ടോമേഷൻ ലഭിച്ചു. ഇപ്പോൾ എനിക്ക് എന്റെ മാർക്ക്ഡൗൺ ഫയൽ ഒരു കമാൻഡ് ഉപയോഗിച്ച് ആവശ്യമുള്ള MS Word ഡോക്യുമെന്റ് ഫോമിലേക്ക് പരിവർത്തനം ചെയ്യാൻ കഴിയും.

വിശദാംശങ്ങൾ കാണുക ഇവിടെ.

കുറിപ്പ്
ഈ ഉദാഹരണത്തിൽ, തീർച്ചയായും, ഞാൻ ചില അമൂർത്തമായ മാർക്ക്ഡൗൺ ഫയൽ പരിവർത്തനം ചെയ്യുന്നു, എന്നാൽ "കോംബാറ്റ്" ഡോക്യുമെന്റിലും അതേ സമീപനം പ്രയോഗിച്ചു, എനിക്ക് ലഭിച്ച ഔട്ട്പുട്ട്, മാനുവൽ ഫോർമാറ്റിംഗ് വഴി ഞങ്ങൾക്ക് മുമ്പ് ലഭിച്ച അതേ MS Word ഡോക്യുമെന്റ് ആയിരുന്നു. .

പൊതുവേ, pywin32 ഉപയോഗിച്ച്, MS Word ഡോക്യുമെന്റിന്റെ മേൽ ഞങ്ങൾക്ക് ഏതാണ്ട് പൂർണ്ണമായ നിയന്ത്രണം ലഭിക്കുന്നു, അത് അത് മാറ്റാനും നിങ്ങളുടെ കോർപ്പറേറ്റ് സ്റ്റാൻഡേർഡിന് ആവശ്യമായ ഫോമിലേക്ക് കൊണ്ടുവരാനും ഞങ്ങളെ അനുവദിക്കുന്നു. തീർച്ചയായും, മറ്റ് ഉപകരണങ്ങൾ ഉപയോഗിച്ച് സമാന ലക്ഷ്യങ്ങൾ കൈവരിക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, VBA മാക്രോകൾ, പക്ഷേ പൈത്തൺ ഉപയോഗിക്കുന്നത് എനിക്ക് കൂടുതൽ സൗകര്യപ്രദമായിരുന്നു.

ഈ സമീപനത്തിനുള്ള ഒരു ഹ്രസ്വ ഫോർമുല:

Markdown + Git -- (нечто) --> MS Word

"എന്തെങ്കിലും" എന്നത് പ്രശ്നമല്ല. എന്റെ കാര്യത്തിൽ, അത് പൈവിൻ 32 ഉള്ള പാണ്ടോക്കും പൈത്തണും ആയിരുന്നു. നിങ്ങളുടെ മുൻഗണനകൾ വ്യത്യസ്തമായിരിക്കാം, പക്ഷേ പ്രധാന കാര്യം അത് സാധ്യമാണ് എന്നതാണ്. ഈ ലേഖനത്തിന്റെ പ്രധാന സന്ദേശം ഇതാണ്.

ചുരുക്കത്തിൽ, ഈ സമീപനത്തിലൂടെ നിങ്ങൾ മാർക്ക്ഡൗൺ ഫയലിൽ മാത്രം പ്രവർത്തിക്കുകയും സഹകരണത്തിനും പതിപ്പ് നിയന്ത്രണത്തിനുമായി Git ഉപയോഗിക്കുകയും ആവശ്യമുള്ളപ്പോൾ മാത്രം (ഉദാഹരണത്തിന്, ക്ലയന്റിന് ഡോക്യുമെന്റേഷൻ നൽകുന്നതിന്) ആവശ്യമുള്ള ഫോർമാറ്റിൽ സ്വയമേവ ഒരു ഫയൽ സൃഷ്ടിക്കുക എന്നതാണ് ആശയം. ഉദാഹരണത്തിന്, MS Word ).

പ്രക്രിയ

പലർക്കും, ഡോക്യുമെന്റേഷനുമായി പ്രവർത്തിക്കുന്ന പ്രക്രിയ ഇപ്പോൾ എങ്ങനെ സംഘടിപ്പിക്കാമെന്ന് മനസിലാക്കാൻ മുകളിൽ നൽകിയിരിക്കുന്ന ഫോർമുല മതിയെന്ന് ഞാൻ കരുതുന്നു. എന്നിട്ടും, ഞാൻ സാധാരണയായി നെറ്റ്‌വർക്ക് എഞ്ചിനീയർമാരിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു, അതിനാൽ ജോലി പ്രക്രിയ ഇപ്പോൾ എങ്ങനെയിരിക്കാമെന്നും എംഎസ് വേഡ് ഫയലുകൾ എഡിറ്റുചെയ്യുന്ന സമീപനത്തിൽ നിന്ന് ഇത് എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നുവെന്നും ഞാൻ പൊതുവായി കാണിക്കും.

വ്യക്തമായി പറഞ്ഞാൽ, Git-മായി പ്രവർത്തിക്കാനുള്ള പ്ലാറ്റ്‌ഫോമായി ഞങ്ങൾ GitHub തിരഞ്ഞെടുക്കും. അതിനുശേഷം നിങ്ങൾ ഒരു റിപ്പോസിറ്ററി സൃഷ്ടിച്ച്, മാസ്റ്റർ ബ്രാഞ്ചിൽ നിങ്ങൾ പ്രവർത്തിക്കാൻ ഉദ്ദേശിക്കുന്ന മാർക്ക്ഡൗൺ ഫയലോ ഫയലുകളോ സ്ഥാപിക്കണം.

"ഗിത്തബ് ഫ്ലോ" അടിസ്ഥാനമാക്കിയുള്ള ഒരു ലളിതമായ പ്രക്രിയ ഞങ്ങൾ നോക്കാം. അതിന്റെ വിവരണം ഇന്റർനെറ്റിലും ഇൻറർനെറ്റിലും കാണാം ഹബ്രെ.

ഡോക്യുമെന്റേഷനിൽ നാല് പേർ ജോലി ചെയ്യുന്നുണ്ടെന്നും അവരിൽ ഒരാളാണ് നിങ്ങളെന്നും പറയുക. തുടർന്ന് നാല് അധിക ശാഖകൾ സൃഷ്ടിക്കപ്പെടുന്നു, ഉദാഹരണത്തിന്, ഈ ആളുകളുടെ പേരുകൾ. എല്ലാവരും പ്രാദേശികമായി, സ്വന്തം ബ്രാഞ്ചിൽ പ്രവർത്തിക്കുകയും ആവശ്യമായ എല്ലാ മാറ്റങ്ങളും വരുത്തുകയും ചെയ്യുന്നു git കമാൻഡുകൾ.

പൂർത്തിയാക്കിയ ചില ജോലികൾ പൂർത്തിയാക്കിയ ശേഷം, നിങ്ങൾ ഒരു പുൾ അഭ്യർത്ഥന സൃഷ്ടിക്കുന്നു, അങ്ങനെ നിങ്ങളുടെ മാറ്റങ്ങളെക്കുറിച്ചുള്ള ചർച്ച ആരംഭിക്കുന്നു. ഒരുപക്ഷേ, ചർച്ചയ്ക്കിടെ, നിങ്ങൾ മറ്റെന്തെങ്കിലും ചേർക്കുകയോ മാറ്റുകയോ ചെയ്യണമെന്ന് അത് മാറുന്നു. ഈ സാഹചര്യത്തിൽ, നിങ്ങൾ ആവശ്യമായ മാറ്റങ്ങൾ വരുത്തുകയും ഒരു അധിക പുൾ അഭ്യർത്ഥന സൃഷ്ടിക്കുകയും ചെയ്യുക. ഒടുവിൽ, നിങ്ങളുടെ മാറ്റങ്ങൾ അംഗീകരിക്കുകയും മാസ്റ്റർ ബ്രാഞ്ചിലേക്ക് ലയിപ്പിക്കുകയും ചെയ്യുന്നു (അല്ലെങ്കിൽ നിരസിച്ചു).

തീർച്ചയായും, ഇത് തികച്ചും പൊതുവായ വിവരണമാണ്. വിശദമായ ഒരു പ്രക്രിയ സൃഷ്ടിക്കുന്നതിന്, നിങ്ങളുടെ ഡെവലപ്പർമാരെ ബന്ധപ്പെടാനോ അറിവുള്ള ആളുകളെ കണ്ടെത്താനോ ഞാൻ നിർദ്ദേശിക്കുന്നു. എന്നാൽ Git-ലേക്ക് പ്രവേശിക്കുന്നതിനുള്ള തടസ്സം വളരെ കുറവാണെന്ന് ഞാൻ ശ്രദ്ധിക്കാൻ ആഗ്രഹിക്കുന്നു. പ്രോട്ടോക്കോൾ ലളിതമാണെന്ന് ഇതിനർത്ഥമില്ല, എന്നാൽ നിങ്ങൾക്ക് ലളിതമായി ആരംഭിക്കാം. നിങ്ങൾക്ക് ഒന്നും അറിയില്ലെങ്കിൽ, കുറച്ച് മണിക്കൂറുകളോ അല്ലെങ്കിൽ ദിവസങ്ങളോ പഠിച്ച് ഇൻസ്റ്റാൾ ചെയ്തതിന് ശേഷം നിങ്ങൾക്ക് ഇത് ഉപയോഗിക്കാൻ തുടങ്ങാമെന്ന് ഞാൻ കരുതുന്നു.

മുകളിലുള്ള ഉദാഹരണത്തിൽ വിവരിച്ചിരിക്കുന്ന പ്രക്രിയയുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഈ സമീപനത്തിന്റെ പ്രയോജനം എന്താണ്?

വാസ്തവത്തിൽ, പ്രക്രിയകൾ തികച്ചും സമാനമാണ്, നിങ്ങൾ മാറ്റിസ്ഥാപിച്ചു

ഒരു ഫയൽ പകർത്തുന്നു -> ഒരു ശാഖ സൃഷ്ടിക്കുന്നു
അവസാന ഫയലിലേക്ക് ടെക്സ്റ്റ് പകർത്തുന്നു -> ലയിപ്പിക്കുന്നു
ഏറ്റവും പുതിയ മാറ്റങ്ങൾ നിങ്ങളിലേക്ക് പകർത്തുന്നു -> git pull/fetch
കത്തിടപാടുകളിലെ ചർച്ച -> അഭ്യർത്ഥനകൾ പിൻവലിക്കുക
ട്രാക്ക് മോഡ് -> git diff
ഏറ്റവും പുതിയ അംഗീകൃത പതിപ്പ് -> മാസ്റ്റർ ബ്രാഞ്ച്
ബാക്കപ്പ് (ഒരു റിമോട്ട് സെർവറിലേക്ക് പകർത്തുന്നു) -> git push
പങ്ക് € |

അതിനാൽ, നിങ്ങൾ ഇതിനകം ചെയ്യേണ്ടതെല്ലാം സ്വയമേവ യാന്ത്രികമാക്കി.

ഉയർന്ന തലത്തിൽ അത് നിങ്ങളെ അനുവദിക്കുന്നു

പ്രമാണ മാറ്റങ്ങൾക്കായി വ്യക്തവും ലളിതവും നിയന്ത്രിതവുമായ ഒരു പ്രക്രിയ സൃഷ്ടിക്കുക
കാരണം നിങ്ങൾ അന്തിമ പ്രമാണം (ഞങ്ങളുടെ ഉദാഹരണത്തിൽ MS Word ൽ) സ്വയമേവ സൃഷ്ടിക്കുന്നു, ഇത് ഫോർമാറ്റിംഗ് പിശകുകളുടെ സാധ്യത കുറയ്ക്കുന്നു

കുറിപ്പ്
ഇത്രയും പറഞ്ഞുകഴിഞ്ഞാൽ, നിങ്ങൾ ഡോക്യുമെന്റേഷനിൽ മാത്രം പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും, Git ഉപയോഗിച്ച് നിങ്ങളുടെ ജോലി വളരെ എളുപ്പമാക്കാൻ കഴിയുമെന്ന് വ്യക്തമാണെന്ന് ഞാൻ കരുതുന്നു.

ഇതെല്ലാം ഡോക്യുമെന്റേഷന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുത്തുകയും അത് സൃഷ്ടിക്കുന്നതിനുള്ള സമയം കുറയ്ക്കുകയും ചെയ്യുന്നു. മറ്റൊരു ചെറിയ ബോണസ് - നിങ്ങൾ Git പഠിക്കും, അത് നിങ്ങളുടെ നെറ്റ്‌വർക്ക് ഓട്ടോമേറ്റ് ചെയ്യുമ്പോൾ നിങ്ങളെ സഹായിക്കും :)

ഒരു പുതിയ പ്രക്രിയയിലേക്ക് എങ്ങനെ മാറാം?

ലേഖനത്തിന്റെ തുടക്കത്തിൽ, നാളെ നിങ്ങൾക്ക് ഒരു പുതിയ രീതിയിൽ പ്രവർത്തിക്കാൻ കഴിയും എന്ന് ഞാൻ എഴുതി. നിങ്ങളുടെ ജോലിയെ ഒരു പുതിയ ദിശയിലേക്ക് എങ്ങനെ കൊണ്ടുപോകാം?

നിങ്ങൾ മിക്കവാറും പിന്തുടരേണ്ട ഘട്ടങ്ങളുടെ ക്രമം ഇതാ:

നിങ്ങളുടെ പ്രമാണം വളരെ വലുതാണെങ്കിൽ, അതിനെ ഭാഗങ്ങളായി വിഭജിക്കുക
ഓരോ ഭാഗവും മാർക്ക്ഡൗൺ ആക്കി മാറ്റുക (ഉദാഹരണത്തിന് Pandoc ഉപയോഗിച്ച്)
മാർക്ക്ഡൗൺ എഡിറ്ററുകളിലൊന്ന് ഇൻസ്റ്റാൾ ചെയ്യുക (ഞാൻ ഉപയോഗിക്കുന്നു ടൈപ്പോറ)
മിക്കവാറും നിങ്ങൾ സൃഷ്ടിച്ച മാർക്ക്ഡൗൺ പ്രമാണങ്ങളുടെ ഫോർമാറ്റിംഗ് ക്രമീകരിക്കേണ്ടി വരും
മുമ്പത്തെ അധ്യായത്തിൽ വിവരിച്ചിരിക്കുന്ന പ്രക്രിയ പ്രയോഗിക്കാൻ ആരംഭിക്കുക
അതേ സമയം, നിങ്ങളുടെ ജോലിക്ക് അനുയോജ്യമായ രീതിയിൽ പരിവർത്തന സ്ക്രിപ്റ്റ് പരിഷ്ക്കരിക്കാൻ ആരംഭിക്കുക (അല്ലെങ്കിൽ നിങ്ങളുടേതായ എന്തെങ്കിലും സൃഷ്ടിക്കുക)

നിങ്ങൾ Markdwon കൺവേർഷൻ മെക്കാനിസം -> ആവശ്യമായ ഔട്ട്‌പുട്ട് തരം ഡോക്യുമെന്റ് സൃഷ്‌ടിക്കുന്നതുവരെ നിങ്ങൾ കാത്തിരിക്കേണ്ടതില്ല. നിങ്ങളുടെ മാർക്ക്ഡൗൺ ഫയലുകൾ പരിവർത്തനം ചെയ്യുന്നതിനുള്ള നടപടിക്രമം വേഗത്തിൽ ഓട്ടോമേറ്റ് ചെയ്യാൻ നിങ്ങൾക്ക് കഴിയുന്നില്ലെങ്കിലും, Pandoc ഉപയോഗിച്ച് നിങ്ങൾക്ക് അത് ഏതെങ്കിലും രൂപത്തിൽ ചെയ്യാം, തുടർന്ന് അത് നേരിട്ട് അന്തിമ ഫോമിലേക്ക് കൊണ്ടുവരാം. സാധാരണയായി നിങ്ങൾ ഇത് ഇടയ്ക്കിടെ ചെയ്യേണ്ടതില്ല, പക്ഷേ ചില ഘട്ടങ്ങളുടെ അവസാനം മാത്രം, ഈ സ്വമേധയാലുള്ള ജോലി, അസൗകര്യമുണ്ടെങ്കിലും, എന്റെ അഭിപ്രായത്തിൽ, ഡീബഗ്ഗിംഗ് ഘട്ടത്തിൽ തികച്ചും സ്വീകാര്യമാണ്, മാത്രമല്ല പ്രക്രിയയെ "മന്ദഗതിയിലാക്കരുത്" വളരെ.

മറ്റെല്ലാം (മാർക്ക്ഡൗൺ, ജിറ്റ്, പാൻഡോക്, ടൈപ്പോറ) ഇതിനകം തയ്യാറാണ്, അവരുമായി പ്രവർത്തിക്കാൻ കൂടുതൽ പരിശ്രമമോ സമയമോ ആവശ്യമില്ല.

അവലംബം: www.habr.com