Как работать над одним проектом в github

3. Работа со своим проектом на GitHub

3.3. Получение репозитория из GitHub и отправка изменений для текущего проекта с ветками (для нескольких пользователей)

Если над проектом работает несколько пользователей, то в проекте будут работать в разных ветках ответвленных от главной master :

1. git checkout master — переключаемся в ветку master локально, чтобы забрать ветку master с коммитами из репозитория с GitHub .
2. git pull origin master — забираем все изменения с ветки master
3. git checkout -b comments — когда мы обновили ветку master в текущем локальном репозитории получив данные из GitHub , то теперь создаем и переключаемся в новую ветку comments для внесения новых изменений.
4. git status — после внесения изменений в ветку comments проверяем текущее состояние репозитория перед отправкой на GitHub
5. git add . — индексируем файлы после изменения перед отправкой на GitHub
   git add «index.html» — индексирует выбранный файл
6. git commit -m «. » — короткое описание коммита
7. git push -u origin comments — отправляем изменения в удаленный репозиторий.
   • — origin — главный репозиторий,
   • — comments — новая ветка от ветки master

Дополнительно

• 6.1. Сохранение фрагментов кода на GitHub
  — Gist
• 6.2. Удаление репозитория
• 6.3. Создание файла — .gitignore
• 6.4. Создание файла README.md синтаксис Markdown
• 6.5. Откат к коммиту, расширение Git Graph для VS Code
• 6.6. Описание профиля на GitHub

7. Короткая инструкция

• 7.1. Если проекта нет на компьютере: клонирование и работа с проектом
• 7.2. Если проект есть на компьютере: получение обновлений (git pull) и работа с проектом

8. Secret Cloud

• 8.1. Клонирование проекта
• 8.2. Начало работы над задачей в Jira
• 8.3. Начало и завершение работы в новой ветке VSCode: stash, pull, add, restore, commit и push
• 8.4. Просмотр всех коммитов и активностей
• 8.5. Завершение задачи в Jira и учет рабочего времени
• 8.6. Работа с багами
• 8.7. Unit-тестирование Jest
• 8.8. Merge Request в GitLab
• 8.9. Присоединений изменений с удаленной ветки (с GitLub) к новой локальной ветке
• 8.10. Посмотреть другую удаленную (GitLab) ветку, с которой не работал
• 8.11. Получение данных по API для таблиц
• 8.12. Структура импортов
• 8.13. Добавление алиасов для путей в webpack
• 8.14. Удаление подписки при размонтировании компонента
• 8.15. Отправка запроса и получение данных:
  useSelector, useDispatch, actions, initialState
• 8.16. Структура проекта
• 8.17. Загрузка файла

Пример работы над проектом в системе контроля версий (git)

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

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

Цепочка применения изменений в нашем случае будет выглядеть как «Feature» -> «Dev» -> «Production». Между «dev» и «production» еще может возникать «stage», но это уже зависит от конкретных особенностей проекта, в том числе финансовых.

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

Как это выглядит на пальцах?

Программист на локальной машине создает новую ветку, в котрой он будет работать над поставленной задачей. И тут надо запомнить первую и одну из самых главных тонкостей — ветка создается только от актуальной основной («master») ветки.

Почему именно так? Какими бы не были схожими ваши ветки, они все разные, причем иногда разные кардинально — начиная от прав доступа к файлам и заканчивая порой совершенно неопределимыми различиями, исток которых, по всей видимости, кроется чуть ли не в рознящихся контрольных суммах. Однако в конечном итоге любые изменения будут заливаться в основную ветку, на которой работает production. И стоит при создании новой ветки по невнимательности отнаследоваться от другой — и долгие часы разруливания конфликтов вам обеспечены.

То есть что бы ни происходило в нашей голове, мы должны сделать следующие шаги:

Переключаемся на основную ветку:

git checkout master

git pull -p

В общих чертах pull состоит из двух компонентов: команды fetch, которая подтягивает изменения с удаленного репозитория, и команды merge, которая совмещает эти изменения с вашей локальной веткой.

Параметр «-p» слабо документирован, однако очень приятен в работе. Формально он никак не относится к самой команде pull, потому вы вряд ли найдете упоминание о нем в ее описании. Однако он передается в fetch, что приводит к удалению всех локальных веток, которые ранее существовали, но были удалены из удаленного репозитория. По сути это избавляет вас от исторического мусора, который со временем начинает доставлять боль при выводе списка веток, не говоря уже о невозможности пользоваться атодополнением.

git checkout -b [название-ветки]

Давайте договоримся, что далее будем ее назвать, например «task-name»

Теперь можно работать в свое удовольствие, ну или ради чего вы там все это затеяли.

Интересное начинается позже. Пока мы пишем код, тем же занимаются и наши коллеги. Да, порой это трудно признать, но помимо вас тоже есть люди, которые работают. И в основную ветку начинают заливаться изменения, которые все далее и далее отдаляют ее от вашей. Простейший алгоритм слияния изменений, который используется гитом (включение или кода между соседними одинаковыми строками) уже не сработает — структура master изменилась. То есть если мы закончим нашу работу, тщательно протестируем все локально и начнем сливать все в master, то увидим кучу незнакомого кода, который, как кажется, специально написан в самых неподходящих местах, чтобы испортить нашу жизнь.

Как избежать этого? Если честно, то, к сожалению, практически никак. Рано или поздно нам придется исправлять возникающие конфликты. Вопрос — когда и сколько сразу. Здесь есть два подхода.

Если коротко, то первый состоит в том, чтобы сделать это в самом конце, когда будем сливать изменения в вышестоящую ветку (в нашем случае это ветка, соответствующая stage-сайту). У этого метода есть свои преимущества, но все равно будет много боли, причем сразу. При этом психологически будет сложнее, потому что в уме вы свою работу уже сделали и хочется поскорее про нее забыть, как про страшный сон.

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

На самом деле все достаточно просто. Rebase — это процесс подтягивания изменений с основной ветки (вообще, с любой, но мы сейчас не об этом) в вашу. Иначе говоря, каждый божий день, перед работой и перед отправкой изменений на удаленный репозиторий вы заливаете все последние изменения с той ветки, от которой отнаследовались при создании вашей (конечно же, от master) и исправляете небольшую порцию конфликтов, если они есть.

Далее мы предполагаем, что вы находитесь на своей feature-ветке.

Ребейз можно делать на локальную ветку и тогда это будет выглядеть так:

git rebase master

Но на самом деле это не сильно удобно, потому что локальная ветка имеет все шансы быть неактуальной (а регулярно переключаться на нее и делать git pull просто так на всякий случай — занятие, как бы это сказать, из области психиатрии). Поэтому мы сделаем иначе:

git pull -r origin master

То есть все примерно то же самое, но мы ребейзим не на локальный, а на удаленный, оригинальный master, как бы далеко он не ушел от локального.

В процессе ребейза все ваши коммиты последовательно сливаются в master.

При возникновении конфликтов, о чем git нам непременно сообщит кучей гневных сообщений, мы их правим (некоторые подробности чуть ниже по тексту), добавляем исправленные файлы:

git add -u

и продолжаем процесс ребейза:

git rebase --continue

Исправление текущего конфликта в редких случаях можно пропустить:

git rebase --skip

Или полностью откатить весь процесс:

git rebase --abort

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

Поэтому мы будем вынуждены отправить нашу измененную ветку насильно:

git push -f

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

git checkout -b task-name-backup

И не забудьте переключиться назад перед ребейзом и дальнейшей работой:

git checkout task-name

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

Но это чуть позже. Сейчас мы уверены, что все хорошо и можно отдавать работу на тестирование. Мы делаем мерж в ветку, на которой работает дев-сайт. Могу поспорить, что она так и называется — dev.

Ребейзим ветку на master (не обязательно, но не помешает, к тому же должно уменьшить расхождение между dev и master):

git pull -r origin master

Переключаемся на dev и актуализируем ее:

git checkout dev git pull

Внимание — короткая дорога:

git checkout -B dev origin/dev

Так мы одномоментно переключимся и сбросим ветку до состояния origin — меньше телодвижений всяко приятней.

git merge task-name

С большой степенью вероятности получаем конфликты, количество которых зависит от нашей кармы.

Смотрим список того, что конфликтует:

git status

Проводим некоторое время над разрешением конфликтов. Все конфликты git отмечает примерно следующим образом:

 ======= >>>>>>> task-name

