![20 Bedste skjulte iPhone-hemmelige koder i 2021 (alt i orden)](/f/673e0cd330cc9692f822d09d49d44928.jpg?width=100&height=100)
Velkommen Manish Sinha til det skriftlige personale! Manish er en meget klog person, med erfaring med at arbejde med alt fra Zeitgeist til Elementary.
Hej OMG! Ubuntu! læsere, dette er mit første indlæg. Jeg vil mest skrive om tekniske emner som redaktionelle artikler.
Mit mål er at forklare hårde tekniske emner på en enkel måde, som ville være nyttig for wannabe bidragydere, der har fundet bidrag for hårdt på grund af den stejle indlæringskurve forbundet med visse værktøjer.
Samarbejde er nok den vanskeligste og tidskrævende opgave, når man arbejder som et team. Da du første gang hørte udtrykket "versionskontrol", var du måske begyndt at tænke på kode og progammere. Spørgsmålet om samarbejde er ikke kun med programmører, men også med andre områder og erhverv, nemlig design, dokumentation osv. Versionskontrol som et værktøj har været uhyre berømt inden for programmeringscirkler, men brugen er ikke begrænset kun til kildekoden.
Når du arbejder som et team med det samme (som et lignende design eller et sæt dokumentationsfiler), så kan det største problem være at sikre, at hver person har det nyeste arbejde. Når alle bidragydere arbejder sammen, foretager de ændringer i hver del, og derefter skal ændringerne deles.
En løsning er at e -maile hinanden ændringerne kun for at åbne din postkasse og gå tabt blandt lolcat -billederne eller reddit. Chancerne for at springe nogle af dem over er også store, da du kan ende med at få for mange e -mails. Hvis du og en anden fyr ændrer den samme fil, kan det være et mareridt at tage hans/hendes ændringer ud og indarbejde dem i din.
En anden løsning er at sende alle ændringer til en person, og han/hun vil sørge for at flette flere filer og holde filerne opdaterede. Dette involverer en person dedikeret til dette arbejde. Hvilket spild af tid!
Et andet problem, du måske står over for, er, at du på et tidspunkt finder ud af, at den aktuelle situation for dit design eller din dokumentation ikke er så god, og at den, du havde for 4 dage siden, så bedre ud. Hvad vil du gøre?
Se på de filer, der blev sendt til dig 4 dage tilbage fra en person. Jagt disse filer i din postkasse, slut alle stykker sammen, og du er muligvis stadig ikke sikker på, om du har det korrekte sæt filer.
Hvad med at nogen spørger dig - "Hvor meget arbejde har I mennesker gjort i den sidste måned". Der kan være tid, hvor du vil prale af, hvor meget arbejde du mennesker udførte som et team, eller hvis du arbejder som entreprenør eller medarbejder, er det nyttigt at have en oversigt over arbejde.
De store problemer fremhævet ovenfor er:
Det er her versionskontrolsystemer (VCS) kommer ind i billedet. Jeg undgår udtrykket "kildekontrolsystem", da det lyder som om det kun var beregnet til kildekoden. De to ovennævnte problemer løses glimrende af VCS.
I en nøddeskal består det meste af VCS af to dele. En central server, der bruges af alle teamets medlemmer som et fælles område, hvor de lægger deres arbejde og også henter andre menneskers arbejde derfra. Det er et forsøg på at synkronisere sig selv med alle andre.
Den anden del, klientværktøjet i versionskontrolsystemet hjælper dig med at skubbe dit arbejde til serveren og trække andres arbejde fra serveren.
Hvis du er en person, der lige har tilsluttet sig teamet, vil du måske hente alle filerne. I dette tilfælde opretter du en klon af sættet med filer.
Du angiver serverens URL til din VCS -klient, og den henter alle filerne til dig. Derefter kan du begynde at arbejde på disse filer.
Efter noget arbejde med filerne (reparation af fejl, tilføjelse af nye funktioner osv.) Beslutter du, at dette arbejde er nok for nu, og du vil dele disse ændringer med andre mennesker.
VCS -klienten sporer alle filerne. Du kan bede den om at vise, hvilke filer du har ændret, og hvad du har ændret i disse filer.
Efter at have kontrolleret, at ændringerne er fine, skal du foretage dine ændringer. En forpligtelse er ikke andet end et redningspunkt eller en milepæl. Du kan have mange gemmepunkter i en kodebase.
Du kan endda finde de ændringer, du foretog mellem 3. og 4. forpligtelse eller 23. og 25. forpligtelse. Dette er fordi din VCS kender den aktuelle situation for filer, og den ved også, hvilket indhold der var til stede, da du lavede den 23. commit, og hvilket indhold der var til stede, da du lavede den 26. commit.
På skærmbilledet herunder viser vi de ændringer, der er foretaget mellem forpligtelse nr. 1714 og 1716:
Efter at have forpligtet sig, vil din VCS fortælle dig, at der ikke er nogen ventende ændringer.
Dette sker, fordi du har forpligtet dig til alle de ventende ændringer. I dette tilfælde skal du indsende dine ændringer på serveren. Dette gøres ved at skubbe dine ændringer til den eksterne URL, hvorfra du lavede en kopi af filerne.
Efter at have skubbet kan du være interesseret i at vide, om en anden skubbede deres arbejde, mens du foretog dine ændringer og begik det. Dette gøres ved at bede din VCS -klient om at trække ændringerne fra fjernserveren.
Du kan prøve at trække igen efter et stykke tid, hvis du får at vide, at en anden i teamet også har skubbet deres ændringer. Det er normalt en god praksis at trække i ændringerne, før du begynder at arbejde med filerne. Dette er muligvis ikke nødvendigt i alle scenarier, men du vil altid have de seneste ændringer, som normalt er bedre.
I skærmbilledet herunder forsøger jeg at trække ændringerne og fik besked om, at der ikke er flere ændringer.
Dette var bare en introduktion til, hvad et versionskontrolsystem faktisk er.
Den, jeg brugte i snapshots, er basar (aka. bzr), som bruges i Launchpad og få andre steder (f.eks. GNU Savannah).
De andre i kategorien af VCS er Subversion, Git, Mercurial osv.
Der er to slags versionskontrol: Centraliseret og distribueret. Bazaar er et eksempel på distribueret versionskontrolsystem - DVCS. Git og mercurial falder også i denne kategori, mens Subversion (svn) er en centraliseret VCS.
Denne artikel var målrettet folk, der altid frygtede at bruge nogen form for versionskontrolsystemer, så hvis du starter nitpicking, vil der være mange fejl! De fremtidige artikler vil være meget præcise og vil bruge faktiske udtryk.
I fremtidige dele skal du forvente:
.. og mange flere.
Tak!
Alt Ubuntu, dagligt. Siden 2009.