Git add git commit m сообщение git push
Обновлено: 05.07.2024
git config --global user.name "[name]" — установить имя, которое будет прикрепляться к коммиту.
git config --global user.email "[email address]" — установить email, который будет прикрепляться к коммиту.
git config --global color.ui auto — включить полезную подсветку командной строки.
git config --global push.default current — обновлять удаленную ветку с таким же именем, что и локальная, при пуше изменений (если не указано иного).
git config --global diff.tool [tool] — установить программу для разрешения конфликтов при слиянии.
Создание репозиториев
git init [project-name] — создать новый локальный репозиторий с заданным именем.
git clone [url] — загрузить проект и его полную историю изменений.
Работа с изменениями
git status — полный список изменений файлов, ожидающих коммита.
git status -s — краткий вид изменений.
git diff — показать изменения в файлах, которые еще не были добавлены в индекс коммита (staged).
git add [file] — сделать указанный файл готовым для коммита.
git add . — сделать все измененные файлы готовыми для коммита.
git add '*.txt' — добавить только файлы, соответствующие указанному выражению.
git add --patch filename — позволяет выбрать какие изменения из файла добавятся в коммит.
git diff --staged — показать что было добавленно в индекс с помощью git add , но еще не было закоммиченно.
git diff HEAD — показать что изменилось с последнего коммита.
git diff HEAD^ — показать что изменилось с предпоследнего коммита.
git diff [branch] — сравнить текущую ветку с заданной.
git difftool -d — то же самое, что и diff , но показывает изменения в заданной difftool.
git difftool -d master.. — показать изменения, сделанные в текущей ветке.
git diff --stat — показать статистику какие файлы были изменены и как.
git reset [file] — убрать файлы из индекса коммита (изменения не теряются).
git commit --amend — добавить изменения к последнему коммиту.
Работа с ветками
git branch — список всех локальных веток в текущей директории.
git branch [branch-name] — создать новую ветку.
git checkout [branch-name] — переключиться на указанную ветку и обновить рабочую директорию.
git checkout -b /
— переключиться на удаленную ветку.
git checkout [filename] — вернуть файл в первоначальное состояние если он еще не был добавлен в индекс коммита.
git merge [branch] — соединить изменения в текущей ветке с изменениями из заданной.
git merge --no-ff [branch] — соединить ветки без режима “fast forwarding”.
git branch -a — посмотреть полный список локальных и удаленных веток.
git branch -d [branch] — удалить заданную ветку.
git branch -D [branch] — принудительно удалить заданную ветку, игнорируя ошибки.
Работа с файлами
git rm [file] — удалить файл из рабочей директории и добавить в индекс информацию об удалении.
git rm --cached [file] — удалить файл из репозитория, но сохранить его локально.
git mv [file-original] [file-renamed] — изменить имя файла и добавить в индекс коммита.
Отслеживание файлов
.gitignore — текстовый файл, в котором задаются правила для исключения файлов из репозитория. Например:
git ls-files --other --ignored --exclude-standard — список всех игнорируемых файлов.
Сохранение фрагментов
git stash — положить во временное хранилище все отслеживаемые файлы.
git stash pop — восстановить последние файлы, положенные во временное хранилище.
git stash list — список всех сохраненных изменений во временном хранилище.
git stash drop — удалить последние файлы, положенные во временное хранилище.
Просмотр истории
git log — список изменения текущей ветки.
git log --follow [file] — список изменения текущего файла, включая переименования.
git log --pretty=format:"%h %s" --graph — изменение вида отображения истории изменений.
git log --author='Name' --after= --pretty=oneline --abbrev-commit — посмотреть над чем работал заданный пользователь последнюю неделю.
git log --no-merges master.. — посмотреть историю изменений только для текущей ветки.
git diff [file-branch]..[second-branch] — посмотреть различия между двумя заданными ветками.
git show [commit] — показать метадату и изменения в заданном коммите.
git show [branch]:[file] — посмотреть на файл в другой ветке, не переключаясь на неё.
Отмена коммитов
git reset — убрать изменения из индекса коммита, сами изменения останутся.
git reset [commit/tag] — отменить все коммиты после указанного коммита, изменения будут сохранены локально.
git reset --hard [commit] — принудительно вернутся к указанному коммиту, не сохраняя историю и изменения.
Синхронизация изменений
git fetch [bookmark] — загрузить всю историю с заданного удаленного репозитория.
git merge [bookmark]/[branch] — слить изменения локальной ветки и заданной удаленной.
git push — запушить текущую ветку в удаленную ветку.
git push [remote] [branch] — запушить ветку в указанный репозиторий и удаленную ветку.
git push [bookmark] :[branch] — в удаленном репозитории удалить заданную ветку.
git push -u origin master — если удаленная ветка не установлена как отслеживаемая, то сделать ее такой.
git pull — загрузить историю и изменения удаленной ветки и произвести слияние с текущей веткой.
git pull [remote][branch] — указать конкретную удаленную ветку для слияния.
git remote — посмотреть список доступных удаленных репозиториев.
git remote -v — посмотреть детальный список доступных удаленных репозиториев.
Будучи новичком, я, как и все, искал на StackOverflow полезные Git-команды. Я просто копировал и вставлял их, не задаваясь вопросом, что и как они делают.
Спустя несколько лет эта роль досталась мне. Поэтому в этой статье я все-таки расскажу о ряде git-команд, которые могут пригодиться даже мидлам.
Чтобы убедиться, что мой список будет состоять из реально полезных и практически применимых команд, я отобрал только те, которые реально использовал за последнюю неделю.
Практически каждый разработчик пользуется Git — и, скорее всего, это GitHub. Среднестатистический программист при этом, вероятно, использует только эти три команды в большинстве случаев:
Я начну с самых часто используемых команд, чтобы новичкам было легче понять, что можно сделать с помощью Git. Затем я перейду к уже более продвинутым функциям.
Часто используемые команды
Чтобы инициализировать Git в репозитории, вам просто нужно ввести следующую команду. Если вы не инициализируете Git, вы не сможете запускать другие команды Git в этом репозитории.
Если вы используете GitHub и отправляете код в репозиторий GitHub, который хранится в Сети, вы используете удаленный репозиторий. Имя, установленное по умолчанию для этого удаленного репозитория, называется origin (источник), он же alias (псевдоним). Если вы скопировали проект из GitHub, у него уже есть источник. Вы можете просмотреть этот источник с помощью команды git remote -v. Она выдаст вам URL-адрес удаленного репозитория.
Если вы инициализировали свой репозиторий Git и хотите связать его с репозиторием на GitHub, вам придется создать его на GitHub, скопировать предоставленный URL-адрес и использовать команду git remote add origin , где — ссылка на репозиторий GitHub. Оттуда вы можете добавлять, коммитить и пушить в удаленный репозиторий.
Допустим, вы скопировали чей-то удаленный репозиторий и хотите изменить его владельца на свою учетку GitHub. Схема такая же, как с git remote add origin, с одним дополнением: используйте set-url, чтобы изменить удаленный репозиторий.
Самый распространенный способ скопировать репозиторий — через git clone с указанием URL.
Вы быстро поймете, что ветки — это удобно. Если вы не знаете, что это такое, поищите руководство по этой теме. Это понадобится в дальнейшем.
Команда git branch перечислит все ветки на вашем компьютере. Если вы хотите создать новую ветку, можете использовать команду git branch , где — имя ветки (например, master).
Команда git checkout переключит на существующую ветку. Поэтому чтобы создать новую ветку и сразу же переключиться на нее, можете использовать команду git checkout -b . Обычно эту команду используют, чтобы не писать отдельно git branch, а отдельно git checkout.
Если вы внесли кучу изменений в ветку и хотите смержить ее в основную ветку (назовем ее develop), используйте команду git merge
. Если захочется при этом сначала провести checkout основной ветки, тогда запустите git merge develop, чтобы смержить develop в основную ветку.
Если вы работаете еще с кем-то, может случиться так, что репозиторий обновили на GitHub, но у вас изменения не появились. В этом случае используйте git pull origin
, чтобы получить последние изменения указанной удаленной ветки.
Если вам интересно узнать, какие файлы изменили, можете использовать git status. Если вы хотите увидеть, насколько сильно был изменен файл, используйте git diff, чтобы увидеть количество измененных строк.
Команды для продвинутых
Вскоре вы дойдете до того момента, когда захочется, чтобы ваши коммиты выглядели красиво и при этом были последовательными. Для этого, возможно, придется повозиться со своими прошлыми коммитов, чтобы они стали понятнее.
Команда git logo позволяет увидеть историю коммитов. Она-то и поможет, если вам нужно просмотреть историю и изменить старые коммиты.
Если вам нужно проверить свое приложение из предыдущего коммита, можно сделать это напрямую — просто используйте хэш.
Внимание: force push — штука опасная, использовать ее можно только в крайнем случае, когда других вариантов не остается. Force push перепишет историю вашего приложения — все, что было после force push, исчезнет.
Иногда просто нецелесообразно хранить все в одном коммите. Если вы хотите сохранить свой прогресс, прежде чем исполнить что-то рисковое, или, возможно, вы допустили ошибку и хотите избавиться от нее в истории версий, используйте git rebase.
Допустим, у вас есть 4 коммита в вашей локальной истории (не запушенные на GitHub), и выглядят они неряшливо. Вы можете использовать rebase, чтобы объединить все эти коммиты в один.
Приведенная выше команда откроет редактор, установленный по умолчанию, (если вы ничего не меняли, это будет Vim), который предложит несколько вариантов изменения коммита. Это будет выглядеть примерно так:
Задача: добавить кнопку оформления заказа на страницу оплаты.
- добавить кнопку;
- написать тесты для оформления заказа.
Перечисление конкретных пунктов упрощает написание чейнжлога. Вы также можете добавить информацию в нижний колонтитул.
Примечание: избегайте ребейзинга ваших коммитов, если вы с кем-то работаете над проектом и у вас есть код, запушенный на GitHub. Если вы начнете изменять историю версий прямо на глазах у людей, можете наделать кучу ошибок, которые будет трудно отследить.
В Git почти бесконечное количество команд. Но перечисленные в этой статье команды — чуть ли не единственные, которые потребуются в первые несколько лет программирования.
Subscribe to Блог ASKMENTOR
Get the latest posts delivered right to your inbox
7 мест, где можно найти ментора
Вам когда-нибудь приходило в голову искать наставника в фитнес-клубе? Вы удивитесь, где может тусоваться нужный человек
С чего начать обучение в программировании?
Если вы хотите научиться программированию, но не знаете, с чего начать — вы попали по адресу
В последние годы популярность git демонстрирует взрывной рост. Эта система контроля версий используется различными проектами с открытым исходным кодом.
Новичков часто пугает большое количество замысловатых команд и сложных аргументов. Но для начала все они и не нужны. Можно начать с изучения наиболее часто используемых команд, и после этого постепенно расширять свои знания. Именно так мы и поступим в этой статье. Поехали!
Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.
Git является распределенным, то есть не зависит от одного центрального сервера, на котором хранятся файлы. Вместо этого он работает полностью локально, сохраняя данные в папках на жестком диске, которые называются репозиторием. Тем не менее, вы можете хранить копию репозитория онлайн, это сильно облегчает работу над одним проектом для нескольких людей. Для этого используются сайты вроде github и bitbucket.
Установить git на свою машину очень просто:
- Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
- Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
- OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:
Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.
Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:
Теперь каждое наше действие будет отмечено именем и почтой. Таким образом, пользователи всегда будут в курсе, кто отвечает за какие изменения — это вносит порядок.
Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:
Командная строка должна вернуть что-то вроде:
Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.
status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:
В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:
Если нам нужно добавить все, что находится в директории, мы можем использовать
Проверим статус снова, на этот раз мы должны получить другой ответ:
Коммит представляет собой состояние репозитория в определенный момент времени. Это похоже на снапшот, к которому мы можем вернуться и увидеть состояние объектов на определенный момент времени.
Чтобы зафиксировать изменения, нам нужно хотя бы одно изменение в области подготовки (мы только что создали его при помощи git add), после которого мы может коммитить:
Сейчас наш коммит является локальным — существует только в директории .git на нашей файловой системе. Несмотря на то, что сам по себе локальный репозиторий полезен, в большинстве случаев мы хотим поделиться нашей работой или доставить код на сервер, где он будет выполняться.
1. Подключение к удаленному репозиторию
Проект может иметь несколько удаленных репозиториев одновременно. Чтобы их различать, мы дадим им разные имена. Обычно главный репозиторий называется origin.
Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого - push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).
В зависимости от сервиса, который вы используете, вам может потребоваться аутентифицироваться, чтобы изменения отправились. Если все сделано правильно, то когда вы посмотрите в удаленный репозиторий при помощи браузера, вы увидите файл hello.txt
3. Клонирование репозитория
Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.
Новый локальный репозиторий создается автоматически с GitHub в качестве удаленного репозитория.
4. Запрос изменений с сервера
Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.
Так как новых коммитов с тех пор, как мы склонировали себе проект, не было, никаких изменений доступных для скачивания нет.
Во время разработки новой функциональности считается хорошей практикой работать с копией оригинального проекта, которую называют веткой. Ветви имеют свою собственную историю и изолированные друг от друга изменения до тех пор, пока вы не решаете слить изменения вместе. Это происходит по набору причин:
- Уже рабочая, стабильная версия кода сохраняется.
- Различные новые функции могут разрабатываться параллельно разными программистами.
- Разработчики могут работать с собственными ветками без риска, что кодовая база поменяется из-за чужих изменений.
- В случае сомнений, различные реализации одной и той же идеи могут быть разработаны в разных ветках и затем сравниваться.
1. Создание новой ветки
Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch
Это создаст новую ветку, пока что точную копию ветки master.
2. Переключение между ветками
Сейчас, если мы запустим branch, мы увидим две доступные опции:
master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.
3. Слияние веток
Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:
Изменения завершены, теперь мы можем переключиться обратно на ветку master.
Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).
Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.
В последней части этого руководства мы расскажем о некоторых дополнительных трюках, которые могут вам помочь.
1. Отслеживание изменений, сделанных в коммитах
У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
[spoiler title='Вывод git log']
[/spoiler]
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
[spoiler title='Вывод git show']
[/spoiler]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
[spoiler title='Вывод git diff']
[/spoiler]
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.
2. Возвращение файла к предыдущему состоянию
Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита - использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:
3. Исправление коммита
Для остальных будем использовать идентификаторы:
При отмене старых коммитов нужно быть готовым к тому, что возникнут конфликты. Такое случается, если файл был изменен еще одним, более новым коммитом. И теперь git не может найти строчки, состояние которых нужно откатить, так как они больше не существуют.
4. Разрешение конфликтов при слиянии
Помимо сценария, описанного в предыдущем пункте, конфликты регулярно возникают при слиянии ветвей или при отправке чужого кода. Иногда конфликты исправляются автоматически, но обычно с этим приходится разбираться вручную — решать, какой код остается, а какой нужно удалить.
Давайте посмотрим на примеры, где мы попытаемся слить две ветки под названием john_branch и tim_branch. И Тим, и Джон правят один и тот же файл: функцию, которая отображает элементы массива.
Джон использует цикл:
Тим предпочитает forEach:
Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
[spoiler title='Вывод']
[/spoiler]
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним - конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.
Когда все готово, нужно закоммитить изменения, чтобы закончить процесс:
Как вы можете заметить, процесс довольно утомительный и может быть очень сложным в больших проектах. Многие разработчики предпочитают использовать для разрешения конфликтов клиенты с графическим интерфейсом. (Для запуска нужно набрать git mergetool).
5. Настройка .gitignore
В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore
- Создайте вручную файл под названием .gitignore и сохраните его в директорию проекта.
- Внутри файла перечислите названия файлов/папок, которые нужно игнорировать, каждый с новой строки.
- Файл .gitignore должен быть добавлен, закоммичен и отправлен на сервер, как любой другой файл в проекте.
Вот хорошие примеры файлов, которые нужно игнорировать:
- Логи
- Артефакты систем сборки
- Папки node_modules в проектах node.js
- Папки, созданные IDE, например, Netbeans или IntelliJ
- Разнообразные заметки разработчика.
Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:
Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.
Вот и все! Наше руководство окончено. Мы очень старались собрать всю самую важную информацию и изложить ее как можно более сжато и кратко.
Git довольно сложен, и в нем есть еще много функций и трюков. Если вы хотите с ними познакомиться, вот некоторые ресурсы, которые мы рекомендуем:
Иногда я меняю только одну букву, CSS-отступ или что-то в этом роде. Тем не менее, я должен написать все три команды, чтобы подтолкнуть изменения. Есть много проектов, в которых я всего лишь один толкач, поэтому эта команда будет потрясающей!
Если вы делаете коммит для каждого отдельного изменения, вы делаете это неправильно. выполните команду, когда ваша функция закончена или ошибка устранена (это может быть одно изменение)
Построение ответа @ Гэвина:
Сделав lazygit функцией вместо псевдонима, вы можете передать ей аргумент. Я добавил следующее в мой .bashrc (или .bash_profile, если Mac):
Конечно, вы могли бы усилить это еще больше, приняв еще больше аргументов, например, в какое удаленное место нажать или в какую ветку.
@KaiCarver Хорошая мысль, но лично мне это не нравится. Он не позволяет использовать несколько аргументов, а также противоречит обычному соглашению, заключенному в одну строковую аргумента с пробелами, заключенными в кавычки. Это вторая натура для меня на данный момент (и я бы предположил, много разработчиков). Оставляя цитаты, кажется грязным.
@ btse я являюсь дипломатическим человеком + это пятница. Вот функция, использующая предложение @KaiCarver: function dirtygit() < git add . git commit -a -m "$*" git push >
В итоге я добавил псевдоним в мой .gitconfig файл:
Использование: git cmp "Long commit message goes here"
Псевдоним также может быть определен из командной строки, это добавляет его к вашему .gitconfig :
Это именно то, что я искал! Работает отлично, спасибо! Я не смог найти полную ссылку на синтаксис или подробный список команд. Что именно делает !f() < . >; f ? Более подробное объяснение этой строки сделало бы ответ еще лучше.
@ Оливер Почему это в кавычках? Почему восклицательный знак? F в конце вызывает функцию? Что такое "$ @"?
Хотя я согласен с Уэйном Вернером в его сомнениях, технически это вариант:
Другой вариант может заключаться в написании хука post-commit, который выполняет push.
@wlz Я только что попробовал, и он отлично работает. Обратите внимание, что вся строка находится в одинарных кавычках. git автоматически добавляются побеги (проверено с помощью git config -e ).
В Windows мне нужно было избегать двойных кавычек около $ 1, чтобы заставить его работать из PowerShell (используя . \ "$ 1 \" . )
Как правило, вы будете делать что-то вроде этого:
стирать, ополаскивать, повторять до тех пор, пока вы не закончите функцию X, не остановитесь или не захотите, чтобы другие увидели, что вы сделали Тогда вы делаете
Git - это не SVN, но кажется, что вы пытаетесь использовать его как таковой. Вы можете найти некоторые ресурсы в конце статьи здесь, которые будут полезны.
Спасибо за объяснение, но GIT не рухнет, если будет такая команда для тех, кто знает, что они делают .
@Lucas: Опытные программисты скажут вам, что люди, которые просят автоматическую команду commit-push, не знают, что они делают. Есть причина для 3-этапной проверки кода (если вы используете ветки функций, 4-этапные).
@ Slebetman: Я не объяснил это правильно. В приложениях Facebook каждое изменение должно быть развернуто на действующем сервере даже для разработки. Итак, мы установили хуки коммитов для этого. Вы вносите изменения, фиксируете их и видите изменения в своем приложении. Мне нужно добавить git, stage, затем нажать его, чтобы увидеть одно изменение. Разве это не выглядит излишним?
Я использую это в моем .bash_profile
Не забудьте запустить source ~/.bash_profile после сохранения псевдонима.
Мне действительно это нравится. . и поэтому принял его в свой собственный ~ / .bash_profile;) спасибо .. +1
Вы можете использовать скрипт bash, установить псевдоним для запуска любой команды или группы команд
Если вы хотите дать ответ, пожалуйста, добавьте больше комментариев о том, как это работает. Ответы, которые являются просто дампом кода, обычно не принимаются хорошо. Смотрите как ответить .
Я думаю, что это должен быть правильный ответ. Как это ответить на вопрос как можно более кратко. Просто введите его в терминал, и он работает! Если вы не хотите добавлять псевдоним, альтернативой было бы просто создать расширение textExpander и запустить его с помощью комбинации клавиш.
Установить как псевдоним в bash:
(Чтобы сделать этот псевдоним постоянным, вам нужно включить его в ваш .bashrc или .bash_profile)
Самое простое решение:
git add уже содержится в параметре commit, но при желании вы можете подключить их все:
В Linux / Mac этот практичный вариант также должен работать
Если вы работаете над новой веткой, созданной локально, измените git push часть с помощью git push -u origin branch_name
Вы можете попробовать Gitu .
В первый раз (должен быть установлен узел js):
Чтобы выпустить эти три команды одновременно.
Хорошо, что вам не нужно беспокоиться, когда вы переустанавливаете свою систему или когда вы хотите сделать это на разных компьютерах, и никаких изменений файлов не требуется. Это также работает на разных платформах (не только Linux и Mac, но и Windows в командной строке, как cmd и powershell ), просто, что вы должны установить npm и nodejs ( git конечно).
Если файл уже отслеживается, вам не нужно запускать git add , вы можете просто написать git commit -am 'your message'
Если вы не хотите писать коммит, вы можете подумать о том, чтобы сделать что-то вроде
git commit --allow-empty-message -am ''
Этот результат - Попробуйте это: Простой скрипт одна команда для git add, git commit и git push
Откройте свой CMD в Windows и вставьте этот ответ
git commit -m "your message" . && git push origin master
Как упоминалось в этом ответе, вы можете создать псевдоним git и назначить для него набор команд. В этом случае это будет:
и использовать его с
Извини, ты прав. Я думаю, что я не заметил, что ответ Тильмана Фогеля был таким же, как мой .. Должен ли я удалить его ??
Напишите небольшой скрипт с именем gitpush.sh со строками ниже и добавьте его в ~ директорию.
Теперь добавьте псевдоним в ~ / .bashrc, как показано ниже:
Я использую командный файл:
Есть некоторые проблемы со сценариями выше:
git config --global alias.acpp '! git add -A && branchatu && branchatu = $ && git commit - m "$ 1" && shift && git pull -u origin $ branchatu && git push -u origin $ branchatu '
Если вы хотите svn-подобное поведение git commit, используйте это в псевдонимах git в вашем .gitconfig
Если вы используете рыбную раковину (основываясь на ответе btse):
Сохраните этот файл в ~ ~ .config / fish / functions как quickgit.fish. Создайте каталог, если он не существует. '--git-dir = $ PWD / .git' Гарантирует, что мы запускаем команды git для проекта git, где мы вызвали функцию
Уже есть много хороших решений, но вот решение, которое я считаю более элегантным для того, как я хочу работать:
Это позволяет мне бежать:
Если вы используете VSCode, вы можете скачать это расширение, которое позволит вам сделать это одним простым сочетанием клавиш.
Если вы используете Mac:
Отредактируйте .bash_profile в вашем любимом редакторе (или вы можете просто набрать "open -e .bash_profile", чтобы открыть его в TextEdit).
Скопируйте и вставьте ниже в файл:
После этого перезапустите свой терминал и просто добавьте, подтвердите и нажмите одну простую команду, например:
Для пользователей MAC VSC лучшая настройка:
1) нажмите shift + cmd + P и введите:
Нажмите ENTER (это установит команду кода, чтобы легко добраться до bash_profile)
2) теперь вы можете запустить: code ~/.bash_profile открыть пустой bash_profile
3) введите там новую функцию:
4) Теперь перезапустите VSC
5) внесите изменения, сохраните их и наберите lazygit message для одновременного запуска трех команд
Для пользователей MacOS:
Откройте свой терминал или iTerm2 или другой терминал, который вы используете.
Перейдите в папку вашего профиля пользователя с помощью команды ~/ . Это папка по умолчанию для .bash_profile файла:
Введите nano .bash_profile эту команду, чтобы открыть .bash_profile документ (или создать его, если он еще не существует) в простейшем текстовом редакторе для терминала - nano .
Теперь вы можете внести простые изменения в файл. Вставьте эти строки кода, чтобы изменить подсказку терминала:
Теперь сохраните ваши изменения, набрав ctrl + o и нажмите Return для сохранения. Затем выйдите nano , набрав ctrl + x .
Теперь нам нужно активировать ваши изменения. Наберите source .bash_profile (или . ~/.bash_profile ) и просмотрите ваши быстрые изменения.
В iTerm2 Preferences/Profiles/General/Command установлен Login Shell и Send text at start в source ~/.bash_profile . Поэтому вам не нужно делать это вручную после каждого перезапуска macOS.
Я сделал этот сценарий .sh для команды
Добавьте ~/.bash_profile для добавления, фиксации и нажатия одной командой:
Также есть функция для добавления и фиксации аналогичным образом:
Работает точно так же, как эта g функция и имеет те же ограничения. Просто поставь c вместо этого. Например
Вы также можете добавить псевдоним для отправки на пульт:
Это составляет в 2 -х букв, c и p вы используете при работе с репозиторием мерзавца. Или вы можете использовать g вместо этого, чтобы сделать все это только с одной буквы.
Читайте также: