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

Обновлено: 06.07.2024

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

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

Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.

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

Установить git на свою машину очень просто:

  • Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
  • Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
  • OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:

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

Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

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

Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.

status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:

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

Если нам нужно добавить все, что находится в директории, мы можем использовать

Проверим статус снова, на этот раз мы должны получить другой ответ:

Коммит представляет собой состояние репозитория в определенный момент времени. Это похоже на снапшот, к которому мы можем вернуться и увидеть состояние объектов на определенный момент времени.
Чтобы зафиксировать изменения, нам нужно хотя бы одно изменение в области подготовки (мы только что создали его при помощи git add), после которого мы может коммитить:

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

1. Подключение к удаленному репозиторию

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

Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого - push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

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

3. Клонирование репозитория

Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.

Новый локальный репозиторий создается автоматически с GitHub в качестве удаленного репозитория.

4. Запрос изменений с сервера

Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.

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

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

  • Уже рабочая, стабильная версия кода сохраняется.
  • Различные новые функции могут разрабатываться параллельно разными программистами.
  • Разработчики могут работать с собственными ветками без риска, что кодовая база поменяется из-за чужих изменений.
  • В случае сомнений, различные реализации одной и той же идеи могут быть разработаны в разных ветках и затем сравниваться.

1. Создание новой ветки

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch

Это создаст новую ветку, пока что точную копию ветки master.

2. Переключение между ветками

Сейчас, если мы запустим branch, мы увидим две доступные опции:

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

3. Слияние веток

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

Изменения завершены, теперь мы можем переключиться обратно на ветку master.

Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

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

1. Отслеживание изменений, сделанных в коммитах

У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
[spoiler title='Вывод git log']

[/spoiler]
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
[spoiler title='Вывод git show']

[/spoiler]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
[spoiler title='Вывод git diff']

[/spoiler]
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.

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

Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита - использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:

3. Исправление коммита

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

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

4. Разрешение конфликтов при слиянии

Помимо сценария, описанного в предыдущем пункте, конфликты регулярно возникают при слиянии ветвей или при отправке чужого кода. Иногда конфликты исправляются автоматически, но обычно с этим приходится разбираться вручную — решать, какой код остается, а какой нужно удалить.
Давайте посмотрим на примеры, где мы попытаемся слить две ветки под названием john_branch и tim_branch. И Тим, и Джон правят один и тот же файл: функцию, которая отображает элементы массива.
Джон использует цикл:

Тим предпочитает forEach:

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
[spoiler title='Вывод']

[/spoiler]
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним - конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

Когда все готово, нужно закоммитить изменения, чтобы закончить процесс:

Как вы можете заметить, процесс довольно утомительный и может быть очень сложным в больших проектах. Многие разработчики предпочитают использовать для разрешения конфликтов клиенты с графическим интерфейсом. (Для запуска нужно набрать git mergetool).

5. Настройка .gitignore

В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore

  1. Создайте вручную файл под названием .gitignore и сохраните его в директорию проекта.
  2. Внутри файла перечислите названия файлов/папок, которые нужно игнорировать, каждый с новой строки.
  3. Файл .gitignore должен быть добавлен, закоммичен и отправлен на сервер, как любой другой файл в проекте.

Вот хорошие примеры файлов, которые нужно игнорировать:

  • Логи
  • Артефакты систем сборки
  • Папки node_modules в проектах node.js
  • Папки, созданные IDE, например, Netbeans или IntelliJ
  • Разнообразные заметки разработчика.

Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:

Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.

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

Bitbucket — это сервис для хостинга систем управления версиями кода (Version Control System, VCS). Через такую систему разработчики отслеживают изменения в коде. Официальное руководство по использованию Bitbucket— здесь.

Что такое VCS

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

Bitbucket. Облачный хостинг VSC и его возможности

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

Обновление подписки на сервис увеличивает количество минут сборки и объем хранилища больших файлов, включенных в пакет: 3$ (приблизительно 220 руб.) в месяц для стандартной учетной записи и 6$ (приблизительно 440 руб.) для премиум-версии. У сервиса GitHub есть корпоративная версия; ее аналог — премиум у Bitbucket — стоит 21$ в месяц (1550 руб.).

Другие особенности Bitbucket

Гибкость. Данные в Bitbucket можно импортировать из множества других сервисов: Git, CodePlex, Google Code, SourceForge и SVN.

Интеллектуальный семантический поиск. В Bitbucket зашит семантический поиск JQL. Он сканирует ваш синтаксис, чтобы найти определения, соответствующие вашему запросу, а не просто имена переменных. Это делает поиск более быстрым.

Wiki-функция. Каждый bitbucket repository (репозиторий) может иметь свою собственную вики. Эта функция включает всю необходимую информацию и заметки по работе с платформой. Кроме того, вы можете использовать вики для постоянного размещения документации по ПО.

Интеграция с Jira. Jira — ПО, которое позволяет планировать задачи, управлять проектами и отслеживать ошибки. Bitbucket легко интегрируется с ним: оба проекта принадлежат компании Atlassian. Если вы используете их вместе, можете установить фиксацию кода для автоматического обновления задач в Jira.

Как создать приватный репозиторий в Bitbucket

Репозиторий (repository)

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

Что такое VCS и для чего они нужны - гуглим, статей на эту тему полно.

Git (не путать с GitHub) создает локальный репозиторий в папке с вашим проектом. (скрытая папка .git) который будет хранить версии ваших кодов.

Управлять этим репозиторием можно через командную строку, или средствами ide (если она поддерживает работу с git'ом)

Происходит это следующим образом:
- Вы создаете проект.
- Вы создаете репозиторий (команда из командной строки (см доки по гиту) или соответственное меню в IDE.
- Пишете классы, файлы и т.д вашей программы.
- Делаете Commit (помещаете в созданный локальный репозиторий то, что вы "натворили")
- Далее можете создать новый branch (ветку) (а можете и не создавать )
- Внести изменения в код, закоммитить. Вернуться к предыдущей ветке.. ну и т.д. (Как всем этим пользоваться полно доков и статей.)

Помимо локально репозитория существуют еще и удаленные репозитории. Они существуют совместно с локальным репозиторием и отдельно от него работать с ними не получится.
Пример таких репозиториев GitHub и bitbucket.
Работа с ними это, по сути, синхронизация вашего удаленного репозитория с локальным.
Вам нужно зарегистрировать аккаунт на одном из этих сайтов.
Затем создать новый репозиторий. (под каждый проект свой) (Название удаленной репы не важно).
Специальной командой сделать привязку вашего локального репозитория к удаленному. (Ее можно найти на стартовой странице только что созданного удаленного репозитория)
Выглядит она примерно вот так:

После "привязки" удаленного репозитория, нужно выгрузить в него коммиты из локального репозитория.
Для этого делается Push (см доки по гиту или IDE)
После пуша ваш проект появляется на соответствующем сайте. Вы можете дать ссылку на него своим друзьям. И они с помощью этой ссылки смогут легко открыть ваш проект у себя на компьютере. Но те изменения что они сделают в проекте они останутся только в их локальных репозиториях. Внести изменения в ваш удаленный репозиторий у них так просто не получится. (он же для них readonly)

Для того что бы внести изменения в ваш репозиторий им нужно сделать Fork. (Зайти на сайт и там сделать Fork вашего проекта).
Fork - это клонирование(копирование) вашего проекта на аккаунт к другу.
Далее друг импортирует созданную копию к себе на компьютер (при этом из удаленного репозитория копируются файлы и создается локальный репозиторий)
Друг вносит изменения
Делает коммит (в локальный репозиторий)
Делает пуш в удаленный репозиторий (копию вашего проекта)
А затем может сделать Pull в ваш репозиторий (тот с кого был сделан форк).
Когда он сделает Pull вам на сайте придет оповещение. (Запрос на изменение вашего репозитория)
Вы можете его просмотреть, принять или отклонить.

Я работаю в IDEA, сделаю в ней простой пример.
Создаю новый проект.


IDEA создает служебные файлы (.idea, *.iml), которые мне не хотелось бы добавлять в репозиторий (ведь далеко не факт, что другие пользователи будут открывать мой проект в IDEA) для того что бы их убрать гуглим gitignore
в IDEA я делаю так:
(внизу IDE)


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


Созданный класс добавлен в локальный репо.
Теперь выгрузим это все на гитхаб.
Для этого создаем на сайте новый репозиторий. Я сделал на гитхабе и назвал его HelloWorld.
Ищем там команду привязки и вводим ее в командную строку. (я воспользуюсь Терминалом IDEA)

Буду признателен за правки, дополнения и т.д =) Все исправлю, все добавлю =)

Наконец-то я бегу git commit -m 'First commit' . Есть 0 изменений, 0 вставок и 0 удалений! Почему мои файлы не передаются? Я использую push и pull так же.

редактировать Вот полный журнал:

Вы действительно должны сделать git push origin master , а не просто git push . Это связано с тем, что стандартное поведение git push заключается в том, что каждая ветвь перемещается к одной с тем же именем на удаленной стороне, пока существует удаленная ветвь с таким именем . В этом случае ваш репозиторий BitBucket полностью пуст (без master ветвления, так как нет никаких коммитов), поэтому никакие ветки не будут вытеснены поведением по умолчанию git push или git push origin . Ваш толчок сработает, если вы сделаете:

. но так как это ваш первый толчок, вы должны сделать:

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

Попробуй git push origin master .

Попробуйте вернуться обратно в bitbucket и просмотреть список файлов репозитория в веб-браузере. Вы должны увидеть свой файл там.

Ваша конфигурация указывает на слияние с ref 'master' с пульта, но такой ref не был получен.

Обратите внимание, это особенно сбивает с толку, потому что запуск вручную "git fetch --tags . " занимает другой путь кода, а FETCH_HEAD остается в хорошей форме.

Читайте также: