Оригинальная статья, краткое изложение опыта и жизненные перипетии на всем пути от набора в школу до фабрики А

Нажмите, чтобы узнать подробностиwww.codercc.com

1. Введение в git

В реальной разработке git используется как инструмент контроля версий для совместной работы команды. Поэтому очень необходимо обобщить основные инструкции по работе с git.В этой статье некоторые термины или теоретические основы не перекодированы.Обратитесь к сообщению в блоге учителя Ляо Сюэфэн., эта статья только суммирует команды.

Общий процесс работы git выглядит следующим образом (из сети)

В основном это включает в себя четыре ключевых момента:

1. Рабочая область: место, где на локальном компьютере хранятся файлы проекта, например папка LearnGitProject;
2. Промежуточная область (индекс/стадия): при использовании git для управления файлами проекта папка .git будет добавлена ​​к локальному файлу проекта, и эта папка .git называется репозиторием. Папка .git состоит из двух частей, одна из которых представляет собой промежуточную область (Index или Stage), в которой, как следует из названия, временно хранятся файлы.Обычно команда add используется для добавления файлов рабочей области в промежуточную площадь;
3. Локальный склад: папка .git также включает ветку master, автоматически созданную git, и указывает указатель HEAD на ветку master. Используйте команду фиксации, чтобы добавить файлы из промежуточной области в локальный репозиторий;
4. Удаленный склад: не на локальном складе, код проекта находится на удаленном сервере git, например, проект на github, это удаленный склад, обычно используйте команду клонирования, чтобы скопировать удаленный склад на локальный склад и отправить его на удаленный склад после разработки.

Подробнее:

Во время ежедневной разработки код фактически помещается в рабочую область, то есть в локальные файлы XXX.java.Культура кода и образование передаются в область временного хранения (Index/Stage) с помощью таких команд, как add, что означает, что код полностью передается git, который управляет им, а затем отправляет промежуточную область в основную ветку с помощью таких команд, как commit, что означает создание версии или отправку кода на локальное хранилище. Кроме того, процесс командной совместной работы естественным образом предполагает взаимодействие с удаленными репозиториями.

Поэтому после такого анализа git-команды можно разделить на такую ​​логику для понимания и памяти:

1. команда настройки управления git;

   Несколько интерактивных команд основного хранилища:

2. Взаимодействие между рабочей областью и областью подготовки;

3. Взаимодействие между зоной подготовки и локальным складом (филиалом);

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

2. команда настройки git

Информация о конфигурации запроса

1. Список текущей конфигурации:git config --list;
2. Список конфигураций репозитория:git config --local --list;
3. Список глобальной конфигурации:git config --global --list;
4. Список конфигураций системы:git config --system --list;

Используя git в первый раз, настройте информацию о пользователе

1. Настроить имя пользователя:git config --global user.name "your name";
2. Чтобы настроить почтовые ящики пользователей:git config --global user.email "youremail@github.com";

Другая конфигурация

1. Настройте, какой инструмент анализа различий использовать при разрешении конфликтов, например vimdiff:git config --global merge.tool vimdiff;
2. Настройте цвет вывода команды git:git config --global color.ui auto;
3. Настройте текстовый редактор, используемый git:git config --global core.editor vi;

3. Операционные команды в рабочей области

Новый склад

1. Управляйте файлами проекта в рабочей области с помощью git, то есть создайте новое локальное хранилище:git init;
2. Скопируйте проект из удаленного репозитория git:git clone <url>, например: git clone git://github.com/wasd/example.git; Если вы хотите определить новое имя проекта при клонировании проекта, вы можете указать новое имя проекта после команды clone:git clone git://github.com/wasd/example.git mygit;

Отправить

1. Отправьте все файлы в рабочей области в промежуточную область:git add .
2. Отправьте указанный файл в рабочей области в промежуточную область:git add <file1> <file2> ...;
3. Зафиксируйте все файлы в папке в рабочей области в промежуточной области:git add [dir];

отозвать

1. Удалите файл рабочей области, а также удалите соответствующую запись файла из промежуточной области:git rm <file1> <file2>;
2. Удалите файл из промежуточной области, но сохраните файл в рабочей области:git rm --cached <file>;
3. Отмените файлы, которые были помещены в промежуточную область:git reset HEAD <file>...;
4. Отменить последнюю операцию над файлом:git checkout --<file>. Чтобы убедиться, что последняя модификация файла больше не нужна, если вы хотите сохранить последнюю модификацию для будущей работы, вы можете использовать скрытие и ветвление;
5. Скрыть текущие изменения, чтобы иметь возможность переключать ветки:git stash;
6. Посмотреть весь текущий тайник:git stash list;
7. Примените последний тайник:git stash apply, если вы хотите применить более ранний тайник:git stash apply stash@{2}; чтобы повторно применить поэтапные изменения, добавьте--indexпараметр:git stash apply --index;
8. С помощью команды apply просто применяется хранилище, а содержимое все еще находится в стеке, вам нужно удалить указанное хранилище:git stash drop stash{0}; если вы используете команду pop не только для повторного применения тайника, но и для его немедленной очистки из стека:git stash pop;
9. В некоторых случаях вы можете захотеть применить изменения тайника, а после внесения некоторых других изменений отменить ранее примененные изменения тайника. Git не предоставляет такой команды, как stash unapply , но того же эффекта можно добиться, распаковав тайник:git stash show -p stash@{0} | git apply -R; Точно так же, если вы не укажете конкретный репозиторий, Git выберет самый последний репозиторий:git stash show -p | git apply -R;

файл обновления

1. Переименуйте файл и зафиксируйте переименованный файл в промежуточной области:git mv [file-original] [file-renamed];

Проверить новую информацию

1. Запросите статус всех файлов в текущей рабочей области:git status;
2. Сравните разницу между текущим файлом в рабочей области и staging области, то есть содержимым, которое не было временно сохранено после модификации: git diff сравнение разницы между указанным файлом в рабочей области и staging областью:git diff <file-name>;

4. Операционные команды на промежуточной площадке

коммит файлов в репозиторий

1. Отправьте файлы в staging area на локальное хранилище, то есть отметьте новую версию:git commit -m "commit_info";
2. Все файлы, которыми управляет git, размещаются и отправляются вместе, пропуская процесс добавления в область подготовки:git commit -a -m "commit_info";
3. При отправке файлов, если вы обнаружите, что пропустили несколько файлов или комментарии неверны, вы можете отменить последнюю отправку:git commit --amend;

Посмотреть информацию

1. Сравните различия между промежуточной областью и предыдущей версией:git diff --cached;
2. Отличие указанного файла в промежуточной области от локального хранилища:git diff <file-name> --cached;
3. Просмотр истории коммитов: git log; параметры-pЧтобы расширить содержимое diff каждой фиксации, используйте-2Показать два последних обновления, напримерgit log -p -2;

тег

Git использует два типа тегов:Легкий и аннотированный. Облегченный тег подобен ветке, которая не меняется, на самом деле это ссылка на конкретный объект коммита. С другой стороны, аннотированная метка — это отдельный объект, хранящийся в репозитории, который имеет собственную информацию о контрольной сумме, включая имя метки, адрес электронной почты и дату, а также описание метки. позволяет использовать GNU Privacy Guard (GPG) для подписи или проверки. В общем, мы рекомендуем использовать аннотированные теги, чтобы сохранить релевантную информацию; конечно, если это только временные теги или если вам не нужна дополнительная информация в примечании, можно использовать облегченный тег.

1. Перечислите все присутствующие теги:git tag;
2. Используйте определенный шаблон поиска, чтобы перечислить подходящие теги, например, заинтересованные только в версиях серии 1.4.2:git tag -l "v1.4.2.*";
3. Создайте метку с типом аннотации, вам нужно добавить-aпараметры, такие какgit tag -a v1.4 -m "my version 1.4";
4. Используйте команду git show для просмотра информации о версии соответствующего тега вместе с объектом фиксации при отображении тега:git show v1.4;
5. Если у вас есть собственный закрытый ключ, вы можете использовать GPG для подписи тега, просто используйте команду-sпараметр:git tag -s v1.5 -m "my signed 1.5 tag";
6. Проверьте подписанные теги: git tag -v , как вgit tag -v v1.5;
7. Чтобы создать упрощенный тег, просто используйте команду git tag напрямую, даже-a,-sа также-mНикаких опций не требуется, просто укажите имя метки напрямую, напримерgit tag v1.5;
8. Отправьте тег в удаленный репозиторий: git push origin , напримерgit push origin v1.5;
9. Перенесите все локальные теги в удаленный репозиторий:git push origin --tags;

управление филиалом

