Я пока использовал Git только, когда один работал над проектом. Там всё просто: git init, add, commit, push.
Но я не понимаю, как осуществляется совместная работа над проектом в Git? Кто-нибудь может объяснить на пальцах?
Допустим, подключается новый разработчик. Он делает clone проекта и получает всю копию. Потом что делает? Создает свою личную ветку, в ней работает и пушит на сервер? Или как?
Как он узнает, приняли ли его изменения? Как он узнает про изменения, сделанные другими разработчиками?
Ничего не понимаю, какая-то каша в голове.
Re: Кто может объяснить, как осуществляется совместная работа в Git?
Здравствуйте, danilla, Вы писали:
D>Допустим, подключается новый разработчик. Он делает clone проекта и получает всю копию. Потом что делает? Создает свою личную ветку, в ней работает и пушит на сервер? Или как? D>Как он узнает, приняли ли его изменения? Как он узнает про изменения, сделанные другими разработчиками? D>Ничего не понимаю, какая-то каша в голове.
На пальцах — нет ниакого сервера и веток. Есть у тебя проект, есть у друга на расшаренной папке. Сделав один или несколько коммитов, ты можешь сделать push другу, "добавив" свои коммиты после его. После этого, они появятся в его истории. Аналогично, друг может сделать pull с твоей папки, если имеет к ней доступ.
Если коммиты пересекаются (скажем, отредактировали один и тот же файл), то сделать push не получится — надо делать сначала pull (стянуть коммиты друга себе), потом merge (привести пересекающиеся файлы к рабочему виду). После этого можно делать push, т.к. считается, что в процессе merge все косяки были устранены.
Чтобы не заморачиваться с расшариванием папок друг другу, де-факто используют сервера (хоть shared folders, хоть HTTP, хоть SSH) — технической разницы с предыдущим вариантом нет. Есть организационная — не надо бегать друг за другом в поисках последней версии, ее договорились хранить на сервере. Ну, еще можно права настроить.
В процессе merge может оказаться, что ваши дорожки с другом сильно разошлись, и вы наделали несовместимых изменений. Тут в игру вступают ветки — ты можешь создать ветку test и сделать в нее pull версии друга. Это загрузит его историю изменений, не трогая реальные файлы исходников. Дальше, ты можешь сделать checkout этой ветки, что приведет твои физические исходники в соответствие с его версией (причем, у совпадающих файлов не поменяется timestamp, что ускорит последующую сборку). Вдоволь наигравшись с его версией, ты можешь добавить в нее пару коммитов для своих собственных тестов (да хоть с комментариями, как правильно мерджить) и снова зачекаутить свою версию. Опять же, совпадающие файлы останутся как есть, различающиеся обновят timestamp.
Если вы с другом были няшками и разбивали работу на множество независимых коммитов, то может оказаться, что весь сыр-бор возник где-то в середине (вы сделали коммиты A1->A2->A3, друг — B1->B2->B2 и конфликтуют A2 и B2). Тогда можно будет зачекаутить коммит A2 в отдельную ветку, смерджить туда B2 (отредактировав вручную), а потом накатить неконфликтующие изменения A3 и B3. В любом случае, ветка — это просто отдельная версия проекта, которю можно в любой момент выгрузить в реальный мир, сделав checkout. Используется для удобства, если надо переключаться между несколькими версиями.
Еще бывает, что пока вы с другом работаете над новой версией, пользователи хотят мелкие багфиксы. Тогда кроме веток у вас с другом, можно держать 2 ветки на сервере — experimental и stable. Push и pull (см. выше) всегда делаются применительно к конкретной ветке. И ты сможешь отложить работу над новой фичей, закоммитить ее в experimental у себя, выгрузить stable с сервера в свой stable, закоммитить туда багфикс, pushнуть это обратно на сервер, и вернуться в свой experimental. И это все без изменений timestamp-ов файлов, которые совпадают во всех вариантах. Более того, если юзер захочет багфикс, который был недавно добавлен в experimental, можно будет выгрузить stable, сделать туда cherry-pick конкретного коммита (это как одной командой сделать diff изменений в experimental, и patch прямо в stable), и запушить все обратно на сервер.
Ну и если вы с другом умудренные опытом и ленивые, то у вас рано или поздно появится билд-сервер, который будет автоматом выгружать stable, собирать инсталлятор, и выкладывать его благодарным юзерам, пока вы с другом продолжаете работать над experimental.
Как-то так.
Re: Кто может объяснить, как осуществляется совместная работа в Git?
Здравствуйте, danilla, Вы писали:
D>Я пока использовал Git только, когда один работал над проектом. Там всё просто: git init, add, commit, push. D>Но я не понимаю, как осуществляется совместная работа над проектом в Git? Кто-нибудь может объяснить на пальцах?
D>Допустим, подключается новый разработчик. Он делает clone проекта и получает всю копию. Потом что делает? Создает свою личную ветку, в ней работает и пушит на сервер? Или как? D>Как он узнает, приняли ли его изменения? Как он узнает про изменения, сделанные другими разработчиками? D>Ничего не понимаю, какая-то каша в голове.
Ну, вообще есть много вариантов работы...
Можно рассмотреть простейший случай, когда все работают в отдной ветке (почти как в старых cvs и svn). Пусть эта ветка называется "master" (так основная ветка обычно и называется)
Ты, новый разработчик, делаешь копию репозитория:
git clone
По умолчанию у тебя будет как раз установлена ветка master, поэтому следющая комманда не нужна, но так вообще она переключит тебя на нужную ветку:
git checkout master
Потом так же, поработал и:
git add
git commit
И точно так же пушишь изменения на сервер:
git push
Но, что если кто-то другой уже не сервере что-то поменял? В этом случае push не сработает и вернет ошибку! Поэтому перед тем, как сделать push нудно забрать с сервера последние изменения и слить их с твоими, это может сделать комманда:
git pull
Если твои и чужие изменения находятся в разных частях кода, по они автоматом сольются, но если вы меняли одно и то же место, то будет конфликт изменений.
Если конфликтов не было, то можно спокойно пушить:
git push
А вот если конфликт был, то будет веселее, тебе надо в ручную подправить файлы, в которых они были и снова:
git add
git commit
git push
Ну и еще есть очень полезные комманды:
git status
git diff
Это один из вариантов работы, все можно сделать и подругому. Когда его поймешь, можешь читать про ветки и другие фичи.
Re: Кто может объяснить, как осуществляется совместная работа в Git?
D>Допустим, подключается новый разработчик. Он делает clone проекта и получает всю копию. Потом что делает? Создает свою личную ветку, в ней работает и пушит на сервер? Или как?
рекомендую в ютубе поискать про гит. до черта даже на русском, где просто на пальцах рассказывают с картинками. на хабре куча статей.
даже в больших проектах не требовалась вся мощь гита. и в 99% случаев все сводилось к тому, как ты работал в одиночку. еще не забывай, что никто не заставляет собственно через консоль с ним работать. оболочек для него достаточно много.
Re: Кто может объяснить, как осуществляется совместная работ
Вариантов много. Лично мне нравится следующий процесс.
Имеется ровно одна основная ветка — main. В ней периодически делаются теги с версиями, деплой на прод идёт по тегам. Деплой на тест идёт самую ветку.
Простые изменения коммитятся сразу в main. В основном какие-то фиксы или опечатки и тд.
Для всего нетривиального создаётся отдельная ветка, в которой ведётся разработка. Как только готов результат — производится rebase ветки на main, при необходимости подчищаются мусорные коммиты и тд, в общем история приводится в порядок и делается pull request. Кто-то его просматривает, одобряет и main через fast forward перематывается на эту ветку, ветка удаляется. Ну или дорабатывается, если не одобряют. В принципе всё, весь workflow. В main получается красивая линейная история.
D>Как он узнает, приняли ли его изменения? Как он узнает про изменения, сделанные другими разработчиками?
В git как таковом вообще говоря нет понятия pull request (или merge request ещё называют). Но этот функционал есть и в github и в gitlab и, наверное, во всех остальных популярных серверных системах. В основном именно через них осуществляется коммуникация разработчиков. Эстеты могут генерировать patch-файлы и отправлять их по почте.
Здравствуйте, danilla, Вы писали:
D>Я пока использовал Git только, когда один работал над проектом. Там всё просто: git init, add, commit, push. D>Но я не понимаю, как осуществляется совместная работа над проектом в Git? Кто-нибудь может объяснить на пальцах?
D>Допустим, подключается новый разработчик. Он делает clone проекта и получает всю копию. Потом что делает? Создает свою личную ветку, в ней работает и пушит на сервер? Или как? D>Как он узнает, приняли ли его изменения? Как он узнает про изменения, сделанные другими разработчиками? D>Ничего не понимаю, какая-то каша в голове.
В самом гит специальных правил "принятие", "пул реквесты", "личные ветки" и т.п. отсутствуют.
То есть, теоретически он может тупо так же как и ты писать прямо в main, периодически синхронизируясь с сервером (pull/push).
Правила придумывают сверху, по вкусу. Например gitflow, github flow (набор правил как работать).
Re: Кто может объяснить, как осуществляется совместная работ
git — это только контроль версий — самый нижний уровень. За ревью пулл-реквестов отвечает отдельный софт из набора CI/CD типа Atlassian bitbucket или Gerrit, который использует git как бекенд.
Конкретная стратегия бранчинга зависит от конкретной политики команды.
Самый простой воркфлоу (для битбакета) такой (без всяких девелопмент веток, варианты конфликтов опущены, но это не меняет основную идею):
git checkout master
git pull
git checkout -b feature/abc
git add ...
# прошло N дней...
git commit -a -m "My new cool abc feature"
git pull --rebase origin master
# тут разрешаем конфликты, если они есть
git push origin feature/abc
далее происходит ревью пулл-реквеста.
Главное здесь — разраб никогда не пушит прямо в мастер, т.к. мастер — это релизная ветка, в которую может пушить либо CI/CD, либо главный разраб по результатам ревью.
Разраб получает нотификации по емейлу о прогрессе ревью своего пулл-реквеста.
Если CI/CD нет, то пулл-реквест это просто запрос разраба тому, кто отвечает за master ветку.
Разраб может написать мейл или позвонить синьеру и/или всем заинтересованным, типа:
привет, чуваки. Вот тут у меня фича бранч, уже в origin репозитории, я его типа локально протестировал, все юнит-тесты ОК.
Посмотрите пжалста.
Когда код одобрен И слит в master, если используется review/CI/CD софт, разраб получает уведомление о слитии в целевую ветку пулл-реквеста.
Если review/CI/CD не используется, ответственный за master ветку может послать разрабу емейл, типа:
ОК, чувак, код ОК. Мерджим.
Если где-то конфликты, они разрешаются разрабом.
Если код структурирован и один только разраб работает над фичей, конфликтов может и не быть.
Но допустим, несколько разрабов работают над одним и тем же файлом.
Тогда перед пушем на сервак (git push origin feature/abc) им лучше сначала получить все коммиты из мастера или из той фича-ветки, которая может потенциальмо иметь изменения, актуальные для фичи abc:
git pull --rebase origin master
(изменения из уже принятых в master фич будут скачаны в локальный мастер, и изменения, добавленные разрабом (git add ...) будут помещены в самый конец истории коммитов ветки feature/abc)
или, если известно, что кто-то другой уже работает или потенциально может работать над фичей abc:
git pull --rebase origin feature/abc
Уже на этом этапе, если изменения в одних и тех же файлах, и git не знает, как их объединить, файлы будут помечены гитом как конфликтные.
После разрешения конфликтов (локально), можно пушить свои изменения в origin feature/abc и далее по списку.
Но при такой стратегии (с --rebase) меняется история коммитов в feature/abc, и это должны понимать данный разраб и другой разраб, работающий над abc (и соотв. пушить надо с флагом -f).
Возможен и вариант без --rebase (git pull origin feature/abc), но он может привести к захламленности ветки коммитами.
Преимущество pull --rebase и rebase в том, что можно как угодно менять историю коммитов в feature/abc, добавленную после пулла с master и соотв. агрегируя все актуальные изменения вплоть до пуша в мастер.
Например, можно коммитить свои изменения по частям, а потом, перед синхронизацией со вторым разрабом объединять свои изменения в один коммит.
Можно менять последний коммит второго разраба, добавляя свои изменения.
Главное — договориться со вторым разрабом, как вы будете работать, и это уже может быть за рамками "генеральной линии Партии".
И главное не менять ничего в истории master ветки до работы над feature/abc.
