Если используется аутентификация по паролю:
- $ git clone https://username:password@gitsrv/opt/git/repository.git
Работа с ветками
Показать все ветки:- $ git branch
- $
git branch
- $
git checkout
- $
git checkout -b
- $
git branch -d
- $
git push origin --delete
Работа с коммитами
Как удалить последний коммит?
- $ git reset --soft HEAD^
Git How To. Глава 17. Удаление коммиттов из ветки
Официальная документация Git. Основы Git - Отмена изменений
Как изменить последний коммит?
- $ git add new_file.txt
- $ git commit --amend
Как изменить комментарий к последнему коммиту?
- $ git commit --amend
- $ git commit --amend -m "Новый комментарий"
Как объединить несколько коммитов?
- $ git rebase -i HEAD~3
Откроется редактор со списком коммитов, вверху будет самый старый коммит.
- pick 1111111 Commit 1 comment
- pick 2222222 Commit 2 comment
- pick 3333333 Commit 3 comment
- pick 1111111 Commit 1 comment
- squash 2222222 Commit 2 comment
- squash 3333333 Commit 3 comment
Как отменить изменения в определенном файле и вернуть его в состояние, в котором он находился после последнего коммита?
- $ git checkout -- file.txt
Как отменить все незафиксированные (незакомиченные) изменения?
- $ git checkout
Как придержать некоторые файлы для следующего коммита?
Допустим, вы хотите закоммитить изменения в некоторых файлах, а изменения в других файлах зафиксировать в следующем коммите. Тогда можно временно удалить их из репозитория (unstage files), а потом снова добавить.- $ git reset HEAD file.txt
Если не удаётся сделать push на удаленный репозиторий из-за того, что текущая версия репозитория меньше, чем на удаленном репозитории
В этом случае можно сделать принудительный push.- $ git push -f origin master
Слияние веток
Как взять из другой ветки только некоторые файлы?
- $ git checkout branchname -- path/to/file.file
Удалённые репозитории
Вывод на экран информации об удалённом репозитории
- $ git remote show origin
- * remote origin
- Fetch URL: git@gitsrv:/opt/git/test-project.git
- Push URL: git@gitsrv:/opt/git/test-project.git
- HEAD branch: master
- Remote branch:
- master new (next fetch will store in remotes/origin)
- Local ref configured for "git push":
- master pushes to master (local out of date)
Добавление удалённого репозитория
- $ git remote add origin git@gitsrv:/opt/git/test-project.git
Удалённые ветки - это ссылки на состояние веток в ваших удалённых репозиториях. Это локальные ветки, которые нельзя перемещать; они двигаются автоматически всякий раз, когда вы осуществляете связь по сети. Удалённые ветки действуют как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.
В качестве источника ветви мы используем мастер-ветвь, она содержит последнюю версию. Чтобы начать работу немедленно, мы переключаемся на ветвь, активируя ветвь «Оформить заказ». На странице «Филиалы» отображается локальная ветвь. Полужирный шрифт и вывод в верхней части окна показывают, что наши файлы находятся на одном уровне.
Добавление удалённого репозитория
Теперь мы можем интегрировать новую функцию. Поэтому в разделе «Неотслеживаемые файлы» следует проверить, есть ли файлы, относящиеся к проекту. Появится сообщение с важной запиской о том, что изменения сохраняются только локально и все равно должны быть отправлены на сервер. Теперь пришло время предоставить остальной команде новую функцию. Наше местное отделение должно быть опубликовано. На странице «Филиалы» щелкните правой кнопкой мыши неопубликованную ветку, чтобы выбрать публикацию в контекстном меню.
Они выглядят как (имя удал. репоз.)/(ветка) . Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, проверьте ветку origin/master . Если вы с партнёром работали над одной проблемой, и он выложил ветку iss53 , у вас может быть своя локальная ветка iss53 ; но та ветка на сервере будет указывать на коммит в origin/iss53 .
Как разрешать конфликты слияния?
В ходе проверки кода новая функция должна быть передана основной ветке. Сначала выбираются ветвь источника и целевая ветвь. Теперь запрос может быть создан. Группа, выбранная в качестве аудиторов, получает уведомление и теперь может просматривать запрос на перенос. Комментарии могут быть обменены на запрос тянуть. Каждый экзаменатор может голосовать: одобрен, одобрен с аннотациями, отклонен и т.д. особенно важным является тот факт, что конфликтов слияния не возникает. Если представленные изменения не совместимы с принятым статусом сообщества, отправитель запроса на перенос обязан переписать его изменения.
Всё это, возможно, сбивает с толку, поэтому давайте рассмотрим пример. Скажем, у вас в сети есть свой Git-сервер на git.ourcompany.com . Если вы с него что-то склонируете (clone), Git автоматически назовёт его origin , заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка master , и назовёт его локально origin/master (но вы не можете его двигать). Git также сделает вам вашу собственную ветку master , которая будет начинаться там же, где и ветка master в origin, так что вам будет с чем работать (см. рис. 3-22).
В классических центральных системах контроля версий эта работа попадает в рецензент. После проверки аудитор может выполнить слияние непосредственно в браузере. Таким образом, вновь разработанная функция интегрирована. Локальный репозиторий еще не знает слияния в центральном репозитории. Кроме того, могут быть дополнительные коммиты, которые мы также хотим передать.
Файлы не изменены. Список этих коммитов для главного филиала теперь заполнен. Здесь может потребоваться сначала вытащить тяну за последними изменениями. Только тогда могут быть переданы коммиты. Выдающаяся кнопка синхронизации - нажатие и втягивание в одну. Он загружает все изменения с сервера и отправляет свое собственное сообщение.
Рисунок 3-22. Клонирование Git-проекта даёт вам собственную ветку master и origin/master, указывающий на ветку master в origin.
Если вы сделаете что-то в своей локальной ветке master , а тем временем кто-то ещё отправит (push) изменения на git.ourcompany.com и обновит там ветку master , то ваши истории продолжатся по-разному. Ещё, до тех пор, пока вы не свяжетесь с сервером origin, ваш указатель origin/master не будет сдвигаться (см. рис. 3-23).
В конце состояние состояния ведущей ветви теперь переходит в устойчивую ветвь. Для этого выполняется слияние. Из состояния стабильной ветви теперь может быть получен новый релиз. Вам не нужен логин, и вам не нужно регистрироваться нигде. В какой-то момент вам понадобится, когда вы будете работать над несколькими проектами.
Для этого выберите «инструменты → параметры». В следующем диалоговом окне введите нужное имя и адрес электронной почты, который вы хотите использовать для управления версиями. Эта информация хранится только локально и не используется нигде в Интернете.
Рисунок 3-23. При выполнении локальной работы и отправке кем-то изменений на удалённый сервер каждая история продолжается по-разному.
Для синхронизации вашей работы выполняется команда git fetch origin . Эта команда ищет, какому серверу соответствует origin (в нашем случае это git.ourcompany.com); извлекает оттуда все данные, которых у вас ещё нет, и обновляет ваше локальное хранилище данных; сдвигает указатель origin/master на новую позицию (см. рис. 3-24).
И создайте ровно один такой репозиторий сейчас, нажав «добавить». Теперь мы предполагаем, что вы уже начали свою магистерскую диссертацию и поместили ее в каталог под названием «Мастерарбейт». Укажите имена репозитория, которые должны совпадать с именем существующего каталога, и описание того, где находится каталог.
Как добавить пустую директорию в репозиторий?
Теперь вы увидите все файлы в своем каталоге в представлении, которые покажут вам все еще не синхронизированные изменения. В частности, вы теперь ищете, какие файлы вы хотите подвергнуть управлению версиями. Вы можете исключить типы файлов, чтобы не удалять тики из ненужных файлов, которые вы не хотите в репозитории, каждый раз. Выберите «инструменты → настройки».
Рисунок 3-24. Команда git fetch обновляет ваши удалённые ссылки.
Чтобы продемонстрировать то, как будут выглядеть удалённые ветки в ситуации с несколькими удалёнными серверами, предположим, что у вас есть ещё один внутренний Git-сервер, который используется для разработки только одной из ваших команд разработчиков. Этот сервер находится на git.team1.ourcompany.com . Вы можете добавить его в качестве новой удалённой ссылки на проект, над которым вы сейчас работаете с помощью команды git remote add так же, как было описано в главе 2. Дайте этому удалённому серверу имя teamone , которое будет сокращением для полного URL (см. рис. 3-25).
Продолжайте работать и вносите изменения
Вы должны добавить их в свой репозиторий. Чтобы убедиться, что вам не нужно настраивать это каждый раз, сделайте список глобально известным. Теперь выберите «инструменты → открыть оболочку здесь». В открывшемся окне командной строки введите следующую команду. Если вы хотите, вы можете также включить более подробное описание в поле «Расширенное описание». Вы добавляете дополнительные части, есть некоторые графические файлы или некоторые необработанные данные и заметки, которые вы хотели бы иметь версии.
Рисунок 3-25. Добавление дополнительного удалённого сервера.
Теперь можете выполнить git fetch teamone , чтобы извлечь всё, что есть на сервере и нет у вас. Так как в данный момент на этом сервере есть только часть данных, которые есть на сервере origin , Git не получает никаких данных, но выставляет удалённую ветку с именем teamone/master , которая указывает на тот же коммит, что и ветка master на сервере teamone (см. рис. 3-26).
Если не удаётся сделать push на удаленный репозиторий из-за того, что текущая версия репозитория меньше, чем на удаленном репозитории
Нажав на имя файла или галочку слева от него, выберите или отмените выборку для этого фиксации. Либо вы хотите зафиксировать определенные изменения в фиксации, либо не хотите использовать определенные файлы. Теперь вы видите все предыдущие коммиты вместе с их краткими описаниями, и поэтому они так важны.
При выборе в этом списке вы можете точно увидеть, что изменилось. Это создает новую фиксацию, которая отменяет ваши последние действия. Если вы хотите перейти к состоянию дальнейшего фиксации, выберите «откат к этому фиксации» с соответствующим фиксацией. Это изменит ваши файлы в каталоге, поэтому убедитесь, что вы перенесли все в репозиторий раньше, что вам может понадобиться!
Рисунок 3-26. У вас появилась локальная ссылка на ветку master на teamone-е.
Отправка изменений
Если у вас есть ветка serverfix , над которой вы хотите работать с кем-то ещё, вы можете отправить её точно так же, как вы отправляли вашу первую ветку. Выполните git push (удал. сервер) (ветка) :
Затем вам нужно «разветвить» то, что называется «ветвь» на жаргоне версий. Все в порядке, потому что позже Гит помогает воссоединить ветви. В этом диалоговом окне вы контролируете слияние ветвей. Если вы изменили что-то в разных ветвях в тех же местах, в тех же строках, конечно, конфликт в слиянии. Вы должны это исправить самостоятельно.
Однако в этом представлении вы можете видеть беспорядок, но не исправляете его. Измените соответствующие разделы в соответствии с вашими потребностями. Удалите маркировочные линии. Затем вы можете снова зафиксировать и указать «Ручное слияние» в качестве соответствующего комментария.
$ git push origin serverfix Counting objects: 20, done. Compressing objects: 100% (14/14), done. Writing objects: 100% (15/15), 1.74 KiB, done. Total 15 (delta 5), reused 0 (delta 0) To [email protected]:schacon/simplegit.git * serverfix -> serverfix
Это в некотором роде сокращение. Git автоматически разворачивает имя ветки serverfix до refs/heads/serverfix:refs/heads/serverfix , что означает “возьми мою локальную ветку serverfix и обнови из неё удалённую ветку serverfix”. Мы подробно обсудим часть с refs/heads/ в главе 9, но обычно её можно опустить. Вы также можете выполнить git push origin serverfix:serverfix - произойдёт то же самое - здесь говорится “возьми мой serverfix и сделай его удалённым serverfix”. Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы ветка называлась serverfix на удалённом сервере, то вместо предыдущей команды выполните git push origin serverfix:awesomebranch . Так ваша локальная ветка serverfix отправится в ветку awesomebranch удалённого проекта.
Давайте представим простой пример ветвления и слияния с рабочим процессом, который может быть представлен в реальности. Представьте, что вы выполняете следующие шаги.
- Вы работаете на веб-сайте.
- Вы создаете ветку для новой темы, над которой хотите работать.
- Вы делаете некоторую работу над этой веткой.
Основные процедуры ветвления
Представьте, что вы работаете над проектом, и у вас уже есть несколько подтверждений. Запись простых и коротких подтверждений. Вы решили работать с проблемой № 53 в системе, которую ваша компания использует для отслеживания проблем. Поскольку проблема № 53 является конкретной и своевременной проблемой, в которой вы собираетесь работать, вы создаете для него новую ветку. На рисунке 3-11 показан результат.
$ git fetch origin remote: Counting objects: 20, done. remote: Compressing objects: 100% (14/14), done. remote: Total 15 (delta 5), reused 0 (delta 0) Unpacking objects: 100% (15/15), done. From [email protected]:schacon/simplegit * serverfix -> origin/serverfix
Важно отметить, что когда при получении данных у вас появляются новые удалённые ветки, вы не получаете автоматически для них локальных редактируемых копий. Другими словами, в нашем случае вы не получите новую ветку serverfix - только указатель origin/serverfix , который вы не можете менять.
Создайте указатель на новую ветку. Вы работаете на веб-сайте и делаете некоторые подтверждения изменений. Затем вы получаете звонок, уведомляющий вас о другой неотложной проблеме на веб-сайте. Проблема, которую вы должны решить немедленно. Лучше всегда иметь чистое и чистое рабочее состояние, прежде чем прыгать между ветвями. И для этого у нас есть некоторые процедуры, которые мы увидим позже.
Пока, поскольку мы подтвердили все изменения, мы можем без проблем перейти к мастер-ветке. После этого у вас будет рабочая папка точно так же, как это было до того, как вы начали работу над проблемой. # И вы сможете сосредоточиться на новой неотложной проблеме. Чтобы убедиться, что ваша рабочая копия точно такая же, как и ветка, в последнем подтверждении внесенных изменений. Возвращение к неотложной проблеме. Мы создадим новую ветку исправлений, на которой будет работать до разрешения.
Чтобы слить эти наработки в свою текущую рабочую ветку, выполните git merge origin/serverfix . Если вам нужна своя собственная ветка serverfix , над которой вы сможете работать, то вы можете создать её на основе удалённой ветки:
$ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. Switched to a new branch "serverfix"
Это даст вам локальную ветку, на которой можно работать. Она будет начинаться там, где и origin/serverfix .
Удаление веток на удалённом сервере
Рисунок 3 - ветвь исправления, основанная на исходной главной ветви. Вы можете выполнить тесты, убедиться, что решение верное, и включить изменения в ведущую ветвь, чтобы привести их в действие. Это то, что называется «быстрая перемотка вперед». Теперь сделанные изменения уже находятся в снимке подтверждения, отмеченном главной ветвью. И вы можете развернуть их.
После слияния главная ветвь указывает на тот же сайт, что и ветвь исправления. Решив неотложную проблему, которая прервала вашу работу, вы можете вернуться туда, где вы были. Но прежде, интересно удалить ветвь исправления. Поскольку нам это больше не понадобится, поскольку оно указывает точно на тот же сайт, что и главная ветвь.
Отслеживание веток
Получение локальной ветки с помощью git checkout из удалённой ветки автоматически создаёт то, что называется отслеживаемой веткой . Отслеживаемые ветки - это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на отслеживаемой ветке, вы наберёте git push , Git уже будет знать, на какой сервер и в какую ветку отправлять изменения. Аналогично выполнение git pull на одной из таких веток сначала получает все удалённые ссылки, а затем автоматически делает слияние с соответствующей удалённой веткой.
Основные процедуры плавления
И с этим вы готовы вернуться к работе над проблемой № 53. Предположим, что ваша работа с проблемой № 53 уже завершена и готова к объединению с главной ветвью. Он несколько отличается от ранее выполненного слияния с исправлением. В этом случае запись о развитии расходилась в более ранней точке.
Основные конфликты, которые могут возникнуть при слияниях
Мы рассматриваем этот процесс как «подтвержденное слияние». И это отличается тем, что у него более одного отца. Стоит отметить тот факт, что именно Гит сам автоматически определяет лучшего общего предка для слияния. И вручную закройте проблему в системе отслеживания проблем вашей компании. В некоторых случаях процессы слияния обычно не являются текучими. Например, если в задаче № 53 вы изменили ту же часть, которая также была изменена в проблеме с исправлением.
При клонировании репозитория, как правило, автоматически создаётся ветка master , которая отслеживает origin/master , поэтому git push и git pull работают для этой ветки "из коробки" и не требуют дополнительных аргументов. Однако, вы можете настроить отслеживание и других веток удалённого репозитория. Простой пример, как это сделать, вы увидели только что - git checkout -b [ветка] [удал. сервер]/[ветка] . Если вы используете Git версии 1.6.2 или более позднюю, можете также воспользоваться сокращением --track:
Вы можете получить конфликт слияния, чтобы. Скорее, он останавливается в этом процессе, ожидая разрешения конфликта. Все, что противоречит и не может быть разрешено, обозначается как «не слияние». Закладки, которые помогут вам, когда вы вручную открываете файлы и редактируете их, чтобы исправить их.
Отменить все изменения, кроме тех, что уже добавлены в планируемый коммит
Конфликтный файл будет содержать. Чтобы разрешить конфликт, вы должны вручную выбрать контент с той или иной стороны. Например, вы можете изменить блок, оставив его таким, чтобы. Эта коррекция содержит немного обеих частей. Это запустит соответствующий инструмент визуализации и позволит вам разрешить конфликты с ним. Если вы хотите использовать инструмент, отличный от выбранного по умолчанию, вы можете выбрать его из списка поддерживаемых инструментов, показанных в начале. Введите имя инструмента.
$ git checkout --track origin/serverfix Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. Switched to a new branch "serverfix"
Чтобы настроить локальную ветку с именем, отличным от имени удалённой ветки, вы можете легко использовать первую версию с другим именем локальной ветки:
$ git checkout -b sf origin/serverfix Branch sf set up to track remote branch refs/remotes/origin/serverfix. Switched to a new branch "sf"
Теперь ваша локальная ветка sf будет автоматически отправлять (push) и получать (pull) изменения из origin/serverfix.
Удаление веток на удалённом сервере
Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку master на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере, используя несколько бестолковый синтаксис git push [удал. сервер] :[ветка] . Чтобы удалить ветку serverfix на сервере, выполните следующее:
$ git push origin:serverfix To [email protected]:schacon/simplegit.git - serverfix
Хлоп. Нет больше ветки на вашем сервере. Вам может захотеться сделать закладку на текущей странице, так как эта команда вам понадобится, а синтаксис вы, скорее всего, забудете. Можно запомнить эту команду вернувшись к синтаксису git push [удал. сервер] [лок. ветка]:[удал. ветка] , который мы рассматривали немного раньше. Опуская часть [лок. ветка] , вы, по сути, говорите “возьми ничто в моём репозитории и сделай так, чтобы в [удал. ветка] было то же самое”.
