Понимание Git помогает В разработке, но изучение начинать сложно. Пусть это руководство станет первым шагом к знакомству с Git.
Git используется для хранения и транспортировки кода по умолчанию, это основная система контроля версий для разработчиков сегодня. Каждый, кто использовал Git, знаком с git add, git commit и git push. Для большинства пользователей это все, что они когда-либо будут делать с Git, и их это устраивает. Этого достаточно для большинства их задач.
Необычные ситуации возникают время от времени, и почти каждый сталкивается с необходимостью сделать что-то более продвинутое. Например, git rebase или git cherry-pick, или работая с изменением состояния HEAD. Именно здесь многие разработчики начинают немного нервничать.
Я здесь, чтобы сказать вам, что все в порядке. Каждый, кто использовал или когда-либо будет использовать Git, повстречает те же проблемы.
Git великолепен, но не прост в изучении, и иногда он может сбить с толку. Git не похож почти ни на что другое в информатике. Обычно вы изучаете его постепенно, в контексте другой работы по программированию. Большинство разработчиков, которых я встречал, никогда специально не изучали Git, кроме, разве что, краткого руководства.
Git имеет открытый исходный код, а это означает, что мы можем изучить код и посмотреть, как он работает. Он написан в основном на языке C, что может затруднить его понимание для многих разработчиков. У вас может сложиться впечатление, что Git был написан для продвинутых профессионалов в области Linux. Это потому, что так и было изначально.
Краткая история Git
Git начинался как специальный набор скриптов, которые Линус Торвальдс мог использовать для управления исправлениями.
Вот как он представил то, что впоследствии стало Git, в списке рассылки ядра Linux:
So I’m writing some scripts to try to track things a whole lot faster. Initial indications are that I should be able to do it almost as quickly as I can just apply the patch, but quite frankly, I’m at most half done, and if I hit a snag, maybe that’s not true at all. Anyway, the reason I can do it quickly is that my scripts will _not_ be an SCM, they’ll be a very specific “log Linus’ state” kind of thing. That will make the linear patch merge a lot more time-efficient, and thus possible.
Поэтому я пишу несколько скриптов, чтобы отслеживать ситуацию намного быстрее. По первоначальным данным, я смогу сделать это почти так же быстро, как просто наклеить пластырь, но, честно говоря, я сделал максимум половину, и если я наткнусь на препятствие, возможно, это вообще не так. В любом случае, причина, по которой я могу сделать это быстро, заключается в том, что мои скрипты не будут SCM, они будут очень специфической вещью типа «регистрации состояния Линуса». Это сделает объединение линейных патчей намного более эффективным по времени и, следовательно, возможным.
Когда я не понимаю, как работает Git, первое, что я делаю, — это представляю, почему и как Линус применил бы его для управления исправлениями. Он вырос, чтобы обрабатывать гораздо больше, и действительно представляет собой полноценный SCM (Source code management), но запоминание изначального варианта использования иногда полезно для понимания «почему».