Простое понимание Git
Во-первых, поймите, что клиентская сторона означает ваш локальный компьютер. Компьютер, который физически находится перед вами. Также поймите, что сервер Git — это удаленный компьютер, компьютер, который находится где-то еще, с которым вы разговариваете со своим локальным компьютером. Во-вторых, поймите, что Git — это инструмент разработки программного обеспечения с открытым исходным кодом, доступный каждому, и что Github — это компания, которая размещает сервер Git, поэтому вашей команде не нужно настраивать дополнительный сервер и управлять им. Git работает, размещая весь код команды на сервере, доступном для всех в команде. На сервере хранится основная копия кода, в которую команда может вносить свои изменения и извлекать другие изменения. Github предоставит это вашей команде бесплатно, но оно будет общедоступно. На стороне клиента или на локальном компьютере для члена команды, пишущего код, программное обеспечение Git хранит копию исходного исходного кода, которую можно редактировать. Программист, такой как вы, внесет изменения в эту локальную копию, а затем Git отследит эти изменения. Изменения в коде попадают в промежуточную область, которая находится на стороне клиента (ваш локальный компьютер). Каждое изменение, которое вы хотите зафиксировать, называется фиксацией. Каждый коммит индексируется хешем коммита. На самом деле вы можете возвращаться между фиксациями и возвращать изменения в свою локальную редактируемую копию. Когда кто-то хочет внести большие изменения, он делает копию основного кода и ответвляется, чтобы внести свои изменения, а затем объединяется обратно, когда они закончат.
Создание репозитория
Репозиторий кода — это просто место для хранения вашего исходного кода и других важных файлов, которые должны быть доступны вашей команде. Думая о том, как работает инфраструктура Git, нам нужно настроить репозиторий на сервере Git, а затем настроить клиент, чтобы он мог общаться с этим сервером. Поскольку мы используем Github, нам придется использовать сайт для создания репозитория. Это легко, и все это можно сделать через веб-интерфейс. Как только это будет сделано, это даст вам варианты, которые я пройду сейчас.
git инициировать
Это инициализирует текущий каталог в каталоге git, который будет загружен с помощью .git. Git будет просматривать этот каталог на предмет изменений, соответствующих промежуточной области клиента. Затем мы должны указать URL-адрес сервера Git, в случае с Github мы должны указать URL-адрес репозитория Github.
git remote добавить `repo_name` `server_url`
Эта команда сообщит локальному клиенту, откуда извлекать и отправлять изменения, а также присвоит ей удобное имя.
Клонирование репозитория
В рабочей ситуации вас, скорее всего, попросят клонировать исходный код проекта и внести в него изменения.
git клонировать «repo_url»
Внесение изменений, коммит кода
Что теперь делать, когда вы действительно вносите изменения? Зафиксируйте изменение в промежуточной области.
git commit -am «сообщение фиксации»
Здесь мы говорим git зафиксировать наши изменения в тестовой области. Изменения не в мастере и не являются общими, но вы можете думать об этом как о сохраненной контрольной точке для себя. Это даст вам идентификатор фиксации для изменений и зарегистрирует сообщение о том, что вы изменили.
Совместное использование кода, отправка кода
Теперь, когда у нас действительно есть некоторые изменения, сохраненные в нашей тестовой области, мы можем поделиться ими с остальной частью команды.
мастер происхождения git push
Теперь это вытолкнет все коммиты из вашей промежуточной области и объединит их с основным репозиторием кода сервера. Origin — это переменная в конфигах git, которая указывает, какой репозиторий кода сервера содержит код. Мастер — это то, что мы называем основной веткой, об этом мы поговорим позже в отдельной статье.
Получение изменений от команды, получение кода
Товарищи по команде внесли некоторые изменения, и теперь вы, вероятно, хотите синхронизировать его с вашей локальной копией.
мастер происхождения git pull
Это вытянет и объединит все изменения с вашей локальной веткой. Как и в прошлый раз, вы можете видеть, что мы просим вытащить с исходного сервера основную ветку.
Проверка статуса
Теперь иногда мы не можем вспомнить, где мы сделали какие-то изменения или добавили ли мы какие-то файлы. Самый простой способ проверить незафиксированные изменения — использовать команду git status.
статус git
Проверка изменений
Иногда мы хотели бы знать, кто внес изменение или когда оно было последним. Об этом можно узнать из команды log. Теперь представьте, что журнал извлекается с исходного сервера каждый раз, когда мы извлекаем данные. Таким образом, у нас есть только журнал с последней попытки. Каждое сообщение фиксации и идентификатор фиксации показаны здесь. Мы можем откатить изменения, используя эти идентификаторы коммитов.
журнал git
Дождитесь моей следующей статьи, где я расскажу о работе над несколькими файлами между собой. Я буду говорить о ветвлении, разрешении конфликтов и откате локальных изменений.
Если вам понравилась эта история, ознакомьтесь с другими моими статьями на Medium или зайдите на мой сайт: https://codeisdead.com.
