предисловие

Недавно я хотел загрузить код на GitHub, в результате все npm демо, которые я нашел, были установлены локально, и если я выложу их на GitHub, они были бы мертвы, это было несколько сотен M, а затем я искал почему я не загрузил.node_modulesСпустя долгое время у меня ничего не получилось, так что я собираюсь успокоиться и изучать git, а также использовать его как заметку для чтения в будущем.
До исследований у меня было всего 5 команд

$ git init 
$ git add .
$ git commit -m "提交的xxxxx"
$ git pull
$ git push

что такое гит

Git — это распределенная система управления версиями с открытым исходным кодом, позволяющая гибко и эффективно управлять любым проектом, небольшим или большим. Git — это программное обеспечение для управления версиями с открытым исходным кодом, разработанное Линусом Торвальдсом для помощи в управлении разработкой ядра Linux. Git отличается от широко используемых инструментов управления версиями CVS, Subversion и т. д. Он использует метод распределенной библиотеки версий без поддержки программного обеспечения на стороне сервера.

Git рабочий процесс

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

Базовые концепты

локальный репозиторий (репозиторий)

Репозиторий: в рабочей области есть скрытый каталог .git, который является не рабочей областью, а репозиторием Git.

Что такое локальный репозиторий (репозиторий)

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

кеш хранения

Зона временного хранения: по-английски называется stage, или index. Обычно он хранится в индексном файле (.git/index) в «каталоге .git», поэтому иногда мы называем промежуточную область индексом.

Рабочее пространство

Рабочая область: это каталог, который вы видите на своем компьютере.

Основное использование Git

Не буду вдаваться в подробности, думаю все, просто пикантная картинка выше и несколько команд на картинке

$ git init，              //初始化本地仓库 .git
$ git status -sb，        //显示当前所有文件的状态
$ git diff                //查看更改，查看difference，显示的格式正是Unix通用的diff格式,
$ git add 文件路径        //用来将变动加到暂存区
$ git commit -m "信息"    //用来正式提交变动，提交至 .git 仓库如果有新的变动，我们只需要依次执行 git add xxx 和 git commit -m 'xxx' 两个命令即可
$ git log                 //查看变更历史

откат версии

Когда я отправляю несколько коммитов, скажем, у нас теперь есть 3 версии (1, 2, 3), теперь это версия 3, я обнаружил, что коммит только что был неправильным, и я хочу вернуться к версии 2.

$ git reset --hard               //重置暂存区与工作区，与上一次commit保持一致

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

$ git reset --hard [commitid]     //重置当前分支的HEAD为指定commit，同时重置暂存区和工作区，与指定commit一致
//commitid 使用git log --stat查看

Параллельный мир Б
В обычном мире B вы просто откатили версию до версии 2 и легли спать, на следующий день вы обнаружили, что версия 3 была правильной, но с помощьюgit logне вижуcommitУ меня есть информация, что мне делать?

$ git reflog                      //用来记录你的每一次命令,显示当前分支的最近几次提交

Сценарий 1. Если вы испортили содержимое файла в рабочей области и хотите напрямую отменить изменения в рабочей области, используйте команду
$ git checkout -- file

Сценарий 2: Когда вы не только испортили содержимое файла в рабочей области, но и добавили его в область временного хранения, вы хотите отменить модификацию, в два шага, первый шаг — использовать команду
$ git reset HEAD file
, он возвращается к сцене 1, и второй шаг заключается в работе в соответствии со сценой 1.

Сценарий 3. Если в репозиторий были отправлены недопустимые изменения, и вы хотите отозвать эту отправку,git reset --hard, но предполагается, что он не переносится на удаленный склад.

Удалить файлы

$ git rm [file1] [file2] ...      //删除工作区文件，并且将这次删除放入暂存区

Другой случай, что он удален по ошибке, потому что в репозитории он еще есть, поэтому вы можете легко восстановить ошибочно удаленный файл до последней версии:

$ git checkout -- test.txt

филиал

Какая польза от веток на практике? Предположим, вы собираетесь разработать новую функцию, но на ее завершение уходит две недели.Вы написали 50% кода за первую неделю.Если вы отправите его сразу, неполная кодовая база приведет к тому, что другие не смогут работать, потому что код еще не написан. Если вы дождетесь, пока код будет полностью написан, а затем отправите его снова, существует огромный риск потери вашего ежедневного прогресса.
Теперь, когда у вас есть ветки, вам не нужно бояться. Вы создали ветку, которая принадлежит вам, другие не могут ее видеть, и вы продолжаете нормально работать в исходной ветке, в то время как вы работаете над своей собственной веткой, отправьте ее, если хотите, пока разработка не будет завершена, а затем слейте его с исходной веткой, таким образом, это будет безопасно и не повлияет на работу других.
Как вы уже знаете, для каждого коммита Git связывает их во временную шкалу, и эта временная шкала является ветвью. На данный момент существует только одна временная шкала, в Git эта ветка называется master веткой, то есть master веткой. Строго говоря, HEAD указывает не на коммит, а на мастер, а мастер указывает на коммит, поэтому HEAD указывает на текущую ветку.

