LINUX.ORG.RU

Расскажите про Git

 ,


0

2

Я не понимаю, как ведётся совместная разработка на больших проектах.

Например, есть ядро линукса. Над ним работают тысячи, если не десятки тысяч человек. И все они вносят различные изменения. Какие-то исправления, улучшения, новые возможности. Допустим, кто-нибудь разработал крутой OOM. Но код писал он на определённой версии ядра, уже устаревшей к моменту окончания разработки. Как ему внести эти изменения в актуальную версию ядра? Кто-то вручную должен адаптировать его код?

Ну и посоветуйте книги/гайды по гиту. Эта вундервафля слишком сложная.

А чем не нравится делать архивы с разными версиями исходников? Ну, типа 2022-02-24.rar – все просто и наглядно.

DrBrown
()
Ответ на: комментарий от DrBrown

Хочется красиво. Да и, например, если проект весит много, то иметь на каждую версию архив - такое себе.

Original_1
() автор топика

Ну и посоветуйте книги/гайды по гиту.

git status
git add filename
git commit
git push
git pull
git clone
git branch
git checkout
git merge
fsb4000 ★★★★★
()
Ответ на: комментарий от Original_1

Хочется красиво

Намажь архив нутеллой, будет и красиво и вкусно.

DrBrown
()

ну ядро линукса настолько большое, что вероятность встретить другого кодера на той же строчке крайне мала… :)

проблема разрешения мердж-конфлитов стара как само программирование.
вот первый выхлоп из яндекса Безболезненное разрешение Merge конфликтов в Git а там еще куча статей

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)

гугли - git длы новичков. ничего там сложного нет. идея git - иметь базу данных версий содержимого неких твоих файлов, с метками версий, и ты можешь как коммитить туда новые версии данного файла или файлов, а также откатываться по версиям назад.

если есть конфликт файлов - он либо разрешается автоматически, либо требует ручного разрешения, когда невозможно однозначно разрешить конфликт.

ну и куча вспомогательной ерунды вокруг этого всего, типа веток

alysnix ★★★
()

Попробуй pijul, потом нам расскажешь.

grem ★★★★★
()

Девелопер перед тем, как запушить свой коммит, делает отдельный бранч и коммит отправляет в него. Дальше уже забота старшего поргоммиста, пусть сам трахаецца с этими мержами.

dnb ★★★★
()

Я не понимаю, как ведётся совместная разработка на больших проектах.

Есть разные схемы. Если хочешь подготовится к использованию гита на работе, то можно забить, у них должен быть подробный документ, как что делать, потому что может быть по разному. А если для своего проектика, то прогай в локальной репе и пуши в репу на сервере. Потом можно освоить ветки.

goingUp ★★★★★
()

Толкай в мастер а если запрещено - так то мужеложцы сделали, иди разбираться

DumLemming ★★★
()
Ответ на: комментарий от AntonI

Тогда уж устраивать вечера художественного чтения исходников, как это принято у поэтов.

DrBrown
()
git checkout main
git pull
git checkout feature/my-feature-branch
git rebase -i main
git add -p
git commit -m $COMMIT_MESSAGE
git push
# repeat until merged
anonymous-angler ★☆
()
Последнее исправление: anonymous-angler (всего исправлений: 1)

гит надо использовать даже в индивидуальной разработке. создаешь локальный реп, ветку develop, от нее ветки фич, когда надо, и коммитишь туда в свое удовольствие. дефолтная ветка мастер - это считай продакшн ветка(ну можно и отдельно сделать «продакшн» ветку). полезно тем, что можно безболезненно делать разные версии проекта, откатываться, делать сравнения - что менялось, если попалась какая-то хитрая бага и проч.

а потом радостно выложить этот свой реп на гитхаб, чтобы все подывились какой ты отпетый погроммист.

alysnix ★★★
()

ядро линукса

Засылаются через рассылку патчи. Высокопоставленные лица проверяют, включают в состав в случае одобрения

xDShot ★★★★★
()

Как ему внести эти изменения в актуальную версию ядра?

Перебазировать изменения на актуальную версию

xDShot ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.