എന്നെ രക്ഷിച്ച ഗിറ്റ് തന്ത്രങ്ങൾ

മിക്ക ആളുകളും ഏകദേശം ആറ് ഗിറ്റ് കമാൻഡുകൾ ഉപയോഗിക്കുന്നുഃ ക്ലോൺ, ട്രിഗ്, അഡ്, കമ്മീറ്റ്, പുഷ്, ചെക്ക് ഔട്ട് (അല്ലെങ്കിൽ സ്വിച്ച്). ഒരു സാധാരണ ദിവസത്തിന് ഇത് മതിയാകും. പക്ഷെ, വൈകാതെ, എന്തെങ്കിലും കുഴപ്പം സംഭവിക്കും. തെറ്റായ ശാഖയില് ഒരു കംമെയിറ്റ്. കഴിഞ്ഞ ആഴ്ചയിൽ എപ്പോഴോ വന്ന ഒരു ബഗ്. എല്ലാം മായ്ച്ചുകളഞ്ഞ ഒരു ബലപ്രയോഗം.

അപ്പോഴാണ് കുറച്ച് സാധാരണ കമാൻഡുകൾ രക്ഷകന്മാരാകുന്നത്. DevOps ൽ, ഗിറ്റ് എന്നത് നമ്മൾ അടിസ്ഥാന സൌകര്യങ്ങൾ വിന്യസിക്കുന്ന രീതി കൂടിയാണ്, അവയെ അറിയുന്നത് കൂടുതൽ ഉപയോഗപ്രദമാണ്.

റീബേസ് ചെയ്യുകയോ ലയിപ്പിക്കുകയോ?

രണ്ടും രണ്ടു ശാഖകളില് നിന്നുള്ള ജോലികള് സംയോജിപ്പിക്കുന്നു. അവര് വ്യത്യസ്തമായി ചെയ്യുന്നു:

• ലയിപ്പിക്കുക രണ്ട് ചരിത്രങ്ങളും ചേര് ക്കുന്ന ഒരു ലയന കമ്മീറ്റ് ഉണ്ടാക്കുന്നു. ഒന്നും തന്നെ മാറ്റിവെക്കപ്പെടുന്നില്ല. ചരിത്രം കൃത്യമായി എന്താണ് സംഭവിച്ചതെന്ന് കാണിക്കുന്നു, എല്ലാ ശാഖകളും ഉൾപ്പെടെ.
• പുനർനിർമാണം നിങ്ങളുടെ കംമെറ്റ്സ് ആവർത്തിക്കുന്നു, ലക്ഷ്യ ശാഖയുടെ മുകളില് , അവിടെ നിന്ന് തുടങ്ങിയ പോലെ. ചരിത്രം ഒരു നേരിയ വരി ആയി മാറുന്നു, പക്ഷേ നിങ്ങളുടെ പ്രതികൾ പുതിയ ഐഡി കിട്ടുന്നു.

git switch feature
git fetch origin
git rebase origin/main      # put my commits on top of the latest main

എന്റെ പൊതുനിയമം: നിങ്ങളുടെ സ്വന്തം പ്രാദേശിക ശാഖകളെ പുനർനിർമ്മിക്കുക അവ കാലികവും വൃത്തിയുള്ളതുമായി നിലനിർത്തുക; മറ്റുള്ളവരുടെ കരാറുകള് റീബേസ് ചെയ്യരുത്. (പ്രധാന ശാഖ പോലെ ശാഖകൾ പങ്കിട്ടു). പല ടീമുകളും ചർച്ച ഒഴിവാക്കുന്നു. കുക്കോസ് ലയനം pull requests: മുഴുവൻ ബ്രാഞ്ചും പ്രധാനത്തിൽ ഒരു ക്ലീൻ കമ്മീറ്റ് ആയി മാറുന്നു.

ഇന്ററാക്ടീവ് റീബേസ് ഒരു pull request തുറക്കുന്നതിനു മുമ്പ് നിങ്ങളുടെ commits വൃത്തിയാക്കാൻ അനുവദിക്കുന്നു: squash "fix typo" commits, reorder, reword messages.

git rebase -i origin/main

ബൈസെക്ട് ഉപയോഗിച്ച് ഒരു ബഗ് കണ്ടെത്തുന്നു

"കഴിഞ്ഞയാഴ്ച അത് പ്രവർത്തിച്ചു, ഇപ്പോൾ അത് പ്രവർത്തിക്കുന്നില്ല. "ഇതിനിടയിൽ 80 കമ്മിറ്റുകളുണ്ട്. " അവയെ ഓരോന്നായി പരിശോധിക്കുന്നതിനു പകരം, ഗിറ്റ് ഒരു ബൈനറി തിരയൽ നടത്തട്ടെഃ

git bisect start
git bisect bad                 # current commit is broken
git bisect good v2.3.0         # this version worked
# Git checks out a commit in the middle. Test it, then:
git bisect good                # or: git bisect bad
# ...repeat about 6-7 times for 80 commits...
git bisect reset

ഇതിലും നല്ലത്, പരാജയപ്പെട്ടാൽ പൂജ്യം അല്ലാത്തത് പുറത്തു വരുന്ന ഒരു ടെസ്റ്റ് സ്ക്രിപ്റ്റ് ഉപയോഗിച്ച് അത് ഓട്ടോമേറ്റ് ചെയ്യുക:

git bisect run ./scripts/test-login.sh

ഗിറ്റ് കൃത്യമായ കമ്മിറ്റ് കണ്ടെത്തുന്നു, സാധാരണയായി മിനിറ്റുകൾക്കുള്ളിൽ. അടിസ്ഥാന സൌകര്യങ്ങളുടെ കാര്യത്തിലും ഇത് ശരിയാണ്: "ഏത് മാറ്റമാണ് ഹെൽമിന്റെ ചാർട്ട് തകർത്തിയത്?"

git bisect "കഴിഞ്ഞ ആഴ്ചയിൽ തകർന്നു" എന്ന് എഴുപത് ഘട്ടങ്ങളിലൂടെ "ഈ സമയത്ത് തകർന്നു" എന്നാക്കി മാറ്റുന്നു.

റീഫ്ലോഗ് ഉപയോഗിച്ച് ഏതാണ്ട് എന്തും മാറ്റിവെക്കുന്നു

ഗിറ്റിനെ കുറിച്ചുള്ള ഏറ്റവും ആശ്വാസകരമായ വസ്തുത ഇതാ: അത് ഒരിക്കലും യഥാർത്ഥത്തിൽ പ്രതിജ്ഞാബദ്ധമായ പ്രവൃത്തി നഷ്ടപ്പെടുന്നില്ല. ഒരു മോശം റീസെറ്റ്, ഒരു മോശം പുനർസ്ഥാപനം അല്ലെങ്കിൽ ഒരു ബ്രാഞ്ച് ഇല്ലാതാക്കിയാലും, ഒരു സമയത്ത് കമിറ്റ്സ് നിലനിൽക്കും. പുനർനിർമ്മാണം എല്ലായിടത്തും കാണിക്കുന്നു HEAD അടുത്തിടെ ചൂണ്ടിക്കാട്ടി:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~3
# e4f5g6h HEAD@{1}: commit: add retry logic
# ...

git reset --hard e4f5g6h      # go back to before the bad reset
# or recover a deleted branch:
git branch rescued e4f5g6h

"ഞാൻ എന്റെ ജോലി നശിപ്പിച്ചു" എന്ന് നിങ്ങൾ ചിന്തിച്ചാൽ, നിർത്തുക, ശ്വസിക്കുക, ഓടിപ്പോകുക git reflog.

മറ്റു ദൈനംദിന രക്ഷാപ്രവർത്തനങ്ങൾ

തെറ്റായ ശാഖയിൽ ഏർപ്പെട്ടിരിക്കുന്നു:

git switch correct-branch
git cherry-pick <commit>
git switch wrong-branch
git reset --hard HEAD~1       # remove it from the wrong branch (if not pushed)

അവസാനത്തെ കംമെറ്റ് പരിഹരിക്കുക (സന്ദേശമോ മറന്നുപോയ ഫയലോ):

git add forgotten-file.yaml
git commit --amend

ഇതിനകം നീക്കിയിട്ടുള്ള ഒരു കംമെറ്റ് റദ്ദാക്കുക, സുരക്ഷിതമായി, ചരിത്രം തിരുത്തി എഴുതാതെ:

git revert <commit>

ഗിറ്റോപ്സ് സജ്ജീകരണത്തില് , git revert അക്ഷരാർത്ഥത്തില് ഒരു വിന്യാസം എങ്ങനെ പിൻവലിക്കുന്നു എന്നതാണ്.

പാർക്ക് പൂർത്തിയാകാത്ത പ്രവൃത്തികൾ:

git stash push -m "half-done refactor"
git stash list
git stash pop

ആരാണ് ഈ വാചകം മാറ്റിയത്, എന്തിന്?

git blame -L 40,60 values.yaml
git log -p -S "replicas: 1" -- deploy/   # find the commit that added or removed a string

കൂടുതൽ സുരക്ഷിതമായി തള്ളാൻ നിർബന്ധിക്കുക., നിങ്ങള് ക്ക് ഇനിപ്പറയുന്ന കാര്യങ്ങൾ ചെയ്യേണ്ടിവരുമ്പോൾ:

git push --force-with-lease

വ്യത്യസ്തമായി --force, അത് മറ്റാരെങ്കിലും തളച്ചാൽ അത് നിരസിക്കും.

ശാഖകളെ സംരക്ഷിക്കുക

ഒരു ടീമിൽ ഏറ്റവും സുരക്ഷിതം പിഴവുകൾ എളുപ്പത്തിൽ പ്രധാന ഭാഗത്ത് എത്താത്തതാണ്.

• ശാഖ സംരക്ഷണം / നിയമങ്ങൾ: പ്രധാന ആവശ്യങ്ങൾക്കായി പിൻ അഭ്യർത്ഥനകൾ, അവലോകനങ്ങൾ, പാസ് പരിശോധനകൾ എന്നിവ ആവശ്യപ്പെടുന്നു. ബലപ്രയോഗം തടയുക, ഇല്ലാതാക്കുക.
• കോഡ് ഉടമകൾ: ശരിയായ ഫയലുകൾക്കായി ശരിയായ ടീമിൽ നിന്ന് അവലോകനങ്ങൾ സ്വപ്രേരിതമായി ആവശ്യപ്പെടുക. പ്രത്യേകിച്ച് ഇൻഫ്രാസ്ട്രക്ചർ ഫോൾഡറുകളിൽ ഉപയോഗപ്രദമാണ്.
• ഒപ്പിട്ട കരാറുകൾ: SSH അല്ലെങ്കിൽ GPG കീകളിലൂടെ (അല്ലെങ്കിൽ Sigstore ന്റെ gitsign ഉപയോഗിച്ച് കീ രഹിതമായി) സൈൻ ഇൻ ചെയ്യുക, സംരക്ഷിത ബ്രാഞ്ചുകളിൽ ഒപ്പുകൾ ആവശ്യപ്പെടുക. അത് തെളിയിക്കുന്നു കുറ്റകൃത്യങ്ങള് യഥാർത്ഥത്തില് വന്നത് അവര് അവകാശപ്പെടുന്ന ആളില് നിന്നാണെന്ന്.

# .github/CODEOWNERS
/infrastructure/   @acme/platform-team
/deploy/prod/      @acme/platform-team @acme/sre

ഞാന് എപ്പോഴും ഉപയോഗിക്കുന്ന ചില ക്രമീകരണങ്ങള്

git config --global pull.rebase true          # rebase instead of merge on pull
git config --global rebase.autoStash true     # stash and unstash automatically during rebase
git config --global push.autoSetupRemote true # no more --set-upstream
git config --global rerere.enabled true       # remember conflict resolutions
git config --global init.defaultBranch main

പിന്നെ, നീ എന്തു പരിശീലിക്കണം?

ശ്രമിക്കൂ git bisect ഒരു യഥാർത്ഥ ബഗ് പരിശോധിച്ച് ഒരു ടെസ്റ്റ് റീസെറ്റ് നടത്തുക. അതിനുശേഷം ഒരു റിപ്പോയിൽ ഒരു റീഫ്ലോഗ് വീണ്ടെടുക്കൽ നടത്തുക. ഒരിക്കൽ നീ നിന്നെത്തന്നെ രക്ഷിച്ചുകഴിഞ്ഞാൽ, ഗിറ്റ് പേടിപ്പെടുത്തുന്നത് അവസാനിപ്പിക്കും.

എന്റെ അഭിപ്രായം: ജിറ്റ് മിക്കവാറും എല്ലാം ഓര് മിക്കുന്നു. അത് ചോദിക്കാൻ അനുവദിക്കുന്ന കമാൻഡുകൾ പഠിച്ചാൽ, നിങ്ങൾക്ക് ജോലി നഷ്ടപ്പെടാൻ സാധ്യത കുറവായിരിക്കും.

ഡെസ്ലി