Git: бришење гранки, Merge и враќање лош Push

August 2, 2026 · – посетители

Овие три работи се јавуваат постојано, а некако командите никогаш не остануваат баш во главата од еден пат до друг. Затоа еве ги, запишани како што треба.

Бришење гранка

git branch -d feature-x

Ова е безбедната верзија — Git прво проверува, и одбива ако feature-x има Commit-и што никогаш не стигнале до твојата тековна гранка. Ако си сигурен, можеш да го заобиколиш тоа: (1)

git branch -D feature-x

Но тоа ја брише само локално. Ако гранката постои и на remote-от (на пример на GitHub), треба да ја избришеш и таму, посебно:

git push origin --delete feature-x

Едно нешто вредно да се знае: бришењето гранка всушност не ги брише нејзините Commit-и. Тие само остануваат без референца и седат во репозиториумот сè додека garbage collector-от на Git конечно не ги исчисти, а тоа може да потрае. Значи git branch -D е поблага команда отколку што изгледа — ако избришеш погрешна гранка, обично сепак постои пат назад (повеќе за тоа во делот за Reflog подолу). Не би се потпрел на тоа како план, но добро е да се знае дека постои.

Merge на гранки

Вообичаениот редослед е: премини на гранката во која сакаш да правиш Merge, па потоа спои ја другата во неа.

git checkout main
git merge feature-x

Она што следи зависи од тоа дали main се поместил откако си се одгранил. Ако не се поместил, Git едноставно го лизга покажувачот на main напред за да се изедначи со feature-x — тоа е fast-forward, без Merge Commit. Ако main во меѓувреме напредувал, Git создава вистински Merge Commit кој ги врзува двете истории заедно (2).

Понекогаш го сакаш токму тој Merge Commit дури и кога fast-forward бил можен — тој остава видлив белег во историјата дека постоела feature-гранка и дека била споена, наместо промената тивко да се вглави. За тоа:

git merge --no-ff feature-x

Ако истите редови биле допрени од двете страни, Git запира и го остава конфликтот тебе да го решиш:

git status

Тоа ќе ги наведе датотеките што се во конфликт. Отвори ги една по една, ќе видиш ознаки <<<<<<<, ======= и >>>>>>> околу спротивставените промени — избери што всушност треба да остане, избриши ги ознаките, па потоа:

git add resolved-file.txt
git commit

А ако сето тоа прерасне во поголема неред отколку што вреди, можеш едноставно да се откажеш од целата работа:

git merge --abort

Тоа враќа сè точно онака како што било пред да почнеш со Merge-от.

Враќање лош Push

Ова е ситуацијата од која луѓето најмногу паничат, а искрено, таа паника обично е неоправдана — но овде навистина е важно кое решение го земаш.

Ако постои и најмала можност некој друг веќе да ја повлекол гранката, не допирај ја историјата. Наместо тоа, додади нов Commit што го поништува стариот:

git revert <bad-commit-sha>
git push

Ова е здодевната, секогаш-безбедна опција. Не презапишува ништо — само додава Commit одозгора што ја поништува грешката, така што историјата на сите останува синхронизирана без некој да мора да прави нешто посебно од своја страна (3).

Ако гранката е навистина само твоја и никој сè уште не ја повлекол, можеш да ја превртиш назад и да ја презапишеш: (4)

git reset --hard <last-good-commit-sha>
git push --force-with-lease

Користи --force-with-lease, а не обично --force, барем од навика ако не поради друга причина. Разликата е поважна отколку што изгледа: --force-with-lease проверува дали никој не направил Push на гранката откако последен пат си направил fetch, и одбива ако е така. Обичното --force не проверува ништо — со задоволство ќе ја презапише туѓата работа без ниту трошка предупредување (5).

А ако зјапаш во терминалот обидувајќи се да се сетиш кој всушност бил последниот добар Commit — git log нема да ти помогне тука, бидејќи прикажува само Commit-и достапни од местото каде што моментално си, а тоа не го вклучува она од кое веќе си се оддалечил со Reset. Она што ти треба е:

git reflog

Тоа прикажува секое место кон кое твојата гранка неодамна покажувала, вклучувајќи ги и оние што испаднале од вообичаената историја. Врати се назад до пред работите да тргнат наопаку, па потоа: (6)

git reset --hard HEAD@{2}

(замени со позицијата или SHA што всушност одговара на твојот случај). Reflog-от е локален на твојата машина и обично ги чува записите околу 90 дена, така што тоа е помалку „итно поништување за лоши Push-ови“, а повеќе општа мрежа за безбедност за „мислам дека штотуку нешто расипав“ — вреди да се запамети дека постои дури и надвор од оваа конкретна ситуација.

Заклучна мисла

Сите три се потпираат на истиот основен факт: Git речиси никогаш ништо не отфрла веднаш. Избришани гранки, ресетирани Commit-и, стари позиции на гранка — сите остануваат подолго отколку што изгледа. Токму тоа е она што ги прави -D, reset --hard и force push-от доволно безбедни за секојдневна употреба, сè додека знаеш каде да бараш ако некое од нив се покаже како грешка.

Поврзани текстови

• Разбирање на Make — што всушност предизвикува повторно градење

Дополнително читање

1. git-branch — создавање, листање и бришење гранки.
2. git-merge — стратегии за спојување и решавање конфликти.
3. git-revert — поништување Commit-и преку создавање нови.
4. git-reset — поместување на покажувачот на гранка, со разликата помеѓу --soft, --mixed и --hard.
5. git-push: --force-with-lease — зошто е побезбедна од --force.
6. git-reflog — враќање Commit-и што повеќе не се појавуваат во вообичаената историја.