закоммитить это что значит

Первый коммит в Github

Руководство по созданию первого коммита в свой репозиторий на Github

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

Основы

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

Git — это инструмент, позволяющий реализовать распределённую систему контроля версий.

GitHub — это сервис для проектов, использующих Git.

Создать коммит (commit) значит зафиксировать изменения любых файлов, входящих в репозиторий.

Репозиторий — каталог файловой системы, в котором могут находится: файлы журналов конфигураций и операций, выполняемых над репозиторием, а также сами контролируемые файлы.

Репозиторий бывает:

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

Установка Git

Для Linux:

1. Откройте терминал и перейдите в желаемую директорию для установки.
2. Введите: sudo apt-get install git

Для macOS:

1. Воспользуемся homebrew
2. Вводим в терминале: brew install git

Для Windows, (для macOS и Linux — альтернатива):

1. Перейдите по ссылке: http://git-scm.com/downloads
2. Выберите нужный пакет и следуйте дальнейшим инструкциям.

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

Создание и настройка локального репозитория

Пусть наш проект имеет путь в файловой системе Users/Public/Project. Перед созданием локального репозитория желательно удалить все ненужные, временные файлы в папке проекта.

2. Настроим имя пользователя и адрес электронной почты:

(где Name – логин пользователя, email@mail.ru — почта)

Теперь каждое наше действие будет отмечено именем и почтой, это вносит порядок в историю изменений.

tree – команда для просмотра древовидной структуры файловой системы, в которой мы находимся.

find – удаление файлов со специфичным суффиксом.

3. Переходим в папку с проектом Users/Public/Project:

4. Создадим локальный репозиторий в папке с проектом:

Командная строка должна вернуть что-то вроде:

Добавление файлов в локальный репозиторий

1. Теперь создадим любой файл в нашей директории, например, first.txt

2. Добавим его в систему управления версиями:

3. Если нужно добавить все файлы в директории, то используем:

4. Проверить текущее состояние:

Можно отменить добавление файла командой:

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

После добавления нужного файла в staging area (область подготовленных файлов) можно создать версию проекта.

Ключ –m означает создание пользователем описания этого коммита.

Для удаления всеx файлов в папке, не относящихся к проекту, и не сохраненных в репозитории, можно воспользоваться командой:

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

Все действия до этого раздела производились над локальным репозиторием, который находится у вас на компьютере. Если мы хотим сохранить проект в Интернете, и предоставить к нему доступ, то создадим репозиторий на Github.

1. Регистрируемся на сайте: github.com под именем nikname (может быть любым другим).

2. Нажимаем кнопочку «+» и вводим название репозитория.

3. Выбираем тип Public (Private доступен только в платной версии).

4. Нажимаем Create.
В результате создан репозиторий в Github (на экране видим инструкцию, по соедининению локального репозитория со вновь созданным).

5. Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (желательно использовать его, но можно любое другое, главное – не master – оно используется в момент релиза версии).

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

Если все правильно сделано, то увидим:

Для отмены регистрации удаленного репозитария, введите:

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

-u ключ установления связи между удаленным репозиторием github и веткой master. Все дальнейшие изменения переносятся на удаленный репозиторий следующей командой: git push

Источник

Что именно означает «запушить» «закомитить» «смерж

Скажите что именно означает:

4 «залить версию на стенд»

что именно делают программисты с кодом когда говорят используя эти термины?

а еще что такое класс и библиотека

Скажите что именно означает:

4 «залить версию на стенд»

что именно делают программисты с кодом когда говорят используя эти термины?

1. 2. Внести код в хранилище.
3. Соединить две или более веток кода.
4. Тоже самое, что 1 и 2) Каждое внесение кода нумеруется. Получается версия. Внесение версии на стенд это коммит и выдача сборки на стенд. Как правило для тестирования.
5. Ветка кода. Ответвление для проработки какого-либо функционала.

«Внесение версии на стенд это коммит и выдача сборки на стенд.» т.е.

1 закоммитить значит внести написанный в программе для написания текста программного кода, код в некоторую ветку кода в хранилище github?

2 каждая ветка состоит из последовательноости версий кода, а каждая версия состоит из нескольких внесенных дополнений кода-дополнение кода это «коммиты»

«Внесение версии на стенд это коммит и выдача сборки на стенд.» т.е.

1 «закоммитить» значит внести написанный в программе для написания текста программного кода, код в некоторую ветку кода в хранилище github?

2 каждая ветка состоит из последовательноости версий кода, а каждая версия состоит из нескольких внесенных дополнений кода-дополнение кода это «коммиты»

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

У меня стойкое ощущение дежавю. Ровно на этот вопрос я отвечал не более чем год назад.

Ну за 17 лет работы форума тут такое было не раз, да))

а вообще это хорошая идея кандидатов отсеивать

ну как бандосы «на фене» начинают разговаривать и сразу «палят» подсадного

и тут типа вопрос кандидату: «вот у нас тут билд зафейлился, а мы резилить хотим, что делать? черри-пикать коммиты? ревертить чейнджи? накатывать фиксы?»

и смотришь как тот выкрутится 🙂

1. 2. Внести код в хранилище.
3. Соединить две или более веток кода.
4. Тоже самое, что 1 и 2) Каждое внесение кода нумеруется. Получается версия. Внесение версии на стенд это коммит и выдача сборки на стенд. Как правило для тестирования.
5. Ветка кода. Ответвление для проработки какого-либо функционала.

В хранилище. гитхаб это одно из..

2 каждая ветка состоит из последовательноости версий кода, а каждая версия состоит из нескольких внесенных дополнений кода-дополнение кода это «коммиты»

Тут не подскажу. Кто может помочь с пуш?

Нет. Сборка это сборка из кода. А не версия кода.

Обновление стенда с новой версией программы/кода.

Злые мы стали, товарищи..))

Вообще, при наличии таких вопросов, найдите любую лекцию в сети и изучите принципы работы с хранилищем кода.
Там всей теории на пяток рисунков и полчаса чтения с чаем.

а вообще это хорошая идея кандидатов отсеивать

ну как бандосы «на фене» начинают разговаривать и сразу «палят» подсадного

и тут типа вопрос кандидату: «вот у нас тут билд зафейлился, а мы резилить хотим, что делать? черри-пикать коммиты? ревертить чейнджи? накатывать фиксы?»

и смотришь как тот выкрутится 🙂

И потеряете хорошего начинающего кандидата только из-за того, что он не знает терминов?)

И потеряете хорошего начинающего кандидата только из-за того, что он не знает терминов?)

это просто для оценки кандидата, чтобы определить «начинающий» он или «продолжающий»

можно ведь и наоборот например отсеять такого который будет грамотно отвечать, потому что типа «оверквалифайд»

да и тут не в терминах же смысл, а в понимании пайплайна

На удивление хорошая лекция от Яндекса.

facebook (Дети диаграммы Ганта)

Я в свое время со всем этим разобралась «на живую» за полдня) когда уже оформилась на работу. А последние два года и вовсе не приходится возиться с гитом, только сами билды смотрю. И штош теперь, не взяли бы меня работать, не будь трехлетней давности опыта работы с?)

Источник

Гит-словарик для начинающих программистов

Мёржим бранчи и коммитим реквесты

Мы часто упоминаем Git — способ организации хранения и контроля версий файлов в рабочем проекте. Сегодня расскажем о странных словах: «бранч», «коммит», «пулл-реквест» и об остальных понятиях в гите.

О чём речь

Гит — это такой способ хранения файлов и их версий. Гит позволяет смотреть историю изменений файлов, кто какие дополнения и когда вносил, как развивался проект, кто что в него добавлял и почему.

Главная особенность гита — он помнит всё, что вы в него внесли, и может показать, какие именно строчки вы правили несколько лет назад, когда чинили ошибку авторизации, например.

На базе гита есть сервис «Гитхаб». Работает так:

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

Это если вкратце. Теперь будут подробности.

Что такое репозиторий (git repository)

Гит-репозиторий — это облачное хранение вашего проекта на сервере (например, на сервере Гитхаба, но можно и на другом).

У каждого программиста может быть сколько угодно репозиториев, по одному на каждый проект. А можно вести все проекты в одном репозитории, но тогда это превратится в мешанину. Но каждый имеет право на мешанину.

В репозитории могут храниться:

Что такое бранч (git branch)

Бранч — это ветка или копия проекта, в которую можно вносить любые изменения и они не повлияют на основной проект.

В гит-репозитории всегда есть как минимум один бранч, который называется master. Если не создавать других веток, то все изменения будут сразу идти в главную ветку проекта. Для очень маленьких или учебных проектов это терпимо, но в любом коммерческом коде поступают иначе: создают ветки.

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

Но представьте такую ситуацию: мы только что запустили сайт для заказчика и он срочно хочет добавить интерактивный раздел со скидками. Можно сделать так: править рабочие файлы проекта «по живому», чтобы сразу видеть результат. А можно сделать из мастера отдельную ветку news и работать уже в ней (и это очень похоже на форк). В этом случае мы получим полную копию проекта, в которую можно вносить любые правки и они никак не повлияют на запущенный сайт. Мы в этой ветке пилим всё, что нужно клиенту, показываем ему результат на секретном сайте, а потом объединяем её с мастером. Это называется «смёржить бранчи».

Что такое клонирование (git clone)

Клонирование — это когда вы копируете репозиторий себе на жёсткий диск. Это нужно, чтобы начать в нём что-то менять.

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

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

Что значит «смёржить» (git merge)

Смёржить (от англ. merge — объединять, совмещать) — это когда мы отправляем всё, что сделали в одной ветке, в другую. Весь новый код, исправления ошибок, дополнительные функции — всё это отправится в новую ветку. Если же мы что-то удалим в коде, то при объединении этот фрагмент тоже удалится из основной ветки.

Получается, что схема работает так:

Что такое коммит (git commit)

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

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

Например, вы изменили файл главной страницы index.html и добавили его в список файлов текущего коммита. Теперь его можно отправить на сервер, а можно ещё поправить сразу style.css и внести в этот же коммит. Системе всё равно, сколько файлов обрабатывать, поэтому как и что коммитить — решает программист.

Единственное требование к коммитам — указывать, что именно вы поменяли в проекте, человеческим языком. Хорошим тоном и правильным подходом считается писать, что именно вы изменили: «Добавил цвет и стили основной кнопки», «Убрали метод вызова старого API», «Сделали рефакторинг функции SetOutOfDate()». Это описание будут читать другие разработчики.

Коммитить можно хоть после правки каждой строчки — весь вопрос в том, насколько нужна такая детализация в проекте. Но иногда и изменения из одной строчки можно закоммитить, если оно действительно важное.

Что такое пуш и пулл (git push, git pull)

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

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

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

Чем коммит отличается от пуша

Коммит — это когда вы фиксируете изменения в проекте, как бы подводите итог своей работе.

Пуш — это когда вы отправляете сделанную работу туда, где хранится копия вашего кода.

Получается, последовательность действий такая:

Что дальше

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

Источник

Как переводить термин Git: «commit» (сущ.) / «to commit» (глаг.)?

Поискав по доступным источникам выяснилось, что «в официальных переводах» используют перевод «фиксация (сущ.) / фиксировать (глаг.)» (от «фиксация транзакции» из терминологии БД, что логично):

Для программистов, понятное дело, в результате «профдеформации», слово «коммит» выглядит родным, но должно ли это сказываться на переводе?

Все же, как переводить термин Git: «commit» (сущ.) / «to commit» (глаг.)?

PS: Свой вариант пишите в комментариях.

Всего голосов: 1060

т.е. ты пришел за советом к профдеформированным? 🙂

В таком случае: коммит, (за)коммитить. Это слово уже прочно вжилось в лексикон и от «фиксировать» (и компании) массово возникнет резкий зуд чуть пониже спины у читающих русскую версию Pro Git.

«Фиксация» звучит нормально. Жаль не прижилось.

В науке такое мнение тоже когда-то доминировало, но проверку временем оно не прошло.

Как наименее поврежденное «переводом». Серьезно, некоторые вещи лучше не переводить. Меня в своё время коробило от «нитей»(threads). Я понимаю, что оно так может и правильнее, но всё же даже вариант «потоки» звучит менее уныло.

Хотя с другой стороны kernel тот же переводят как «ядро» и это вполне себе прижившийся вариант. Хз

Не ссыте обогащать русский язык, это всем на пользу.

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

Проголосовал за «фиксация/зафиксировать», но нужно как минимум упомянуть, что в повседневном волапюке используется «коммит/закоммитить».

Про «фиксацию» в значении коммита слышу впервые.

Про «фиксацию транзакции» в СУБД тоже не слышал?

Не вижу никаких преимуществ у «фиксации». Такое же иностранное слово как и «коммит», с той только разницей что программисты не поймут о чем речь.

Ты говоришь так, будто «фиксация» русское слово.

В СУБД слышал. Не очень понятно как одно связано с другим.

Меня в своё время коробило от «нитей»(threads). Я понимаю, что оно так может и правильнее, но всё же даже вариант «потоки» звучит менее уныло.

Ох уж поиски русских терминов от людей с именами Иван или Александр.

Про «фиксацию» в значении коммита слышу впервые.

Про «фиксацию транзакции» в СУБД тоже не слышал?

В СУБД слышал. Не очень понятно как одно связано с другим.

Глаголом «to commit» // К.О.

Для программистов, понятное дело, в результате «профдеформации», слово «коммит» выглядит родным, но должно ли это сказываться на переводе?

А перевод делается для чего, и для кого? Чтобы показать «неверным» глубину их падения?

Это разные области и специалисты там часто не пересекаются. Зачем связывать одно с другим, если «коммит» всеми уже используется? У программистов 1С, например, есть целый пласт терминологии, которая нигде больше не встречается.

Коммит / Закоммитить конечно же.

Про «фиксацию транзакции» в СУБД тоже не слышал?

В СУБД слышал. Не очень понятно как одно связано с другим.

Это разные области и специалисты там часто не пересекаются

Это одно слово, с одним и тем же значением. «to commit a revision» и «to commit a transaction» по смыслу очень близки.

Зачем связывать одно с другим, если «коммит» всеми уже используется?

Все же, как переводить термин Git: «commit» (сущ.) / «to commit» (глаг.)?

Я считаю, что надо не дословно переводить, а по смыслу действия. Но тогда надо, чтобы перевод стал общераспространенным. А вот как вы на русском языке сегодня стали бы искать в google действие, аналогичное «to commit»?

Если коммит, то google может и по англоязычному commit сможет поискать, так как часто транслитерацию делает. Есть плюс от такого такого прямого заимствования.

А если все же переводить, то как? Про фиксацию в первый раз вообще слышу. Даже в голову не пришло бы так переводить и искать в поисковике. Я бы использовал в поиске слова «патч», «исправление», «коммит». А если мы новый термин ищем, то, может, «вклад»/«приложить» использовать?

Термин, появившийся не в русском языке, имеет право на транслитерацию.

спользуют перевод «фиксация (сущ.) / фиксировать (глаг.)» (от «фиксация транзакции» из терминологии БД, что логично):

Чертовски логично и здраво, но уже прижился вариант коммит / закоммитить, так-что неважно что там логично и правильно.

Тебе не кажется, что будет странно в книге ориентированной для программистов видеть такие строки:

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

Мне кажется коммит/закоммитить наиболее очевидно. А чтобы вообще всем было понятно, где-нибудь в первых главах нужно дать объяснение, что такое коммит и что значит закоммитить; для тех, кто впервые знакомится с DVCS.

Мне кажется коммит/закоммитить наиболее очевидно.

В науке такое мнение тоже когда-то доминировало, но проверку временем оно не прошло.

Разве? Я не очень в теме, но по-моему серьёзный математик/физик/естественнонаучник без английского просто не сможет существовать.

Источник

Git для начинающих. Урок 4.
Коммиты и история коммитов
Работа с файлами

Видеоурок. Часть 1. Практика, основы работы с коммитами и историей коммитов

Видеоурок. Часть 2. Практика, дополнительные приемы и фишки

Видеоурок. Часть 3. Общие наблюдения и советы. Как делать «хорошие» коммиты

Конспект урока

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

Что такое коммит

По-научному это сохранение состояния, фиксация или слепок изменений.

Как сделать коммит

