Share
Ved utvikling av programvare gjør kildekontroll våre liv så mye lettere. Fra å spore våre endringer for å introdusere kodesamarbeid, bidrar det til å øke produktiviteten. Videre er det faktum at det finnes en rekke forskjellige verktøy tilgjengelig - Subversion, Perforce, Mercurial og så videre - gjør det enda bedre ved å gi oss muligheter å velge mellom.
I denne serien ser vi spesielt på Git og bruker Bitbucket og hvordan de kan hjelpe oss i vårt daglige arbeid. I denne artikkelen skal vi være spesielt fokusert på å bruke Bitbucket for diskusjon, feilsporing, utgivelse av tagging og mer.
En av hovedtrekkene til Git - og dermed Bitbucket - er ideen om trekkforespørsler. I denne artikkelen skal vi se på trekkforespørsler og hvordan de ikke bare drar nytte av oss fra et kildekontrolperspektiv, men også fra et peer review-synspunkt.
Når noen utsteder en trekkforespørsel i prosjektet, betyr det at de ber om at deres kode slås sammen i kodebase. Det vil si, de ber om at du trekker sin kode inn i prosjektet.
Men vi, som opprettholdere, har muligheten til å gjennomgå, teste og forene de endringene som er innført av forespørselen. Gjør ingen feil: Vi spiller en svært viktig rolle i å avgjøre om den spesielle forespørselen oppfyller både standardene og målene for programvaren vår.
Hvis det oppdages en uoverensstemmelse, kan vi be bidragsyteren til å oppdatere trekkforespørselen ved å enten rydde opp koden, løse eventuelle utestående problemer eller forbedre den generelle kvaliteten på koden. På den annen side kan vi også avvise trekkforespørselen dersom vi bestemmer at det ikke oppfyller hvilke kriterier vi anser for nødvendige for prosjektet.
For å kunne utstede en trekkforespørsel må en person først forkaste kodebase for det opprinnelige prosjektet. Dette betyr at de tar et øyeblikksbilde av kodebasen i sin nåværende tilstand, lager et sett med endringer, og deretter foretar endringene til deres personlige kopi av koden. Derfra ber utvikleren da om at endringen blir trukket inn i opprinnelig lager.
Som tidligere nevnt kan trekkforespørsler bestå av et hvilket som helst antall ting:
Brukt av lag av alle størrelser - både internt og distribuert - er kildekontrolladministrasjon en verdifull del av å utvikle programvare. Saken er når det gjelder å arbeide med kildekontrollsystemer, brukerne har ulike roller av tillatelser.
Det vil si når det gjelder å opprettholde et lager, vil noen utviklere ha skrivebeskyttet tilgang, mens andre har både lese og skrive tilgang. Og de med skriveadgang er de som er ansvarlige for å opprettholde trekkforespørsler.
I denne serien av artikler tar vi en titt på hvordan Bitbucket kan forbedre lagets arbeidsflyt når det gjelder utvikling av programvare. Akkurat som vi tidligere har diskutert, tillater Bitbucket folk å delta i prosjektet, både ved å begå kode til det, ved å gjennomgå trekkforespørsler og gjennomføre sammenslåinger av de nevnte forespørsler.
En av de fineste funksjonene i Bitbucket er at den lar deg legge til flere anmeldere til en enkelt trekkforespørsel som deretter kan godkjenne (eller avvise) forespørselen. Dette gir igjen de som opprettholder lageret evnen til å gjennomgå kvaliteten på koden som er angitt i trekkforespørselen.
Kanskje vil de ønske velkommen til tilleggene til prosjektet, kanskje ikke. Uansett hva som er tilfelle, gir Bitbucket vedlikeholdsmedlemmer verktøyene som er nødvendige for å gi tilbakemelding på en gitt trekkforespørsel.
Endelig støtter Bitbucket inline kommenterer hver trekkforespørsel, noe som gjør det mye lettere å diskutere en bestemt linje, blokk eller kodemodul.
Alt i alt gjør denne tilnærmingen det mye enklere å avgjøre om en trekkforespørsel bør slås sammen, om den bør avvises, eller hvilke områder av kunden som bør endres før sammenslåing av forespørselen.
For å komme i gang, besøk et prosjektets dashbord i nettleseren din, og klikk deretter på Gaffel å gaffel depotet.
Deretter vil du bli presentert med et skjema som lar deg angi et egendefinert navn og en tilpasset beskrivelse. Du har også muligheten til å sette lagerets synlighet og tillatelser blant andre funksjoner.
Hvis du er ansvarlig for koden som skal skrives og vil ha tilgang til tilleggsverktøy for å gjøre det lettere å jobbe med et lag rundt kodebasen, velger du deretter Prosjektledelse alternativet fra det tilsvarende grensesnittelementet.
Etter å ha klikket på Gaffelbeholder knappen, vil du ta tak i den nyeste versjonen av kodebase av prosjektet og få den tilgjengelig i et repository som er helt eget. For å sjekke koden til din lokale maskin, kan du bruke en Git-klient som SourceTree, eller du kan gjøre det fra kommandolinjen ved å utstede følgende kommandoer i den lokale katalogen der prosjektet ditt er lagret:
$ git klone https: //[email protected]/yourusername/reponame.git
Legg merke til at nettadressen som vi har spesifisert ovenfor, er synlig i kontrollpanelet i depotet ditt i Bitbucks dashboard.
Etter at du har sjekket koden, kan du begynne å jobbe med prosjektet på din lokale maskin. Når du introduserer endringer, vil du ønske å forplikte dette til depotet. For å gjøre dette, legger du først arbeidet ditt og du forplikter arbeidet ditt til depotet.
På dette tidspunktet er vi klare til å faktisk komme til jobb. Hva dette betyr vil variere avhengig av prosjektets natur: Kanskje du jobber for å lukke en feil, kanskje du refactoring en funksjon, eller kanskje legger du til en funksjon.
Uansett hva som er tilfelle, når endringene er gjort, kan du utstede en forpliktelse til depotet. Dette betyr at du tar filene du har jobbet med, og kombinerer dem til en enkelt samling av endringer som kalles endringssett. Endringer settes vanligvis sammen med en kort melding som forklarer hva som ble endret og hvorfor.
Når du forplikter kode, i det minste i begynnelsen, er du egentlig ikke pådriver noe til depotet. Med andre ord, hvis dette er ditt første forpliktelse, blir ikke koden din faktisk lagret online i Bitbucket. I stedet finnes endringene bare på din lokale maskin. Når du har utført din første push, eksisterer koden i depotet.
Til slutt gir kildekontroll en måte å opprettholde en ren historie om endringene dine, samt en enkel måte å vende tilbake til et bestemt tidspunkt.
Når du har presset en endring til fjernregisteret (enten via en klient eller via kommandolinjen), er du klar til å initialisere en trekkforespørsel. Dette betyr at du er klar til å ta kode som du har presset inn i gaffelen din i kodebase og spør de opprinnelige vedlikeholderne om de vil fusjonere koden i prosjektet.
Å gjøre dette i Bitbucket-programmet er enkelt. Bare gå til dashbordet i forked-depotet, og klikk deretter på Lag trekkforespørsel.
Deretter vil du bli presentert med et grensesnitt som gjør at du kan opprette din trekkforespørsel. Forespørselen vil inkludere ditt lager, det opprinnelige arkivet og en tittel og beskrivelse.
Her velger du ditt arkiv som kildearkivet og den opprinnelige kodebaseens lager som målregisteret. Du må kanskje endre disse i dashbordet, avhengig av dine krav.
Hvis du for eksempel har kalt din kopi av koden "utvikle" når du utsteder kommandoen "git add remote" tidligere, men den opprinnelige kodebasen bruker ordet "master", må du sørge for at du har valgt de riktige verdiene.
Endelig er dette her hvor Bitbucket gir deg mulighet til å legge til korrekturlesere på en trekkforespørsel. Som tidligere nevnt, gjør dette det mye lettere å tiltrekke seg oppdragsgiveres oppmerksomhet, slik at de kan vurdere arbeidet ditt, gi opp eventuelle kommentarer de måtte ha, og slå sammen (eller avvise) forespørselen din.
Bitbucket oppdaterer automatisk din forespørselsforespørsel når du trykker kode til kildekatalogen, slik at prosjektrevisoren alltid får se den nyeste koden de kan trekke.
Når anmelderen ber om en bestemt endring, kan han / hun ganske enkelt trykke på de forespurte endringene i din kopi av depotet - det vil si forked repository.
Hvis du opprettholder et lagringssted som mottar trekkforespørsler fra andre, vil du sannsynligvis legge merke til at depotet ditt vil motta både varsling i Bitbucket-programmets dashbord, så vel som i e-postadressen din.
I tillegg, hvis du er en anmelder, vil du også motta et varsel og en e-post. For å administrere alle innkommende trekkforespørsler, klikk på "Trenger forespørsler" -linken og velg trekkforespørselen du vil arbeide med.
Som du kan se, gir Bitbucket et rent grensesnitt hvor du kan diskutere og gjennomgå trekkforespørsler. Både vedlikeholdere og seere kan avvise, slå sammen, eller be om ytterligere arbeid som skal utføres på en gitt trekkforespørsel.
Forutsatt at du har en forespørsel som er klar til å bli slått sammen, klikker du på det bestemte alternativet for å gjøre akkurat det. Hvis du tilfeldigvis jobber med flere korrekturlesere, gjør Bitbucket det også klart om hvem som godkjente forespørselen ved å bruke et avmerkingsmerke på deres avatar. Tydeligvis, jo flere sjekker som vises på tvers av korrekturleserne, desto mer sannsynlig er forespørselen klar for sammenslåing.
Men hva skjer hvis sammenslåingen av trekkforespørselen mislykkes? På dette tidspunktet må en manuell fusjon gjøres (som er en felles del av kildekoden ledelse, men utenfor rammen av denne artikkelen), hvoretter koden vil bli forpliktet til depotet.
Kildekontrollen gir tydeligvis mange fordeler for lag; Trekkforespørsler er imidlertid en kraftig funksjon som gjør det enkelt å bidra til et prosjekt og for å få andre til å lese om koden din, kommentere den og forbedre den før den slås sammen i kodebase.
Dette alene kan hjelpe deg til å bli en mye bedre utvikler som du lærer fra erfaringen fra andre utviklere som opprettholder det større prosjektet. Hvis du ikke allerede er, kan du prøve å bruke trekkforespørsler i arbeidsflyten din for å forbedre koden din, og samle tilbakemelding fra andre.
.
Accentsconagua