Что такое git и для чего он используется

Содержание:

Работа со своим первым репозиорием Git

Доступ получен, исходники в Вашем распоряжении. Теперь переключаемся на работу с TortoiseGit. Для порядка, каждую из операций, которые мы будем сейчас выполнять я буду также записывать в виде консольной команды – лишним знание работы с консолью никогда не будут.

Итак, выбираем директорию на жестком диске где мы будем хранить все файлы. Далее действуем следующим образом:

1. Вызываем контекстное меню и выбираем пункт “TortoiseGit — Settings“:

В появившемся окне переходим сразу к пункту “Git – Config” и записываем свое имя и адрес электронной почты. Эти данные должны в точности совпадать с теми, что записаны в Вашем аккаунте на github, иначе ваш ключ просто не подойдет.

2. Клонируем репозиторий. Для этого заходим на страницу проекта, и копируем в буфер адрес:

Теперь жмем правой кнопкой мыши на директории, в которой будем хранить исходники и в меню выбираем “Git Clone..“:

В открывшемся окне в поле URL вставляем скопированный адрес и жмем “Ok”:

Начнется процесс клонирования репозитория.

Всё вышесказанное можно было бы заменить всего двумя командами в консоли:

После клонирования репозитория Вы автоматически переключитесь на нашу главную ветку (master). Так как каждый из нас занят определенной работой в проекте, то у каждого своя ветвь в репозитории, поэтому и Вам придется создавать свой branch. Делается это достаточно просто.

3. Создаем свою ветку. Для этого жмем правую кнопку мыши на директории в которую мы клонировали репозиторий и выбираем в меню “TortoiseGit — Create Branch“:

В открывшемся оке задаем название новой ветки и указываем на основании какой ветки репозитория мы будем создавать новую. Жмем “Ок”, подтверждая создание ветки. Теперь переключаемся на свой новый branch.

Выбираем в меню “TortoiseGit – Switch/Checkout…“:

В открывшемся окне выбираем нашу новую ветку и жмем “Ок”. Убеждаемся, что мы успешно переключились:

По сути, все что касалось создания нового branch’a в консоли решилось бы всего одной командой:

4. Программируем. Теперь, когда мы все настроили – открываем необходимый проект в Delphi, вносим свои коррективы, изменяем модули и т.д. В общем ведем нормальную плодотворную работу с проектом.

5. Вносим изменения в репозиторий. После того как внесены какие-то изменения нам необходимо их закрепить в Git. И здесь опять же проявляется отличие этой системы контроля версий от того же SVN. Дело в том, что Commit в Git не сбрасывается сразу на сервер. Для того, чтобы внести изменения в удаленный репозиторий используется команда PUSH. В общем виде работа может быть построена следующим образом:

1. Вносятся изменения в проект

2. Изменения закрепляются в вашем локальном репозитории, используя команду Commit в меню или, используя консоль:

3. Когда Вам необходимо/удобно/требуется закрепить все изменения на сервере выполняем push в свою ветку (brunch). Команда консоли выглядит так:

Здесь стоит, наверное рассмотреть весь процесс на деле. К примеру, мы решили добавить в проект простой текстовый файл с описанием чего либо. Создаем файл, записываем в него данные и добавляем файл в индекс.

Для этого выбираем новый файл, вызываем меню и выбираем “Add…”:

По рисунку можно видеть, что я вношу в индекс новый файл text.txt. Жмем “Ok”.

После того как файл добавлен, можно сразу же сделать Commit – кнопка Commit появится в окне с выводом консоли. Жмем её и откроется окно для внесения Commit’a:

Заполняем поле с описанием, жмем “Ок”  и коммит готов. Если хотите сразу отправить эти изменения в репозиторий, то в окне с выводом консоли появится также кнопка PUSH. Если же Вас не устраивает таскать по 1 файлику туда-сюда или изменения столь незначительны, что их нет смысла отправлять на сервер, то просто продолжаете дальше кодить, а push выполним позднее.

Чтобы выполнить команду push можете поступить следующим образом:

1. Зажимаем Shift и вызываем контекстное меню. В меню должны появится дополнительные команды:

Выбираем команду Push. Перед Вами откроется окно следующего содержания:

Все, что от Вас требуется на данном этапе – нажать на кнопку (на рисунке она выделена красным) найти в списке удаленную ветку в которую вы делаете push и два раза нажать Ok. Все изменения, произведенные Вами в локальном репозитории отправятся в Сеть.

Small and Fast

Git is fast. With Git, nearly all operations are performed locally, giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere.

Git was built to work on the Linux kernel, meaning that it has had to effectively handle large repositories from day one. Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Speed and performance has been a primary design goal of Git from the start.

Benchmarks

Let’s see how common operations stack up against
Subversion, a common centralized version control system that is similar
to CVS or Perforce. Smaller is faster.

For testing, large AWS instances were set up in the same availability zone.
Git and SVN were installed on both machines, the Ruby repository was copied to
both Git and SVN servers, and common operations were performed on both.

In some cases, the commands don’t match up exactly. Here, matching on the lowest
common denominator was attempted. For example, the ‘commit’ tests also include
the time to push for Git, though most of the time you would not actually be pushing
to the server immediately after a commit where the two commands cannot be separated
in SVN.

All of these times are in seconds.

Operation Git SVN
Commit Files (A) Add, commit and push 113 modified files (2164+, 2259-) 0.64 2.60 4x
Commit Images (B) Add, commit and push a thousand 1 kB images 1.53 24.70 16x
Diff Current Diff 187 changed files (1664+, 4859-) against last commit 0.25 1.09 4x
Diff Recent Diff against 4 commits back (269 changed/3609+,6898-) 0.25 3.99 16x
Diff Tags Diff two tags against each other (v1.9.1.0/v1.9.3.0) 1.17 83.57 71x
Log (50) Log of the last 50 commits (19 kB of output) 0.01 0.38 31x
Log (All) Log of all commits (26,056 commits – 9.4 MB of output) 0.52 169.20 325x
Log (File) Log of the history of a single file (array.c – 483 revs) 0.60 82.84 138x
Update Pull of Commit A scenario (113 files changed, 2164+, 2259-) 0.90 2.82 3x
Blame Line annotation of a single file (array.c) 1.91 3.04 1x

Note that this is the best case scenario for SVN—a server with no load with a
gigabit connection to the client machine. Nearly all of these
times would be even worse for SVN if that connection was slower, while
many of the Git times would not be affected.

Clearly, in many of these common version control operations, Git is
one or two orders of magnitude faster than SVN, even under ideal conditions
for SVN.

One place where Git is slower is in the initial clone operation.
Here, Git is downloading the entire history rather than only the latest
version. As seen in the above charts, it’s not considerably slower for an operation
that is only performed once.

Operation Git* Git SVN
Clone Clone and shallow clone(*) in Git vs checkout in SVN 21.0 107.5 14.0
Size (MB) Size of total client side data and files after clone/checkout (in MB) 181.0 132.0

It’s also interesting to note that the size of the data on the client side
is very similar even though Git also has every version of every file for the
entire history of the project. This illustrates how efficient it is at compressing
and storing data on the client side.

Step 2: Add a new file to the repo

Go ahead and add a new file to the project, using any text editor you like or running a touch command. `touch newfile.txt` just creates and saves a blank file named newfile.txt. 

Once you’ve added or modified files in a folder containing a git repo, git will notice that  the file exists inside the repo. But, git won’t track the file unless you explicitly tell it to. Git only saves/manages changes to files that it tracks, so we’ll need to send a command to confirm that yes, we want git to track our new file.

After creating the new file, you can use the git status command to see which files git knows exist.

What this basically says is, «Hey, we noticed you created a new file called mnelson.txt, but unless you use the ‘git add’ command we aren’t going to do anything with it.»

Distributed

One of the nicest features of any Distributed SCM, Git included, is that it’s distributed. This means that instead of doing a «checkout» of the current tip of the source code, you do a «clone» of the entire repository.

Multiple Backups

This means that even if you’re using a centralized workflow, every user essentially has a full backup of the main server. Each of these copies could be pushed up to replace the main server in the event of a crash or corruption. In effect, there is no single point of failure with Git unless there is only a single copy of the repository.

Any Workflow

Because of Git’s distributed nature and superb branching system, an almost endless number of workflows can be implemented with relative ease.

Subversion-Style Workflow

A centralized workflow is very common, especially from people transitioning from a centralized system. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

Integration Manager Workflow

Another common Git workflow involves an integration manager — a single person who commits to the ‘blessed’ repository. A number of developers then clone from that repository, push to their own independent repositories, and ask the integrator to pull in their changes. This is the type of development model often seen with open source or GitHub repositories.

Dictator and Lieutenants Workflow

For more massive projects, a development workflow like that of the Linux kernel is often effective.
In this model, some people (‘lieutenants’) are in charge of a specific subsystem of the project and they merge in all changes related to that subsystem. Another integrator (the ‘dictator’) can pull changes from only his/her lieutenants and then push to the ‘blessed’ repository that everyone then clones from again.

Staging Area

Unlike the other systems, Git has something called the «staging area» or «index». This is an intermediate area where commits can be formatted and reviewed before completing the commit.

One thing that sets Git apart from other tools is that it’s possible to quickly stage some of your files and commit them without committing all of the other modified files in your working directory or having to list them on the command line during the commit.

This allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as needed.

Of course, Git also makes it easy to ignore this feature if you don’t want that kind of control — just add a ‘-a’ to your commit command in order to add all changes to all files to the staging area.

Установка Git

Прежде чем использовать Git, вы должны установить его на своём компьютере.
Даже если он уже установлен, наверное, это хороший повод, чтобы обновиться до последней версии.
Вы можете установить Git из собранного пакета или другого установщика, либо скачать исходный код и скомпилировать его самостоятельно.

Примечание

В этой книге используется Git версии 2.8.0.
Хотя большинство используемых нами команд должны работать даже в старых версиях Git, некоторые из них могут не работать или действовать немного иначе, если вы используете старую версию.
Поскольку Git отлично справляется с сохранением обратной совместимости, любая версия после 2.8 должна работать нормально.

Установка в Linux

Если вы хотите установить Git под Linux как бинарный пакет, это можно сделать, используя обычный менеджер пакетов вашего дистрибутива.
Если у вас Fedora (или другой похожий дистрибутив, такой как RHEL или CentOS), можно воспользоваться :

Если же у вас дистрибутив, основанный на Debian, например, Ubuntu, попробуйте :

Чтобы воспользоваться дополнительными возможностями, посмотрите инструкцию по установке для нескольких различных разновидностей Unix на сайте Git https://git-scm.com/download/linux.

Установка на Mac

Существует несколько способов установки Git на Mac.
Самый простой — установить Xcode Command Line Tools.
В версии Mavericks (10.9) и выше вы можете добиться этого просто первый раз выполнив ‘git’ в терминале.

Если Git не установлен, вам будет предложено его установить.

Если Вы хотите получить более актуальную версию, то можете воспользоваться бинарным установщиком.
Установщик Git для OS X доступен для скачивания с сайта Git https://git-scm.com/download/mac.


Рисунок 7. OS X инсталлятор Git

Установка в Windows

Для установки Git в Windows также имеется несколько способов.
Официальная сборка доступна для скачивания на официальном сайте Git.
Просто перейдите на страницу https://git-scm.com/download/win, и загрузка запустится автоматически.
Обратите внимание, что это отдельный проект, называемый Git для Windows; для получения дополнительной информации о нём перейдите на https://gitforwindows.org. Для автоматической установки вы можете использовать пакет Git Chocolatey.
Обратите внимание, что пакет Chocolatey поддерживается сообществом

Для автоматической установки вы можете использовать пакет Git Chocolatey.
Обратите внимание, что пакет Chocolatey поддерживается сообществом

Установка из исходников

Многие предпочитают устанавливать Git из исходников, поскольку такой способ позволяет получить самую свежую версию.
Обновление бинарных инсталляторов, как правило, немного отстаёт, хотя в последнее время разница не столь существенна.

Если вы действительно хотите установить Git из исходников, у вас должны быть установлены следующие библиотеки, от которых он зависит: autotools, curl, zlib, openssl, expat, and libiconv.
Например, если в вашей системе используется (Fedora) или (системы на базе Debian), вы можете использовать одну из следующих команд для установки всех зависимостей, используемых для сборки и установки бинарных файлов Git:

Для того, чтобы собрать документацию в различных форматах (doc, html, info), понадобится установить дополнительные зависимости:

Примечание

Пользователи RHEL и производных от неё (таких как CentOS или Scientific Linux) должны для корректной установки пакета

Если вы используете систему на базе Debian (Debian/Ubuntu/Ubuntu-производные), вам так же понадобится установить пакет :

Если вы используете систему на базе RPM (Fedora/RHEL/RHEL-производные), вам так же понадобится установить пакет , который уже установлен в системах на базе Debian:

К тому же из-за различий имён бинарных файлов вам понадобится сделать следующее:

Когда все необходимые зависимости установлены, вы можете пойти дальше и скачать самый свежий архив с исходниками из следующих мест:
с сайта Kernel.org https://www.kernel.org/pub/software/scm/git, или зеркала на сайте GitHub https://github.com/git/git/releases.
Конечно, немного проще скачать последнюю версию с сайта GitHub, но на странице kernel.org релизы имеют подписи, если вы хотите проверить, что скачиваете.

Затем скомпилируйте и установите:

После этого вы можете получать обновления Git посредством самого Git:

prev | next

Ummmmm … что? Могу ли я сделать это на сайте?

Вы можете!

GIF черезGIPHY

Один из способов сделать это — просто проверить кнопку, о которой мы упоминали ранее, когда редактировали файл README. Супер просто!

Вы также можете в любое время создать новую ветку прямо на веб-сайте, перейдя в свой репозиторий, щелкнув раскрывающееся меню в левой и средней части экрана с надписью «Branch: master», введя имя ветви и выбрав Ссылка «Создать ветку» (или нажмите Enter на клавиатуре). Теперь у вас есть две ветви, которые выглядят одинаково! Это отличное место для внесения изменений и их тестирования, прежде чем вы захотите, чтобы они повлияли на основную ветку.


Создание ветки

Если вы работаете с отдельной веткой, ваши изменения влияют только на эту ветку.

Если вы довольны своими изменениями и хотите объединить их с главной веткой, вы можете открытьтянуть запрос, Таким образом, если бы вы были в команде, вы бы предложили свои изменения и попросили бы кого-нибудь рассмотреть их или включить ваш вклад и объединить их в свою ветку.

Вы можете открыть запрос на удаление, как только сделаете коммит, даже если вы еще не закончили свой код. Вы можете сделать это прямо на сайте, если вам удобнее. Если вы внесли некоторые изменения в свою ветку и хотите объединить их, вы можете

  • Нажмите вкладку запроса на извлечение рядом с верхним центром экрана.
  • Нажмите зеленую кнопку «Новый запрос на извлечение»
  • Перейдите в поле «Примеры сравнений» и выберите ветку, которую вы сделали, чтобы сравнить с исходной веткой.
  • Посмотрите свои изменения, чтобы убедиться, что они действительно то, что вы хотите зафиксировать.
  • Затем нажмите большую зеленую кнопку «Создать запрос на извлечение». Дайте ему название и напишите краткое описание ваших изменений. Затем нажмите «Создать запрос на извлечение!»


Новый запрос на извлечение
Создать пул-запрос

Теперь, если это ваш репозиторий, вы можете объединить ваш запрос на извлечение, нажав зеленую кнопку «Слить запрос на извлечение», чтобы объединить изменения в мастер. Нажмите «Подтвердить слияние», затем удалите ветвь после того, как ваша ветвь была включена с помощью кнопки «Удалить ветвь» в фиолетовом поле.

Если вы участвуете в проекте, у людей в команде (или у рецензента) могут возникнуть вопросы или комментарии. Если вам нужно что-то изменить, это время! Если все хорошо, они могут развернуть изменения прямо из ветки для окончательного тестирования перед тем, как объединить их. И вы можете развернуть свои изменения, чтобы проверить их в производстве.

Если ваши изменения были проверены, вы можете пойти дальше и объединить ваш код в основную ветку. Пул-запросы сохранят запись ваших изменений, а это значит, что вы можете просмотреть их в любое время, чтобы понять изменения и принятые решения.

Теперь пришло время добавить несколько файлов в ваш проект!

фотоНадим МеррихнаUnsplash

Это все, что мы собираемся сделать:

git statusgit addgit commit -m " "git push

Не о чем беспокоиться!

Я думаю, у вас, вероятно, есть файлы, которые вы хотите поместить в свой новый репозиторий. Идите вперед, найдите ваши файлы и перетащите их в новую папку для репозитория, который вы создали на своем рабочем столе, так же, как вы это обычно делаете с любым набором файлов, которые вы, возможно, захотите переместить в папку.

Теперь проверьтеположение делвашего проекта!

Зайдите в свой терминал и зайдите в папку для своего хранилища. Тогда беги

git status

чтобы увидеть, все ли в курсе. (Если вы просто перетащили некоторые файлы в папку вашего проекта, это определенно не так!) Чтобы добавить один из ваших файлов в хранилище, вы должны запустить

git add <fileneame>

В противном случае вы можете добавить все с

git add --all

или даже

git add .

Это ваши предложенные изменения. Вы можете сделать то же самое с совершенно новыми файлами и с файлами, которые уже есть, но имеют некоторые изменения. Вы на самом деле еще ничего не добавляете. Вы предлагаете Git новые файлы и изменения.

Чтобы зафиксировать изменения, вы запустите процесс, запустив

git commit -m “<commit message>”

Вы вносите изменения в HEAD, но не в удаленный репозиторий. (Убедитесь, что вы заменяете это сообщение в кавычках своим ) После внесения изменений вы делаете «снимок» хранилища с помощью команды «commit». В этот «снимок» вы включите сообщение с -m.

Когда вы сохраняете изменения, это называется фиксацией. Когда вы делаете коммит, вы добавляете сообщение о том, что вы изменили и / или почему вы его изменили. Это отличный способ рассказать другим, что вы изменили и почему.

Теперь ваши изменения находятся в заголовке вашей локальной рабочей копии. Чтобы отправить изменения в удаленный репозиторий, запустите

git push

вставить ваши изменения прямо в ваш репозиторий. Если вы работаете на своем локальном компьютере и хотите, чтобы ваши коммиты также были видны в сети, вы должны передать изменения в git hub с помощью команды git push.

Вы можете увидеть, все ли обновлено в любое время, запустивкоманда!

Итак, теперь у вас есть репозиторий GitHub, и вы знаете, как добавлять файлы и вносить в него изменения!

Поздравляем !!!

Легкий тег

Как только вы достигнете определенного этапа в написании проекта, вы захотите отметить его, чтобы в случае чего вернуться к нему позднее. Вы можете делать релизы и частое версионирование вашего проекта. Это называется легкий тег в Git. Тег представляет собой статический снимок хранилища в данный конкретный момент времени, на который ссылается имя. Есть два типа тегов. Один из них — легкий, метка для указателя в вашей истории коммитов, другой — это аннотированный тег, который содержит больше информации, включая информацию о том, кто был первым создателем этого тега, дату создания и короткое сообщение с аннотацией.

Чтобы назначить легкий тег для текущей ревизии, в командной строке выполните:

$ git tag release-1.0.0.0

Это имя нашего тега с параметром release-1.0.0.0.

Чтобы создать новый аннотированный тег, мы просто добавляем флаг -a и флаг -m, чтобы применить короткую аннотацию:

$ git tag -a release-1.0.0.0 -m "First full public release"

Чтобы просмотреть все наши теги в хранилище, мы запускаем:

$ git tag

Если вы хотите просмотреть больше информации о конкретном теге, используйте с параметром :

$ git show release-1.0.0.0

Это покажет полную информацию об этом конкретном теге, включая имя пользователя, дату создания и аннотацию.

Продвинутое использование: интерактивная подготовка

Вы можете с удобством управлять областью подготовленных файлов (например при фиксации нескольких небольших коммитов вместо одного большого) с помощью интерактивной консоли, которую можно запустить . В ней доступны 8 команд:

  •  — показывает для каждого файла краткое описание того, что (не)подготовлено;
  •  — подготавливает отслеживаемые файлы;
  •  — убрать один или несколько файлов из подготовленной области;
  •  — подготавливает неотслеживаемый файл;
  •  — подготавливает только часть файла (полезно, когда вы, например, изменили несколько функций, но хотите разбить изменения на несколько коммитов). После выбора файла вам будут показаны его фрагменты и представлены возможные команды: . Можно ввести , чтобы узнать, что делает каждая команда;
  •  — показывает список подготовленных файлов и позволяет посмотреть изменения для каждого из них;
  •  — выходит из интерактивной консоли;
  •  — показывает краткое описание каждой команды.

Символ  рядом с файлом означает, что команда изменит его статус (подготовлен/неподготовлен в зависимости от того, происходит ли обновление или откат). Если нажать Enter, не введя ничего ни в одном из под-меню команды, то все файлы перейдут в (не)подготовленное состояние.

Обратите внимание, что создание патчей (подготовка только части файла) доступно не только в интерактивной консоли, но и через команду 

Что такое Git?

Git – это три сервиса в одном. Целый комплекс программных решений, используемых в различных сферах деятельности для отслеживания итераций разрабатываемого продукта. 

Чаще всего Git используется в разработке приложений и сайтов, но он также находит применение и в других сферах, например в переводах книг. 

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

Система контроля

Под системой контроля в контексте Git подразумевается программный механизм для работы с контентом. В «работу» также входит хранение, передача данных, отслеживание изменений и прочие аспекты.

Система контроля версий

Как я уже отмечал выше, обычно Git используют для работы с программным кодом. Кодеры ведут разработку своих продуктов, используя систему контроля версий, чтобы иметь полный контроль над своим детищем, над каждой его версией и вариацией. 

То есть в любой момент времени можно вернуться в прошлое и восстановить предыдущую версию программы, если новый релиз все поломал. Или когда срочно нужно посмотреть, как выглядел код до рефакторинга. 

И это касается не только кода. Переводы больших книг, дизайнерские работы, рисунки и прочее. Правилам работы в системе контроля версий можно подчинить почти любой продукт, и везде от этого будет только польза. 

Распределенная система контроля версий

Также Git позволяет вести параллельную разработку, когда несколько программистов одновременно вносят изменения в одно приложение или сайт, но при этом не мешают друг другу и спокойно дополняют продукт, не вызывая сбоев в работе сервиса/сайта/приложения, которое использует их клиент. 

Для этого используются удаленные файловые хранилища, где лежат различные вариации кода. Например:

  • основное приложение со всеми нужными функциями,

  • его версия с новым дизайном,

  • новая версия с дополнительными возможностями. 

И пока основное приложение остается нетронутым, две его вариации активно развиваются, пока не станут частью основы. Впрочем, этот аспект Git мы еще разберем более подробно. 

Основы работы с удаленным репозиторием¶

git clone — создание копии (удаленного) репозитория

Для начала работы с центральным репозиторием, следует создать копию оригинального проекта со всей его историей локально.

Клонируем репозиторий, используя протокол http:

git clone http://user@somehost:port/~user/repository/project.git

Клонируем репозиторий с той же машины в директорию :

git clone /home/username/project myrepo

Клонируем репозиторий, используя безопасный протокол ssh:

git clone ssh://user@somehost:port/~user/repository

У git имеется и собственный протокол:

git clone git://user@somehost:port/~user/repository/project.git/

Импортируем svn репозиторий, используя протокол http:

git svn clone -s http://repo/location

-s

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитория.

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

git remote add username-project /home/username/project

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

Естественно, что после оценки изменений, например, командой , надо создать коммит слияния с основной:

git merge username-project/master

Команда сразу забирает изменения и проводит слияние с активной веткой.

Забрать из репозитория, для которого были созданы удаленные ветки по умолчанию:

git pull

Забрать изменения и метки из определенного репозитория:

git pull username-project --tags

Как правило, используется сразу команда .

git push — вносим изменения в удаленный репозиторий

После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.

Отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию:

git push

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

git push ssh://yourserver.com/~you/proj.git master:experimental

В удаленном репозитории origin удалить ветку experimental:

git push origin :experimental

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

git push origin master:master

Отправить метки в удаленную ветку master репозитория origin:

git push origin master --tags

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

git push origin origin/develop:master

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

git push origin origin/develop:refs/heads/test

Качаем и устанавливаем софт

  1. msysgit – качаем Git For Windows
  2. TortoiseGit. На момент написания статьи последней была версия (19.6 MB). Новые версии Вы можете найти также по приведенной ссылке.

Получается, что скачать нам надо чуть больше 30 Mb.
Теперь устанавливаем скачанные программы.

Вначале ставим msysgit, а потом TortoiseGit.

При установке msysgit настройки по умолчанию можно не изменять.
При установке TortoiseGit выбираем в окне “Choose SSH Client” второе значение:
После успешной установки обоих продуктов работу над первым этапом можно считать завершенной. Приступим ко второму – получение доступа к репозиторию Git.

Git можно установить на Windows и в WSL

важное замечание: при включении WSL и установке дистрибутива Linux устанавливается новая файловая система, отделенная от Windows NTFS C:\. диск на компьютере

В Linux буквы дисков не задаются. Они получают точки подключения. Корневой каталог файловой системы — это точка подключения корневого раздела или папки в случае с WSL. Не все в разделе — это один и тот же диск. Например, на моем ноутбуке я установил две версии Ubuntu (20,04 и 18,04), а также Debian. при открытии этих дистрибутивов выберите корневой каталог с командой , а затем введите команду , Windows откроется проводник, и отобразится путь к каталогу для этого дистрибутива.

Дистрибутив Linux Windows путь к домашней папке access
Ubuntu 20.04
Ubuntu 18.04
Debian
Windows PowerShell

Совет

если вы ищете доступ к каталогу файлов Windows из командной строки распространения WSL, вместо доступа к каталогу будет получен доступ с помощью , поскольку дистрибутив Linux просматривает Windowsную файловую систему в качестве подключенного диска.

Необходимо установить Git в каждой файловой системе, с которой планируется использовать.

Как работать с Git?

В Git имеется много команд, поэтому разобьём их по теме и причине использования. Но начнём с того, что рассмотрим работу Git на локальной машине, ведь большая часть операций происходит именно там. После этого перейдём к многопользовательскому формату.

Вообще, с Git можно работать и через графический интерфейс (например, GitHub Desktop), и через командную строку. Командную строку изучить необходимо хотя бы потому, что она предоставляет больше возможностей, чем некоторые инструменты с интерфейсом.

Обычно, команды Git имеют следующий вид:

git <команда> <аргументы>

В качестве аргумента может быть путь к файлу. Также у команд бывают опции, обозначаемые —<опция> либо -<однобуквенная опция>. Они обеспечивают более детальную настройку действия команды. В нашем материале команды будут представлены в общем виде, а значит всё, что будет в <>, вы можете менять на собственные значения.

Кстати, если возникают затруднения с использованием той либо иной команды, рекомендуется открыть руководство посредством git help <команда>. Если просто нужно напоминание, применяйте git <команда> -h либо git <команда> —help (в Git -h и —help имеют одинаковое значение).

Install Git on Windows

Git for Windows stand-alone installer

  1. Download the latest Git for Windows installer.

  2. When you’ve successfully started the installer, you should see the Git Setup wizard screen. Follow the Next and Finish prompts to complete the installation. The default options are pretty sensible for most users.

  3. Open a Command Prompt (or Git Bash if during installation you elected not to use Git from the Windows Command Prompt).

  4. Optional: Install the Git credential helper on Windows

    Bitbucket supports pushing and pulling over HTTP to your remote Git repositories on Bitbucket. Every time you interact with the remote repository, you must supply a username/password combination. You can store these credentials, instead of supplying the combination every time, with the Git Credential Manager for Windows.

Install Git with Atlassian Sourcetree

Sourcetree, a free visual Git client for Windows, comes with its own bundled version of Git. You can download Sourcetree here.

To learn how to use Git with Sourcetree (and how to host your Git repositories on Bitbucket) you can follow our comprehensive Git tutorial with Bitbucket and Sourcetree. 

Step 5: Create a new branch

Now that you’ve made a new commit, let’s try something a little more advanced.

Say you want to make a new feature but are worried about making changes to the main project while developing the feature. This is where git branches come in. 

Branches allow you to move back and forth between ‘states’ of a project. Official git docs describe branches this way: ‘A branch in Git is simply a lightweight movable pointer to one of these commits.’ For instance, if you want to add a new page to your website you can create a new branch just for that page without affecting the main part of the project. Once you’re done with the page, you can merge your changes from your branch into the primary branch. When you create a new branch, Git keeps track of which commit your branch ‘branched’ off of, so it knows the history behind all the files. 

Let’s say you are on the primary branch and want to create a new branch to develop your web page. Here’s what you’ll do: Run git checkout -b <my branch name>. This command will automatically create a new branch and then ‘check you out’ on it, meaning git will move you to that branch, off of the primary branch.

After running the above command, you can use the git branch command to confirm that your branch was created:

The branch name with the asterisk next to it indicates which branch you’re on at that given time. 

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector