За актуализирана версия на това ръководство вижте версията с обикновен текст в Github. Това е по-лесно за мен да изпращам актуализации на: https://github.com/KevinVerre/kevins-guide-to-git
Съдържание:
Тема 0. Въведение в Git и това ръководство.
Тема 1. Какво е Git.
Тема 2. Разликата между Git и Github
Тема 3. Въведение в разклоненията и ангажиментите
Тема 4. Създаване на ангажименти
Тема 5. Типичен пример за работен процес
Тема 6. Разрешаване на конфликти
Тема 7. Пребазиране и коригиране
Тема 8. Друг софтуер, изграден върху Git< br /> Тема 9. Псевдоними и автоматично попълване
Тема A: Команди, които трябва да знаете.
Тема B: Други ресурси
## Тема 0. Въведение в Git и това ръководство.
Git е името на програма за „Контрол на версиите“ (или „контрол на ревизиите“), която много компютърни програмисти използват, за да им помогнат да пишат софтуер. Софтуерът за контрол на версиите помага на програмистите да пишат софтуер, като позволява на програмите да записват множество версии на своите проекти едновременно и след това да комбинират тези версии по-късно. Освен това помага на екипи от програмисти да работят заедно, докато пишат част от софтуера.
Програмисти, които са експерти по Git, могат да използват Git за по-бързо и по-лесно писане на код. За съжаление, да се научите да използвате Git е много трудно и смущаващо. Целта на това ръководство е да помогне на хората да се справят по-добре с git. Ще бъде полезно както за начинаещи, така и за опитни потребители. Тъй като git е толкова труден за използване, много опитни потребители на git все още имат много да учат.
Има много ресурси онлайн, които могат да ви помогнат да научите как да използвате git. Въпреки това пиша това ръководство, за да го улесня за научаване. От една страна, тези ръководства могат да бъдат много трудни за разбиране. Друго нещо, тези ресурси понякога вършат лоша работа при обяснението на основните концепции на git. Вместо това те често се фокусират върху Git командите, без да им дават контекст. Те могат да пропуснат много информация, която, ако знаехте, ще ви е много по-лесно да научите и използвате Git. Ако разбирате основните концепции на git, ще бъдете по-добре подготвени да използвате правилно командите.
Но след като прочетете моето ръководство и разберете основните концепции на Git, ще сте готови да започнете да го овладявате. В този момент ще получите много повече от уроците и препратките, които други са създали.
Това ръководство се съхранява в публично хранилище на Github. Можете да прочетете това ръководство онлайн там. Можете също така да видите как се е променил с течение на времето, като използвате хронологията на извършените промени. https://github.com/KevinVerre/kevins-guide-to-git
Към края на това ръководство е раздел Команди, които трябва да знаете. Чувствайте се свободни да преминете към този раздел, ако вече знаете много за git и просто искате да научите някои нови трикове.
## Тема 1. Какво е Git.
Представете си, че създавате софтуерен проект. Може да е софтуерно приложение, уебсайт, мобилно приложение, скрипт или нещо друго. Имате папка, която съдържа всички файлове, свързани с този проект: файлове с код, файлове с изображения, подпапки, може би някои файлове с данни и т.н. Git е инструмент, който ви позволява да запазвате различни версии на тази папка. След това можете да се върнете към по-стари версии, ако е необходимо. Можете също да работите върху множество различни версии (наречени клонове) едновременно и да ги комбинирате по-късно. Промените между две версии се съхраняват като списък с извършени промени, наречен „комит“.
Git е част от софтуера. За да използвате git, той трябва да бъде инсталиран на вашия компютър. Компютрите с инсталиран Git могат да комуникират и да изпращат команди до други компютри с инсталиран Git. Разбира се, другият компютър, с който взаимодействате, използвайки вашия компютър, трябва да знае, че може да ви има доверие, така че обикновено изисква парола или таен ключ. Можете обаче да използвате git само на един компютър. Git е програма само за команден ред, което означава, че я използвате, като въвеждате команди в терминала или командния ред, вместо да използвате графичен потребителски интерфейс. Има обаче други програми, които ви позволяват да използвате Git с графичен потребителски интерфейс. Има дори уебсайтове, които ви позволяват да използвате git, като GitHub и BitBucket.
Git е създаден от Линус Торвалдс, известен програмист от Финландия (но сега живеещ в Съединените щати). Торвалдс стана известен с това, че написа и управлява ядрото на Linux, кодът с отворен код, който захранва операционните системи Linux. Git е създаден от Torvalds, за да подпомогне по-нататъшното развитие на ядрото на Linux. Името "git" идва от британски английски, където се използва като обидна жаргонна дума. Ако наречете някого глупак, вие го наричате идиот, досаден или неприятен. Официалната документация за софтуера git шеговито и смирено нарича git „git — глупавият инструмент за проследяване на съдържание“. Софтуерът Git е написан на езика за програмиране C. Той е с отворен код и можете да разгледате C кода, от който е направен Git.
След като git е инсталиран на вашия компютър, можете да го използвате за създаване на git проекти, наречени хранилища. Хранилището в компютърните науки е място, където се съхраняват код и данни. Git хранилището е просто папка („директория“) на вашата машина. Ще наречем това папка на проекта или папка на хранилището. В тази папка са всички файлове и подпапки на вашия проект.
Вътре в папката на хранилището има и специална подпапка, наречена „.git“. Скритата папка .git е това, което прави вашата директория репо Git. Папката .git се създава, когато създавате ново хранилище на git. Докато използвате програмата git, за да правите промени във вашия проект, програмата git ще записва информация в папката .git. Можете да разгледате папката .git, ако желаете, но не е необходимо да знаете много за нея, за да използвате Git. Това е просто място за програмата .git за съхраняване на информация, без тя да пречи на файловете и папките на вашия проект. Всеки път, когато изпълните команда Git, програмата Git ще търси тази скрита папка .git и ще използва файловете и папките вътре в нея, за да намери информация за ангажименти, разклонения и т.н.
В Unix файловете и папките, чието име започва с точка, не се показват по подразбиране, когато се използва командата “ls” за изброяване на съдържанието на папка. Вместо това трябва да използвате „ls -a“, което ще изведе цялото съдържание на папка, включително файлове и папки, които започват с точка. Така че, ако направите „ls -a“ вътре в папка на git хранилище, трябва да видите поддиректорията .git.
Папката на хранилището съдържа поддиректорията .git, но ще съдържа и дърво с други подпапки и файлове. Всяка папка или файл, който е вътре в хранилището, се счита за част от git хранилището. Специалната подпапка .git обаче се появява само на едно място: вътре в папката на хранилището от най-високо ниво. Това означава, че другите подпапки в хранилището не съдържат специална подпапка .git.
Можете да имате няколко различни git проекта/хранилища на вашия компютър едновременно. Така че, когато изпълнявате команда git, програмата git трябва да знае върху кой git проект се опитвате да изпълните командата. Той ще използва вашето текущо местоположение в структурата на директорията (вашата настояща работна директория или „pwd“), за да знае върху кое git хранилище работите. Когато изпълните команда от вътрешността на git хранилище, командата ще бъде изпълнена в git хранилището, в което се намирате в момента. Тя определя в кое хранилище се намирате, като търси специалната папка .git. Той намира от папката .git, като я търси в текущата ви директория и ако не е там, я търси във всяка от родителските директории на текущата ви директория. Той използва информация за извличане, съхранена в папката .git, когато се изпълняват команди.
Ако се опитате да изпълните git команда, докато не сте някъде в git хранилище, ще видите това съобщение за грешка:
„фатално: Не е git хранилище (или някоя от родителските директории): .git”
Това означава, че въз основа на папката, в която сте изпълнили командата, тя не може да намери папка .git в текущата папка или някоя от родителските папки, така че не сте в git хранилище.
За да създадете git хранилище, използвате командата „git init“ заедно с името, което искате да дадете на вашия проект. Така че „git init super_marlin_bros“ ще каже на git да създаде нова поддиректория, наречена „super_marlin_bros“ в директорията, в която се намирате в момента. Тази нова директория „super_marlin_bros“ е вашата папка на хранилището. И като част от процеса на инициализация, програмата git ще създаде папка .git вътре в папката на вашето хранилище. Можете също да използвате „git init“, за да инициализирате git хранилище въз основа на съществуваща папка, вместо да създавате нова папка. В такъв случай просто дайте името или пътя на папката, която искате да превърнете в папка на git хранилище, и „git init“ ще създаде подпапка .git вътре в нея.
Друг начин да създадете папка git repository на вашия компютър е чрез „клониране“ на git repository, което вече съществува някъде другаде. Това е много често срещан начин за създаване на git проект. И ще говорим повече за това по-късно.
Различните хранилища на git могат да взаимодействат помежду си с помощта на програмата git. Така че, ако двамата с вас работим заедно по проект, аз мога да имам git хранилище, което съдържа кода на проекта на моя компютър, а вие можете да имате своя собствена папка git хранилище, която съдържа кода на проекта на вашия компютър. След това можете да използвате програмата git, за да актуализирате файловете във вашата папка на вашия компютър въз основа на промените, които направих на моя компютър.
На практика е необичайно хранилищата на двама членове на екипа да си взаимодействат директно. Вместо това е типично да се създаде допълнително хранилище някъде, до което всички членове на екипа имат достъп. Това обикновено се нарича „оригинално“ хранилище. Съществува на компютър, с който всички членове на екипа имат разрешение да взаимодействат. И обикновено се хоства на сървърен компютър, който е включен през цялото време, така че по всяко време член на екипа да може да изпрати работата си в първоначалното хранилище. И по всяко време по-късно другите членове на екипа могат да изтеглят тези промени от първоначалното хранилище в собственото си хранилище. Хранилището, с което работите на собствения си компютър, се нарича „локално“ хранилище. Първоначалното хранилище и папките на хранилището, принадлежащи на други членове на екипа, са „отдалечени“ хранилища от ваша гледна точка, защото те (почти винаги) не съществуват на същия компютър като вашия.
Програмата git може да използва специалната папка .git, за да съхранява информация не само за вашето локално хранилище, но и информация за файловете и папките в отдалечени хранилища, които имате разрешение да преглеждате. На практика обикновено има само едно отдалечено хранилище, което ви интересува („произход“), но на теория можете да имате информация за произволен брой отдалечени хранилища, съхранени във вашата подпапка .git. Процесът на изтегляне на актуализации от отдалечено хранилище и съхраняване на съдържанието на тези актуализации във вашата подпапка .git се нарича извличане. Ако извлечете отдалечено хранилище, можете да видите кода, който е бил в това отдалечено хранилище по времето, когато сте изтеглили, дори ако не сте свързани към Интернет или към това отдалечено хранилище!
Git понякога се нарича „разпределена система за контрол на ревизиите“. Git е „децентрализиран“, тъй като софтуерът git е написан по такъв начин, че всички хранилища на git за конкретен проект са равностойни (равни). Например, да кажем, че имаме три git хранилища за един и същи проект. Единият е на моя компютър, един е на вашия компютър и един е на сървър, към който и двамата можем да изпращаме промени чрез Git. И трите от тези компютъра работят с един и същ git софтуер. Въпреки че избираме да третираме едно от тези хранилища (това на сървъра) като специално, няма нищо в начина, по който е настроен неговия git софтуер или .git подпапка, който да е различен от другите хранилища.
На практика обикновено имате централен git сървър, работещ през цялото време, който ви позволява да извличате от първоначално репо. Но дори и да излезе офлайн, можете да запазите всичките си промени локално и да изпратите промените си по-късно.
## Тема 2. Разликата между Git и Github
Обичайно за начинаещите е да смесват Git и Github. Git е програма, която можете да инсталирате на вашия компютър. По подразбиране това е програма от команден ред без потребителски интерфейс. Git ви позволява да споделяте кодови файлове, които са на вашия компютър, с други компютри, като вашите съотборници или сървъра на вашата компания.
Github е уебсайт (и компанията зад уебсайта). Почти можете да мислите за Github като за програма, работеща върху Git, която добавя допълнителни функции. Тъй като Github има Git, работещ на техните сървъри, можете да споделяте кода си напред и назад между вашия компютър и сървърите на Github. Има няколко причини, поради които може да искате да го направите. От една страна, съхраняването на вашия код на техните сървъри е удобно. Техните сървъри винаги работят и са безопасни, защото вашите неща са защитени от вашите потребителски имена и пароли. По този начин всеки от вашия екип може винаги да има достъп до хранилището, съхранявано в Github, през интернет. Въпреки че Git не изисква „централно“ хранилище, екипите използват Github като централно хранилище за удобство. Когато искат да споделят нов код, който са написали, те се насочват към Github. И когато искате да видите нов код, който някой друг е написал, го изтегляте от Github, вместо да го изтегляте директно от компютъра на вашия съотборник.
Github предлага безплатна версия и платена версия. Ако използвате безплатната версия, целият ви код е публично видим. Това позволява на хората да го видят (но не и да правят промени в него). С платената версия можете да контролирате кой може да вижда вашия код. Но има причини, поради които може да искате други хора да видят вашия код. Например, за да го покажете или да позволите на други хора да правят предложения за подобрения.
В допълнение към платената версия на Github, има и Enterprise версия на Github, която ви позволява да стартирате Github сървър на вашите собствени сървъри.
Уебсайтът на Github идва с много инструменти, за да улесните използването на Git. Можете да използвате потребителския интерфейс във вашия браузър, а не командния ред.
## Тема 3. Въведение в разклоненията и ангажиментите
Така че вашето Git проектно хранилище е папка, която съдържа всички подпапки и файлове за проекта вътре в нея. Клонът е версия на тази папка. Всеки клон има име и принадлежи към хранилище. Всяко хранилище може да има толкова разклонения, колкото искате. И ако вашето хранилище има разрешение да взаимодейства с друго хранилище за същия проект, можете да видите техните клонове. Да приемем, че искате да имате две различни версии на вашата папка едновременно, можете да го направите просто като имате два клона. Или можете да имате два различни клона, които представляват една и съща версия на папката на проекта.
Можете да мислите за клон като за поредица от ангажименти. Ангажиментите са единиците, с които изграждате вашето Git хранилище. Един комит може да съдържа произволен брой промени в произволен брой файлове. Комитът може да каже, че даден файл е добавен или премахнат към папката. Комитът може да каже, че определен ред в обикновен текстов файл е премахнат или че определен ред е добавен.
Всяко git репо започва с един клон, наречен „master“. Но можете да създадете нов по всяко време. Когато създадете нов клон, той се съхранява само във вашето локално репо. Но можете също да насочите клонове към друго репо, ако желаете. Когато превключите от работа върху един клон към друг клон, Git ще промени вашите файлове и папки, за да промени състоянието на вашия код в края на този клон.
Последният комит на текущия клон се нарича HEAD. Ангажиментите преди него са HEAD~1, HEAD~2, HEAD~3 и т.н.
Комитът е колекция от промени в хранилището. А клонът е колекция от ангажименти, която е резултат от всички ангажименти, прилагани един след друг. Те се наричат клони, защото образуват дървовидна структура. Обикновено вторичен клон на ангажиментите се разклонява от друг по-основен клон. След това, ако по-късно искате вторичният клон да бъде включен обратно в основния клон, можете да го обедините в основния клон.
Какво съдържа ангажиментът? Комитът съдържа следните полета: хеш на комит (който се използва като низ за идентификация), низ на съобщение за ангажимент, промените (във всички съответни файлове и папки), низ с име на автор, дата и час. Идентифицирате ангажимент по неговия хеш към комит. Но не е нужно да използвате всичко: ако получите първите няколко знака, Git ще се опита да разбере кой къмит имате предвид. Този хеш идва от хеш функция, която приема всички данни, свързани с ангажимента (включително съобщението към комит). Което всъщност не можете да „редактирате“ къмит, а вместо това трябва да го замените с нов къмит с нов хеш.
Git също функция, наречена етикети. Те ви позволяват да дадете String име на конкретен ангажимент, който може да се използва за препратка към този комит другаде. Но много хора използват Git без да използват тагове, така че го смятам за разширена функция.
## Тема 4. Крафт ангажименти
Комитът е колекция от промени в хранилището. Промените в хранилището могат да включват добавяне на нов файл, премахване на файл или промяна на редовете във файл. Промяната в хранилището може да бъде поетапна или непоетапна. Поетапната промяна е тази, която се подготвяте да използвате в ангажимент. Вие създавате ангажимент, като правите промени в хранилището, поставяте промените, които искате да ангажирате, и след това създавате ангажимент от етапната промяна.
Командата “git status” ще ви покаже статуса на всички промени, направени в хранилището след последния комит. Ще ви покаже дали файловете са добавени, премахнати или променени. Командата “git diff” ще ви покаже как са се променили файловете. Командата „git diff — staged“ ще покаже промените в хранилището, които са етапни. По подразбиране „git diff“ ще ви покаже разликите за цялото хранилище. Можете също така да покажете промените в определен файл, като използвате „git diff FILENAME“. Хранилището, върху което работите, понякога се нарича „работна директория“ и разликите, които сте направили, са промени в „работното дърво“. Друго име за етапа е „индексът“.
Следващата стъпка е да „етапирате“ промените, като ги добавите към „сцената“. Ако сте добавили нов файл или сте направили промяна във файл, можете да организирате тази разлика, като използвате командата „git add FILENAME“. Ако сте премахнали файл, можете да поставите тази разлика в репото, като използвате командата „git rm FILENAME“. Разбира се, поставянето на всеки файл поотделно може да стане досадно, така че не е нужно да го правите по този начин. Можете да организирате всички промени в папка (включително промени в папки в тази папка), като използвате „git add DIRECTORY“. И, разбира се, точката означава текущата директория, в която се намирате, така че е обичайно да правите „git add .“. Понякога може да искате да дадете на тази команда аргумент. По подразбиране „git add DIRECTORY/FILENAME“ ще инициира нови файлове и промени във файлове, но няма да индикира, че даден файл е премахнат. Така че аргументът -A му казва да инициира всички промени, включително премахване на файлове. Така че, ако сте в главната директория, командата “git add -A” ще добави към сцената всички промени, които сте направили във вашето работно дърво.
Защо имаме етапен процес? Сцената ви помага да създавате ангажименти точно както искате, като ви дава място да видите какво ще има в ангажимента, преди да бъде създаден.
Понякога може да откриете, че има някои промени във файл, който искате да подготвите, и други промени във файл, които не искате да подготвите, защото не искате да запазите тези промени. Използването на “git add -p” ще ви позволи да прегледате разликите в този файл и да изберете кои по-малки промени (наречени “hunks”) искате да добавите и кои не.
Понякога ще искате да премахнете промяна от сцената. Както „git status“ ще ви каже, можете да използвате „git reset HEAD ‹filename›“, за да премахнете промените на този файл от промежутъчната среда, но да запазите промените в работното дърво. Не съм сигурен обаче защо командата е „git reset HEAD“, тъй като тя не отхвърля вашите промени, които сте направили в HEAD, а просто ги премахва.
Можете също така да премахнете промяната, ако решите, че не я искате.
Концепция: Gitignore
Понякога искате да имате файлове в папката на вашето хранилище, без тези файлове да бъдат „проследени“ като част от хранилището. Така че имате нужда от начин да кажете на git кои файлове в папката на вашето хранилище не трябва да се проследяват. Вие правите това, като създавате .gitignore файлове във вашето хранилище.
Файловете, които са игнорирани, няма да се показват като непроследени в git status. И те няма да бъдат добавени към зоната за етап, когато използвате git add.
## Тема 5. Типичен пример за работен процес
Сега ще ви преведем през пример за това как един екип обикновено може да използва Git.
Ще започнете, като създадете папка, която съдържа целия ви код и файлове. Когато сте готови да започнете да използвате Git с този проект, можете да инициализирате Git repo в тази папка. Веднага ще имате главен клон без ангажименти и всички съществуващи файлове и папки ще бъдат неетапирани промени. Можете да поставите цялата директория. Промяната ще бъде представена като добавяне на всички ваши файлове и папки, тъй като сте започнали без нищо и добавянето на всичко ще ви отведе до мястото, където сте.
Тъй като искате да съхранявате работата си в облака, намирате копие на Git сървър, работещ в Интернет. Повечето хора използват Github или Bitbucket или нещо подобно, безплатна или платена версия. Но можете също да стартирате свой собствен Git сървър, ако наистина искате. Ако сте настроили идентификационните си данни, можете да изпратите копие на вашето Git репо в облака. Това ще действа като вашето първоначално репо. Можете да настроите вашия локален главен да сочи към основния клон на произхода като негов клон нагоре по веригата. Това ви позволява да следите колко ангажименти сте напред или зад този клон.
Вашият колега, Бети, може да клонира репото от облака на своя локален компютър. Ако иска, тя може да изпрати нови ангажименти или нови клонове към произхода. За да докаже, че е тази, за която се представя, може да се наложи да създаде ssh ключ от парола.
След като работите върху проекта известно време, решавате, че искате да кодирате нова функция. Ще създадете нов клон, за да поставите всички нови промени в кода, свързани с тази функция. Това се нарича клон на функция.
Преди да направите това, ще трябва да се уверите, че вашият главен клон е актуален. Така че проверявате master и изтегляте всички ангажименти от origin/master към local/master. От master създавате нов клон и го наричате „new-video-player“. (Или каквото и да описва функцията, върху която работите.) Създавате няколко ангажимента в този клон, докато започне да работи според вашето удовлетворение.
През времето, когато работихте върху вашия клон на функцията, главният клон се придвижи напред с няколко ангажимента. Така че е добра практика да обедините най-новата глава на главен клон във вашия клон на функции. По този начин всички ангажименти от главния клон ще бъдат във вашия клон на функции, включително тези, които не сте имали, когато клонът на функциите е създаден за първи път. Това може да причини някои конфликти при сливане, в който случай ще бъде създаден нов ангажимент за справяне с тези конфликти. По този начин вече ще сте се справили с тези конфликти, когато е време да обедините клона на функцията обратно в главния клон.
Когато сте готови да споделите това, което сте изградили с вашия колега, вие изпращате новия си клон към източника като отдалечено копие на този нов клон. Сега вашият колега, Бети, може да копира клона на функцията от origin/new-video-player в своето локално репо и да го провери. Тя тества новата функция, която сте създали, и преглежда кода ви.
Всичко изглежда добре, така че сте готови да пуснете новата си функция. Вие обединявате своя клон на функцията с вашия локален главен клон. Сега вашият локален главен клон е пред началния главен клон. Избутвате главния си клон до произход, така че всичко да бъде настигнато от вас. Сега, следващия път, когато внедрите главен клон към продукт, той ще съдържа вашата нова функция. Освен това може да имате производствен клон на произход, който представлява версията на master, която е внедрена в производството.
## Тема 6. Разрешаване на конфликти
Git следи файловете и промените, направени в тях с течение на времето. Ако е текстов файл, той може да посочи кои редове са променени и как. Ако това е файл с изображение или някакъв друг нетекстов ресурс, Git просто ще ви уведоми, че двоичният файл на файла е променен.
В един клон на последователни ангажименти не може да възникне конфликт. Един ангажимент може да промени ред. След това следващият комит може евентуално да промени същия ред. Но винаги щеше да знае реда. Както „преди“, така и „след“ версиите на този ред биха били подходящи.
Но когато ангажиментите от един клон се сливат в друг клон, е възможно промените в комитите да са в конфликт. Представете си, че един ред код е оригинална версия A. В един клон B този ред код се променя от версия A на версия B. Но в другия клон C този ред се променя от версия A на версия C. Ако просто опитате за да се приложи промяна C след промяна B, това би довело до конфликт, тъй като промяна C приема версия A като начална точка, а не версия B.
Така че това, което Git ще направи, е да маркира всички конфликти във всички файлове. След това ви помоля да ги обедините ръчно. След това, когато приключите с обединяването им, ще се създаде нов ангажимент, за да ги обедините, както искате. В зависимост от логиката на кода и промените, които се опитвате да направите във всеки клон, можете да решите какво е най-добре да направите относно конфликта. Например, можете да решите, че ако всеки клон има различен код на този ред, обединената версия трябва да съдържа и двата реда код, един след друг. Или може да решите, че искате едното и можете да изтриете другото. Или може да решите, че искате напълно нова версия на тази линия, която правилно комбинира идеите зад двете промени.
## Тема 7. Пребазирайте и коригирайте
Rebase е мощна команда, която напредналите потребители на Git могат да използват. Позволява ви да пренапишете историята на ангажиментите на git и да жонглирате около комитите. Можете дори да редактирате ангажимент, като замените създаването на заместващ ангажимент за него. Всъщност всъщност не редактирате ангажимента, а по-скоро го заменяте с ангажимент, който е старият комит плюс всякакви нови промени.
Rebase ви позволява да вземете един или повече ангажименти и да ги приложите отново (с нови промени) към текущия клон. Например, можете да използвате rebase, за да пренаредите ангажиментите в клон. Или можете да разделите единичен ангажимент на два комита. Или да комбинирате два ангажимента в един комит. Или можете да премахнете ангажимент от клон. Или можете да редактирате съобщенията за ангажиране.
Можете също да използвате rebase, за да преместите ангажименти от един клон в друг. В този случай е възможно да имате конфликти при сливане точно както при сливането на два клона.
Използвам интерактивен режим (git rebase -i), когато пребазирам. Това извежда малък текстов файл, който редактирате във Vim. Този файл действа като инструкции за повторното базиране. Когато запазите и излезете, повторното базиране продължава с тези инструкции.
Пребазирането се счита за донякъде опасно действие, защото може да се използва за премахване на ангажименти. И всеки път, когато редактирате ангажимент, вие всъщност просто го изтривате и заменяте с нов ангажимент. Докато изтривате само ангажименти на локален клон, който не сте натиснали никъде, това не е проблем. Например, понякога ще пребазирам ангажименти, за да комбинирам множество ангажименти в един по-всеобхватен комит, за да направя историята на ангажиментите по-чиста.
Нещата могат да се объркат, ако пребазирате ангажименти на клон, който вече е бил насочен към първоначалното репо или клон, използван от някой друг. Защото сега във вашата версия на клона липсват ангажименти, които оригиналът имаше, и вместо това има различни ангажименти. Това по същество е конфликт на мета сливане, защото Git не знае кои комити трябва да бъдат включени в клона. Тези конфликтни ангажименти трябва да бъдат разрешени ръчно, за да могат двата клона отново да се синхронизират. Не е краят на света, ако това се случи, но затова се смята за лоша практика да се пребазират ангажименти на клон, които вече са били насочени.
Можете да прочетете повече за rebase в документацията на Git „git rebase — помощ“.
„git commit — amend“ е удобна команда, която трябва да знаете. По същество това е много малко, бързо и лесно пребазиране. Той променя само най-скорошния комит в текущия клон (HEAD). Позволява ви да промените съобщението за ангажимент за този комит. Също така, всички промени, които в момента се изпълняват, когато тази команда се изпълнява, ще бъдат включени като част от този ангажимент. Разбира се, зад кулисите това, което прави това, всъщност е изтриване на ангажимента и създаване на нов, който да го замени, с нов хеш идентификатор и всичко останало. Това ви позволява бързо и лесно да добавите нещо, което сте забравили да напишете или да поставите в ангажимент, който току-що сте създали.
## Тема 8. Друг софтуер, изграден върху Git.
Най-разпространеният софтуер, изграден върху Git, са програми, които ви позволяват да използвате Git с GUI интерфейс вместо командния ред.
Някои текстови редактори и IDE идват с вградена Git функционалност. Например Xcode на Apple.
„Gitless“ е интерфейс на командния ред, изграден върху git, който е проектиран да бъде по-лесен за научаване как да се използва от Git.
Други програми са изградени върху Git и креативно се възползват от способностите на git, за да поддържат различни версии на файлове в синхрон. Например мениджърът на пакети на Ruby on Rail „RubyGems“ използва Git repos за съхраняване и споделяне на код.
## Тема 9. Псевдоними и табулиране
След като се научите добре да използвате Git, ще искате да научите как да използвате git по-бързо. Има два чудесни начина да направите това: псевдоними и автоматично довършване.
Можете да настроите псевдоними, за да направите git командите по-кратки, така че да не се налага да пишете толкова много, за да изпълните команда. Има (поне) две различни места, където можете да конфигурирате това.
Първият е в глобалния конфигурационен файл на git за вашето потребителско име. Редактирайте .gitconfig файла на вашия потребител, за да управлявате вашата git конфигурация. По подразбиране това е файл, съхраняван в ~/.gitconfig. Вие определяте секцията за псевдоним на конфигурационния файл с [alias]. Ето някои, които имам в моите:
[псевдоним]
co = плащане
ci = ангажиране
amend = ангажиране — изменение
s = състояние
st = състояние
sh = показване
b = клон
br = клон
p = изтегляне
d = разл.
l = дневник
a = добавяне
Можете също да създадете псевдоними за вашия терминал, като вашия ~/.bashprofile. Пример: псевдоним gs='git status '
Git също има инструмент за автоматично довършване на раздели. След като инструментът за автоматично попълване на раздели е инсталиран, просто трябва да започнете да въвеждате името на клон (или друг идентификатор), да натиснете раздела и той ще се опита да завърши пълното име. Той обаче не е вграден с Git. Трябва да изтеглите кода и да го инсталирате. Бих го нарекъл полуофициален, тъй като е наличен в същото репо като официалния изходен код на git. Но това не е част от основния им проект. Можете да изтеглите версията за bash от тук и след това да я намерите във вашия bash_profile:
https://github.com/git/git/tree/master/contrib/completion
## Тема A. Команди, които трябва да знаете.
git “команда” — помощ
Git ще ви покаже страницата за помощ за командата, ако добавите — помощ
git diff
Показва промените във файловете в хранилището, които не са добавени към зоната за етапи.
git diff — етапен, git diff — кеширан
— етапен и — кеширан правят едно и също нещо. И двете ви показват кои промени във вашето хранилище са добавени към промежутъчния участък. Това означава, че тези промени са избрани да бъдат част от следващия комит
git checkout -
Аргументът dash ще провери предишния клон, в който сте били преди текущия ви клон. (Подобно на това как `cd -` променя вашата директория към предишната, в която сте били.)
git init “foldername”
създайте нова директория с “foldername” като име. След това създайте ново git repo в тази директория.
git init ./
инициализирайте ново git repo в текущата директория
git status
Показва текущия статус. Включва в кой клон сте. Какви промени са направени във файловете и дали това са непоетапни промени или промени, които вече са били поетапни. Също така показва дали вашият текущ клон е зад своя клон нагоре по веригата.
git клон
git клон -r
git клон -v
Показва по-подробна информация за клоновете, като например кой е последният комит във всеки
git клон - vv
Показва ОЩЕ ПО-подробна информация за клоновете, включително клона нагоре по веригата за всеки клон, който има един
git show
Същото като „git show HEAD“
git show HEAD< br /> Показва съдържанието на комита HEAD (най-новия комит в текущия клон)
git show “commit-hash”
Показва съдържанието на конкретен комит.
git log — графика
Отпечатва графика, за да можете да видите как са обединени клоновете
git log -n 3
Използвайте -n x, за да покажете само информация за X най-новите ангажименти
git log — oneline< br /> Използвайте аргумента — oneline, за да отпечатате само един ред на git commit
git log — reverse
Този флаг показва ангажименти, започващи от най-старите към най-новите, вместо от най-новите към по-старите.
git fetch
Вашето локално хранилище съхранява информация за това, което знае a относно отдалеченото хранилище. Извикването на git fetch казва на git да комуникира с отдалеченото хранилище и да актуализира това, което вашето локално хранилище знае за него.
git fetch -p
По подразбиране git fetch ще актуализира това, което вашето локално хранилище знае за отдалеченото хранилище. Той ще изтегли нови ангажименти и клонове. Но ако клон е изтрит в отдалеченото хранилище, вашето локално хранилище няма да изтрие съответния локално-отдалечен клон. Въпреки това, ако използвате -p за подрязване, това ще изтрие всички локални-отдалечени клонове, които вече нямат съответен клон в отдалеченото хранилище.
git merge “other_branch”
Това ще обедини “other_branch” в текущия ви клон. Освен ако сливането не е сливане с бързо превъртане напред, това ще създаде „комит за сливане“.
git pull
Това прави две неща. Първо, прави git fetch. Това означава, че вашето локално хранилище ще има всички актуализации от отдалеченото хранилище, съхранени под формата на отдалечени клонове. Също така, ако сте на клон, който има отдалечен клон нагоре по веригата, той ще обедини този отдалечен клон нагоре по веригата (който сега е локално-отдалечен клон поради Fetch) в текущия ви клон
git add -p ИМЕ НА ФАЙЛ
Искали ли сте някога да настроите някои от промените във файл, но не всички промени в този файл? Можете да направите това с аргумента — patch или накратко -p. Git ще прегледа всички промени във файла. За да направи това бързо, той го прави на „парчета“ от редове вместо на отделни редове. Парчето е група от линии, които са една до друга. За всяка част можете да кажете на Git дали искате да я поставите или да преминете към следващата част. Можете дори да му кажете, че искате да разбиете парчето на отделни редове, ако искате да получите наистина конкретни неща относно това, което добавяте към зоната за етап.
Когато това стане, опитайте да изпълните командата `git status`. Ще видите името на файла да се показва както в списъка с файлове с поетапни промени, така и в списъка с файлове с непоетапни промени.
git commit — поправка
Това прави промени в последния комит на текущия ви клон (HEAD). Позволява ви да правите две неща. Първо, той ви позволява да модифицирате съобщението за ангажиране на най-скорошния си ангажимент (HEAD). Той също така ще комбинира вашите поетапни промени с HEAD. Използвам това, ако създам ангажимент, но след това осъзнавам, че има друга промяна, която искам да направя във файловете и да добавя към този комит. Така че това е много удобен начин да промените съдържанието на последния си ангажимент.
Обърнете внимание, че това всъщност изтрива вашия HEAD ангажимент и създава нов комит (с нов комит хеш), който да го замени. Това е вид „ребазиране“.
Това е много чист начин за редактиране на ангажимент, който току-що сте направили, но не сте натиснали или обединили никъде другаде. В този случай вие премахвате ангажимент от текущия си клон и го свързвате с новия ангажимент, който съдържа измененията.
Въпреки това, може да стане малко грозно, ако го използвате при ангажимент, който сте натиснали или сте слели към друг клон. Защото сега има два ангажимента: изменената версия на текущия ви клон и оригиналната версия на някой друг клон. Тези два ангажимента ще са в конфликт един с друг, ако се опитате да ги обедините. Обикновено това не е лошо, тъй като Git ще знае как автоматично да разрешава прости конфликти при сливане. Но потенциално може да се обърка.
git clean
Използва се за почистване (изтриване) на непроследени файлове във вашето репо. Тъй като тази команда изтрива файлове от вашия компютър, тя изисква допълнителен аргумент (-f), за да го принуди да направи каквото и да било
git clean — dry-run
Аргументът — dry-run отпечатва кои файлове ще бъдат премахнат без реално премахване на никакви файлове
git clean -f
Аргументът -f (или — сила) казва на git, че сте сериозни относно премахването на тези файлове
git clean -d
Изтрива непроследени директории, както и файлове
git blame “filename”
Покажете кой ангажимент (и кой автор на комит) е отговорен за всеки ред от файла.
git reset
Използвам това, за да се отърва от ангажименти
git checkout ‹commit› ‹file›
Използвам това, за да се върна към определена версия на файл. Той ще организира разликите за този файл от ‹HEAD› до ‹commit›. Така че, ако се ангажирате, ще имате старата версия на файла.
git bisect
Това е инструмент (който идва с git), който можете да използвате, за да откриете кога във вашия код е въведена грешка. Това, което прави, е да ви помогне да проверите старите версии на вашия код. За всеки комит ръчно тествате за грешка и след това казвате на командния ред дали грешката е налице или не. Ако имате скрипт или команда, която можете да стартирате, за да тествате за грешка, можете да конфигурирате инструмента за разполовяване да изпълнява тази команда на всяка разполовяваща.
Не всеки ще има нужда от `git bisect`, но е хубаво да знаете, че е там, ако някога имате нужда от него за огромен проект.
git rebase -i ‹commit/branch›
git rebase -i HEAD~3
Стартира процедура за повторно базиране в интерактивен режим. Интерактивният режим ви позволява да видите какви ангажименти ще бъдат приложени отново и да направите промени, преди да бъдат приложени отново. В примера HEAD~3 пребазирам последните три комита на текущия ми клон. Четвъртият предпоследен ангажимент (3 комита преди HEAD) действа като край на клона и аз пребазирам всички ангажименти, които идват след HEAD~3 върху HEAD~3.
git remote prune origin
Когато извлечете списъка с отдалечени клонове от отдалечено репо (обикновено произход), той записва списъка с тези отдалечени клонове. Той запазва клоновете в този списък с препратки ДОРИ СЛЕД като клонът е бил изтрит в отдалеченото репо. Ако използвате `git branch -r`, за да покажете отдалечените клонове, тези изтрити клонове пак ще се показват в списъка с имена на клонове. За да ги премахнете от този списък, използвайте `git remote prune ‹origin или друго име на отдалечено репо›`
## Тема B. Други ресурси.
Можете да намерите колекции от Git съвети и трикове онлайн, като този списък, който се появява в Github repo: https://github.com/git-tips/tips
Компанията Atlassian, която прави инструменти за разработчици на софтуер, има страхотни образователни уеб страници за Git. Можете да четете тези уеб страници безплатно. Сега Atlassian е компанията майка на BitBucket, продукт, който се конкурира с GitHub.
GitHub.com също има някои добри, безплатни ресурси и уроци, за да помогне на хората да научат Git.
Официалният уебсайт на Git има безплатна книга, която обхваща всички функции на Git. Нарича се „Pro Git“: https://git-scm.com/book