Представим, что мы добавляем блок учеников на сайт. Добавляем новую разметку в index.html и новые стили в main.css. Чтобы сохранить изменения, нужно их закоммитить. Но предварительно сообщить git, какие именно файлы мы хотим положить в коммит. Команда git add добавляет (или подготавливает) файлы к коммиту. Можно добавить файлы по отдельности, вот так

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

Создаем сам коммит

Состояние файлов в git. Измененные и подготовленные файлы

Подготовленные файлы отличаются от измененных тем, что они «подготовлены» к коммиту, то есть будут добавлены в следующий коммит.

git add filename добавляет или подготавливает файл к коммиту.
git reset filename удаляет файл из подготовленных к коммиту.

Содержимое файлов при этом не меняется. Один файл может одновременно находиться и в измененных, и в подготовленных. Это происходит, если мы добавили файл, но не закоммитили и продолжили делать в нем измения.

Из чего состоит коммит

Каждый коммит имеет

Как добавить файлы и сделать коммит одной командой

Отслеживаемые и неотслеживаемые файлы

История коммитов, git log

Все коммиты можно посмотреть в истории коммитов. История хранит все данные обо всех коммитах проекта. Показывается история командой

История включает в себя все сведения о коммитах: хэш, автор, дата и список изменений. Список изменений смотреть командой git show по хэшу коммита

Если мы сделали коммит, но хотим поправить его commit message

Эта команда перезапишет сообщение последнего коммита. Это перезаписывание истории, операция опасная. Лучше делать ее только до того, как отправили коммит на сервер (push разберем через урок)

Откат коммитов, git revert

Если мы сделали неверный коммит и хотим откатить изменения, сделанные в нем, то поможет команда git revert

Работа с файлами

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

При обычном переименовании файла в файловом менеджере или командой mv git сначала показывает 2 файла: старый удаленный и новый неотслеживаемый. Чтобы git понял, что этот файл именно переименованный, нужно сначала добавить эти файлы в подготовленные к коммиту

Тогда при команде git status файл будет отображаться именно как переименованный

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

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

Командная строка vs IDE

Работа в PhpStorm продемонстрирована в первых двух частях видео.

Как и в прошлом уроке мы видим, что некоторые вещи удобнее делать в IDE. Например, процесс добавления файлов (git add) в PhpStorm при создании коммита почти не привлекает внимания. Но важно понимать, что такое git add и зачем он нужен. И что любая IDE под капотом все равно выполняет базовые команды git. Просто для нас предоставляется удобная обертка, чтобы мы больше сосредоточились на самом проекте, а не на git.

Наблюдения и советы при работе с коммитами

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

Используйте удобные инструменты в IDE, но не забывайте командную строку. В ней вы лучше будете понимать, как устроен git, как он работает

Хорошие и плохие коммиты

С точки зрения git коммиты не бывают плохими и хорошими. Но есть удачные и неудачные подписи к коммитам с точки зрения наших коллег. Несколько примеров

Добавлен файл VipClient
Работа с vip-клиентами вынесена в отдельный класс
По первому коммиту можно предположить, что в VipClient мы скорее всего работаем с ВИПами. Во втором коммите это точно понятно, плюс дополнительная информация, что это отдельный класс.

Поправлены стили в main.css
Рефакторинг стилей в main.css
Первый коммит говорит о правке стилей, но непоянтно, что именно поправлено. Бага? Новые значения? Изменен цвет текста по рекомендации дизайнера? Второй коммит ясно указывает, что это рефакторинг

Маленький фикс
Исправлена опечатка в заголовке title страницы «О компании»
Коммит «маленький фикс» даже приблизительно не говорит, в чем он заключается. Второй коммит дает полное представление

Немного о философии коммитов

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

Мы больше думаем о том, что мы работаем не одни, а в команде. История коммитов общая для всего проекта. Чем лучше мы научимся формировать и подписывать коммиты, тем легче будет ориентироваться в истории нам самим и нашим коллегам.

В любом проекте важны не только код и его структура, но и история коммитов и хорошие commit message.

На этом все. В следующем уроке мы будем больше работать с историей коммитов и посмотрим различные варианты использования команды git log

Источник