Собственно, по этим многочисленным угловым скобкам и можно провести поиск в каждом конфликтующем файле.

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

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

Как и вслучае с ребейзом, процесс мержа можно откатить:

git merge --abort

Когда все конфликты разрешены, а соответствующее им обрамление удалено, делаем git add исправленных файлов. Впрочем, делаем в большинстве случаев добавление всех измененных файлов:

git add -u

Создаем коммит с указанием того, что решали конфликты слияния (далее дева этот коммит не пойдет и карму нам не испортит)

git commit -m "Task-name - fixing merge conflicts"

И заливаем все это на удаленный репозиторий.

git push

Далее специально обученные люди решают, насколько ваше творение соответствует общественным ожиданиям, однако рано или поздно будет принято решение мержить ветку в production.

И тут еще одна тонкость. Я бы сказал — жирность: dev и master сайты находятся в этой цепочке не последовательно, а параллельно. Иными словами, мы не переносим изменения из dev в master. Feature-ветка мержится в master напрямую. Во многом именно поэтому мы наследуемся именно от мастера и регулярно на этот мастер ребейзим.

Конечно, такой процесс неизбежно приведет к росту расхождений между рабочим и тестовым сайтом, но по мере необходимости последний можно актуализировать, попросту делая push —force мастера в дев.

Какие могут быть проблемы и как их избежать

Никак. Если проект большой, то так или иначе вы будете сталкиваться с необходимостью при решении конфликтов разбираться не только в своем, но и в чужом коде. И здесь важно не только обеспечить работоспособность своего функционала, но и не сломать чужой. Для этого нужно при необходимости тесно контактировать с другими разработчиками и никогда не действовать по принципу «что это тут за лишний код понапоявлялся. скопирую-ка я в этой файл содержимое своей ветки». Иначе отдельный котел вам будет обеспечен, и хорошо, если в иной жизни, а не в этой, причем вечером и в пятницу.

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

Ну и, безусловно, основная доля серьезных проблем возникает, если вы или кто-то из сотрудников нарушает основные правила работы с репозиторием — начинают ветку не от master или даже работают непосредственно в master.

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

Как вести разработку вдвоем с Github?

Требуется вдвоем работать над одним проектом. Мой партнер никогда не имел дело с git, а я никогда не имел дело с командной работой. Я уже создал репозиторий на github, нужно дать минимальные инструкции для работы вдвоем моему партнеру: простые, без всяких команд в консоли, а через клиент github for windows.
Мне нужно написать простую инструкцию. Скажите всё ли я правильно пишу и в чем я заблуждаюсь

Я создаю ветку в которой мой партнер будет разрабатыавать новую функцию. Эта ветка создана на основе ветки, в которой тружусь я.

Далее сама инструкция, которую нужен прокоментировать. Важна правильность последовательности действий.

устанавливаешь клиент, вводишь в нем свой логин
https://windows.github.com/

в программе clone
переключаешься на
пишешь код, делаешь коммит

потом жмешь кнопочку pullrequest. Делаешь запрос в из в

Далее я жму Confirm Merge на GitHub’е и в моем репозитории появляется новая функция, разработанная партнером.

Вопрос 2
Будут ли в репозитории партнера (копии) появляться коммиты, которые я делаю в своих ветках?
Вот например затем мне понадобится чтобы партнер начал разрабатыавть новую функцию. Я создаю ветку для этой функции на основе ветки, в которой я вел разработку во время того как партнер писал первую функцию. Появится ли эта ветка со всеми моими наработками у партнера?

Где вообще можно найти понятный алгоритм, желательно с видео как работать в гитхабе вдвоем. Важно чтобы было всё просто: без всяких команд в консоли и на windows

• Вопрос задан более трёх лет назад
• 26651 просмотр

4 комментария

Оценить 4 комментария

Интеграция с GitHub — Введение в Git

Сейчас у нас есть репозиторий с двумя коммитами. Содержимое директории hexlet-git выглядит так:

ls -a .git PEOPLE.md README.md 

Перед тем, как продолжить экспериментировать, добавим наш репозиторий на GitHub. В этом уроке мы познакомимся с этим сервисом и освоим самые базовые действия с ним.

Как добавить репозиторий

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

Добавим наш репозиторий на GitHub:

1. Зарегистрируйтесь на GitHub и создайте ssh-ключи по инструкции . SSH-ключи — это наиболее безопасный способ работы с GitHub, поэтому важно разобраться с ними
2. Создайте репозиторий на GitHub. Назовите его hexlet-git. Важно, чтобы репозиторий создавался пустым, поэтому не отмечайте галочки, добавляющие файлы
3. На странице репозитория вы увидите готовые команды для подключения созданного репозитория на GitHub к уже существующему репозиторию у вас на компьютере: Выполните эти шаги:

# Подробнее эти команды мы разберем позже git remote add origin git@github.com:/hexlet-git.git git branch -M main git push -u origin main 

После этой команды репозиторий, созданный на github.com, «соединяется» с локальным репозиторием hexlet-git. Здесь может возникнуть вопрос: «Почему соединяется? Разве это не один и тот же репозиторий?».

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

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

В примере выше именно команда git push отправляет изменения во вновь созданный репозиторий.

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

Теперь не важно, какие изменения делаются в локальном репозитории. На GitHub все коммиты попадут только после команды git push , поэтому не забывайте делать ее. Бывает такое, что разработчик случайно удаляет локальный репозиторий, забыв запушить изменения — применить команду git push .

Далее мы попробуем скачать репозиторий с GitHub так, как будто у нас нет локальной копии. Для этого удалите директорию проекта hexlet-git с вашего компьютера.

Как клонировать репозиторий

Репозитории на GitHub делятся на публичные и приватные. Публичный репозиторий любой человек может клонировать себе на компьютер. После клонирования он начнет работать с ним как с личным.

Единственное ограничение — он не сможет запушить изменения, так как GitHub не дает напрямую менять чужие репозитории.

Клонирование — базовая операция при работе с удаленными репозиториями. Проекты, над которыми работают программисты, всегда находятся в системах, подобных GitHub. Для работы с ними нужно клонировать репозиторий к себе на компьютер.

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

/hexlet-git.git cd hexlet-git ls -la # Если эта операция проходит первый раз, # То вы можете увидеть такое подобное сообщение The authenticity of host github.com cannot be established. RSA key fingerprint is SHA256: хххххххххх Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added github.com (RSA) to the list of known hosts. # Наберите yes и нажмите Enter 

Мы получили точную копию репозитория, который был у нас до удаления директории hexlet-git.

Как получить изменения с GitHub

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

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

Считается, что достаточно вызывать git pull , но это может приводить к созданию ненужных коммитов, из-за которых становится сложнее следить за историей изменений.

Правильная работа с git pull требует знания таких вещей, как ветвление и git rebase . Они довольно сложны для новичков, поэтому мы рассмотрим их позже, когда появится хоть какой-то опыт работы с Git.

Выводы

Подведем некоторый итог. В этом уроке мы создали репозиторий с несколькими коммитами и добавили его на GitHub. Теперь его можно склонировать для дальнейшей разработки.

Какую пользу из Git мы можем извлечь к текущему моменту? У нас есть запасная копия кода на сайте GitHub. Как минимум, нам нестрашно потерять код. Теперь его легко восстановить при случае, а еще им можно поделиться с другими.

Отдельно стоит сказать, что GitHub — это хоть и самая популярная, но не единственная площадка для хостинга репозиториев. Кроме него, особенно известны Bitbucket и GitLab. Последний можно даже поставить к себе на сервер и хостить репозитории внутри своей компании, что многие и делают по соображениям безопасности или экономии.

Самостоятельная работа

1. Выполните все шаги из урока, создайте и добавьте ssh-ключи на GitHub по инструкции
2. Добавьте новый файл NEW.md с произвольным содержимым в репозиторий. Для этого нужно выполнить коммит
3. Залейте изменения на GitHub с помощью git push
4. Обновите страницу репозитория на GitHub. Там должен появиться последний коммит — те изменения, которые были совершены

Дополнительные материалы

1. Цикл git-разработки (init, commit, push on GitHub)
2. GitHub — Настройка и конфигурация учетной записи
3. Создание SSH-ключа для работы с GitHub по SSH

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты

Об обучении на Хекслете

• Статья «Как учиться и справляться с негативными мыслями»
• Статья «Ловушки обучения»
• Статья «Сложные простые задачи по программированию»
• Вебинар « Как самостоятельно учиться »

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях: