Создаем ветку на основе конкретного коммита

Опираться будем на уникальный идентификатор коммита. Чтобы найти его, напишем:

git log

Выделен коммит с комментарием “added hello world…”. У него уникальный идентификатор — “6c44e53d06228f888f2f454d3cb8c1c976dd73f8”. Нужно создать ветку development начиная с этого коммита. Для этого напишем:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

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

git statusgit log

И правда: получилось, что у нас два коммита. Кстати, интересный момент: в этой ветке еще нет файла.gitignore, поэтому наш скомпилированный файл (GitTest.class) теперь подсвечивается в untracked состоянии. Теперь можем провести еще раз ревизию наших веток, написав:

git branch –a

Видно, что есть две ветки — master и development — и сейчас стоим на development.

Создаем ветку на основе текущей

Второй способ создания ветки — создание на основе другой. Я хочу создать ветку на основе master ветки, поэтому нужно сперва перейти на нее, а уже следующим шагом — создать новую. Смотрим:

· git checkout master — переходим на ветку master;

· git status — проверяем, точно ли на мастере.

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

git checkout -b feature/update-txt-files

Если есть сомнения, что эта ветка будет не такой же, как и master, можно это легко проверить, написав git log и посмотреть на все коммиты. Там их должно быть четыре.

Размолвим конфликты

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

То есть, есть главная ветка. От нее в какой-то момент создают второстепенную, в которой происходят изменения. Как только работа сделана, нужно слить одну ветку в другую. Создаем ветку feature/update-txt-files. Как написано в имени ветки — обновим текст.

Теперь нужно создать новый коммит:

git add *.txtgit commit -m “updated txt files”git log

Теперь, если мы хотим смерджить feature/update-txt-files ветку в master, нужно перейти в master и написать git merge feature/update-txt-files:

git checkout mastergit merge feature/update-txt-filesgit log

Как результат — теперь и в мастер ветке есть коммит, который был добавлен в feature/update-txt-files. Эта функциональность добавлена, поэтому можно удалить фиче (feature) ветку. Для этого напишем:

git branch -D feature/update-txt-files

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

git checkout -b feature/add-header... делаем изменения в файле

git add *.txtgit commit -m “added header to txt”

Переходим на master ветку и также обновляем этот текстовый файл в той же строке, что и фиче ветка:

git checkout master… обновили test_resource.txt

git add test_resource.txtgit commit -m “added master header to txt”

И теперь самый интересный момент: нужно смерджить изменения из feature/add-header ветки в master. Мы находимся в мастер ветке, поэтому нужно только написать:

git merge feature/add-header

Но мы получим результат с конфликтом в файле test_resource.txt:

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

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

1. между “<<<<<<< HEAD” и “=======” находятся изменения мастер, которые были в этой строке в мастер ветке.

2. между “=======” и “>>>>>>> feature/add-header” находятся изменения, которые были в feature/add-header ветке.

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

Посмотрим на статус изменений, описание будет несколько другим. Будет не modified состояние, а Unmerged. Так что смело можно было добавить пятое состояние… Посмотрим:

git status

Убедились, что это другой случай, необычный. Продолжаем:

git add *.txt

В описании можно заметить, что предлагают написать только git commit. Слушаем и пишем:

git commit

И все: таким образом мы сделали это — решили конфликт в консоли.