Как стать Git-мастером: 7 советов по повышению производительности
Oct 25, 2019 · 4 min read
Автозаполнение команд Git в терминале
Git предоставляет сценарий автозаполнения, который нужно скачать для использования этой функции. Запустите следующую команду для скачивания сценария в домашнюю директорию:
Этот фрагмент выполняет поиск сценария автозаполнения в домашней директории и, при наличии запускает его при каждом входе в bash.
Локальное удаление ветки в удаленном репозитории
С помощью команды push можно быстро удалить ветку в удаленном репозитории из локальной системы. Предположим, что у вас уже есть доступ к удаленному репозиторию.
Force Push без рисков
Отмена изменений в Git
Несмотря на определенную пользу Git в большинстве случаев, иногда необходимо внести изменения в некоторые операции. В этом разделе мы обсудим отмену трех типов изменений — отслеживание файла, внесение изменений и создание коммита.
Чтобы отменить процесс отслеживания файла с Git, запустите следующую команду:
Для отмены внесения изменений в файл с момента последнего коммита выполните следующее:
Эта команда отменяет статус репозитория до N коммитов перед HEAD и не приводит к изменениям в файлах.
Сохранение незафиксированных изменений с помощью stash
Представьте, что вы работаете с новой функцией, а начальник спрашивает о ходе выполнения предыдущего задания. Текущая функция еще не завершена, поэтому создание коммита не имеет логического смысла. Что же нужно сделать?
На помощь приходят Git stash. Следующая команда сохраняет все незафиксированные изменения и возвращается к состоянию репозитория при последнем коммите.
Чтобы возобновить работу над этой функцией, используйте следующую команду для проверки всех stashes:
Эта команда показывает список всех сохраненных stash с отметками времени. Применить N-й stash из списка stash можно с помощью следующей команды:
Выборочная фиксация изменений из файла
Обработка больших файлов с помощью Git LFS
Git хорошо справляется с текстовыми файлами, однако не способен эффективно обрабатывать двоичные файлы. Документы Excel, проекты Photoshop и другие исполняемые файлы — примеры таких двоичных файлов.
На помощь приходит Git LFS! Это open source расширение для Git, которое управляет большими двоичными файлами, помещая текстовые указатели в Git и сохраняя содержимое файла на удаленном сервере. В результате повышается эффективность процесса управления репозиторием, в то время как удаленный сервер обрабатывает большие двоичные файлы при внесении изменений.
После загрузки и установки в локальной системе инициализируйте Git LFS для каждого репозитория с помощью следующей команды:
Чтобы отследить один тип расширения файла (например, PSD), выполните следующую команду:
Бонусный совет: отладка с помощью Git
Знаете ли вы, что Git — очень эффективный инструмент для устранения проблем в кодовой базе? Git Blame помогает тщательно проанализировать историю файла, а процесс Bisect инициирует бинарный поиск по коммитам.
Заключение
На этом наш список завершен. В этом руководстве мы рассмотрели семь советов (и даже бонусный!) по повышению эффективности рабочего процесса.
Git push, git pull, git fetch — в чем разница? Шпаргалка по git-командам
Git — это распределенная система контроля версий. Она позволяет хранить данные обо всех изменениях кода в конкретных папках на жестком диске и обеспечивает удобную командную работу.
Git push
Команда git push в ходе выполнения переносит все изменения, внесенные юзером, в удаленный репозиторий (например, такой как GitHub):
Вынужденная команда push при корректировке коммитов:
Git pull
Команда git pull отвечает за скачивание данных с сервера. Процесс очень похож на клонирование репозитория, но здесь скачиваются не все коммиты, а только новые.
По сути, git pull — это сочетание команд git fetch (загружает коммиты, ссылки, файлы из удаленного репозитория в локальный) и git merge (объединяет несколько коммитов в один общий).
Git pull для удаленной ветки
Git fetch
Синхронизация с командой git fetch origin
Это отобразит ветки, которые уже были загружены:
Git merge
Команда git merge связывает ряд коммитов в одно целое. В свою очередь git создает коммит слияния, где и объединяются изменения обеих последовательностей.
Конфликт в слиянии
По завершению слияния, выполните команду git add : таким образом вы проинформируете, что причина конфликта разрешена. Важно запомнить, что конфликты допустимы только в трехслойном слиянии и никогда не возникают при ускоренном.
Разница между командами git
Условно говоря, git pull – это последовательность двух команд: git fetch (прием изменений от сервера) и git merge (слияние).
В свою очередь, git push переносит ветвь разработки в удаленную исходную точку, а git merge — объединяет изменения из разработки в локальную ветку.
Шпаргалка по git-командам
git init — создание новых репозиториев;
git clone — клонирование удаленного репозитория;
git rm — удаление файла;
git log — просмотр истории коммитов;
git branch
— создание новой ветки;
git branch –d
— удаление ветки;
git merge
— слияние веток;
git push
— отправка ветки на удаленный сервер;
git push :
— удаление ветки на удаленном сервере;
git tag — просмотр меток;
git push — обмен метками;
git remote — отображение удаленных репозиториев;
git pull
— получение данных из удаленного репозитория и слияние с локальным;
git push
— отправка локальных изменений на удаленный сервер.
Git push force что это
Check your version of git by running
SYNOPSIS
DESCRIPTION
Updates remote refs using local refs, while sending objects necessary to complete the given refs.
You can make interesting things happen to a repository every time you push into it, by setting up hooks there. See documentation for git-receive-pack[1].
When the command line does not specify where to push with the argument, branch.*.remote configuration for the current branch is consulted to determine where to push. If the configuration is missing, it defaults to origin.
When neither the command-line nor the configuration specify what to push, the default behavior is used, which corresponds to the simple value for push.default : the current branch is pushed to the corresponding upstream branch, but as a safety measure, the push is aborted if the upstream branch does not have the same name as the local one.
OPTIONS
The «remote» repository that is destination of a push operation. This parameter can be either a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below).
The is often the name of the branch you would want to push, but it can be any arbitrary «SHA-1 expression», such as master
If doesn’t start with refs/ (e.g. refs/heads/master ) we will try to infer where in refs/* on the destination it belongs based on the type of being pushed and whether is ambiguous.
If unambiguously refers to a ref on the remote, then push to that ref.
Other ambiguity resolutions might be added in the future, but for now any other cases will error out with an error indicating what we tried, and depending on the advice.pushUnqualifiedRefname configuration (see git-config[1]) suggest what refs/ namespace you may have wanted to push to.
The object referenced by is used to update the reference on the remote side. Whether this is allowed depends on where in refs/* the reference lives as described in detail below, in those sections «update» means any modifications except deletes, which as noted after the next few sections are treated differently.
The refs/heads/* namespace will only accept commit objects, and updates only if they can be fast-forwarded.
The refs/tags/* namespace will accept any kind of object (as commits, trees and blobs can be tagged), and any updates to them will be rejected.
I.e. a fast-forward of commits and tags outside refs/
The special refspec : (or +: to allow non-fast-forward updates) directs Git to push «matching» branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side.
Do everything except actually send the updates.
Produce machine-readable output. The output status line for each ref will be tab-separated and sent to stdout instead of stderr. The full symbolic names of the refs will be given.
All listed refs are deleted from the remote repository. This is the same as prefixing all refs with a colon.
All refs under refs/tags are pushed, in addition to refspecs explicitly listed on the command line.
Use an atomic transaction on the remote side if available. Either all refs are updated, or on error, no refs are updated. If the server does not support atomic pushes the push will fail.
Usually, «git push» refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it.
This option overrides this restriction if the current value of the remote ref is the expected value. «git push» fails otherwise.
This option allows you to say that you expect the history you are updating is what you rebased and want to replace. If the remote ref still points at the commit you specified, you can be sure that no other people did anything to the ref. It is like taking a «lease» on the ref without explicitly locking it, and the remote ref is updated only if the «lease» is still valid.
—force-with-lease alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have for them.
—force-with-lease= : will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the specified value (which is allowed to be different from the remote-tracking branch we have for the refname, or we do not even have to have such a remote-tracking branch when this form is used). If is the empty string, then the named ref must not already exist.
If your editor or some other system is running git fetch in the background for you a way to mitigate this is to simply set up another remote:
Now when the background process runs git fetch origin the references on origin-push won’t be updated, and thus commands like:
This flag disables these checks, and can cause the remote repository to lose commits; use it with care.
Force an update only if the tip of the remote-tracking ref has been integrated locally.
This option enables a check that verifies if the tip of the remote-tracking ref is reachable from one of the «reflog» entries of the local branch based in it for a rewrite. The check ensures that any updates from the remote have been incorporated locally by rejecting the forced update if that is not the case.
This option is equivalent to the argument. If both are specified, the command-line argument takes precedence.
Suppress all output, including the listing of updated refs, unless an error occurs. Progress is not reported to the standard error stream.
Use IPv4 addresses only, ignoring IPv6 addresses.
Use IPv6 addresses only, ignoring IPv4 addresses.
GIT URLS
In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.
Git supports ssh, git, http, and https protocols (in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it).
The native transport (i.e. git:// URL) does no authentication and should be used with caution on unsecured networks.
The following syntaxes may be used with them:
Малоизвестные Git-команды
У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.
git please
Каждому разработчику приходилось хотя бы раз общаться со своим тимлидом на тему принудительного пуша (force pushing) в общую ветку (не делайте этого). Ребейз (rebasing), внесение правок и squash — всё это забавно до тех пор, пока вы не перезапишете часть общей истории и не раскидаете дублирующиеся коммиты по всему репозиторию. К счастью, Git не позволит вам невольно перезаписать историю на сервере. Вам придётся явным образом передать в git push опцию —force, чтобы доказать серьёзность своих намерений. Но принудительный пуш — это грубый подход: вы затаптываете локальной версией вышерасположенную ветку, и все изменения, которые вы к тому моменту не подтянули (fetch), будут стёрты из истории.
git commend
Бывало так, что вы закоммитили и тут же сообразили, что забыли проиндексировать (stage) файл? Больше не нужно об этом беспокоиться! Алиас git commend тихо прикрепляет к последнему созданному вами коммиту все проиндексированные файлы, повторно используя уже имеющееся сообщение о коммите.
git it
Первому коммиту в репозитории нельзя сделать ребейз, как обычному. Поэтому рекомендуется в качестве корневого создавать пустой коммит. Алиас git it инициализирует ваш репозиторий и за одну операцию создаёт пустой корневой коммит. И когда вы в следующий раз запустите проект, то не надо просто добавлять его в систему управления версиями: выполните git it!
git staaash
git stash — одна из самых восхитительных и полезных Git-команд. Она регистрирует все изменения, вносимые в отслеживаемый файл в вашем рабочем дереве, и скрывает их для последующего использования, а вам показывает чистое дерево, чтобы вы могли спокойно работать с другой его частью. Но если вы создали новые файлы и ещё не проиндексировали их, то по умолчанию git stash их не тронет, поэтому у вас будет неопрятное рабочее дерево. Соответственно, по умолчанию не скрывается и содержимое неотслеживаемых или игнорируемых файлов.
Я сделал несколько удобных алиасов для разных вариантов git stash, в зависимости от того, какие биты вашего рабочего дерева нужно скрыть:
Если сомневаетесь в выборе, то самый длинный алиас (git staaash) всегда сможет восстановить рабочее дерево состояния свежего клона вашего репозитория.
git shorty
Я запускаю git status чаще любой другой Git-команды. Встроенная помощь в Git за последние годы стала куда удобнее, что очень хорошо для начинающих, но для более опытных пользователей информация слишком многословна. Например, git status объясняет мне в 12 строках, что у меня пара индексированных, неиндексированных и неотслеживаемых изменений:
Всё то же самое git shorty говорит мне тремя строками:
Для краткости я сделал это в виде алиаса git st, не смог остановиться.
git merc
Если вы используете обычный рабочий процесс ветвления без ребейза, то будет не лучшим решением запускать стандартный git merge для слияния веток с фичами с мастер-веткой. Если не добавить к этой команде опции, то по умолчанию станет использоваться стратегия слияния —ff, при которой новый коммит слияния будет создан только в том случае, если в мастер-ветке нет новых изменений. В противном случае мастер-ветка просто «перемотается» до места последнего коммита в вашей ветке. Лишь иногда, создавая коммит слияния, при просмотре Git-истории бывает непросто сказать, какой код был разработан в какой ветке.
git merc использует стратегию —no-ff, при которой всегда создаётся коммит слияния.
Между прочим, —no-ff всегда используется по умолчанию в ходе слияния pull request’ов в Bitbucket.
git grog
Мой алиас git grog (или graphical log) в последние годы разросся настолько, что я больше не уверен, будто точно знаю, что он делает. Но выглядит красиво:
Для сравнения, вот стандартный git log:
Там доступны все виды удобных форматов, так что форкайте вышеуказанную команду и пользуйтесь на здоровье!
Для поклонников GUI
Если вы поклонник Git GUI и работаете под Mac или Windows, то, возможно, вы используете наш бесплатный Git-клиент Atlassian SourceTree. Если да, то примените описанные в этой статье алиасы, создав новое кастомное действие — можно назначить комбинацию клавиш — в настройках SourceTree:
Это действие запускается с помощью меню (Actions → Custom Actions) или клавиатурной комбинации:
Git push
Использование git push
Публикация указанной ветки в удаленном репозитории вместе со всеми необходимыми коммитами и внутренними объектами. Эта команда создает локальную ветку в репозитории назначения. Чтобы предотвратить перезапись коммитов, Git не позволит опубликовать данные, если в репозитории назначения нельзя выполнить ускоренное слияние.
Публикация всех локальных веток в указанном удаленном репозитории.
Обсуждение git push
Команда git push чаще всего используется для публикации выгружаемых локальных изменений в центральном репозитории. Для того чтобы поделиться изменениями, внесенными в локальный репозиторий, с удаленными участниками команды, необходимо выполнить команду push.
Git push и синхронизация
Публикация в чистые репозитории
Принудительная публикация
Git предотвращает перезапись истории центрального репозитория, отклоняя push-запросы, если нельзя выполнить их ускоренное слияние. Так, если история удаленного репозитория отличается от вашей истории, необходимо загрузить удаленную ветку командой pull и выполнить ее слияние с локальной веткой командой merge, а затем попробовать выполнить команду push еще раз. Это похоже на то, как в SVN необходимо синхронизироваться с центральным репозиторием с помощью команды svn update перед тем, как сделать коммит набора изменений.
Примеры
Команда git push по умолчанию
Поскольку мы уже убедились, что локальная главная ветка была обновлена, должно произойти ускоренное слияние, а команда git push не должна сообщать о каких-либо описанных выше проблемах, связанных с невозможностью выполнения такого слияния.
Принудительная команда push при исправлении коммитов
Стирание удаленной ветки или тега
Иногда ветки необходимо чистить для наведения порядка. Чтобы полностью стереть ветку, ее необходимо стереть как в локальном репозитории, так и в удаленном.
Первая команда сотрет локальную ветку с именем branch_name. Если в команде git push перед именем ветки поставить двоеточие, будет стерта удаленная ветка.
