Продуктивное использование Git
Данная статья подразумевает, что система контроля версий Git уже установлена и глобальные параметры конфигурации (а именно имя пользователя и электронной почты) указаны верно. В противном случае, пожалуйста, обратитесь к руководству по установке и настройке Git:
- Установка Git на Ubuntu 12.04
- Установка Git на Ubuntu 14.04
- Установка Git на сервер CentOS 6.4
Git является очень полезной программой, позволяющей ускорить разработку проектов по программированию. Данная программа не привязывается к определенному языку и не имеет требований относительно файловой структуры, позволяя разработчикам самостоятельно структурировать рабочий процесс согласно их требованиям.
Прежде чем использовать Git разработки проекта, нужно спланировать свой рабочий процесс. При этом, как правило, учитываются размер и масштаб проекта. Чтобы получить общее представление о Git, будет достаточно одной ветки разработки. По умолчанию, первая ветка любого проекта Git называется master. Следующий урок этой серии расскажет, как создать другие ветки.
Что такое Git? Зачем он нужен?
Итак, создайте новый проект и назовите его testing (если у вас уже есть проект, который нужно импортировать в git, перейдите к разделу «Конвертирование существующего проекта»).
Создание рабочего пространства
На данном этапе нужно позаботиться о чистом рабочем пространстве (workspace) для кодирования, особенно если код будет разрабатываться для нескольких проектов сразу. Рекомендуется создать отдельную папку по имени git в домашнем каталоге, который содержит подкаталоги для каждого проекта.
Итак, для начала нужно создать рабочее пространство.
Данная команда выполняет два действия:
- создает в домашнем каталоге каталог по имени git и подкаталог testing (здесь будет храниться проект);
- переходит в базовый каталог проекта.
В базовом каталоге нужно создать несколько файлов для проекта. На этом этапе можно либо следовать руководству и создать несколько фиктивных файлов для тестирования, либо создать файлы/каталоги, которые позже станут частью реального проекта.
Чтобы создать тестовый файл для репозитория:
Создав в рабочем пространстве все необходимые файлы, попробуйте отследить файлы при помощи git. Как это сделать, покажет следующий раздел.
Конвертирование существующего проекта
Когда все нужные файлы находятся в рабочем пространстве git, нужно сказать git использовать текущий каталог как среду git.
Создав новый пустой репозиторий, добавьте в него нужные файлы и каталоги.
Для этого используйте следующую строку:
В данном случае не должно появиться никакого вывода (к сожалению, Git не всегда сообщает о правильной работе компонентов).
Всякий раз, когда в репозитории добавляются новые или изменяются уже существующие файлы, нужно создавать сообщение к коммитам (или commit message). Об этом речь пойдет в следующем разделе.
Что такое GIT простым языком? Как работает, основные команды GIT
Создание сообщений коммита
Сообщение коммита, или сообщение о коммите (commit message) – это короткое сообщение, объясняющее внесенные изменения. Такие сообщения необходимо создавать перед отправкой изменений кодирования (который называется push); это отличный способ объяснить остальным разработчикам проекта, что именно было изменено в коде и чего от этих изменений ожидать.
Сообщения коммитов, как правило, достаточно короткие (в пределах 1-2 предложений) и должны излагать внесенные поправки. Рекомендуется создавать сообщение о каждом внесенном изменении, прежде чем передать код. Можно передавать столько сообщений о коммитах, сколько нужно. Единственное требование для любого коммита: он должен включать в себя, по крайней мере, один файл и сообщение. Передача данных (или push) должна иметь как минимум один коммит.
Продолжая работу с приведенным ранее примером, создайте сообщение для коммита:
Вышеприведенная команда содержит два важных параметра. Первый – это параметр –m, который позволяет набрать комментарий к коммиту (в данном случае Initial Commit). Второй – это параметр –а, который означает, что данное сообщение о коммите нужно применить ко всем добавленным или измененным файлам. Для первого коммита это приемлемо; в целом же, рекомендуется указывать определенные файлы или каталоги для каждого коммита.
Также можно выполнить:
Чтобы указать определенный файл коммита. Чтобы указать дополнительные файлы или каталоги, внесите в конец этой команды список нужных файлов, разделенный пробелами.
Передача изменений на удаленный сервер
До этого момента все действия выполнялись на локальном сервере. Для простоты отслеживания версий файлов Git рекомендуется использовать локально. Тем не менее, работая в команде разработчиков, нужно предавать (или толкать) внесенные в код изменения на удаленный сервер. Об этом и пойдет речь в этом разделе.
Первое, что нужно для передачи кода на удаленный сервер – предоставить URL репозитория и назвать его. Чтобы настроить удаленный репозиторий и просмотреть список всех таких репозиториев (если их более одного), введите следующую команду:
Конечно, можно указать любое имя для удаленного репозитория, но URL должен указывать на действительный репозиторий. К примеру, чтобы толкнуть код на GitHub, нужно использовать URL репозитория, предоставленный проектом.
Когда удаленный репозиторий настроен, можно приступать к передаче кода.
Чтобы толкнуть код в удаленный репозиторий, наберите:
Команда git push толкает все изменения, origin – это имя нового удаленного репозитория, а master – имя первой ветки.
Теперь для передачи кода в будущем можно просто набирать git push.
Надеемся, данное руководство помогло вам получить общее представление об использовании git в командной работе. Следующее руководство проводит более глубокий анализ веток git и объясняет преимущества их использования.
Источник: www.8host.com
Чем отличаются Git, GitHub и GitHub Desktop?
Рассмотрим популярные инструменты, которые обязательно должны быть в арсенале современного программиста.
Система контроля версий GIT
Во время работы у программиста часто бывает следующая ситуация:
- Написал фрагмент кода, проверил, программа работает.
- Написал следующий фрагмент, проверил, а программа уже не работает.
Нужно понять, что именно нарушилось, а для этого нужно вернуться к работающей версии. Для этого нужно где-то сохранить копию предыдущей версии.
Для этого существуют системы контроля версий, которые называются VCS (Version Control System). Хотя каждая система управления версиями имеет свои специфические особенности, но общий принцип работы у всех один:
- Существует центральное хранилище (Repository), где хранится информация о всех версиях программы.
- Программист перед началом работы получает копию текущей версии (Pull).
- После внесения изменений в программу программист заносит в хранилище следующую версию (Push).
- При ведется журнал изменений и можно в любой момент получить любую версию программы.
На данный момент самой популярной системой контроля версий является GIT. Ядро Git представляет собой набор утилит командной строки с параметрами.
Среди проектов, использующих Git — ядро Linux, Android, jQuery, PHP.
Сервис для хостинга проектов GitHub
Крупнейшим сервисом для хранения Git-проектов является GitHub.
Этот сервис позволяет размещать проекты любой сложности. В частности, на GitHub размещен исходный код ядра Linux.
В 2018 году Microsoft купила GitHub за 7,5 млрд долларов.
До апреля 2020 г. на GitHub можно было бесплатно размещать только открытые проекты.
Сейчас можно размещать бесплатно как открытые, так и закрытые проекты. На сервисе GitHub по состоянию на май 2021 г. было зарегистрировано 65 миллионов программистов.
На GitHub есть система звезд, которые выставляются репозиториям. По количеству звезд можно находить самые востребованные проекты.
Программа GitHub Desktop
Для работы с сервисом GitHub разработана программа GitHub Desktop. Она позволяет легко начать работать с сервисом. Для этого нужно сделать следующие шаги:
- Скачать и установить программу GitHub Desktop.
- Завести аккаунт на GitHub.
- Создать новый репозиторий.
- Подключиться к репозиторию.
Создание репозитория
Для создания закрытого репозитория выберите Private.
Открытый репозиторий (Public) доступен в поиске, виден в вашем профиле и любой человек может посмотреть код и предложить свои изменения.
Рекомендуется для репозиториев создавать файл README, в котором кратко описывать, для чего этот репозиторий нужен.
После создания репозитория к нему нужно подключиться из программы.
Основные термины Git
Репозиторий (Repository) — каталог файловой системы, в котором хранятся файлы разработки.
Удаленный репозиторий (Ориджин, Origin) — репозиторий, находящийся на сервере. Это общий репозиторий, в который приходят все изменения.
Локальный репозиторий — репозиторий, расположенный на локальном компьютере разработчика. Именно с ним работает программист.
Клон (Clone) — копия Origin в локальный репозиторий.
Форк (Fork) — копия репозитория. Форк позволяет разработчику вносить изменения без риска испортить исходный код.
Коммит (Commit) — запись изменений в локальный репозиторий.
Пуш (Push) — отправка всех неотправленных коммитов в удаленный репозиторий.
Пул (Pull) — получение последних изменений с удаленного репозитория.
Пулреквест (Pull Request) — запрос на слияние форка репозитория с основным репозиторием. Пулреквест может быть принят или отклонен владельцем репозитория.
Общая схема работы с Git
Во время работы с Git чаще всего программист делает следующие шаги:
- Получить рабочую версию текста программы (Pull).
- Внести изменения в текст программы.
- Зафиксировать изменения в локальном репозитории (Commit).
- Отправить все коммиты в удаленный репозиторий (Push).
- При необходимости получить изменения из удаленного репозитория (Fetch).
Форк проекта
Для разработки типовых задач программисту не нужно начинать разработку с “чистого листа”. Лучше найти похожий проект на GitHub и сделать форк.
Форк — это копия проекта, которая может разрабатываться автономно. При необходимости можно сделать пул реквест для запроса соединения с оригиналом.
Этапы создания форка:
- Найти проект на Github. Например, https://github.com/octocat/Spoon-Knife
- Нажать ссылку Fork
- В GitHub Desktop клонировать проект и выбрать “For my own purposes”.
После этого проект будет автономен.
Ветвление в GIT
Во время разработки можно создавать так называемые ветки (branch).
Ветки позволяют вести независимую разработку. Основная ветка называется main. После принятия решения по новой ветке она или удаляется, или сливается (merge) с main.
Отмена изменений в GIT
Ключевой особенностью GIT является легкая отмена исправлений.
В случае неудачи программист всегда может вернуться к предыдущей версии. Это можно сделать командой revert.
Отмену можно делать до необходимой версии.
Выбор Gitflow
В каждой компании существует набор правил, по которым осуществляется порядок внесения изменения в Git. Этот набор обычно называют gitflow (от слова flow — поток).
Типовой gitflow выглядит так:
- Основная ветка main содержит только полностью работающие версии.
- Текущая разработка ведется в ветке dev.
- Каждый программист заводит свою ветку.
После того как все программисты объявили о завершении этапа происходит слияние в основную ветку.
Страницы GitHub
На GitHub есть еще полезная услуга, которая называется GitHub Pages
Вы получаете один сайт для каждой учетной записи GitHub и неограниченное количество сайтов для проектов.
Для создания страниц Github нужно создать репозиторий с именем аккаунта. Адрес этой страницы будет иметь вид:
https://username.github.io
Адреса проектов будут иметь вид:
http://username.github.io/repository
На этих сайтах можно размещать только статические страницы (HTML, CSS). Основное назначение — описание проектов.
Все эти возможности GitHub делают данный сервис весьма полезным для работы программиста.
Похожие записи:
Программа с демонстрацией виджетов GTK+
Локальный WAMP-сервер UwAmp
Редактор интерфейса Glade
Привет! Мог бы написать статью про Git, но в командной строке?
Константин Шереметьев
Использование командной строки не рекомендую, так как это сильно замедляет работу, именно поэтому программисты используют визуальные среды, в том числе и GitHub Desktop.
Я и собираюсь использовать визуальные среды, но после того как в принципе смогу сделать основные команды через командную строку. Так что лучше всего представить цепочку освоения Git’а так :
— называем задачу,
— показываем как это делается из под командной строки, затем
— показываем как это делается через GUI от GitForWindows/GitHubDesktop/SmartGit И все: вы получили студента — который по настоящему освоился и дальше уже все остальное освоит по аналогии!
Порядок действий что в первую очередь нужен новичку что бы стартовать (пробелы можно будет доосвоить через документацию):
— установить GitForWindows/GitHubDesktop
— если уже стоит — то проверить не нуждается ли установка в починке?
— понять разницу между системной и портативной установкой, и как их совмещать.
— настроить первично
— научиться создавать локальный репозиторий
— и/или клонировать себе удаленный
— для этого уметь использовать авторизацию
— добавлять файлы в проект (и исключать из него)
— комитить изменения
— создавать, переключать и объединять ветки
— синхронизировать локальный репозиторий с удаленным
— теперь поучиться сравнивать и отменять изменения. Это мой минимум — для того что бы уже практиковаться и переваривать уже всякие другие руководства. Сможете так сделать?
Или может знаете что кто-то уже так сделал, и вы не заходите изобретать велосипед и просто поделитесь ссылкой? Буду очень даже благодарен !!
Константин Шереметьев
Этот список не содержит чего-то особо сложного. Достаточно небольшой практики и все получится.
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.
- Мини-книга «Путь в программисты»
Можно ли стать программистом за год с нуля? Читайте в моей бесплатной мини-книге «Путь в программисты». Скачать бесплатно
Источник: progtips.ru
The git development community что это за программа
How Git makes software development better and easier.
- Agile
- Agile Manifesto
- Scrum
- Back
- Overview
- Sprints
- Sprint Planning
- Scrum Ceremonies
- Product Backlog
- Backlog Grooming
- Sprint Reviews
- Daily Stand Ups
- Scrum Master
- Retrospective Meeting
- Distributed Scrum Team
- Scrum Roles
- Scrum of Scrums
- Scrum Artifacts
- Scrumban
- Back
- Overview
- Board
- Kanban Board Examples
- Metrics
- WIP Limits
- Cards
- Kanban vs. Scrum
- Stand Up
- Kanplan
- Back
- Overview
- Project Plan
- Program Management
- Dependencies Management
- Workflow
- User Stories, Epics, Initiatives, And Themes
- Epics
- User Stories
- Story Points Estimation
- Metrics
- Gantt Charts
- Project Portfolio Management
- Back
- Overview
- Product Strategy
- Product Planning
- Product Roadmap
- Product Manager
- Product Requirements Documents
- Product Features Prioritization
- Net Promoter Score
- Product Analytics
- Idea Management
- Remote Product Management
- Lean Project Management
- Back
- Overview
- Agile Portfolio Management
- Lean Portfolio Management
- OKRs
- Agile Project Planning
- SAFe
- Spotify Model
- Agile Release Train
- [email protected]
- Agile Triangle
- Kata
- LeSS Framework
- Back
- Overview
- Agile Developer
- Software Development Manager
- Git
- Code Review
- Software Release
- Agile QA
- Technical Debt
- Agile Testing
- Incident Response
- Сontinuous Integration
- Back
- Overview
- Сollaborative Design
- Back
- Overview
- Go Agile
- Back
- Overview
- Distributed Team
- Release Manager
Try the Best Project
Management Tool
for Remote Teams
For Agile teams, Git is the reliable version control system and a significant part of a DevOps toolset.
What is Git in simple words? This open-source project actively supports a range of workflows that suit the needs of any Agile software development team.
The distributed nature of Git gives it excellent performance characteristics. They provide Agile developers with the freedom to experiment locally and publish their changes only when they are ready for distribution to the team.
What is the purpose of Git? What are the Git advantages? What are the types of branches in Git, and how should you use them? You probably have even more questions. This post aims to give you all the answers and clarify controversial points.
Let’s dive in!
What Is Git?
Table of Contents hide
If you are searching for the most widely used modern version control system over the globe, this is definitely Git. Git is an actively maintained open source project originally developed in 2005 by Linus Torvalds, the creator of the Linux kernel.
Numerous software projects rely on Git for version control. This includes commercial projects and open source as well. Developers who have experience working with Git are widely represented in the pool of available software development talents. Git has a distributed architecture; it is an example of a Distributed Version Control System (DVCS).
Rather than have only one place for the full version history of the software, in Git, every developer’s working code copy is also a repository that may include the full history of all changes. It is worth adding that Git was designed with performance, flexibility, and security in mind.
Why Git?
Nowadays, many developers prefer Git above all other tools around. Git can really change the way developers think of merging and branching. With Git, merging/branching is extremely simple and cheap. They are considered one of the core parts of the daily workflow.
Because of its simplicity and repetitive nature, branching and merging are no longer something scary. Version control tools are aimed to assist in branching/merging more than anything else.
What are the origins of Git?
Git began with fiery controversy and creative destruction. The Linux kernel has a fairly large scope. For most of the lifetime of this open-source software project maintenance (1991–2002), changes to the software were passed around as patches and archived files.
In 2002, BitKeeper – a proprietary DVCS was what the Linux kernel project began to use.
In 2005, warm relationships between the company that developed BitKeeper and the community that developed the Linux kernel broke down. The free-of-charge status of the tool was revoked.
This situation prompted the Linux community to create their own tool based on the lessons they learned while using BitKeeper. The new system had the following goals:
- Simple design
- Advanced speed
- Strong support for non-linear development
- Ability to handle large projects like the Linux kernel efficiently
- Fully distributed
So, 2005 was the year of Git’s birth. Since that time, Git has evolved and matured but yet retains the initial qualities. It’s really fast, efficient with large projects, and provides an excellent branching system for non-linear development.
Three states of Git
This is the most important thing to remember about Git if you want the rest of the learning process to run smoothly. Git has three main states that your files can be in: modified, staged, and committed.
- Modified files consist of files that have changed but have not yet been committed.
- A Staged file is a modified file in its current version, marked for inclusion in the next commit.
- Committed files mean that the files are already saved in your local database.
Git Basics: Repositories, Branches, and Commits
In order to see Git in practice, you should dive into some basic terms in short words.
A location where your code is stored is a Repository . In fact, this is a folder on your machine that contains your project code. After turning this folder into a Git Repository, Git manages the project code version history.
However, the code is not directly stored in the Repository. Inside the Repository, you have Branches (subfolders). After you add the first code to the Repository, a default Main Branch is created. You are not limited to one Branch as the Repository usually has multiple Branches.
However, the question is: Where do you store your code? Inside the Branches is the answer. Branches contain different code versions — your Commits . Every single Commit is a snapshot of a specific version of the code.
Introducing the Git Flow Workflow
There are 5 branch types in the Git flow workflow:
1. Main Branch
The main branch is typically referred to as “master” but nowadays this term looks outdated, and it’s better to use the “main” term instead.
Containing production-ready code that can be released is the key goal of the main branch in the Git flow workflow.
The main branch is created at the start of a project. It is maintained throughout the development process. It can be tagged at different commits to signify different versions or releases of the code. The other branches will be merged into the main branch after they have been competently tested.
2. Develop Branch
The Develop branch in Git workflow is created at the start of a project. It is maintained throughout the development process and includes pre-production code with newly developed features that are in the testing process.
The features that are newly created should be based on the Develop branch. Then they should be merged back in when ready for testing.
Git flow development also contains three types of supporting branches with their specific purposes: feature, release, and hotfix branches.
3. Feature Branch
This is the most common type of branch in the Git flow workflow. You’ll need the Feature Branch when adding new features to the code.
You will start this branch off the develop branch when working on a new feature. Then you’ll merge your changes back into the develop branch when the feature is completed and thoroughly reviewed.
4. Release Branch
It should be used when preparing new product releases. The work being performed on Release Branches concerns finishing touches and minor bugs. They relate to new code that should be considered separately from the main Develop Branch.
5. Hotfix Branch
The Hotfix Branch is applied to quickly address necessary changes in the Main Branch.
The Main Branch is the base of the Hotfix Branch. It should be merged back into both the Main and Develop Branches. Merging the changes from the Hotfix Branch back into the Develop Branch is critical. This ensures that the fix persists the next time the Main Branch is released.
What are the benefits of using Git?
- Performance. Git is about great performance when it comes to version control systems. Branching, merging, and committing are well optimized for a better performance than other systems.
- The branching model. It allows having multiple local branches which are independent of each other. This enables you to have friction-less context switching, role-based code, and disposable experimentation.
- Security. Git handles your security with a special algorithm that manages your versions, files, and directory securely.
- Distributed in nature. It means that the repository or the complete code base is mirrored onto the developer’s system (meaning that he/she can work on it only).
- Staging area. There is an intermediate stage called “index” in Git (also known as “staging area”) where commits can be modified before completing the commit.
- Open-source. The open-source nature invites developers to contribute to the software and make it more robust and reliable through the features and additional plugins.
Three Tips to Succeed
1. Think about tasks as Git Branches
When you know all the features, when they are added to a product roadmap , and the development team is ready, then Git may come into play.
Product, Quality Assurance , design, and engineering teams hold a feature kick-off meeting to get a shared understanding of what a feature will be. So, the project scope defines what tasks the feature needs to be broken down into before the team can complete it. These tasks ( user stories ) are then assigned to individual developers.
Here Git starts to fit up into your Agile workflow. Branching is straightforward. It allows teams to easily collaborate inside one codebase. While creating a branch, developers have their own isolated version of the codebase which they can change.
2. Take the advantage of testing multiple branches individually
When branches are ready for code reviews, Git plays another key role in an Agile development workflow – testing.
Effective Agile and DevOps teams practice code reviews and apply automated tests. Developers can easily notify their teams that the branch work is ready for review. A pull request is a way to ask another developer to merge one of your branches into the Main Branch and that it is ready for testing.
3. Get transparency and quality to Agile development
If you want Git to work perfectly for your Agile workflow, make sure that your Main is always green. In case a feature isn’t ready, then wait for the next release. This will not be actually a big deal if you practice shorter release cycles.
To sum up
For many, this branching model has nothing shocking new. However, the “big picture” figure may turn out to be tremendously useful in your projects. It forms an elegant model that is easy to comprehend. It allows team members to develop a shared understanding of the branching and releasing processes.
Now you know all the basics of Git, so go ahead and explore it closely in practice!
Pavel is a Content Marketing Manager at Hygger.io https://hygger.io/guides/agile/software-development/git/» target=»_blank»]hygger.io[/mask_link]
Учебник по Git: установка Git
В этой подглаве коротко описано, как можно установить программу «Git» на свой компьютер разными способами. Порядок установки зависит от операционной системы, установленной на компьютере. В подглаве описан порядок установки для Unix-подобных операционных систем и для операционных систем семейства «Windows». Заключительная часть подглавы посвящена тому, как можно собрать исполняемый файл программы «Git» из исходников (это программа с открытыми исходниками) на Unix-подобной операционной системе.
У меня на компьютере установлена операционная система «Windows 10 Pro» (64-разрядная), поэтому меня интересовал раздел данной подглавы, посвященный установке программы «Git» на компьютер с операционной системой семейства «Windows». Этот раздел данной подглавы маленький, состоит всего из двух параграфов, но всё необходимое там описано. Вот страница официального сайта программы «Git», посвященная установке этой программы на компьютер с операционной системой из семейства «Windows»:
Хоть в учебнике сказано, что после перехода по этой ссылке должно начаться автоматическое скачивание дистрибутива программы «Git», этого не происходит. Видимо, с 2014 года (время написания учебника) это убрали.
В учебнике отмечено, что с указанной страницы можно скачать не оригинальную программу «Git» (которая, как я понимаю, работает только на Unix-подобных операционных системах), а отдельную программу для операционных систем «Windows», которая называется «Git for Windows».
Вот ссылка на исходники программы «Git for Windows»:
https://github.com/git-for-windows/git
У программы «Git for Windows» есть собственный отдельный сайт, у которого есть два адреса URL (оба этих адреса ведут на один и тот же сайт):
http://git-for-windows.github.io
https://gitforwindows.org
В описании проекта «Git for Windows» на веб-сервисе «GitHub» сказано, что программа «Git for Windows» является форком оригинальной программы «Git», содержащим изменения, нужные при работе в операционных системах семейства «Windows».
Что интересно, на данный момент номера версий для оригинальной программы «Git» и для программы «Git for Windows» совпадают. Вероятно, разработчики этих отдельных программ как-то согласуют свои действия друг с другом.
Установка на практике
Итак, я перешел на страницу, упомянутую выше:
и нажал там на первую же ссылку для скачивания «Click here to download», хотя ниже есть еще ссылки на разные версии дистрибутива. Эта ссылка указывает на один из дистрибутивов, расположенных на веб-сервисе «GitHub» по следующему адресу:
Я скачал файл с таким названием (его размер 47,9 Мбайт):
Из названия этого файла видно, что это дистрибутив программы «Git for Windows» версии 2.35.1(2) для операционной системы семейства «Windows» (64-разрядной), не младше «Windows Vista». Это самая свежая версия этой программы на данный момент, датированная 1 февраля 2022 года.
Я запустил эту программу-установщик. Она установила программу «Git for Windows» в следующую папку, затребовав 263,9 Мбайт места на жестком диске:
C:Program FilesGit
Список устанавливаемых компонентов программы «Git for Windows» я оставил по умолчанию:
Далее установщик попросил выбрать текстовый редактор, который программа «Git for Windows» будет использовать по умолчанию. Я выбрал из предложенного списка текстовый редактор «Notepad++», которым давно пользуюсь.
Далее предлагается возможность сменить умолчательное название первоначальной ветки нового репозитория, создаваемого с помощью программы «Git for Windows» (команда git init ), с «master» на какое-нибудь другое. Эта функция установщика, очевидно, была добавлена после известного скандала, случившегося года два назад (см. тут). Тогда каким-то американцам не понравилось название «master» (одно из значений этого слова переводится на русский язык как «господин» или «хозяин») из-за того, что оно, якобы, неприятно напомнило им о судьбе когда-то угнетавшихся в США негров.
Лично меня слово «master» не смущает, так как в данном случае оно используется в другом значении («главный»). Поэтому я оставил опцию по умолчанию: «Let Git decide» (позволить программе «Git» самой решать). Это значит, что пока что умолчательное имя для первоначальной ветки остаётся «master», но в будущих версиях программы это может измениться. На уже существующие репозитории эта опция не влияет.
Далее установщик предлагает выбрать один из трех вариантов настройки переменной среды PATH: 1) не изменять эту переменную среды. Там сказано, что в этом случае программу «Git for Windows» можно будет запустить только из «Git Bash» (я пока не знаю точно, что это такое, но подозреваю, что это программа-эмулятор командной строки «bash» из Unix-подобных операционных систем); 2) прописать путь к программе «Git for Windows» в этой переменной среды. В этом случае программу «Git for Windows» можно будет запустить из командной строки «cmd.exe» или из программы «Windows PowerShell» без указания полного пути к исполняемому файлу программы; 3) Прописать в этой переменной среды кроме пути к программе «Git for Windows» еще пути к каким-то дополнительным утилитам. Это может повлиять на работу обычных утилит операционной системы «Windows».
По умолчанию выбрана вторая опция из этих трех. Ее я и оставил выбранной.
Далее я выбирал из двух опций насчет использования SSH (тут подробнее). Выбрал опцию по умолчанию: будет использоваться программа «ssh.exe», которая установится сейчас вместе с программой «Git for Windows».
Выбрал опцию (предлагается два варианта) насчет библиотеки SSL/TLS, используемой программой «Git for Windows» при соединениях по протоколу HTTPS: «Use the native Windows Secure Channel library» (использовать встроенную в операционную систему «Windows» библиотеку).
Настройка преобразований окончаний строк: есть три опции. Оставил опцию по умолчанию: «Checkout Windows-style, commit Unix-style line endings» (при получении текстовых файлов из каталога «Git» в рабочую копию для изменения конвертировать LF в CRLF, при коммитах конвертировать CRLF в LF). Там сказано, что это рекомендуемая опция в кроссплатформенных проектах для операционной системы «Windows».
Настройка эмулятора терминала: есть две опции: 1) использовать «MinTTY»; 2) использовать умолчательное для операционной системы «Windows» окно консоли. Выбрал вторую опцию.
Выбор поведения команды git pull : есть три опции. Выбрал первую: «Default (fast-forward or merge)», так как там сказано, что это стандартное поведение этой команды.
Выбор «credential helper» (по-русски «менеджер учетных данных»): есть две опции. Я выбрал опцию «None» (не использовать менеджер учетных данных).
Настройка дополнительных опций: есть два флага: 1) «Enable file system caching» (включить кэширование при работе с файлами), по умолчанию флаг установлен; 2) «Enable symbolic links» (включить символические ссылки), по умолчанию флаг не установлен. Оставил умолчания.
Настройка экспериментальных опций: есть два флага, по умолчанию оба не установлены. Оставил, как есть.
Только после этого началась и успешно закончилась установка программы.
В целом мне понравилось, как сделана программа-установщик. Однако, при установке требуется настроить слишком много опций. Это минус. Очевидно, что большинство из этих опций можно сконфигурировать уже после установки программы «Git for Windows», поэтому их настройку следовало бы отложить до момента после установки.
О настройке большинства из перечисленных опций я имею довольно смутное представление, поскольку являюсь новичком в использовании программы «Git for Windows». Надеюсь, позже будет возможность перенастроить вышеуказанные опции при необходимости.
Я пока что не знаю, как проверить работоспособность установленной программы. Продолжу читать учебник дальше. Думаю, в следующих главах всё станет понятно.
Источник: ilyachalov.livejournal.com