Все, что вы должны знать до этого:
https://www.learnenough.com/git-tutorial
https://www.atlassian.com/git/tutorials/comparing-workflows
- Это типа промышленный стандарт. Найти разработчика, который работал с системами контроля версий, но никогда не трогал Git, довольно непросто.
- Git придумали для решения проблем распределенных разработчиков.
- Его писали компьютерные ботаники, поэтому он содержит более 70 команд и все они разные, причем если одна часть зашита в главный бинарник, то другая - размазана по Perl-скриптам.
- По-умолчанию Git будет пытаться сжать и сохранить все версии больших бинарных файлов, что в большинстве случаев является неоптимальным подходом.
- Для многих самая сложная операция: rebase локального бранча перед ревью.
- Нельзя взять и в одном репозитории раздать разных прав разработчикам.
Обозреть возможные workflow - https://www.atlassian.com/git/tutorials/comparing-workflows
https://gist.github.com/leesmith/8441773
-
Во многих компаниях средней руки официальный главный бранч на сервере представляет собой помойку. Целиком его никто не собирает и не проверяет, он просто лежит, а у всех свои собственные бранчи, где они ковыряют ошибки и фичи. Потом приходят специально обученные люди и делают из этого релиз, пинают тех, кто накоммитил, заставляют фиксить баги и не разрешают в этот код добавлять новые фичи. Этот процесс называется Интеграция. Потом, когда будущий релиз начинает собираться, все это уходит тестерам и они проверяют функционал по спискам требований и написанным тестам, по результатам заводятся баги, и дальше это релизится с определенной периодичностью с репортами о новых/старых/исправленных багах. Само собой, никакими пулл-реквестами здесь не пахнет.
-
Один из несложных примеров организации совместной работы над сайтом с PR. Модель разработки состоит в том, что разработчикам поручаются куски работы, разбитые на самодостаточные стадии, по мере выполнения они пушат незавершенную работу на ревью, а по окончании работы делают PR уже чистого кода.
-
Не совсем относится к Git, но не смог пройти мимо интересного подхода:
В Питере была компания. Называлась Беркут. Сейчас вроде развалилась, но не уверен. Там вроде надо было так что тебе ставили задачи которые гранулированы по пол дня. Ну то есть если задача больше чем на пол дня её надо было бить. Тоже работал при подходе, когда перед тем как взять фичу - надо было провести декомпозицию до тасок не более 8ч. Ну вот провёл ты эту декомпозицию, а времени на так все равно больше вышло. Что тогда? > Декомпозировать дальше
https://www.atlassian.com/git/tutorials/git-lfs
https://mirrors.edge.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html https://habr.com/post/75964/ https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/?_ga=1.256555208.213145851.1487618490
https://dzone.com/articles/how-to-handle-big-repositories-with-git https://samthursfield.wordpress.com/2016/03/16/enourmous-git-repositories/
-
индекс,staging area- область помеченных для следующего коммита файлов. Нужен, чтобы не регистрировать абсолютно все изменения в каталоге проекта. -
origin- название первого дистанционного репозитория, откуда мы клонировали изначально проект черезgit clone. Дословно переводим как источник. -
master- метка (tag), которая ссылается на последний коммит в главной ветке. -
HEAD- алиас на нашу текущую ветку (например, вместо того, чтобы писатьmasterв командной строке илиver0.0.1, указываем простоHEAD). Обычно это вершина ветки, в противном случае в сообщених об ошибке будет встречаться выражение "detached HEAD".
-
git add <файл>- добавить изменения из файла в индекс (либо добавить файл под контроль системы управления версий целиком, если его не было до этого момента). Вместо<файл>можно использовать точку, тогда добавляется содержимое текущего каталога целиком (вместе с подкаталогами). -
git add -u- добавить все изменения в индекс только по файлам, уже находящимся под контролем git -
git commit -a- создать новый коммит из текущего индекса. Ключ-aнеявно перед этой операцией выполняетgit add -u -
git diff --cached- что мы будем коммитить -
git reset- обратная операция дляgit add
-
git branch- список веток в локальном репозитории. Напротив активной будет стоять звездочка -
git branch -a- дополнительно к предыдущей команде вывести также ветки в дистанционных репозиториях -
git merge <ветка>- слить вместе две разные ветки (причем остается только та, которая на момент выполнения команды была активной. -
git rebase <ветка>- воспроизвести все изменения (например, на тестовой ветке), которые произошли на главной (две ветки продолжат жить собственной жизнью).