1. Создайте ветку:git branch <branch-name>,какgit branch testing;
2. Переключиться с текущей ветки на другую ветку:git checkout <branch-name>,какgit checkout testing;
3. Создайте новую и переключитесь на новую ветку:git checkout -b <branch-name>;
4. Удалить ветку:git branch -d <branch-name>;
5. Объединить текущую ветку с указанной веткой:git merge <branch-name>;
6. Показать все ветки локального репозитория:git branch;
7. Просмотрите информацию о последнем объекте коммита каждой ветки:git branch -v;
8. Посмотрите, какие ветки были объединены в текущую ветку:git branch --merged;
9. Посмотрите, какие ветки в данный момент не объединены в текущую ветку:git branch --no-merged;
10. Объединить удаленную ветку с текущей веткой:git merge <remote-name>/<branch-name>,какgit merge origin/serverfix; Если это однострочная ветвь истории, нет никаких различий, которые нужно разрешать, достаточно просто переместить указатель HEAD вперед, чтобы этот процесс слияния можно было назвать перемоткой вперед (Fast forward), а если ветвь истории разветвлена , это будет Использовать две ветки текущей вилки в качестве двух предков для создания нового объекта коммита; если вы столкнулись с конфликтами слияния при слиянии ветвей, вы можете отправить их только после их разрешения вручную;
11. Создайте новую локальную ветку на основе удаленной ветки：git checkout -b <branch-name> <remote-name>/<branch-name>,какgit checkout -b serverfix origin/serverfix;
12. Локальная ветка, извлеченная из удаленной ветки, называется веткой отслеживания. Переместите содержимое из ветки отслеживания в удаленную ветку:git push. Эта команда автоматически определяет, в какую ветку удаленного репозитория следует отправить данные; объедините удаленную ветку с веткой отслеживания:git pull;
13. Переместите изменения, зафиксированные в ветке, в базовую ветку и воспроизведите их:git rebase <rebase-branch> <branch-name>,какgit rebase master server, воспроизведите изменения, отправленные сервером ветки функций, на мастере базовой ветки; самое большое преимущество использования операции перебазирования заключается в том, что, как и при работе с одной веткой, отправленная история изменений также является строкой; если вы хотите выполнить перебазирование в другой функциональная ветвь, основанная на другой. Чтобы перебазировать функциональную ветвь на другую ветвь, используйте--ontoработать:git rebase --onto <rebase-branch> <feature branch> <sub-feature-branch>,какgit rebase --onto master server client; Принципы, которых следует придерживаться при использовании операции перебазирования:Никогда не перебазируйте ветку после публикации коммитов в ветке в общедоступном репозитории.;

5. Операции на локальном складе

1. Просмотр удаленного склада, связанного с локальным складом:git remote; после клонирования каждого удаленного репозитория удаленный репозиторий по умолчаниюorigin; добавлять-vПосле отобразятся параметры удаленного складаurlадрес;
2. Добавление удаленного репозитория обычно требует короткого псевдонима:git remote add [remote-name] [url],Например:git remote add example git://github.com/example/example.git;
3. Получите обновления из удаленного репозитория, недоступные в локальном репозитории:git fetch [remote-name],какgit fetch origin;Использование fetch только извлекает удаленные данные в локальное хранилище и не объединяет их автоматически в текущую рабочую ветку, их можно объединить только вручную. Если вы установили связь филиала с филиалом удаленного склада, вы можете использоватьgit pullВытягивать и вытягивать данные удаленной ветки, а затем автоматически объединять удаленную ветку с текущей веткой на локальном складе;
4. Перенесите ветку локального склада на удаленный склад:git push [remote-name] [branch-name],какgit push origin master; если вы хотите отправить локальную ветку в ветку с другим именем удаленного репозитория:git push <remote-name> <local-branch>:<remote-branch>,какgit push origin serverfix:awesomebranch; если вы хотите удалить удаленную ветку:git push [romote-name] :<remote-branch>,какgit push origin :serverfix. Локальная ветка здесь опущена, что эквивалентно отправке пустого содержимого в удаленную ветку, что эквивалентно удалению удаленной ветки.
5. Просмотр сведений об удаленном репозитории:git remote show origin;
6. Измените местную аббревиатуру удаленного склада:git remote rename [old-name] [new-name],какgit remote rename origin org;
7. Удалить удаленный репозиторий:git remote rm [remote-name];

6. Игнорируйте файл .gitignore

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

# 此为注释 – 将被 Git 忽略
# 忽略所有 .a 结尾的文件
*.a
# 但 lib.a 除外
!lib.a
# 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO
/TODO
# 忽略 build/ 目录下的所有文件
build/
# 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
doc/*.txt
# 忽略 doc/ 目录下所有扩展名为 txt 的文件
doc/**/*.txt

использованная литература

Очень подробные и точные учебные материалы по git;

git-cheat-sheet китайская версия

Сводка команд, информация общая, недостаточно подробная, для справки

Общие команды очень полны