Install git

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 1. Create a Repository

A repository is usually used to organize a single project. Repositories can contain folders and files, images, videos, spreadsheets, and data sets – anything your project needs. We recommend including a README, or a file with information about your project. GitHub makes it easy to add one at the same time you create your new repository. It also offers other common options such as a license file.

Your repository can be a place where you store ideas, resources, or even share and discuss things with others.

To create a new repository

1. In the upper right corner, next to your avatar or identicon, click and then select New repository.
2. Name your repository .
3. Write a short description.
4. Select Initialize this repository with a README.

Click Create repository.

Как опубликовать первый проект на Git

Зайдите в ваш профиль: для этого кликните по иконке в правом верхнем углу и нажмите Your Profile:

 

Теперь создайте репозиторий: перейдите во вкладку Repositories и кликните по кнопке New:

Задайте имя репозитория. Мы придумали название проекта test-github и сделали его публичным, чтобы его могли просматривать все пользователи. Далее нажмите кнопку Create repository:

Пока проект пустой, но мы можем поместить в него наши файлы с локальной машины.

Будем использовать протокол HTTPS — с ним проще работать с Git, чем с SSH. Подробнее про различия протоколов можно прочитать в документации.
Github предлагает несколько вариантов создания проекта:

• клонировать папку по выбранному протоколу;
• создать проект с нуля — сегодня мы рассмотрим именно этот способ;
• опубликовать уже созданный проект; 
• скопировать проект.

Ветвление в git

3.1 Базовые операций

• -r | -a — Список отслеживаемых внешних веток -r. Список и отслеживаемых и локальных веток -a. Список слитых веток —merged. Список не слитых веток —no-merged.
• -l, -f <имя-ветки> — Список имён веток -l. Принудительное создание, перемещение или удаление ветки -f. Создание новой ветки <имя ветки>.
• -r (-d | -D) — Выполнить действие на отслеживаемой внешней ветке -r. Удалить слитую ветку -d. Принудительное удаление (даже не слитой ветки) -D.
• -m | -M <Новая ветка> — Переместить/переименовать ветки и ее журнал ссылок (-m). Переместить/переименовать ветку, даже если целевое имя уже существует -M.
• (-с | -С) <новая-ветка> — Скопировать ветку и её журнал ссылок -c. Скопировать ветку, даже если целевое имя уже существует -C.
• -v, -vv — Список веток с последним коммитом на ветке -v. Список и состояние отслеживаемых веток с последним коммитом на них.

3.2 Слияние веток

• —squash — Создать один коммит вместо выполнения слияния. Если у вас есть конфликт на ветках, то после его устранения у вас на ветке прибавится 2 коммита (коммит с сливаемой ветки + коммит слияния), но указав этот аргумент у вас прибавится только один коммит (коммит слияния).
• —ff-only — Не выполнять слияние если имеется конфликт. Пусть кто ни будь другой разрешает конфликты 😀
• -X — Использовать выбранную стратегию слияния.
• —abort — Отменить выполнение слияния.

Процесс слияния.

Quick Start: Unix

Prerequisites for Linux:

• >= 6

Prerequisites for macOS:

• On macOS 10.14 or below, you will also need:
  • >= 6 from Homebrew

First, download and bootstrap vcpkg itself; it can be installed anywhere,
but generally we recommend using vcpkg as a submodule for CMake projects.

$ git clone https://github.com/microsoft/vcpkg
$ ./vcpkg/bootstrap-vcpkg.sh

To install the libraries for your project, run:

$ ./vcpkg/vcpkg install 

You can also search for the libraries you need with the subcommand:

$ ./vcpkg/vcpkg search 

In order to use vcpkg with CMake, you can use the toolchain file:

$ cmake -B  -S . -DCMAKE_TOOLCHAIN_FILE=/scripts/buildsystems/vcpkg.cmake
$ cmake --build 

With CMake, you will still need to and the like to use the libraries.
Check out the
for more information on how best to use vcpkg with CMake,
and CMake Tools for VSCode.

For any other tools, check out the integration guide.

Вариант 2. Я вообще ничего не знаю

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