Когда мы создаем новую ветку, такую как dev, Git создает новый указатель с именем dev, который указывает на тот же коммит, что и master, а затем указывает HEAD на dev, указывая, что текущая ветка находится на dev:
Видите ли, Git создает ветку очень быстро, потому что, кроме добавления указателя dev и изменения указателя HEAD, файлы в рабочей области не изменились!

Однако отныне модификации и отправки в рабочую область относятся к ветке dev.Например, после новой отправки указатель dev перемещается на один шаг вперед, а указатель master остается неизменным:

3. Если наша работа над dev завершена, мы можем объединить dev в master. Как Git объединяется? Самый простой способ — указать master прямо на текущий коммит dev, и слияние будет завершено:

4. Вы даже можете удалить ветку dev после слияния ветки. Удаление ветки dev означает удаление указателя dev.После удаления у нас остается ветка master:

Как использовать ветки

$ git checkout -b [branch]                //新建一个分支，并切换到该分支
$ git branch                              //命令会列出所有分支，当前分支前面会标一个*号。
$ git add . 
$ git commit -m "提交分支branch"
$ git checkout master                     //切换回master分支
$ git merge [branch]                      //把branch分支合并到master分支
$ git branch -d branch                     //合并完成后删除branch分支

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>

创建+切换分支：git checkout -b <name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>

конфликт ветвей

Например, наш файл теперь выглядит так

fuck 'webpack'                      //master分支

Создаем и переключаемся на ветку посылок

$ git checkout -b parcel

Изменить текстовое содержимое

~~fuck 'webpack~~ ---> parcel no.1
Отправить в тестовую зону

$ git add .
$ git commit "嘻嘻"                      //parcel分支

переключиться обратно на основную ветку

$ git checkout master

Изменить текстовое содержимое

~~fuck 'webpack'~~ --> fuck fuck 'webpack'
Отправить в тестовую зону

$ git add .
$ git commit "哈哈"                      //maser分支

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

$ git merge parcel                      //把parcel分支合并到当前master分支

Тогда будет конфликт

$ git status                        //可以告诉我们冲突的文件：
# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
#
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       both modified:     fuck.txt
#

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

~~fuck fuck 'webpack'~~ --> parcel no.1
представить снова

$ git add .
$ git commit "扑扑"                      //maser分支

Наконец, удалите ветку посылки

 git branch -d parcel

Стратегия управления филиалом

Обычно при слиянии веток Git по возможности использует режим Fast forward (режим по умолчанию), но в этом режиме при удалении ветки информация о ветке теряется.

Если вы хотите принудительно отключить режим быстрой перемотки вперед, Git создаст новую фиксацию при слиянии ветки, чтобы информацию о ветке можно было увидеть из истории ветки.

в виде

$ git checkout -b dev                                 //首先，仍然创建并切换dev分支：
$ git add readme.txt                                  //修改readme.txt文件，并提交一个新的commit
$ git checkout master                                 //现在，我们切换回master分支
$ git merge --no-ff -m "merge with no-ff" dev         //准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward
$ git log --graph --pretty=oneline --abbrev-commit    //合并后，我们用git log看看分支历史：
//合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

Управление филиалом команды

В реальной разработке мы должны следовать нескольким основным принципам управления ветками:

Во-первых, ветка master должна быть очень стабильной, то есть используется только для выпуска новых версий, и обычно не может на ней работать;

Где ты работаешь? Вся работа выполняется на ветке dev, то есть ветка dev нестабильна, в какой-то момент, например, когда выходит версия 1.0, ветка dev объединяется с master, а версия 1.0 выпускается на основная ветка;

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

Итак, ветка командной работы выглядит так:

Ветка команды действительно должна быть такой

|- master                       //正式版
  |- dev                        //测试版
    |- michael                  //队员michael-adc
    |- bob                      //队员bob-肉
    |- bibi                     //队员bibi-大腿

ветвь ошибки

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

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

------------                                              //我们在dev分支上，发现master分支上有代号101号bug
$ git stash                                               //冷冻现在在dev分支上的工作状态 冻结吧！  
$ git checkout master                                     //这个bug发生在master主分支上,我们切回master分支
$ git checkout -b issue-101                               //创建代号101的修复bug分支
修改你的bug
$ git add readme.txt                                      //提交到暂存区
$ git commit -m "fix bug 101"                             //注意填写信息，以免日后查证
$ git checkout master                                     //切换回master分支
$ git merge --no-ff -m "merged bug fix 101" issue-101     //合并分支，注意不使用fast forward模式
$ git branch -d issue-101                                 //删除issue-101分支
$ git checkout dev                                        //bug 改完了，是时候回到dev继续写bug了
$ git stash list                                          //查看刚刚的冻结现场
$ git stash pop                                           //git stash pop，恢复的同时把stash内容也删了：
//一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除

Разработать новую тестовую функцию

Для разработки новой функции лучше всего создать новую ветку;

Если вы хотите отказаться от ветки, которая не была объединена, вы можете передатьgit branch -D <name>Принудительно удалить.

совместная работа нескольких человек

Когда вы клонируете от удаленного хранилища, Git на самом деле автоматически отображает локальную ветку Master к удаленной ветви для удаленного ветви, а имя по умолчанию удаленного репозитория является началом. Для просмотра информации о удаленной библиотеке, используйтеgit remote -v

толкать ветку

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

$ git push origin master

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

$ git push origin dev

Однако не обязательно пушить локальную ветку на удалённую, так какие ветки нужно пушить, а какие нет?

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

多人协作时，大家都会往master和dev分支上推送各自的修改。  
当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。  
现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：
$ git checkout -b dev origin/dev
你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送
推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：
$ git branch --set-upstream dev origin/dev
再pull
这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：

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

Во-первых, попробуйте использоватьgit push origin branch-nameпродвигать собственные изменения;

Если отправка не удалась из-за того, что удаленная ветка новее вашей локальной, вам нужно использоватьgit pullпопытка слияния;

Если слияние существует конфликт, разрешение конфликта и совершать локально;

Если конфликта нет или конфликт разрешен, используйтеgit push origin branch-nameТолчок будет успешным!

еслиgit pullЕсли запрашивается «информация об отслеживании отсутствует», это означает, что отношение связи между локальной и удаленной ветвями не было создано.Используйте команду
git branch --set-upstream branch-name origin/branch-name

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

Чтобы просмотреть информацию об удаленной библиотеке, используйтеgit remote -v

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

Чтобы нажать ветку из локального, используйтеgit push origin branch-name, если отправка не удалась, сначала используйте git pull, чтобы получить новую удаленную фиксацию;

Создайте локальную ветку, соответствующую удаленной ветке, используйтеgit checkout -b branch-name origin/branch-name, желательно, чтобы имена локальной и удаленной ветвей были одинаковыми;

Чтобы установить связь между локальной ветвью и удаленной ветвью, используйтеgit branch --set-upstream branch-name origin/branch-name;

Чтобы захватить ветку с пульта, используйтеgit pull, если есть конфликт, сначала разрешите конфликт.

Управление тегами

Создать ярлыки

Заказgit tag <name>Используется для создания новой метки, по умолчанию используется HEAD, или можно указать идентификатор фиксации;
git tag -a <tagname> -m "blablabla..."Информация на этикетке может быть указана;
git tag -s <tagname> -m "blablabla..."Этикетки можно подписывать с помощью PGP;
Заказgit tagВсе теги можно просмотреть.
Вы также можете создавать метки с описаниями, используя -a для указания имени метки и -m для указания текста описания:

$ git tag -a v0.1 -m "version 0.1 released" 3628164

Вкладка «Действие»

Если метка опечатка, ее тоже можно удалить:

$ git tag -d v0.1

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

$ git push origin <tagname>

Или, чтобы сразу отправить все локальные теги, которые еще не были отправлены на удаленный:

$ git push origin --tags

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

$ git tag -d v0.9

Затем удалите с удаленного. Команда удаления тоже push, но формат такой:

git push origin :refs/tags/<tagname>

игнорировать специальные файлы

Создайте специальный файл .gitignore в корневом каталоге рабочей области Git, затем заполните имена файлов, которые нужно игнорировать, и Git автоматически проигнорирует эти файлы. Нет необходимости писать файл .gitignore с нуля, GitHub подготовил для нас различные файлы конфигурации, просто нужно их объединить и использовать. Все файлы конфигурации можно просмотреть прямо в режиме онлайн:.gitignore

утверждение

Эта статья в основном относится к учебнику git от г-на Ляо Сюэфэна, добавляя немного моего личного понимания, а также изображения и т. д.
Если вы хотите узнать больше о git, вы можете проверить следующие ссылки

Список часто используемых команд git — Жуан Ифэн
Прочитать разницу - Жуан Ифэн
Учебник по git — Ляо Сюэфэн
git tutorial — учебник для новичков
gitbook
Git Community Book