Удаленные репозитории с Git

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

Удаленные репозитории

Удаленный репозиторий - это тот, который нам не принадлежит, который может находиться на облачном сервере, на компьютере другого разработчика или даже в файловой системе. Основная функция этих репозиториев заключается в том, что другие разработчики могут сотрудничать с ним, включая нас через филиалы или филиалы .
Есть много сервисов, которые позволяют нам создавать наши удаленные репозитории, у нас есть GitHub, но он ориентирован на личные проекты и сотрудничество между сообществом разработчиков с определенными проектами, и у нас есть Bitbucket, который ориентирован на частные проекты и рабочие группы в компаниях или организациях.
В этом уроке мы будем использовать Bitbucket, он бесплатный и именно он больше всего напоминает философию работы, на которой мы хотим сосредоточиться.

Создание удаленного хранилища

Мы упомянули, что удаленный репозиторий нам не принадлежит, поскольку он расположен на платформе, которая не принадлежит нам, однако мы можем выполнять над ним операции, начиная от создания его до удаления, если мы хотим.
Чтобы создать наш удаленный репозиторий, мы переходим на страницу Bitbucket и, если мы не зарегистрированы, мы создаем нашу учетную запись, входя в нашу основную панель и ищем опцию Создать, чтобы создать удаленный репозиторий.

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

Теперь нам нужно сделать первый шаг, чтобы убедиться, что все работает правильно, для этого мы создадим новый файл, который может быть .txt с простым текстом. Мы используем команду add, чтобы добавить его в репозиторий, добавляем наш первый коммит и, наконец, добавляем ветку master :

Как мы видим, все прошло гладко, однако для пользователей, которые запускаются и чувствуют себя немного неуверенно по поводу инструмента и задаются вопросом, были ли загружены файлы, они могут перейти в Bitbucket и обновить репозиторий, и они смогут увидеть сделанные изменения :

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

Работа с удаленным репозиторием

Как только мы создали наш репозиторий, пришло время начать совместную работу, для этого первое, что мы должны сделать, - это создать ветки . Помимо основной ветки, мы должны создать дополнительную ветку для проекта в целом, и именно в нее разработчики будут объединять и загружать свои окончательные изменения.
Отдельные филиалы

Кроме того, рекомендуется, чтобы у каждого разработчика была ветвь для него, поэтому изменения каждого члена команды будут разбиты на разделы, и в случае ошибки в окончательной загрузке их можно будет вернуть без особых проблем.
Мы создадим ветку с названием development и персональную ветку для наших изменений, мы сделаем это с помощью команды branch, за которой следует имя ветки, давайте посмотрим, как это выглядит в нашей консоли:

Это создаст наши ветки локально, но пока мы не внесем в них изменения и не сделаем push, они не будут зарегистрированы в нашем репозитории, для этого мы перейдем в нашу личную ветку с помощью команды checkout и подтвердим со статусом, что нам нечего делать, Это должно быть так, поскольку это новая ветка, давайте посмотрим:

$config[ads_text5] not found

Теперь мы создадим папки и некоторые файлы, чтобы придать вес нашему проекту, однако помните, что изменения будут в нашей ветке. После выполнения этих операций мы должны добавить их с помощью add, выполнить соответствующий коммит и, наконец, отправить в нашу ветку, давайте посмотрим эти операции в нашей командной консоли:

Мы уже сделали загрузку в нашу ветку, теперь нам просто нужно сделать то же самое с веткой разработки, но для этого нам не нужно использовать команду add или commit, для этого мы будем использовать команду merge, чтобы присоединиться к изменениям, которых нет в ветвь, это экономит нам много работы и позволяет нам контролировать действия, которые мы выполняем в хранилище.
Чтобы сделать это, мы должны переключиться на ветку разработки с командой checkout, и там мы выполним команду merge, указывающую на ветку jacosta, чтобы присоединиться к внесенным нами изменениям.

$config[ads_text6] not found

С помощью этого действия обновление будет выполнено, но это не означает, что мы загрузили изменения в ветку точно так же, как мы должны выполнить отправку, но это позволяет нам сохранить некоторые дополнительные шаги и дает нам более чистый процесс загрузки. Это действие создаст новую ветвь и объединит наши изменения, если мы все еще не доверяем тому, что консоль сообщает нам, мы можем перейти к Bitbucket, где мы можем увидеть созданные новые ветки, а также действия, которые мы выполнили в разделе недавней активности:

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

Клонирование удаленного хранилища

То, что мы только что увидели, является частью идеи, что мы были теми, кто создал удаленное хранилище, но в тот момент, когда нас приглашают, процесс немного меняется. Предположим, что наша команда также использует Bitbucket и создала репозиторий на платформе, перейдем на главную панель, найдем опцию Clone и, нажав на нее, увидим точную строку для выполнения этого действия, которая клонирует нас именно в том, что находится в репозитории. тот момент:

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

Эта ошибка является одной из наиболее распространенных, и когда многим начинающим пользователям не удается управлять репозиториями с помощью Git, и это загрузка файлов в репозиторий без предварительной проверки внесения изменений. Но решение простое, что может быть самым сложным - принять практику и выполнить команду pull перед началом работы над проектом и перед загрузкой чего-либо, это позволяет избежать неловкой ситуации конфликта в хранилище. вызвано нами.

$config[ads_text5] not found

Заключительные советы

Наконец, важно отметить, что хотя Git позволяет нам контролировать наш проект и наши архивы, объединяя изменения в команде разработчиков, это не инструмент, который мы можем использовать просто для управления проектами.
Мы рекомендуем брать его рука об руку с такими приложениями, как asana или Trello, обеспечивая, чтобы наши проекты охватывали все стороны, таким образом, мы будем знать, что в них всегда будут самые последние изменения, а также что даты и обязательства, установленные для него, будут выполнены в обязательном порядке.,
На этом мы завершили это руководство, в котором мы могли бы создать наш удаленный репозиторий с помощью Bitbucket и, кроме того, мы могли видеть весь рабочий процесс, необходимый для оптимального управления им, когда мы работаем в среде совместной разработки.

$config[ads_text6] not found