Как и зачем работать с Git через командную строку? В статье содержится набор простых действий и команд, которые помогут разобраться с этим.
Перед началом статьи полезно было бы напомнить некоторые термины:
Репозиторий — место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети.
Коммит (commit) — фиксация изменений любых файлов, входящих в репозиторий
Merge — слияние, принимает содержимое ветки источника и объединяет их с целевой веткой.
Push( или “Запушить”) — передача последних фиксаций на удаленный репозиторий
Работать с системой контроля версий и удалённым репозиторием можно внутри многих сред программирования. Такую функцию поддерживают, например, Visual Studio или среды компании JetBrains (PyCharm, IntelijIdea и т.д). Однако в некоторых случаях GUI не очень удобен, и приходится прибегать к работе через консоль. В нашем случае через GitBash.
Пусть на начальном уровне функционала IDEA более чем достаточно, полезно было бы уметь работать через консоль, чтобы иметь представление хотя бы об альтернативе.
Разбирать мы будем самые простые команды для:
- Клонирования существующего репозитория
- Связи локального репозитория с удаленным
- «Стягивание» изменений с удаленного репозитория, отправка измененной версии обратно на GitHub.
- Создание и работы с ветками
Создание репозитория
Здесь есть несколько вариантов. Например, проект уже может лежать у нас на компьютере, а нам необходимо подключить его к системе контроля версий и связать его с GitHub. Либо же какой-то код уже имеется на удаленном репозитории GitHub, а нам лишь необходимо получить его и начать работу.
Разберем сначала второй вариант, но для начала откроем GitBash. У нас появится такое окно:
У гита есть настройка пользователя, от которого будет идти работа. Это разумная и необходимая вещь, так как когда создается коммит, гит берет именно эту информацию для поля Author. Чтобы настроить имя пользователя и пароль для всех проектов, нужно прописать следующие команды:
<em>git config --global user.name ”Ivan Ivanov”</em>
<em>git config --global user.email ivan.ivanov@gmail.com</em>
Далее нам необходимо выбрать папку, где будет лежать проект.
Для этого прописываем путь к папке в таком формате:
cd/:c/<some_dir1>/…/<some_dirK>
Сверху, выше черного пространства указан путь по умолчанию, поэтому можно не прописывать его заново, если мы решили сохранять проект внутри дочерних папок этого пути. В моем случае:
Далее нажимаем Enter. Теперь нам нужно «клонировать» проект из удаленного репозитория. Для этого находим нужный проект на GitHub.
Нажимаем на кнопку Code и из выпадающего окна копируем HTPPS ссылку.
Далее в консоли git bash пишем:
<em>git clone <скопированная_ссылка></em>
Теперь файлы репозитория лежать у нас на компьютере. Снова воспользуемся командой cd чтобы по относительному пути перейти в папку проекта.
Как мы видим появилась возле относительного пути надпись master, это означает что файлы данной папки подключены на систему контроля версий и на данный момент мы находимся на ветке с название master. Что такое ветки я расскажу позднее.
Теперь разберем вариант, когда у нас уже имеется какой либо проект, а нам его нужно подключить к git и загрузить на удаленный репозиторий GitHub
Для этого заходим в папку нашего проекта через консоль gitBash и используем команду:
git init — подключаем файлы к системе контроля версий
Как и в прошлый раз видим надпись master, значит, репозиторий создан, НО пока что локальный. Свяжем его с удаленным, предварительно создав на GitHub.
Так же как и в первом варианте копируем HTTPS ссылку и открываем gitBash.
Введем команду:
<em>git remote add origin https://github.com/DanSprat/TestRepo.git</em>
Теперь мы связали наш локальный и удаленный репозитории. Осталось лишь загрузить файлы на GitHub.
Проверим командой git status возможность сделать commit.
Как мы видим файл SomeFiles.txt был изменен, но пока не готов к коммиту.
Исправим это:
git add . – добавляем все файлы для коммита (вместо точки можно поочередно вписывать названия нужных нам файлов)
Если никаких надписей не появится – все ОК.
Теперь наши файлы готовы к коммиту.
git commit –m <text> — фиксируем изменение проекта
Чтобы проверить последние коммиты напишем команду
git log — список коммитов с полной информацией
ВАЖНО! После этой команды станет недоступна командная строка, чтобы вернуться наберите “q” в нижней строке.
git log —oneline — список коммитов с краткой информацией
И последний шаг – выгрузка на GitHub
git push —set-upstream origin master – загружаем все на удаленный репозиторий. Приписка —set-upstream origin master – связывает нашу локальную ветку master с одноименной удаленной.
Проверяем на GitHub и видим, что все файлы успешно загружены
Теперь предположим, что у нас уже есть локальный репозиторий и он связан с удаленным. Допустим какой- то программист сделал изменения в проекте и «запушили» на GitHub. Как получить обновленный код?
Для этого есть команда
git pull – обновить локальную копию удаленного репозитория
Теперь у вас на компьютере актуальная версия проекта. Можно снова править, коммитить и пушить.
Работа с ветками
Ветка в Git это подвижный указатель на один из коммитов. Обычно ветка указывает на последний коммит в цепочке коммитов. Ветка берет свое начало от какого-то одного коммита.
Во время создания проекта под управлением системы контроля версий создается ветка по умолчанию – master.
Ветка по сути — это ответвление от текущей версии проекта. Все изменения, которые будет вносить разработчик, будут сохраняться в ветке и когда функция будет полностью реализована и проверена, разработчик сможет слить все свои изменения с веткой master
Как часто бывает, над проектом работает сразу несколько программистов, и допустим, один из них работает над какой-нибудь новой функцией. Если он будет вносить изменения в master, то эти изменения могут повлиять на работоспособность проекта.
Чтобы создать ветку нужно прописать
git branch <name_of_branch>
Теперь, нужно перейти на новую ветку
git checkout <name_of_branch>
Но можно все сделать за один шаг
git checkout – b <name_of_new_branch>
Когда программист решает, что его функция полностью работает, он может перекинуть все изменения с рабочей ветки на ветку master. Для этого нужно переключить на основную ветку и сделать merge:
git checkout master
git merge <name_of_branch>
Теперь можно коммитить и пушить изменения.
Попов Даниил, после окончания базового курса, октябрь 2020