Ну что ж, приступим к делу!

Допустим, вы хотите создать новый репозиторий. Это место, где будет «жить » ваш проект. Если вы не хотите создавать новый репозиторий, то можете склонировать уже существующий. Именно так вы копируете чужой проект или берете нужную вам информацию для работы/учебы. Мы еще к этому вернемся, но чуть позже.

Репозиторий — это место, в котором вы систематизируете свой проект. Здесь вы храните файлы, папки, видео, изображения, блокноты Jupyter Notebook, наборы данных и т.д. Перед началом работы с Git необходимо инициализировать репозиторий для проекта и правильно его подготовить. Это можно сделать на сайте GitHub.

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

Перейдите на сайт GitHub. Нажмите на значок + в верхнем правом углу, а затем выберите New repository.
Придумайте имя репозитория и добавьте короткое описание.
Решите, будет ли этот репозиторий размещаться в открытом доступе или останется закрытым для просмотра.
Нажмите Initialize this repository with a README для добавления README-файла

Настоятельно рекомендую снабжать все ваши проекты файлом-описанием, ведь README — это первая вещь, на которую люди обращают внимание при просмотре репозитория. К тому же, здесь можно разместить нужную информацию для понимания или запуска проекта.

Новый репозиторий

Создание нового репозитория

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

Вносить изменения в проект можно двумя способами. Вы можете изменять файлы/блокноты на компьютере либо делать это на сайте GitHub.

Допустим, вам захотелось подкорректировать README-файл на сайте GitHub.

• Для начала перейдите в ваш репозиторий.
• Для выбора файла кликните по его названию (например, кликните по README.md для перехода к файлу-описанию).
• В верхнем правом углу вы увидите иконку с карандашом. Нажмите на нее для внесения изменений.
• Напишите короткое сообщение, передающее суть изменений (и подробное описание, если сочтете это нужным).
• Нажмите кнопку Commit changes.

Изменение файла на GitHub

Подготовка коммита с изменениями

Вы успешно внесли изменения в README-файл своего нового репозитория! Обратите внимание на небольшую кнопку на картинке выше. Она позволяет создавать новую ветку этого коммита и добавлять Pull request

Запомните ее, скоро к ней вернемся.

Как вы видите — ничего сложного!

Лично я предпочитаю работать с файлами на локальном компьютере, а не на сайте GitHub. Поэтому давайте научимся и этому.

Как будет проверяться соблюдение новых правил по охране труда

Напомним, что с 1 января вступили в силу 38 новых правил по охране труда, еще два ПОТ начнут действовать чуть позже. Так, ранее действующие правила признаны утратившими силу. Однако утратившие силу ПОТ до сих пор включены в проверочные листы.

Роструд рассказал, что с 1 января 2021 года инспекторы не вправе проверять исполнение требований правил по охране труда, утративших силу (Письмо Федеральной службы по труду и занятости от 15 января 2021 г. № 57-ТЗ).

Но, если в ходе проверки было выявлено нарушение новых ПОТ, инспектор вправе инициировать внеплановую проверку.

Ознакомиться с письмом № 57-ТЗ можно здесь 

Не забывайте:

если не выполнить требования трудовой инспекции и не предоставить документы на проверку, организации грозит административная ответственность по части 1 статьи 19.4, части 1 статьи 23.1 КоАП:

штраф должностному лицу в размере от 2 000 до 4 000 рублей

Install Git on Windows

1. Navigate to the latest Git for Windows installer and download the latest version.
2. Once the installer has started, follow the instructions as provided in the Git Setup wizard screen until the installation is complete.
3. Open the windows command prompt (or Git Bash if you selected not to use the standard Git Windows Command Prompt during the Git installation).
4. Type to verify Git was installed.

Note: is a popular and recommended resource for downloading Git for Windows. The advantage of downloading Git from is that your download automatically starts with the latest version of Git included with the recommended command prompt, . The download source is the same Git for Windows installer as referenced in the steps above.

Как установить Git

Чтобы использовать команды Git, сперва его нужно поставить на компьютер.

На iOS он чаще всего идёт из коробки: чтобы найти его, нужно открыть терминал и набрать git —version:

Если вдруг его у вас нет, можно воспользоваться менеджером недостающих пакетов для macOS — Homebrew. Для установки пропишите в консоли brew install git.

Чтобы использовать Git на системе Linux, нужно поставить пакет Git. Например, для установки на Ubuntu нужно будет прописать sudo apt install git.

Если вы используете Windows, потребуется поставить консоль. Выберите нужный файл исходя из разрядности вашей системы и загрузите его:

После того как скачаете его, запустите установщик:

Для скорости можно не менять дефолтные настройки и прокликать Next:

Теперь вы можете использовать на Windows такую же консоль, как и на iOS:

Все описанные ниже команды будут работать как в терминале на iOS и Linux, так и в Windows.

Как пользоваться Git?

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

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

Создание проекта

Когда настройка git завершена перейдем к вашему проекту. В самом начале вам достаточно создать папку для файлов проекта. Если вы собираетесь работать над несколькими проектами, создайте папку git в вашем домашнем каталоге, а уже туда поместите папки ваших проектов:

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

Проект готов, но система контроля версий git еще не знает об этом.

Настройка проекта в git

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

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

Если все прошло хорошо, то команда ничего не выведет.

Фиксация изменений

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

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

Команде необходимо передать два параметра, первый — это -m, ваш комментарий, второй -a, означает, что нужно применить действие ко всем измененным файлам. Для первого раза используется этот параметр, но обычно вам нужно указать измененные файлы или каталоги. Например, можно делать так:

Отправка изменений

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

Сначала нужно добавить удаленный репозиторий с помощью команды remote. Для этого нужно передать ей URL:

Затем можно посмотреть список удаленных репозиториев:

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

Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.

Управление ветвями

Для простых проектов достаточно одной ветви. Но если проект большой и он имеет несколько версий, в том числе тестовую, то может понадобиться создать для каждой из них отдельную ветвь. Сначала смотрим доступные ветви:

Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:

Переключаться между ветвями можно тоже с помощью той же команды:

Теперь создадим еще один файл:

И добавим его в нашу новую ветвь develop:

Сделаем коммит для внесенных изменений:

Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:

Затем переключаемся на ветку master и снова смотрим:

Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:

Перед тем как будет выполнено слияние вам нужно ввести комментарий, зачем это нужно. Затем если вы еще раз выполните ls, то увидите, что здесь уже есть нужный файл. Наши примеры git подошли к концу.

Как сократить количество проверок Роструда

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

В отдельных сферах деятельности КНМ органов надзора заменят альтернативные институты:

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

К примеру, компания может быть освобождена от проведения плановых проверок, если заключить договор страхования рисков причинения вреда (ущерба) (п. 9 ст. 25 Закона о госконтроле) или станет членом СРО, у которого с надзорным органом заключено соглашение о том, что проверки деятельности членов организацией приравниваются к плановым проверкам органа надзора.

Мониторинг вместо плановых проверок Роструда

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

Мониторинг предполагает автоматическую фото- и видеосъёмку на объекте компании, при котором собранные материалы направляются контролирующему органу. А лицо, находящееся под таким контролем, будет освобождено от плановых проверок (ст. 96 Закона о госконтроле).

How to install Git in Windows 10

Git is a web based Git or version control repository and Internet hosting service. This is quite easy to use if you are developing a piece of software for personal or professional reason. There is always some controversy going on between installing Git between Windows 7 and 10 (mostly people say that Windows 7 is better than Windows 10). Previously, I used to use Git in Windows 7. But for quite a long time (almost for last one year), I had not used Git in my laptop which was Windows 8. However, with my  laptop’s sudden death, I got a new opportunity to buy new laptop with Windows 10 . So thought to have a quick installation of Git in Windows 10 as I have started to work for some pieces of code.

Below are the steps for quick Git installation in Windows 10:

1. Go to https://git-scm.com/download/win. This will automatically start downloading 64 bit version of Git client.
2. Click on the downloaded software. Read the public license and click next
3. Select your installation drive by browsing or keep the default one and click next
4. I checked on additional icons and keep the rest configuration as it is and clicked next
5. Leave it as it is and click next
6. By selecting this option, you can use Windows Command Prompt and Git Bash to upload code in Github. Click Next
7. Select Windows-style and click next
8. MinTTY can be used as a terminal emulator from Windows platform. Select the option to use MinTTY and click next
9. Keep the options as it is and click next
10. If you like to experiment with Github new features, you can select the experimental, builtin difftool. You can view the code difference between different versions for file(s). This is in beta version. So if you are not sure what to do with it, just click Install without selecting anything.
11. The installation would take some time. Grab a cup of coffee during the break. You deserve it

12. Github installation is completed now. Select the option ‘Launch Git Bash’ and click on Finish button.This will open the Gut Bash terminal on your desktop. You can set your Git repository from here and upload new versions of code.

    Overall, the utility seems has improved over time. I really did not observed any major performance related issue utilizing Git in Windows 10. Well, you can of course discover more. Enjoy exploring!!!

About Swapratim

Tech innovator, Founder, Blogger, Educator, IT Consultant
Passionate about Augmented Reality and how it is changing our world.

Find in Medium: https://medium.com/@swapratimroy

IT conultant, close to a decade now, pursuing different roles & responsibilities.
He has worked on several innovative projects.

He also likes to share his learning with everyone which he had learned over years.

Sole purpose of this blog is to share the author’s knowledge in tech industry, passion for travel and recent trends.

Hope you will enjoy the contents.

View all posts by Swapratim →

Подмодули

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

При клонировании репозитория вам необходимо инициализировать и обновить подмодули:

Запуск данной команды эквивалентен запуску команды:

после обычного клонирования репозитория

Обновление подмодулей

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

Для получения состояния последнего коммита всех подмодулей необходимо выполнить
следующую команду:

или использовать аргументы по умолчанию команды git pull:

Эта команда просто обновляет локальную рабочую копию. При запуске команды git status
каталоги подмодулей будут показаны изменёнными. Чтобы обновить репозиторий необходимо
зафиксировать изменения:

Для получения состояние последнего коммита конкретного подмодуля необходимо использовать команду:

Добавление подмодулей

В текущий проект можно включить другой репозиторий Git в качестве папки, отслеживаемый Git:

После этого необходимо добавить и зафиксировать новый файл .gitmodules. В нём описано
какие подмодули следует клонировать при запуске команды git submodule update

Step 5. Merge your Pull Request

In this final step, it’s time to bring your changes together – merging your branch into the branch.

1. Click the green Merge pull request button to merge the changes into .
2. Click Confirm merge.
3. Go ahead and delete the branch, since its changes have been incorporated, with the Delete branch button in the purple box.

Celebrate!

By completing this tutorial, you’ve learned to create a project and make a pull request on GitHub!

Here’s what you accomplished in this tutorial:

• Created an open source repository
• Started and managed a new branch
• Changed a file and committed those changes to GitHub
• Opened and merged a Pull Request

Take a look at your GitHub profile and you’ll see your new contribution squares!

To learn more about the power of Pull Requests, we recommend reading the GitHub flow Guide. You might also visit GitHub Explore and get involved in an Open Source project.

Last updated July 24, 2020

Клонируем репозиторий

Теперь нам нужно сделать локальную копию нашего удалённого репозитория. Мы снова воспользуемся кнопкой Clone or download, но теперь используем полную ссылку на репозиторий; эту ссылку нужно скопировать (Если у вас окошко выглядит не так как на картинке, то нажмите в окне на ссылку справа сверху Use HTTPS).

Для дальнеших шагов нам потребуется скачать и установить GitHub Desktop. После установки и первого запуска, возможно, потребуется войти в ваш аккаунт GitHub. Далее выбираем Clone repository или через File, а затем уже Clone repository.

Тут мы выбираем из списка репозиторий:

Тут мы вставляем ссылку на репозиторий:

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

Установка 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

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.

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

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

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

Получает изменений из определенного репозитория:

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

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

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

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

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