git
Multfoje mi uzas git stash (git kaŝi) kaj git stash pop por konservi ŝanĝojn en mia labordosierujo aŭ por ŝanĝi branĉon aŭ kontroli neŝanĝitan kodon. Foje mi volas vidi la ŝanĝojn por antaŭa elmetita ŝanĝo. Estas espero se vi volas trovi ilin. git fsck --no-reflog | awk '/dangling commit/ {print
git
Foje mi bezonas trovi kiam io malaperis de dosiero en GIT deponejo. Aliaj foje mi scias pri ĉeno kiu ŝanĝiĝis sed ne scias kie. En tiuj kazoj blame ne donas al mi la deziratan informon. Envenas la pioĉo (an: pickaxe). Per la pioĉo oni povas serĉi la historion de GIT
git
Multfoje kunlaborantoj havas demandojn pri la malsameco inter fetch (eo: prenu), merge (eo: kunigi) kaj pull (eo: tiru) en GIT. Mi penas klarigi ĝin ĉi tie. Unue, iom da fonkono. Kiam vi unue entajpas git init git kreas .git dosierujon por trakti la novan git deponejon, almenaŭ komence ĝi nur
git
Versitenaj sistemoj utilas por vidi la evoluon de kodbazo aŭ la ŝanĝojn. Kulpigi (an: git blame) utilas por vidi kiu/kiam ŝanĝis specifan linion, sed foje io ne funkcias kaj vi ne scias tion kio rompis ĝin. Metodo por malkovri kion okazis estas: hazarde trovi pasintan enmeton ŝanĝi al ĝi
git
Ĉi tio ne estas ĉiutaga afero, sed se vi bezonas ĝin, ĝi estas ĉi tie. Sekve estas metodo por forigi edikedon de loka kaj malloka deponejoj. Por loka edikedo nomita unua_eldono: git tag -d unua_eldono Por malloka edikedo nomita unua_eldono: git push origin :refs/tags/unua_eldono