Как в gitlab удалить ветку
Как в gitlab удалить ветку
Как удалить ветку Git
Для организации разработки различных версий программного обеспечения в Git используются ветки. Ветки также очень часто используются для разработки новой функциональности в программе. Если разработкой продукта занимается команда, каждый разработчик может работать над своей частью функциональности в отдельной ветке.
Когда работа будет завершена, получившуюся ветку можно будет совместить с основной перед этим отправив её на проверку другим участникам команды. При таком рабочем процессе со временем накапливается много ненужных веток, которые надо удалять. В этой небольшой статье мы рассмотрим как удалить ветку локально и удаленно git.
Как удалить локальную ветку Git
Прежде чем что-либо удалять необходимо посмотреть какие ветки у вас есть. Для того чтобы посмотреть локальные ветки используйте такую команду в папке с репозиторием:
Команда выведет список локальных веток, а текущая ветка будет выделена зеленым цветом и звездочкой. Для того чтобы удалить ветку необходимо использовать ту же команду branch с опцией -d. Например, для того чтобы удалить ветку feature/somefeature1 выполните такую команду:
Удаление ветки Git завершено, если после этого вы снова проверите список локальных веток, то этой ветки там больше не будет:
А теперь давайте разберемся как выполняется удаление удалённой ветки Git. В данном случае ветка удалилась только локально, но если она была уже отправлена в удалённый репозиторий, то там она всё ещё есть.
Как удалить удалённую ветку Git
Теперь давайте разберемся как удалить ветку из удаленного репозитория git. Прежде чем смотреть ветки необходимо получить список веток и все обновления из добавленных удалённых репозиториев. Для этого выполните:
Для того чтобы посмотреть удалённые ветки необходимо выполнить такую команду в папке с репозиторием git:
Здесь все ветки отмечены красным и перед именем каждой из них выводится имя удалённого источник, в котором есть эта ветка. В данном случае это origin. Для удаления удалённой ветки используется команда push с опцией —delete, например, для той же feature/somefeature1 команда будет выглядеть вот так:
Теперь такой ветки нет в удалённом репозитории:
git push origin :feature/somefeature1
Такая команда тоже будет работать. Если вы хотите удалить все удалённые ветки, которых нет локально, используйте команду:
Выводы
В этой небольшой статье мы рассмотрели как удалить ветку Git, которая размещена удалённо или локально. Как видите, всё это очень просто даже при использовании командной строки. Если вы будете использовать графические клиенты, то всё станет ещё проще.
Как удалить ветку в Git
Git – популярная система контроля версий и необходимый инструмент в арсенале любого разработчика.
Ветки – неотъемлемая часть работы с Git. В этой статье вы узнаете, как их можно удалять.
Что такое ветки в Git?
Ветка – это снапшот проекта и всех его изменений с определённого момента времени.
Ветвление позволяет создавать новые независимые версии рабочего исходного кода. Ветки можно создавать, чтобы внести изменения, добавить новые функции или написать тест для исправления бага. Новая ветка позволяет делать это без вмешательства в основной код.
Итак, подведем итог: ветки позволяют вносить изменения в кодовую базу, не затрагивая основной код, до тех пор, пока вы не будете готовы включить эти изменения в проект.
Это поможет вам хранить свою кодовую базу в чистоте и порядке.
От редакции Techrocks. Не всегда для работы над отдельными фичами создаются отдельные ветки. На эту тему можно почитать статью «Что такое Trunk Based Development (TBD)?»
Зачем удалять ветки в Git?
Итак, вы создали ветку, чтобы работать в ней над какими-то изменениями. Затем вы слили свои изменения в исходную версию проекта.
Это значит, что вам больше не нужна ветка, в которой вы работали над изменениями. Удалить ее будет хорошим тоном: таким образом она не будет мешаться в вашем коде.
Как удалить локальную ветку в Git
Локальные ветки – это ветки на вашем компьютере, которые не влияют на ветки удаленного репозитория.
Команда для удаления локальной ветки в Git:
Давайте рассмотрим это подробнее на примере.
Следующая команда позволяет вывести список всех локальных веток:
Если мы попытаемся это сделать, то получим примерно такую ошибку:
Так что перед удалением локальной ветки обязательно переключитесь на другую, которую не собираетесь удалять.
Переход делается при помощи команды git checkout :
Теперь можно удалять ветку:
Это связано с тем, что эти коммиты нигде более не отслеживаются, и Git защищает вас от случайной потери этих данных.
Если все же попытаться удалить такую ветку, Git выдаст ошибку:
Используйте данную команду с осторожностью: после её ввода у вас не будут просить подтверждение удаления. Прибегайте к ней только когда абсолютно уверены, что хотите удалить локальную ветку.
Если вы не объединили её с другой локальной веткой или не запушили изменения в удаленный репозиторий, вы рискуете потерять все произведённые изменения.
Как удалить ветку в удалённом репозитории Git
Удалённые ветки существуют отдельно от локальных.
Это ветки в репозиториях на удалённых серверах, к которым мы имеем доступ. В этом заключается их отличие от локальных: последние находятся лишь у нас системе.
Команда удаления (прости Господи) удалённой ветки:
Рассмотрим пример того, как можно удалить ветку в origin.
Чтобы увидеть все удалённые ветки, используйте эту команду:
У меня созданы две локальные ветки ( master и test ) и две удалённые ( origin / master и origin / test ).
Заключение
Теперь вы знаете, как избавляться от локальных и удалённых веток в Git. Спасибо за внимание и удачи!
Git. Урок 3.
Ветвление. Создание, переключение и удаление веток. Команды: branch, checkout, status, log, diff.
1. Что такое ветка.
2. Зачем нужны ветки.
3. Создание новых веток.
4. Просмотр списка веток.
5. Переключение между ветками.
6. Просмотр состояния ветки. Команды: git status, git log, git diff.
6.1. Просмотр состояния файлов ветки. Команда git status.
6.2. Просмотр истории коммитов ветки. Команда git log.
6.3. Просмотр различий между коммитами. Команда git diff.
7. Удаление веток.
Дадим два определения ветки: на логическом и физическом уровнях.
1. Логический уровень.
С точки зрения логики, ветка – это последовательность коммитов. Чтобы проще было понять, что такое ветка, рассматривайте ее как некоторую временную шкалу. Коммиты в ней – снимки интересных моментов, идущие друг за другом в хронологической последовательности. Рисунок ниже поможет вам в интуитивном представлении.
2. Физический уровень
На физическом уровне, то есть с точки зрения внутренней реализации Git, ветка – это ссылка на последний коммит в этой ветке. Картинка ниже поможет вам понять, что к чему.
Преимущество веток в их независимости. Вы можете вносить изменения в файлы в одной ветке, например, пробовать новую функцию, и они никак не скажутся на файлах в другой ветке. Изначально в репозитории одна ветка, но позже мы рассмотрим, как создавать другие.
На самом деле, вначале, когда мы делаем свой первый коммит, Git автоматически создает основную ветку. Вы можете помнить, что ее имя по умолчанию «main» мы задавали в настройках Git в предыдущем уроке. Каждый раз, когда мы создаем новый коммит, Git автоматически перемещает указатель main на последний коммит. Тем не менее, в следующем уроке мы узнаем, как перемещать указатель ветки между коммитами самостоятельно.
Пока мы разбирались, что такое ветка, у вас мог возникнуть вопрос: зачем нужны такие сложности, ведь можно просто делать коммиты и откатывать изменения, когда нужно.
Дело в том, что Git – универсальная система контроля версий: она подходит и большим командам крупных корпораций, и индивидуальным разработчикам для их личных проектов.
Если вы работаете один – скорее всего вы будете редко использовать ветки, но если вы работаете в большой компании, без веток вам не обойтись.
Итак, чаще всего ветки используются в следующих случаях.
Способ 1. Команды git branch + git checkout
Команда git branch
На самом деле, git branch – очень мощная команда, которая умеет много всего. Сейчас мы рассматриваем ее как инструмент для создания веток. Ниже мы рассмотрим еще некоторые способы ее применения.
Команда git checkout
40 шестнадцатеричных цифр в файле выше и есть хэш последнего коммита, на который указывает новосозданная ветка.
С помощью команд git branch и git checkout вы можете создать неограниченное количество веток и переключаться между ними по мере необходимости. Обычно если ветка вам больше не нужна, ее сливают с основной и удаляют. Тема слияния веток заслуживает отдельного урока, поэтому про это мы поговорим в следующий раз, а удаление веток рассмотрим чуть ниже.
Команда git branch
# Теперь выведем только локальные ветки
$ git branch
* develop
feature
main
Теперь, когда мы поняли, как можно узнать имена веток в репозитории, давайте научимся переключаться между ними.
Команда git checkout
Этот маленький фокус позволит вам сэкономить время, особенно, если вы часто переключаетесь между ветками.
Шаг 1. Проверка существования ветки
Нужен этот этап, чтобы случайно не переключиться на ветку, которой не существует. Чтобы понять, как происходит этот процесс, нужно сделать небольшое отступление и рассказать, как вообще Git хранит информацию о существующих ветках.
Шаг 2. Переключение HEAD на нужную ветку
Шаг 3. Изменение рабочей копии
У внимательного читателя мог возникнуть вопрос: почему файлы в рабочей копии подгружаются именно из последнего коммита ветки? Что если до переключения с данной ветки, в ней были какие-то изменения, еще не добавленные в коммит? Что с ними будет? Ответ довольно прост. Согласно трем шагам, указанным выше, Git просто проигнорирует все такие файлы. То есть они останутся в вашей рабочей копии в том же состоянии, в котором и были до этого. Как правило, такое поведение очень неудобно, поскольку позволяет легко запутаться в структуре собственного проекта. Представьте: у вас два параллельных релиза, а вы, переключаясь между ветками, случайно занесли файлы одного релиза в ветку другого.
6.1. Просмотр состояния файлов ветки. Команда git status.
6.2. Просмотр истории коммитов ветки. Команда git log.
Команда git log
-p
Показывает изменения, сделанные в данном коммите.
—graph
Рисует ASCII-граф взаимосвязи коммитов.
—all
Выводит историю всех имеющихся коммитов на всех ветках.
adding complex algebra project
commit 603def20e5da2d512da2852011eb5be3fa156940 (origin/main, origin/HEAD)
Author: smartiqa
Date: Fri Dec 4 02:00:41 2020 +0300
В описании команды git log выше сказано, что в зависимости от ситуации, она может вывести полную историю репозитория, или же только историю некоторых коммитов. Давайте разбираться, как работает Git при выводе истории.
Общее правило, которым руководствуется Git при выводе истории, такое: иди по предкам коммитов, пока они не закончатся. Иногда это бывает удобно, иногда – нет.
Давайте разберемся, что делать, если мы хотим просмотреть историю коммитов только внутри какой-то конкретной ветки. То есть историю от момента создания ветки, до последнего коммита в ней. В этом случае нужно сделать следующее:
GitLab Web Editor
Sometimes it’s easier to make quick changes directly from the GitLab interface than to clone the project and use the Git command-line tool. In this feature highlight, we look at how you can create a new file, directory, branch, or tag from the file browser. All of these actions are available from a single dropdown menu.
Create a file
From a project’s files page, select the ‘+’ button to the right of the branch selector. Choose New file from the dropdown.
Enter a filename in the Filename box. Then, add file content in the editor area. Add a descriptive commit message and choose a branch. The branch field defaults to the branch you were viewing in the file browser. If you enter a new branch name, a checkbox displays, allowing you to start a new merge request after you commit the changes.
When you are satisfied with your new file, select Commit Changes at the bottom.
Shortcuts
You can use shortcuts when editing a file through the Web Editor. It uses the same shortcuts as the Web IDE. For details, read the documentation for Command Palette.
Template dropdowns
When starting a new project, there are some common files that the new project might need. GitLab displays a message to help you:
Highlight lines
Web Editor enables you to highlight a single line by adding specially formatted hash information to the URL’s file path segment. For example, the file path segment MY_FILE.js#L3 instructs the Web Editor to highlight line 3.
The Web Editor also enables you to highlight multiple lines using a similar pattern. In this case, the file path segment MY_FILE.js#L3-10 instructs the Web Editor to highlight lines 3 to 10 of the file.
Select Copy Link Address in the context menu.
Upload a file
The ability to create a file is great when the content is text. However, this doesn’t work well for binary data such as images, PDFs, or other binary file types. In this case, you need to upload a file.
From a project’s files page, select the ‘+’ button to the right of the branch selector. Choose Upload file from the dropdown:
After the upload dialog pops up, there are two ways to upload your file. Either drag and drop a file on the popup or use the click to upload link. After you select a file to upload, a file preview displays.
Enter a commit message, choose a branch, and select Upload file when you are ready.
Create a directory
To keep files in the repository organized it is often helpful to create a new directory.
From a project’s files page, select the plus button ( + ) to the right of the branch selector. Choose New directory from the dropdown.
In the new directory dialog, enter a directory name, a commit message, and choose the target branch. Select Create directory to finish.
Create a new branch
There are multiple ways to create a branch from the GitLab web interface.
Create a new branch from an issue
The Create merge request button changed to open the merge request creation form in GitLab 14.8.
If your development workflow requires an issue for every merge request, you can create a branch directly from the issue to speed the process up. The new branch, and later its merge request, are marked as related to this issue. Once merged, the merge request closes the issue. You can see a Create merge request dropdown below the issue description.
To make this button appear, one possible workaround is to remove your project’s fork relationship. After removal, the fork relationship cannot be restored. This project can no longer be able to receive or send merge requests to the source project, or other forks.
This dropdown contains the options Create merge request and branch and Create branch.
Create a new branch from a project’s dashboard
If you want to make changes to several files before creating a new merge request, you can create a new branch upfront.
From a project’s files page, choose New branch from the dropdown.
To return to the file browser on this new branch, select Create branch.
You can now make changes to any files, as needed. When you’re ready to merge the changes back to your default branch, you can use the widget at the top of the screen. This widget only appears for a period of time after you create the branch or modify files.
Create a new tag
Tags help you mark major milestones such as production releases and release candidates. You can create a tag from a branch or a commit SHA:
From a project’s files page, choose New tag from the dropdown.
Select Create tag. GitLab redirects you to the tag list page.
Commit your changes, and GitLab redirects you to a new merge request form.
If you’d prefer to not use your primary email address for commits created through the web editor, you can choose to use another of your linked email addresses from the User Settings > Edit Profile page.
Git on the command line
Git is an open-source distributed version control system. GitLab is built on top of Git.
You can do many Git operations directly in GitLab. However, the command line is required for advanced tasks, like fixing complex merge conflicts or rolling back commits.
If you’re new to Git and want to learn by working in your own project, learn how to make your first commit.
For a quick reference of Git commands, download a Git Cheat Sheet.
To help you visualize what you’re doing locally, you can install a Git GUI app.
Choose a terminal
Confirm Git is installed
You can determine if Git is already installed on your computer by opening a terminal and running this command:
If Git is installed, the output is:
If your computer doesn’t recognize git as a command, you must install Git.
Configure Git
To start using Git from your computer, you must enter your credentials to identify yourself as the author of your work. The username and email address should match the ones you use in GitLab.
In your shell, add your user name:
Add your email address:
To check the configuration, run:
You can read more on how Git manages configurations in the Git configuration documentation.
Choose a repository
Before you begin, choose the repository you want to work in. You can use any project you have permission to access on GitLab.com or any other GitLab instance.
You can fork any project you have access to.
Clone a repository
When you clone a repository, the files from the remote repository are downloaded to your computer, and a connection is created.
This connection requires you to add credentials. You can either use SSH or HTTPS. SSH is recommended.
Clone with SSH
To view the files, go to the new directory:
Clone with HTTPS
Run the following command. Git automatically creates a folder with the repository name and downloads the files there.
To view the files, go to the new directory:
Convert a local directory into a repository
Add a remote
You add a “remote” to tell Git which remote repository in GitLab is tied to the specific local folder on your computer. The remote tells Git where to push or pull from.
On your computer, open the terminal in the directory you’ve initialized, paste the command you copied, and press enter :
View your remote repositories
To view your remote repositories, type:
Download the latest changes in the project
To work on an up-to-date copy of the project, you pull to get all the changes made by users since the last time you cloned or pulled the project. Replace with the name of your default branch to get the main branch code, or replace it with the branch name of the branch you are currently working in.
You can learn more on how Git manages remote repositories in the Git Remote documentation.
Branches
A new branch is often called feature branch to differentiate from the default branch.
Create a branch
To create a feature branch:
Switch to a branch
All work in Git is done in a branch. You can switch between branches to see the state of the files and work in that branch.
To switch to an existing branch:
For example, to change to the main branch:
View differences
To view the differences between your local unstaged changes and the latest version that you cloned or pulled:
View the files that have changes
When you add, change, or delete files or folders, Git knows about the changes. To check which files have been changed:
Add and commit local changes
To stage a file for commit:
Confirm that the files have been added to staging:
The files should be displayed in green text.
To commit the staged files:
Stage and commit all changes
As a shortcut, you can add all local changes to staging and commit them with one command:
Send changes to GitLab.com
To push all local changes to the remote repository:
For example, to push your local commits to the main branch of the origin remote:
Sometimes Git does not allow you to push to a repository. Instead, you must force an update.
Delete all changes in the branch
To discard all changes to tracked files:
This action removes changes to files, not the files themselves. Untracked (new) files do not change.
Unstage all changes that have been added to the staging area
To unstage (remove) all files that have not been committed:
Undo most recent commit
To undo the most recent commit:
This action leaves the changed files and folders unstaged in your local repository.
You can learn more about the different ways Git can undo changes in the Git Undoing Things documentation.
Merge a branch with default branch
When you are ready to add your changes to the default branch, you merge the feature branch into it:
In GitLab, you typically use a merge request to merge your changes, instead of using the command line.
To create a merge request from a fork to an upstream repository, see the forking workflow.
Advanced use of Git through the command line
For an introduction of more advanced Git techniques, see Git rebase, force-push, and merge conflicts.
Synchronize changes in a forked repository with the upstream
To create a copy of a repository in your namespace, you fork it. Changes made to your copy of the repository are not automatically synchronized with the original. To keep the project in sync with the original project, you need to pull from the original repository.
You can now use the upstream as a to pull new updates from the original repository, and use the origin to push local changes and create merge requests.
Как в gitlab удалить ветку
Создание репозиториев
git init [project-name] — создать новый локальный репозиторий с заданным именем.
git clone [url] — загрузить проект и его полную историю изменений.
Работа с изменениями
git status — полный список изменений файлов, ожидающих коммита.
git diff — показать изменения в файлах, которые еще не были добавлены в индекс коммита (staged).
git add [file] — сделать указанный файл готовым для коммита.
git add ‘*.txt’ — добавить только файлы, соответствующие указанному выражению.
git diff HEAD — показать что изменилось с последнего коммита.
git diff HEAD^ — показать что изменилось с предпоследнего коммита.
git diff [branch] — сравнить текущую ветку с заданной.
git reset [file] — убрать файлы из индекса коммита (изменения не теряются).
git commit — записать изменения в репозиторий. для написания сообщения откроется назначенный редактор.
Работа с ветками
git branch — список всех локальных веток в текущей директории.
git branch [branch-name] — создать новую ветку.
git checkout [branch-name] — переключиться на указанную ветку и обновить рабочую директорию.
git checkout [filename] — вернуть файл в первоначальное состояние если он еще не был добавлен в индекс коммита.
git merge [branch] — соединить изменения в текущей ветке с изменениями из заданной.
Работа с файлами
git rm [file] — удалить файл из рабочей директории и добавить в индекс информацию об удалении.
git mv [file-original] [file-renamed] — изменить имя файла и добавить в индекс коммита.
Отслеживание файлов
.gitignore — текстовый файл, в котором задаются правила для исключения файлов из репозитория. Например:
Сохранение фрагментов
git stash — положить во временное хранилище все отслеживаемые файлы.
git stash pop — восстановить последние файлы, положенные во временное хранилище.
git stash list — список всех сохраненных изменений во временном хранилище.
git stash drop — удалить последние файлы, положенные во временное хранилище.
Просмотр истории
git log — список изменения текущей ветки.
git diff [file-branch]..[second-branch] — посмотреть различия между двумя заданными ветками.
git show [commit] — показать метадату и изменения в заданном коммите.
git show [branch]:[file] — посмотреть на файл в другой ветке, не переключаясь на неё.
Отмена коммитов
git reset — убрать изменения из индекса коммита, сами изменения останутся.
git reset [commit/tag] — отменить все коммиты после указанного коммита, изменения будут сохранены локально.
Синхронизация изменений
git fetch [bookmark] — загрузить всю историю с заданного удаленного репозитория.
git merge [bookmark]/[branch] — слить изменения локальной ветки и заданной удаленной.
git push — запушить текущую ветку в удаленную ветку.
git push [remote] [branch] — запушить ветку в указанный репозиторий и удаленную ветку.
git push [bookmark] :[branch] — в удаленном репозитории удалить заданную ветку.
git pull — загрузить историю и изменения удаленной ветки и произвести слияние с текущей веткой.
git pull [remote][branch] — указать конкретную удаленную ветку для слияния.
git remote — посмотреть список доступных удаленных репозиториев.
git remote add [remote][url] — добавить новый удаленный репозиторий.
Git branch
В этом документе подробно описывается команда git branch и рассматривается общая модель ветвления в Git. Возможность ветвления доступна в большинстве современных систем контроля версий. Однако эта операция в ряде систем может быть довольно затратной как по времени, так и по объему дискового пространства. В Git ветки — это элемент повседневного процесса разработки. По сути ветки в Git представляют собой указатель на снимок изменений. Если нужно добавить новую возможность или исправить ошибку (незначительную или серьезную), вы создаете новую ветку, в которой будут размещаться эти изменения. Объединить нестабильный код с основной базой кода становится сложнее, к тому же перед слиянием с основной веткой можно очистить историю работы над возможностью.
Git предлагает облегченную реализацию веток по сравнению с другими системами контроля версий. Вместо того чтобы копировать файлы из каталога в каталог, Git хранит ветку в виде ссылки на коммит. Получается, что ветка представляет собой вершину серии коммитов, а не контейнер для коммитов. История ветки распространяется через иерархические отношения с другими коммитами.
Во время чтения помните, что ветки в Git не похожи на ветки в SVN. Ветки в SVN используются только для фиксации периодических крупномасштабных наработок, а ветки в Git являются неотъемлемой частью повседневного рабочего процесса. Далее приводится более подробное описание внутренней архитектуры ветвления в Git.
Порядок действий
Ветка представляет собой отдельное направление разработки. Ветки выступают в качестве абстрактного представления для процесса редактирования/индексации/коммита. Можно рассматривать их как способ запросить новый рабочий каталог, раздел проиндексированных файлов и историю проекта. Новые коммиты записываются в историю текущей ветки, что приводит к образованию развилки в истории проекта.
Распространенные опции
Удаление указанной ветки. Это «безопасная» операция, поскольку Git не позволит удалить ветку, если в ней есть неслитые изменения.
Принудительное удаление указанной ветки, даже если в ней есть неслитые изменения. Эта команда используется, если вы хотите навсегда удалить все коммиты, связанные с определенным направлением разработки.
Вывод списка всех удаленных веток.
Создание веток
Важно понимать, что ветки — это просто указатели на коммиты. Когда вы создаете ветку, Git просто создает новый указатель. Репозиторий при этом никак не изменяется. Допустим, вы начинаете работать с репозиторием, который выглядит так:
Затем вы создаете новую ветку с помощью следующей команды.
История репозитория остается неизменной. Все, что вы получаете, — это новый указатель на текущий коммит:
Создание удаленных веток
До сих пор все эти примеры демонстрировали работу с локальными ветками. Команда git branch работает и с удаленными ветками. Для выполнения операций на удаленных ветках сначала необходимо настроить удаленный репозиторий и добавить его в конфигурацию локального репозитория.
Удаление веток
После того как вы завершите работу в ветке и сольете ее с основной базой кода, эту ветку можно будет удалить без потери истории:
Однако, если ветка не была слита, указанная выше команда выдаст сообщение об ошибке:
Эта команда удаляет ветку независимо от ее состояния и не выдает никаких предупреждений, поэтому используйте ее с осторожностью.
Предыдущие команды удаляют локальную копию ветки, но ветка может сохраниться в удаленных репозиториях. Для удаления ветки из удаленного репозитория выполните следующую команду.
Резюме
По сравнению с другими системами контроля версий, операции с ветками в Git являются экономичными и используются часто. Такая гибкость позволяет эффективно настроить рабочий процесс в Git. Дополнительную информацию о рабочих процессах в Git см. на наших страницах, где подробно обсуждаются: рабочий процесс с функциональными ветками, рабочий процесс Git-flow и рабочий процесс с форками.
Готовы попробовать ветвление?
Ознакомьтесь с этим интерактивным обучающим руководством.
rucreatizer/git
Latest commit
Git stats
Files
Failed to load latest commit information.
README.md
Шпаргалка по консольным командам Git
Создать новый репозиторий
Добавление файлов к отслеживанию, индексация отслеживаемых
Убирание файла, папки из отслеживания
Временно переключиться на другой коммит
Переключиться на другой коммит и продолжить работу с него
Потребуется создание новой ветки, начинающейся с указанного коммита.
Удаление файла (просто удалить отслеживаемый файл из папки недостаточно, нужно сделать его неотслеживаемым и отправить коммит)
Перемещение/переименование файлов (Git не отслеживает перемещения/переименование, но пытается его угадать)
Собираем коллекцию простых и сложных примеров работы
Создание нового репозитория, первый коммит, привязка удалённого репозитория с gthub.com, отправка изменений в удалённый репозиторий.
Обычный рабочий процесс
Создание нового репозитория на github.com, клонирование к себе, работа, периодическая «синхронизация с github.com».
Не обязательно после каждого коммита отправлять изменения в удаленный репозиторий, можно сделать это один раз в конце работы.
Внесение изменений в коммит
Есть master (публичная версия сайта), хотим масштабно что-то поменять (переверстать «шапку»), но по ходу работ возникает необходимость подправить критичный баг (неправильно указан контакт в «подвале»).
Работа с ветками, конфликт слияния
Есть master (публичная версия сайта), в двух параллельных ветках (branch_1 и branch_2) было отредактировано одно и то же место одного и того же файла, первую ветку (branch_1) влили в master, попытка влить вторую вызывает конфликт.
Синхронизация репозитория-форка с мастер-репозиторием
Есть некий репозиторий на github.com, он него нами был сделан форк, добавлены какие-то изменения. Оригинальный (мастер-) репозиторий был как-то обновлён. Задача: стянуть с мастер-репозитория изменения (которые там внесены уже после того, как мы его форкнули).
Ошибка в работе: закоммитили в мастер, но поняли, что нужно было коммитить в новую ветку (ВАЖНО: это сработает только если коммит еще не отправлен в удалённый репозиторий)
Нужно вернуть содержимое файла к состоянию, бывшему в каком-либо коммите (известна SHA коммита)
При любом действии с github (или другим удалённым сервисом) запрашивается логин/пароль
Речь именно о запросе пароля, а не ключевой фразы.
Ветвление Git с примерами из реальной жизни
Часто используемые ветки
Есть важное правило: вы не должны работать с этими ветками напрямую. Для любого изменения в программном проекте надо сначала создать новую ветвь, унаследовавшись от dev и дать ей имя, отражающее сделанное изменение.
Теперь перейдём к реальным примерам ветвления Git, встречающимся в повседневной жизни разработчиков программного обеспечения.
Настройка удалённых и локальных веток
Создание ветки на локальном репозитории
Для просмотра локального репозитория после добавления ветки dev в удалённый репозиторий, используется следующая команда:
Эта команда выведет в окно терминала локальные ветви.
Для просмотра удалённых веток применяется следующая команда:
Получение изменений из удалённого репозитория
Теперь dev появилась среди других веток, потому что с помощью git fetch извлекаются последние актуальные метаданные.
Чтобы извлечь и скопировать все изменения из удалённого репозитория, нужно использовать команду git pull :
Теперь информация о ветке верна. Чтобы просмотреть удалённые и локальные ветки, можно использовать уже известную команду с другим ключом:
Переключение между ветками
Как говорилось ранее, dev должна быть основной ветвью для разработки и все действия должны начинаться именно из неё.
CRUD операции с ветками
Создание ветви
Создадим новую ветвь из ветви dev :
Снова проверим локальные ветви:
Обновление имени ветки
Чтобы поменять имя существующей ветки, нет необходимости создавать всё сначала т. к. есть специальная команда:
Если вы находитесь в другой ветви, вы всё равно можете переименовать любую из них следующим образом:
Проверим правильность указанных имён:
Коммит ветки
Внесём изменения в файл README.md и проверим локальный репозиторий:
Перенесём файл в промежуточную область и сделаем коммит:
Отправка изменений на удалённый сервер
Теперь можно пушить коммит:
После отправки актуальной информации о ветке в удалённый репозиторий, нужно проверить, всё ли прошло корректно:
Удаление ветки
Если есть необходимость в удалении ветви, переходим в dev (или в любую ветку, которую нужно удалить) и выполняем удаление:
Видим, что my-new-branch очищена от всех локальных и удалённых репозиториев.
Проделаем всё сначала и создадим новую ветку, как «правильные ребята»:
Проверим состояние ветки:
Пушим результат на удалённый сервер:
Теперь предположим, что ваш коллега нашёл какой-то баг в коде, исправил его и создал копию данной ветки с другим именем: fix/my-killer-feature-bug-fix .
Слияние ветвей
Как обычно, сначала получаем актуальную информацию о репозитории:
Далее ищем ветку, над которой работал коллега:
Теперь можно сливать исправленную ветку с feature/my-killer-feature с помощью команды git merge (убедитесь, что находитесь в нужной ветви).
Проверяем конечный результат:
Заключение
Редакция Библиотеки Программиста надеется, что этот материал поможет вам узнать или укрепить знания о ветвлении в Git для ежедневного использования.
Если вам интересен Git, у нас для него есть специальный тег.
В этом теге наиболее близкие к этой статье следующие:
30 команд Git, необходимых для освоения интерфейса командной строки Git
Git — самая популярная в мире распределённая система контроля версий. Линус Торвальдс, разработчик ядра ОС Linux, создал этот инструмент ещё в 2005 году, а сегодня Git активно поддерживается как проект с открытым исходным кодом. Огромное количество открытых и коммерческих проектов используют Git для контроля версий.
В данной статье перечисляются самые основные команды, которые следует знать разработчику, чтобы освоить управление репозиториями GitHub на высоком уровне. Ознакомиться с ними будет полезно как новичкам, так и опытным разработчикам.
30 основных команд, которые сделают из вас мастера Git
1. Как задать имя пользователя и адрес электронной почты
Кроме того, командой git config можно изменять адрес электронной почты, привязанный к вашим коммитам Git. Новый адрес электронной почты будет автоматически отображаться во всех дальнейших коммитах, поданных на GitHub через командную строку.
2. Кэширование учётных данных
3. Инициализация репозитория
4. Добавление отдельных файлов или всех файлов в область подготовленных файлов
Добавить отдельный файл в область подготовленных файлов можно параметром add с указанием имени файла. Просто замените somefile.js на актуальное имя.
5. Проверка статуса репозитория
Просмотреть статус нужного репозитория можно по ключевому слову status : его действие распространяется на подготовленные, неподготовленные и неотслеживаемые файлы.
6. Внесение изменений однострочным сообщением или через редактор
Также можно открыть текстовый редактор в терминале для написания полного сообщения коммита. Оно может состоять из нескольких строк текста, в котором подробно характеризуются изменения, внесённые в репозиторий.
7. Просмотр истории коммитов с изменениями
8. Просмотр заданного коммита
Также можно использовать сокращённый хеш.
9. Просмотр изменений до коммита
Также можно указать имя файла как параметр и просмотреть изменения, внесённые только в этот файл.
10. Удаление отслеживаемых файлов из текущего рабочего дерева
Можно также использовать маски файлов (например *.js) для удаления всех файлов, соответствующих критерию.
11. Переименование файлов
При выполнении команды файл или папка, указанные как источник, будут перемещены в папку назначения. Индекс будет обновлён соответственно, но изменения нужно записать.
12. Отмена подготовленных и неподготовленных изменений
Если нужно выполнить это действие для всех подготовленных файлов, путь к ним указывать не надо.
13. Изменение последнего коммита
Внимание! Не изменяйте публичные коммиты.
С помощью amend прекрасно исправляются локальные коммиты, а исправления можно передать в общий репозиторий. Однако изменять коммиты, уже доступные другим пользователям, не следует. Помните, что изменённые коммиты являются совершенно новыми, а предыдущий коммит уже не будет доступен в текущей ветке. Последствия будут такими же, как при отмене изменений публичного снимка.
14. Откат последнего коммита
▍ Разница между revert и reset
У команды revert есть два крупных преимущества по сравнению с reset. Во-первых, она не меняет историю проекта и производит операцию, безопасную для коммитов. Во-вторых, её объектом выступает конкретный коммит, созданный в любой момент истории, а git reset всегда берёт за точку отсчёта текущий коммит. К примеру, если нужно отменить старый коммит с помощью git reset, придётся удалить все коммиты, поданные после целевого, а затем выполнить их повторно. Следовательно, команда git revert — гораздо более удобный и безопасный способ отмены изменений.
15. Откат заданного коммита
Откатить проект до заданного коммита можно с помощью параметра revert и идентификатора коммита. Создастся новый коммит — копия коммита с предоставленным идентификатором — и добавится к истории текущей ветки.
16. Создание новой ветки и переход в неё
17. Просмотр списка веток
18. Удаление ветки
Вышеуказанные команды удаляют только локальную копию ветки. В удалённом репозитории она может сохраниться. Если хотите стереть удалённую ветку, выполните следующую команду:
19. Слияние двух веток
Объединить две ветки можно параметром merge с указанием имени ветки. Команда объединит указанную ветку с основной.
Указанная команда объединит заданную ветку с основной и произведёт коммит слияния. Это необходимо для фиксации всех слияний в вашем репозитории.
20. Отображение журнала фиксации в виде графика для текущей или всех веток
21. Прекращение слияния при конфликте
22. Добавление удалённого репозитория
23. Просмотр удалённых URL-адресов
24. Получение дополнительных сведений об удалённом репозитории
Эта команда отображает список веток, связанных с удалённым репозиторием, а также рабочих станций, подключённых для получения и отправки файлов.
25. Отправка изменений в удалённый репозиторий
Отправлять изменения в удалённый репозиторий можно параметром push с указанием имени репозитория и ветки.
Эта команда передаёт локальные изменения в центральный репозиторий, где с ними могут ознакомиться другие участники проекта.
26. Получение изменений из удалённого репозитория
27. Слияние удалённого репозитория с локальным
Слияние удалённого репозитория с локальным выполняется параметром merge с указанием имени удалённого репозитория.
28. Отправка новой ветки в удалённый репозиторий
29. Удаление удалённой ветки
30. Использование перебазирования
Для доступа к этой функции используйте параметр rebase с указанием имени ветки. Перебазирование — это процесс объединения или перемещения последовательности коммитов на новый родительский снимок.
Эта команда изменит основу ветки с одного коммита на другой, как если бы вы начали ветку с другого коммита. В Git это достигается за счёт создания новых коммитов и применения их к указанному базовому коммиту. Необходимо понимать, что, хотя ветка и выглядит такой же, она состоит из совершенно новых коммитов.
▍ Спасибо за внимание!
Вы узнали 30 основных команд интерфейса командной строки Git. Теперь, при условии регулярной практики, у вас есть всё необходимое, чтобы достичь мастерства в управлении репозиториями GitHub.
Источники информации:
- http://techrocks.ru/2021/09/04/removing-local-or-remote-branch-in-git/
- http://smartiqa.ru/courses/git/lesson-3
- http://docs.gitlab.com/ee/user/project/repository/web_editor.html
- http://docs.gitlab.com/ee/gitlab-basics/start-using-git.html
- http://agladky.ru/blog/git-cheat-sheet/
- http://www.atlassian.com/ru/git/tutorials/using-branches
- http://github.com/rucreatizer/git
- http://proglib.io/p/vetvlenie-git-s-primerami-iz-realnoy-zhizni-2020-01-25
- http://habr.com/ru/company/ruvds/blog/599929/