Git е мощен инструмент. Все пак много разработчици научават само толкова, колкото е необходимо, за да се справят. В началото това може да изглежда добре. След като обаче тайните изтекат, се натрупат конфликти при сливане или някой директно ги изпрати към... main, нещата могат бързо да се объркат. Ето защо е важно да се надхвърли основното и да се възприеме сигурен, бърз и последователен работен процес. Този ЧЗВ отговаря на най-често задаваните въпроси, които разработчиците задават относно Git. В процеса на работа той подчертава важни... най-добри практики в git, обяснява ключови понятия, които стоят зад бърз контрол на версиите в Gitи предлага съвети от реалния свят относно git сигурностВсеки раздел е предназначен да ви помогне да спрете да гадаете и да започнете да изпращате код с увереност.
Какво е Гит?
Защо бързият контрол на версиите на Git се нуждае от интелигентни настройки по подразбиране
отивам е разпределена система за контрол на версиите. На практика тя ви позволява да проследявате промените в кодовата си база, да си сътрудничите с колеги и да се връщате назад, когато нещо се повреди. За разлика от централизираните системи, Git работи локално, можете да изпълнявате команди като git commit or git branch дори без достъп до интернет.
На пръв поглед Git може да изглежда като инструмент само за проследяване на историята. Той обаче е от съществено значение за съвременните работни процеси за разработка. Силата на Git бърз контрол на версиите в Git, което позволява на екипите да извършват бързи итерации, като същевременно запазват проследимостта. Освен това, Git е в основата на автоматизацията, CI/CD pipelineи най-добрите практики на DevOps в почти всеки софтуерен проект.
Въпреки това, Git не е просто инструмент за продуктивност. Той е и граница на сигурносттаНапример, ако някой случайно изтича git add . намлява commitSA .env досие, тайни данни като API токени могат да бъдат изпратени до отдалечено хранилище. Атакуващите често сканират публични хранилища, търсейки открити идентификационни данни и чувствителни конфигурационни файлове.
За да сте в безопасност, когато използвате Git, запомнете тези основни неща:
- Употреба
.gitignoreфайл, за да изключите чувствителни или локални файлове. - Изисквайте 2FA за всички Git акаунти (особено на платформи като GitHub или GitLab).
- Никога commit тайни или идентификационни данни, сканирайте ги pre-commit когато е възможно.
За разширена защита, инструменти като Ксигени сканират непрекъснато вашите хранилища. Те улавят твърдо кодирани тайни, откриват уязвим код преди сливането му и дори блокират опасни работни процеси във вашия CI/CD pipeline, всичко това, без да ви пречим.
Кой притежава Git?
Git не е собственост на една-единствена компания. Това е проект с отворен код, поддържан от общност от сътрудници, като разработката се координира чрез Git пощенски списък и е хостван на git-scm.comПървоначално създадена от Линус Торвалдс през 2005 г., Git е проектирана като бърза, разпределена система за контрол на версиите, на която разработчиците могат да се доверят, особено за управление на ядрото на Linux.
Въпреки че никой притежава В традиционния смисъл на думата Git, няколко организации подкрепят неговото непрекъснато развитие, включително GitHub, GitLab и Bitbucket. Те изграждат свои собствени платформи върху Git, като същевременно допринасят за ядрото.
Какво означава Git?
Технически, отивам не означава нищо. Не е акроним. Според Линус Торвалдс, създателят на Git през 2005 г., името е избрано отчасти заради британския жаргон, „git“ може да означава глупав или неприятен човек, и отчасти защото е кратко, запомнящо се и все още не е съществувало като Unix команда.
По собствените му думи: „Аз съм егоистичен негодник и кръщавам всичките си проекти на свое име. Първо „Linux“, сега „Git“.“ Линус Торвалдс
Като оставим настрана забавния произход, Git се превърна в един от най-важните инструменти в разработката на софтуер. Той захранва всичко - от проекти с отворен код до enterprise CI/CD pipelineс. С Git екипите печелят бърз контрол на версиите, децентрализирано сътрудничество и възможност за проследяване и отмяна на промените предиcisели.
Въпреки това, с нарастването на приемането на Git, се увеличиха и рисковете. Зловреден софтуер, тайни и уязвимости във веригата за доставки могат да проникнат незабелязано във вашите хранилища. Ето защо е важно да защитите вашата Git система с инструменти като Ксигени, който анализира commits, сканира зависимостите и налага политики, е от решаващо значение за съвременния DevSecOps работни потоци.
Как да използваме Git?
Най-добри практики за Git за сигурно и ефективно използване на Git
Ефективното използване на Git означава повече от просто запомняне на няколко команди. То включва следването най-добри практики в git, разбиране на това как промените ви преминават през клонове и отдалечени сървъри и избягване на често срещани грешки, които могат да доведат до грешки или дори рискове за сигурността.
Основният работен процес в Git
За да започнете, основният работен процес в Git обикновено включва:
1. Клониране на хранилище:
git clone https://github.com/your-org/your-repo.git 2. Създаване на клон на функции:
git checkout -b feature/cool-new-thing 3. Правене на промени и commitбезопасно придвижване:
git add . git commit -m "Add new feature safely and cleanly" 4. Преминаване към дистанционно управление:
git push origin feature/cool-new-thing 5. Отваряне на pull request (PR), за да обедините промените си в главния клон.
Прилагайте Git сигурност на всяка стъпка
Въпреки че тези стъпки са standard, много разработчици несъзнателно въвеждат рискове. Например commitслучайно добавяне на секрет или публикуване на непроверен код, който нарушава производствения процес.
Ето защо, ето някои подобрения, насочени към сигурността, които можете да приложите незабавно:
- Избягвайте
git add .освен ако не си сигурен какво правиш commitтинг. Използвайтеgit statusпърво и добавете файлове избирателно сgit add <file>. - Пишете смислено commit съобщения. Те подобряват проследимостта и помагат на проверяващите да забелязват аномалии.
- Сканирайте вашия commitпреди да натиснете. Използвайте инструменти като Git на Xygeni Guardrails за улавяне на тайни, зловреден софтуер и неправилни конфигурации преди сливане.
- Принудително провеждане на PR прегледи преди сливане. Това е един от най-лесните начини да предотвратите навлизането на рисков код в основния ви клон.
Важно е да се отбележи, че Xygeni се интегрира директно във вашия Git работен процес. Той сканира всеки commit и връзки с обществеността, за да наложите политиките си за сигурност, без да ви забавяте. Това поддържа вашето хранилище защитено, като същевременно запазва бърз контрол на версиите в Git, бързо, но безопасно.
Какво е Git хранилище?
В основата си а Git хранилище е версирана директория на вашия проект, която проследява всяка промяна във времето. Тя включва целия ви изходен код, клонове, тагове и commit история и потенциално много повече, отколкото очаквате.
И така, защо това има значение за git сигурност?
Защото Git хранилището не е просто история на вашия код. То може да съдържа и:
- Чувствителни конфигурационни файлове като
.envorconfig.yml - Твърдо кодирани тайни случайно добавено по време на разработката
- Зависимости от зловреден софтуер или правописни грешки въведено чрез
package.json,requirements.txtили други манифести
Следователно, разбирането какво се намира във вашето хранилище е от решаващо значение. Не става въпрос само за поддържане на чист код, а за защита на цялото ви pipeline.
Пример:
Често срещана грешка е натискането на местен .env файл със секрети:
git add .env git commit -m "add environment config" git push Дори ако хранилището е частно, тези тайни могат да изтекат чрез форкове или интеграции на трети страни.
За да избегнете това:
echo ".env" >> .gitignore - Настройте pre-commit hooks или CI скенери като Ксигени за да откривате тайни, преди да достигнат до дистанционното ви.
- Почистете историята си с
git filter-repoorBFGако нещо чувствително вече е било commitТед.
Когато изпращате код, Xygeni сканира commit и вашите файлове със зависимости (като package.json or requirements.txt) за изтекли тайни, зловреден софтуер и известни експлойти, всичко това преди да стигне до етапа на PR.
Това гарантира, че вашият най-добри практики в git и хигиената на сигурността се поддържат, дори когато проектът расте. Освен това, Xygeni поддържа сканиране в GitHub, GitLab, Bitbucket и други основни платформи.
В крайна сметка, третирането на вашето Git хранилище като граница за сигурност, а не просто като хранилище за код, помага на екипите да се движат по-бързо, без да оставят критични пропуски.
Какво е контрол на изходния код?
Контрол на източника, известен още като контрол на версията, е практиката за проследяване и управление на промените в кодовата ви база. Инструменти като Git правят това възможно, като записват кой какво е променил, кога и защо. Но не става въпрос само за сътрудничество. В днешния DevOps pipelines, контролът на изходния код е също ваш първи контролно-пропускателен пункт.
По-важното е, че разработчиците разчитат на бърз контрол на версиите в Git да се движи бързо, разклонявайки се, commitсвързване и сливане без забавяне. Когато обаче сигурността се пренебрегне, тази скорост може да има обратен ефект.
Често срещани рискове за сигурността на Git в контрола на изходния код
Атакуващите все по-често атакуват системи за контрол на изходния код като GitHub, GitLab и Bitbucket. Един-единствен изтекъл токен или неправилно конфигуриран работен процес може да даде достъп до цялата верига за доставки на софтуер. Следователно, git сигурност вече не е по избор, а е задължително.
Ето някои от често срещаните рискове:
- Откраднати токени от GitHub използва се за клониране или манипулиране на частни хранилища
- Незащитени главни клонове които позволяват директен риск commits
- Злонамерени сътрудници внасяне pull requests със скрити полезни товари
- Работни процеси с разрешения за запис използва се за инжектиране на зловреден софтуер
Как да прилагате най-добрите практики на Git в контрола на изходния код
За да поддържате контрола на изходния код сигурен, без да забавяте работата си:
- употреба двуфакторна идентификация (2FA) във всички акаунти на разработчици
- Задайте строго правила за защита на клонове и изискват PR прегледи
- Проверка разрешения за работен процес, избягвайте да давате ненужен достъп за запис
- Изпълнете сканирания за уязвимости, тайни и неправилни конфигурации преди сливането
Защо да използваме Xygeni?
Xygeni укрепва възможностите на Git чрез наслояване на:
- CI/CD guardrails
- Откриване на неправилна конфигурация на работния процес
- Тайно сканиране преди сливане
- Прилагане на правилата за заявки за прехвърляне на средства и сливания
В резултат на това можете да поддържате бърз контрол на версиите в Git без да се жертва видимостта или безопасността. Разработчиците работят също толкова бързо, но сега всяка промяна е защитена от автоматизирани проверки.
Когато контролът върху изходния код е засилен, той защитава цялото ви pipeline, От commit да се разположи.
Как да изтеглям (pull) от Git?
- git pull Командата е може би една от най-използваните и най-малко разбирани Git операции. Тя извлича промени от отдалечено хранилище и ги слива в текущия ви клон. Достатъчно просто, нали? Зад тази простота обаче се крие потенциален източник на грешки, повредени компилации и дори проблеми със сигурността.
За да го стартирате:
git pull origin main Тази команда извлича последните промени от main клон на вашето отдалечено устройство (обикновено GitHub, GitLab и т.н.) и се опитва да ги слее с вашия локален код.
Как да изтегляте данни от Git, без да нарушавате сигурността или скоростта на Git
От гледна точка на сигурността, сляпото извличане на код може да бъде рисковано. Злонамерени лица могат да промъкнат вреден код, да нарушат правописни грешки или да „отровят“ кода. commitв публични хранилища. В споделени проекти, дори добронамерени съотборници могат погрешка да внесат несигурни промени. Ето къде най-добри практики в git станат критични.
Също така, когато екипът ви често дърпа, това подкрепя бърз контрол на версиите на git, помагайки на разработчиците да останат синхронизирани, да намалят конфликтите при сливане и да доставят по-бързо. Но ако изтегляте опасен код, скоростта се превръща във ваш враг.
Най-добри практики
да използвам git pull сигурно и ефикасно:
- Оценки на посетители pull request разл преди сливане или изтегляне, особено от външни участници
- предпочитам
git fetch+git mergeза по-голям контрол върху това, което интегрирате - Изпълнявайте тестове локално, преди да изпращате изтеглени промени нагоре по веригата
- Използвайте подписано commitи потвърдете авторството, ако работите по чувствителни проекти
- Следете веригата си за доставки, пакетите, изтеглени чрез автоматизация (напр. скриптове след инсталация), могат да бъдат опасни
Как помага Ксигени
Ксигени добавя guardrails които сканират вашия код преди достига до производство. Например:
- Автоматично открива зловреден софтуер, тайни и уязвим код при отдалечени промени
- Флагове всякакви подправяне или несъответствия в историята на вашето хранилище
- Отнася проверки на политиките on pull requests и слива, блокирайки въвеждането на опасен код
- Непрекъснато следи вашето CI/CD работни процеси, за да се гарантира, че атакуващите не могат да използват логика, базирана на извличане на данни
С Xygeni можете спокойно да прегърнете бърз контрол на версиите в Git, извличане, сливане и внедряване с увереност, че всяка промяна е преминала проверките за сигурност.
How to Commit към Гит?
CommitРаботата в Git е повече от просто писане git commit -m "fix stuff" и продължаваме напред. Ако искаш бърз контрол на версиите в Git който се мащабира заедно с вашия екип и избягва бъдещи главоболия, вашият commitтрябва да бъдат ясни, смислени и сигурни.
How to Commit За безопасно използване на Git чрез най-добрите практики на Git
За да създадете commit, обикновено изпълнявате:
git add <file> git commit -m "Describe what you changed" - git add stage казва на Git кои промени да включи. git commit Командата запазва тези промени в историята на проекта ви. Просто е, нали? Следването обаче най-добри практики в git означава да се продължи по-нататък:
- Напишете описателно commit съобщения.
- Commit логически групирани промени.
- Избягвайте големи, подути commitкоито докосват несвързани файлове.
добър commitправят контрола на версиите по-бърз, по-чист и по-лесен за отстраняване на грешки.
Бързият контрол на версиите в Git започва с „Добро“ Commit Хигиена
Ето къде git сигурност влиза в действие. Небрежният commit може случайно leak secretс, въвеждат уязвимости или изтеглят злонамерени пакети. Преди commitтинг:
- Проверете отново за
.envфайлове, твърдо кодирани токени или открити идентификационни данни. - Валидирайте зависимостите си, безопасни ли са, проверени ли са и актуални ли са?
- Изключете ненужните файлове с помощта на
.gitignore(като лог файлове, артефакти за изграждане или идентификационни данни).
Съвет: Интегриране на commit сканиране във вашия работен процес с инструмент като Xygeni. Той проверява за секрети, пакети с печатни грешки и неправилни конфигурации, преди кодът да достигне до основния ви клон, всичко това без да прекъсва потока ви.
Is git clone Равно на a Pull Request?
Дори не е близо. Въпреки че и двете действия включват отдалечени хранилища, те служат за напълно различни цели:
git cloneе команда, използвана за копирайте цялото отдалечено хранилище на вашата локална машинаОбикновено това е първото нещо, което правите, когато започвате работа по нов проект.
git clone https://github.com/your-team/project.git A pull request (PR) е механизъм за сътрудничество обикновено се използва на платформи като GitHub или GitLab. След като направите промени в локалното или разклоненото си хранилище, отваряте PR (заявка за промяна), за да поискате обединяване на тези промени в споделен клон (като main).
Мислете за това по този начин:
git clone= „Нека взема копие, за да мога да започна да програмирам.“- Pull Request = „Ето какво промених. Моля, прегледайте и одобрете, преди да се обединим.“
Последици за сигурността на Git при клониране на хранилища
Ако просто клонирате хранилища, без да проверявате какво е вътре, може да импортирате:
- Злонамерени скриптове
- Неправилно конфигурирани работни процеси
- Отровени зависимости
По същия начин, pull requests може да бъде вектор за инжектирани уязвимости ако не е сканиран правилно.
Ето защо бързият контрол на версиите не е само въпрос на скорост, а означава и сигурна разработка.cisсъздаване на йони. Инструменти като Ксигени:
- Анализирайте PRs за тайни, уязвим код и неправилни конфигурации
- Приложете проверки на правилата преди сливания
- Предупреждение за опасни приноси, дори в клонирани форкове (forks)
В крайна сметка: Клонирането е начинът, по който започвате; PR-овете са начинът, по който допринасяте. Осигуряването и на двете е част от най-добрите практики на git, които всеки DevOps екип трябва да следва.
Как да клонирам Git хранилище в Visual Studio Code?
Клонирането на Git хранилище може да изглежда лесно, но често именно там тихомълком се промъкват проблеми със сигурността. Ако ви е грижа за бърз контрол на версиите в Git и чисти работни процеси, стъпката на клониране заслужава повече внимание от простото щракване върху „Клониране“.
Най-добри практики в Git при клониране на хранилища в Visual Studio Code
Ето как да го направите сигурно:
- Копирайте URL адреса на хранилището от GitHub, GitLab или Bitbucket. Уверете се, че е от надежден източник, да, дори вътрешните хранилища могат да бъдат рисковани.
- Отворете кода на Visual Studio.
- Отидете в Панел за контрол на изходния код (икона в лявата странична лента) или натиснете
Ctrl+Shift+G. - Кликнете „Хранилище за клониране“, поставете URL адреса и натиснете Enter.
- Изберете локална папка, в която да съхранявате хранилището.
- VS Code ще ви подкани да отворите клонираната папка. Кликнете „Отваряне“.
- Преди да започнете работа, сканирайте хранилището за признаци на проблеми, като например разкрити тайни, зависимости с печатни грешки или съмнителни
.gitистория. Дори проекти, които изглеждат легитимни, могат да включват рискови скриптове или неправилни конфигурации.
Екипите, използващи автоматизирани скенери на този етап, откриват проблемите рано и поддържат връзка с най-добри практики в gitТова е малка стъпка, която може да спести часове по-късно.
Като включите този навик в работния си процес, вие подобрявате както хигиената на проекта, така и сигурността си, без да забавяте темпото. Това е, което съвременните... git сигурност трябва да изглежда като.
Как да проверя текущия клон в Git?
Да знаеш в кой клон се намираш, би трябвало да е втора природа, особено когато жонглираш с множество функции, корекции или линии за издания. Грешките се случват бързо, ако добавяш или изтегляш от грешния клон. За екипи, фокусирани върху бърз контрол на версиите в Git, яснотата побеждава хаоса.
За да проверите текущия си клон:
В терминала си изпълнете:
git branch Текущият клон ще бъде маркиран със звездичка (*), ето така:
* main dev feature/login-fix Като алтернатива, използвайте:
git status Показва нещо подобно:
On branch main Your branch is up to date with 'origin/main'.Избягвайте грешки в сигурността на Git, като проверявате клоновете
Грешките при разклоняване са повече от просто досадни, те представляват риск за сигурността. Случайното сливане или commitПреминаването към грешен клон може да заобиколи прегледите или да инжектира несканиран код в продукцията. Това нарушава потока на най-добри практики в git и отваря вратата за рисковани промени, които се промъкват.
Екипи, които прилагат ясни стратегии за разклоняване и интегрират сканирането в pull requests може да спре повечето проблеми, преди да ескалират. Сигурната разработка не означава бавна разработка, а означава да направите работния си процес с Git по-интелигентен и по-безопасен от самото начало.
Сигурен ли е Git?
Най-добри практики за сигурност на Git, които всеки екип трябва да знае
Сам по себе си Git е просто система за контрол на версиите, тя не защитава магически кода ви. Тя е бърза, гъвкава и мощна, което я прави предпочитана за разработчиците. Тази сила обаче идва с отговорност.
Въпреки че Git поддържа функции като signed commitи защити на клонове, това няма да ви попречи да използвате секретен ключ, да конфигурирате неправилно достъпа или да изтеглите уязвима зависимост. Така че, Git сигурен ли е? Краткият отговор: може да бъде, ако го използвате правилно.
Направете Git сигурен на практика
За да защитите работния си процес в Git, следвайте тези инструкции най-добри практики в git:
- Задайте правила за защита на клонове и изисквайте pull request коментари.
- Никога commit тайни или токени. Използвайте
.gitignoreи сканирайте вашия commits. - Преглеждайте редовно достъпа до хранилището си, не давайте администраторски права на всеки.
- Подпишете вашия commitс GPG за почтеност.
- бягане pre-commit hooks или CI сканирания за улавяне на рискови промени, преди да се появят.
Сигурността в Git не е превключвател, който превключвате, а е навик. Когато третирате Git като част от вашата повърхност за атака, а не просто като инструмент, започвате да изграждате истинска... git сигурност във всяка стъпка. А най-хубавото? Тези навици не ви забавят. Всъщност те правят екипа ви по-бърз и по-уверен, като по този начин постигат резултати. бърз контрол на версиите в Git без да рискуваш това, което е важно.
Най-добри практики в Git за сигурен и бърз контрол на версиите
За да поддържате здрава и сигурна кодова база, вашият Git работен процес се нуждае от повече от просто удобни преки пътища. Тези най-добри практики в git са предназначени да подобрят екипното сътрудничество, да наложат git сигурност, и подкрепа бърз контрол на версиите в Git без да ви забавя.
Използвайте Clear и Atomic Commits
Всеки commit трябва да отразява една логична промяна. Това опростява прегледите на кода, отмяната на предишни промени и проследяването на промените. Избягвайте commitполучаване на големи парчета несвързани актуализации.
Никога Commit Тайните
Винаги проверявайте за .env файлове, токени за достъп или идентификационни данни преди изпращане. Използвайте .gitignore да изключвате чувствителни файлове и да прилагате автоматизирани инструменти за сканиране, за да откривате разкрити тайни на ранен етап.
Прилагане на правилата за защита на клоновете
Защитете основните клонове, като изисквате pull requests, одобрения и проверки на състоянието. Това гарантира, че непроверен или рисков код никога няма да достигне до продукция.
Преглед на зависимостите и сканиране за уязвимости
Закрепете зависимостите си и избягвайте ненадеждни пакети. Използвайте автоматизирани инструменти, за да сканирате хранилището си за уязвими или злонамерени библиотеки, преди да бъдат обединени.
Знак Commits
Активиране на GPG commit подписване, за да се потвърди самоличността на участниците. Тази стъпка добавя допълнителен слой git сигурност и предотвратява подправянето commit истории.
Мониториране на достъпа и разрешенията
Прегледайте кой има достъп до вашите хранилища и какво ниво на контрол имат. Ограничете достъпа за запис, където е възможно, и редовно премахвайте неактивните сътрудници.
Автоматизирайте сканиранията преди сливане и проверките за правила
употреба CI/CD инструменти за валидиране на всяко pull request за тайни, неправилни конфигурации и рискови модели. Автоматизирането на тези проверки е от решаващо значение за поддържането бърз контрол на версиите в Git в мащаб.
Почистване и пребазиране
Преди да натиснете, поправете смачканото commitили промени за почистване. Това поддържа историята ви четлива и намалява шума по време на съвместна работа.
Как Xygeni помага за осигуряване на сигурността на Git
Сигурността не е нужно да ви забавя, особено в Git. Xygeni вгражда невидима защита във вашия работен процес, за да можете... commit, разклонявайте се и сливайте, без да се притеснявате какво може да се промъкне.
Улавя тайни, преди да се разпространят
Случайно commit a .env файл? Случва се. Xygeni маркира тайни като API токени или облачни идентификационни данни в реално време, независимо дали са в нов commit, скрита конфигурация или слой на Docker. Получавате известия, преди да влязат в производство, с опционален работен процес за автоматично отменяне и коригиране.
Блокира рискови зависимости на Commit Време
Не би трябвало да правите обратно инженерство package.json след неуспешно изграждане. Xygeni сканира вашите зависимости по време на commit и маркира пакети, съдържащи злонамерен софтуер, печатни грешки или остарели библиотеки, и ви казва кои от тях са действително експлоатируеми, а не само уязвими.
Автоматично маркира опасни конфигурации на CI
CI/CD е мястото, където малките неправилни конфигурации се превръщат в големи инциденти. Независимо дали настройвате .github/workflows или актуализиране на обява за работа в Jenkins, Xygeni преглежда вашите pipeline конфигурации за рискови модели, като разрешителни токени, опасни скриптове или инжектиране в шел, и спира опасен код, преди да се изпълни.
Уведомява ви за подозрителна активност в хранилището
Xygeni следи вашето SCM дейност непрекъснато. Той сигнализира за принудително изпращане към защитени клонове, премахнати контроли за достъп или необичайни commit модели, след което ви показва точно какво се е променило, кой го е променил и кога.
Прилага се интелигентно Guardrails относно заявленията за прехвърляне на средства и сливанията
Вие определяте какво е приемливо, Xygeni го прилага. Независимо дали блокира PR със секретни данни, неуспешни компилации с експлоатираеми зависимости или прилага политики за сигурност в цялото хранилище, Xygeni ги прилага. guardrails последователно и тихо в различните екипи.
С Xygeni не е нужно да запомнете правилата за сигурност, те са вградени във вашия Git работен процес по подразбиране.
Без превключване на контекста. Без прекъсвания. Просто бързо, сигурно. commitкоито са готови за изпращане. Искате ли да видите как това изглежда във вашия собствен работен процес? Опитайте Xygeni във вашето Git хранилище, не е необходима кредитна карта.
