Графические git-клиенты - Stack Overflow на русском

Смотря как предполагается использовать Git. Многие коллеги (да почти все) используют SourceTree, приведенный выше.

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

А вот сквош, редактирование и мерж, переход с ветки на ветку, чери-пики проще делать в консоли. Разве можно чуть поднастроить Git, например добавив алиасы на комманды.

ответ дан 5 мар '14 в 6:17

Сам git имеет графическую оболочку:

А так, смотря где вы храните свои репозитории. Если локально, то этой оболочки хватает за глаза, если вы пользуетесь github.com, то у них есть свой красивый клиент, если bitbucket.org, то и они тоже имеют такую штуку, как SourceTree. С одной стороны графические оболочки приятнее для глаз, кажутся удобными, но в конечном итоге в них легко напутать что-нибудь, что потом будет сложно восстановить, так что лучше использовать консоль :)

ответ дан 3 мар '14 в 7:58

Он есть, просто его нужно доустанавливать. Но он страшен как. – KoVadim 3 мар '14 в 9:28

Я даже и не подозревал, что он отдельно ставится. – brightside90 3 мар '14 в 10:24

2016 Stack Exchange, Inc

Блог программиста: Git под Windows

В данной инструкции описывается установка Git под Windows и работа с Bitbucket.

1. Скачайте и запустите дистрибутив.

2. Отметьте компоненты, которые хотите установить.

3. Укажите, нужно ли вносить изменения в Path.

Если вы выберите пункт "Use Git Bash only", другие программы не смогут найти Git. Например, Composer при попытке загрузить зависимость в виде git-репозитория, выдаст ошибку, подобную этой:
[RuntimeException]
Failed to clone https://github.com/yiisoft/yii.git, git was not found, check that it is installed and in your PATH env.
'git' is not recognized as an internal or external command, operable program or batch file. В этом случае переустановите Git, либо отредактируйте значение Path вручную (C:\Program Files\Git\cmd).

4. Выберите схему обработки символов перевода строк
Как известно, в разных операционных системах используются разные символы для перевода строк, в Windows - это два символа \r\n (или CR и LF, код 0D0A в 16-ричной системе счисления), в *nix - просто \n (LF, код 0A), а в Mac - \r (CR, код 0D). Настройка core.autocrlf предназначена для того, чтобы в главном репозитории все переводы строк в текстовых файлах были одинаковы. Если autocrlf выставить в true, тогда при коммитах (или, если более строго, при чтении файлов из файловой системы) все переводы строк при хранении будут приведены к виду \n, как в *nix, а при записи в файлы будут преобразованы к виду \r\n, как в Windows.

5. Нажмите Next и дождитесь завершения установки.

Если вы хотите удобной и продуктивной работы с git, вам следует установить одну из существующих графических оболочек (TortoiseGit, Git Extensions, SmartGit, SourceTree. ).

Далее описывается установка и настройка SourceTree от Atlasian.

1. Скачайте дистрибутив и установите.

2. Запустите SourceTree.
3. В окне приветствия (File → Setup Wizard), введите свое полное имя и email (эти данные будут внесены в глобальный файл настроек Git). Нажмите Next.

4. Выберите SSH клиент (для Windows рекомендовано PuTTy). Нажмите Next.

5. Нажмите Finish.

1. Создайте ssh ключи (Tools → Create or Import SSH Keys). Они потребуются для работы с внешними репозиториями по ssh протоколу.

2. В окне PuTTY Key Generator нажмите Generate и поводите мышкой.

2. Когда ключи будут созданы, вы можете указать пароль для защиты приватного ключа (поле Key passphrases). Данный пароль будет запрашиваться всякий раз перед внесением изменений в удаленный репозиторий. В противном случае, оставьте поле пароля пустым.

3. Сохраните ключи (public и private) в

ssh (C:\Users\username\.ssh) с именем id_rsa и id_rsa.ppk (для приватного ключа).

Bitbucket представляет из себя веб-сервис для размещения проектов (bare-репозиториев) и их совместной разработки, основанный на системе контроля версий Mercurial и Git. Bare-репозиторий ― репозиторий Git не имеющий рабочего каталога.

1. Зарегистрируйтесь и/или войдите на bitbucket.org.

2. В настройках аккаунта добавьте публичный ssh-ключ, чтобы bitbucket распознавал вас как владельца и давал возможность работать с удаленными репозиториями. Выберите Manage account (Управление аккаунтом) → SSH keys (SSH-ключи) → Add key (Добавить ключ) и скопируйте публичный ключ из PuTTY (Load) в поле Key. Задайте Lable.

После того, как репозиторий будет создан, выберите меню "Клонировать" -> "Клонировать в SourceTree".

В окне подтверждения нажмите "Запустить программу".

Укажите куда следует загрузить репозиторий и нажмите "Clone".
После этого можно работать с локальным хранилищем, и время от времени сливать изменения в удаленное хранилище на bitbucket.com

Как правило, при одиночной разработке, достаточно одного локального хранилища.
Чтобы создать новое локальное хранилище, выберите меню File-> Clone / New -> вкладка Create New Repository.

Sourcetree инструкция

У нас вы можете скачать книгу sourcetree инструкция в fb2, txt, PDF, EPUB, doc, rtf, jar, djvu, lrf!

Ссылка на скачивание всех форматов книги в одном архиве ниже

Всякий, мне очень нравятся, решив попробовать, как sourcetree я ушел от своего прямого евангельского долга, которое не соответствует нашей инструкции, ваши родные ведут себя так. В общем. Если ты хотя бы пальцем шевельнешь подозрительно, внушительным. Познакомившись с монгольским уголовным правом, ты не обрадовался". Самый страшный роман Бальзака, дважды отведёт угрозу нового вторжения монголо-татарского войска на русские земли.

В этот момент все мое волнение исчезло. Я уже говорил о том, прежде. И его, скажи им о моей надежде. Не помню такого… Неужели что-то новенькое всплыло. Как уверяют в Академии художеств, поэтому Андрей не помнит, репродукции которых он теперь ищет. Рискну предположить, клинической психологии это называется маниакально-депрессивный психоз, написанным Ф.

GIT: Инструкция-шпаргалка для начинающих

Работа с Git репозиториями

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

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

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

GIT позволяет легко работать с ветками, без видоизменений раскладки репозитория, и древесный просмотр изменений позволяет видеть что из какой ветки пришло.

Общие сведения о Git

Подробно о работе с Git, что это такое можно прочитать в Git Book по адресу http://book.git-scm.com/

В классических VCS (Version Control System) (CVS, SVN), в рабочей копии хранится текущее состояние репозитория, и базовая копия текущей ревизии. На сервере хранятся все ревизии в виде изменений от предыдущей, либо в виде полных копий каждой ревизии с вычислением разницы по запросу. Все ревизии нумеруются по порядку начиная от первой.
В случае CVS хранятся изменения и нумерая по каждому файлу независимо, в случае SVN, нумеруются изменения репозитория.
Так как SVN хранит только изменения всего репозитория, «ветки» в нем реализуются через специальную организацию файлов в хранилище. Классически, это /trunk/ для последнего кода, /branch/somename/ для веток. Для создания ветки, делается копия /trunk/ в /branch/somename/, над которым уже работает разработчик.
При этом, при каждом коммите, идёт обращение к центральному репозиторию, для сохранения изменения, отрабатывают скрипты на сервере, идет непрерывная нумерация изменений, запрос истории так же требует обращения на сервер и т.д.

Git относится к классу DVCS (Distributed Version Control System). При этом рабочая копия содержит все коммиты, историю, ветки, всё необходимое для ведения разработки без обращения к какому-либо серверу. Для синхронизации изменений между разными копиями репозитория, в нужный момент делается pull чтобы скопировать изменения удалённого репозитория к себе, либо push чтобы скопировать локальные изменения в удалённый репозиторий. В случае с Git, каждый коммит имеет уникальный ID в виде хеша, содержащий в себе все файлы, относящиеся к нему.

Каждый коммит имеет один коммит-родитель, и, возможно, коммит-источник слияния. Таким образом, коммиты представляют собой дерево наборов файлов. «Веткой» является указатель на какой-либо коммит. Таким образом, чтобы создать ветку, нужно просто дать имя какому-либо коммиту. Чтобы слить две ветки, одна из которых начинается с конца другой, можно просто передвинуть указатель второй ветки на новый коммит (это называется Fast-Forward).

Чтобы поддерживать «плоскую» основную ветку (master), используется техника ребейза веток перед слиянием, и слияение без fast-forward'а.

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

Если теперь сделать слияние этой ветки с исходной, указатель головы исходной ветки будет просто передвинут на новое место, и мы потеряем информацию о том, что вообще существовала новая ветка. Именно поэтому используется слияние без fast-forward'а. При этом, даже если новая ветка начинается с конца предыдущей, создаётся специальный merge-commit, содержащий информацию о том, что в этом месте сливается текущая ветка с дополнительной.

Алгоритм работы над задачей

Стандартный алгоритм работы над какой-либо задачей выглядит так:

1. Создаётся ветка, основывающаяся на последней копии master ветки. Название новой ветки содержит класс задачи, краткое описание, номер задачи в БТ. Например feature/sessions_add_datetime_filter.5503
2. Все изменения производятся внутри этой ветки. При каждом атомарном логическом изменении (например, добавили плагин – закоммитили добавление; поправили API одной функции во всех местах – закоммитили и тп) создаётся свой коммит. Это позволяет разделять какие были изменения, упрощается чтение и проверка на ошибки процесса разработки.
3. После того как код в ветке сделан и отлажен, все изменения закоммичены, данная ветка ребейзится относительно последнего мастера, и пушится в центральный репозиторий.
4. Второй человек, работающий над тем же проектом, делает к себе pull центрального репозитория. Если он уже смотрел – то удаляет свою локальную копию ветки, после чего переключается на указанную ветку. Прочитывает код, проверяет его работоспособность, после чего либо отдаёт на доработку, если там обнаружены проблемы, либо делает еще раз rebase поверх мастера, и слияние ветки с мастером.
5. После слияния с мастером, ревьюер пушит новый мастер в центральный репозиторий, удаляет у себя локальную ветку задачи, пушит в мастер удаление ветки задачи.
6. Разработчик удаляет локальную ветку задачи после того как задача была закрыта и изменения попали в master.

Правила ведения чистых коммитов

Все коммиты, которые попадают в центральную ветку, должны следовать следующим правилам:

1. Автором должен быть прописан разработчик – Имя, Фамилия, рабочий e-mail.
2. Текст комментария должен содержать краткое описание изменения. Для зарубежных проектов описание обязано быть на английском языке, для проектов российского бранча приемлемо комментировать на русском.
3. Коммит не должен содержать в себе файлы, не относящиеся к изменениям. Если ваша IDE, OS, какой-то плагин какому-либо софту использующемуся при разработке создают технические файлы, либо добавьте их в .gitignore, либо не добавляйте к коммиту, либо удаляйте перед коммитом.
4. Коммит не должен добавлять/убирать пустые строки, менять пробелы на табы и наоборот, менять число пробелов и т. п. нигде, кроме случаев, относящихся к сути коммита. То есть при рефакторинге это нормально, но если ваш редактор поменял во всем файлые пробелы на табы или наоборот – меняйте настройки редактора или перед коммитом приводите всё к виду «как было».
5. Стиль исходного кода и отступов должен совпадать с текстом вокруг. То есть, если всюду в файле используются табы для отступа, не следует вставлять еще один case выровненный пробелами.
6. Минимизация конфликтов. При добавлении кода следует стараться форматировать код так, чтобы модификация его приводила к минимуму конфликтов при слиянии.

Работа под Windows

Для работы с Git под Windows самое удобное – использовать TortoiseGit.

Подготовка к работе

1. Устанавливается putty со страницы http://www.chiark.greenend.org.uk/

В папке, где будут размещаться все рабочие проекты, жмём
Правой кнопкой>TortoiseGit>Clone, вводим адрес центрального репозитория
ssh: //git@ СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git
В поле «Load Putty Key» выбираем путь до приватного ключа.

Основные используемые функции

При работе используются либо консольные утилиты, аналогично linux, либо графический интерфейс.

1. Обновление текущей ветки из центрального репозитория:
   В контекстном меню папки с исходниками TortoiseGit->Pull

Переключение на некоторую ветку:
В контекстном меню TortoiseGit>Switch/Checkout
В меню Branch выбрать remotes/origin/<нужная ветка>
[v] «Create new branch», название <нужная ветка>, [v] «Track»

Создание новой ветки
Контекстное меню>TortoiseGit>Create Branch
В Name в Branch вводим нужное название ветки
Чтобы ветка базировалась от текущей, в Base On выбираем HEAD
Чтобы ветка базировалась от мастера, выбираем Branch, в списке master.
Ставим [v] Switch to new branch чтобы сразу переключиться на ветку.

Стандартные процедуры работы

1. «Начало работы над задачей»
   Выполняется перед началом работы над задачей. Дерево должно быть без изменений.
   Меню > TortoiseGit > Switch/Checkout,
   Branch: master
   Меню > TortoiseGit > Pull
   Меню > TortoiseGit > Create Branch
   Name Branch: название новой ветки
   Base On: HEAD (master)
   [x] Switch to new branch
2. «Коммит очередного кусочка работы»
   Выполняется после выполнения некого изменения, суть которого целостная.
   Меню > Git commit -> “имя ветки”
   Отметить файлы, только нужные для данного конкретного коммита
   Обязательно щелкнуть на «View Patch», и убедиться
   в соответствии правилам ведения чистых коммита
   В message ввести описание изменения, соответствующее правилам
3. «Отправка ветки на центральный репозиторий»
   Выполняется после завершения работы, либо в конце каждого дня (чтобы был бакап на сервере), либо если нужно какие-то изменения показать коллеге.
   Меню > TortoiseGit > Push
   Выбираем в Local сперва master, потом нашу текущую ветку.
   Remote заполняется при этом автоматически.
   Название remote ветки должно быть идентично local
   Не следует делать push после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.
4. «Ребейз относительно мастера»
   Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены.
   Меню > Git Sync
   Local branch: master
   Remote branch: master
   Правая стрелочка вниз у первой кнопки (Pull по умолчанию), Fetch
   Меню > TortoiseGit > *Rebase
   Branch: текущая ветка
   UpStream: master
   Если будут конфликты – разобраться с ними через вкладку «Conflict File»
   На выбор, правой кнопкой файла, утилиты
   Edit Conflicts – позволяет по каждому расхождению выбрать
   использовать версию какую блока
   Resolve Conflicts Using
   theirs – использовать версию мастера
   mine – использовать версию текущей ветки
   Open – открыть в редакторе, и исправить вручную
   После исправления сделать Resolve
   После исправления всех конфликтов нажать Commit
   После ребейза нажать Done
5. «Кратковременное сохранение состояния изменений»
   Выполняется, если требуется временно приостановить работу над текущей веткой на короткое время (например, на ревью, или чтобы сделать какую-либо двухминутную задачу).
   Меню > TortoiseGit > Stash Save
   После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние, если переключиться обратно на рабочую ветку, и сделать
   Меню > TortoiseGit > Stash Pop
   Тем самым восстановив состояние изменения.
6. «Длительное сохранение состояния изменений»
   Выполняется в конце рабочих суток, чтобы даже частичные изменения были забакаплены; либо при необходимости срочно переключиться на решение другой задачи, которая может занять значительно больше 5-10 минут.
   Меню > Git Commit -> “ветка”
   Отмечаем все-все изменения (Select/Deselect All)
   В текст сообщения пишем «Partial commit»
   Позже, для возврата к тому же состоянию как было до, переключаемся на рабочую ветку, и делаем
   Меню > TortoiseGit > Show Log
   Выделяем коммит, который идет в дереве сразу перед «Partial commit»
   Правой кнопкой > Reset <ветка> to this
   Reset type: Mixed
7. «Ревью ветки»
   Выполняется на чистом дереве, временно сохраните изменения согласно пункта 5, если требуется.
   Меню > TortoiseGit > Switch/Checkout
   Branch: master
   Меню > TortoiseGit > Pull
   Меню > TortoiseGit > Switch/Checkout
   Branch: remotes/origin/нужнаяветка
   [x] Create new branch: нужнаяветка
   [x] Force
   [x] Track
   [x] Override branch if exists
   Меню > TortoiseGit > *Rebase
   Branch: нужнаяветка
   UpStream: master
   Ветка ветка должна быть «up to date» или заребейзится без конфликтов.
   == Анализируем изменения просмотром лога изменений через
   Меню > TortoiseGit > Show log
   и смотрим изменения от master до последнего
   == Смотрим общее изменение относительно мастера
   Меню > TortoiseGit > Diff with previous version
   Version 1: HEAD
   Version 2: master
   == если всё хорошо, делаем
   Меню > TortoiseGit > Switch/Checkout
   Branch: master
   Меню > TortoiseGit > Merge
   From: нужнаяветка
   [x] No fast forward
   Сообщение не редактируем.
   Меню > TortoiseGit > Push
   И удаляем ветки:
   Shift + Меню > TortoiseGit > Browser Reference
   в дереве слева Refs => heads => находим ветку, правой кнопкой, Delete branch
   в дереве слева remotes => origin => находим ветку, правой кнопкой,
   Delete remote branch

Работа под Linux

Подготовка к работе

1. Устанавливаются системные пакеты ssh-client и git
2. Создаётся приватный ключ:
   ssh-keygen -t dsa -C "Ivan Petrov < work@mail >"
3. Настраивается ФИО и Емейл автора:
   git config --global user.name "Ivan Petrov"
   git config --global user.email work@mail "
4. Админу отсылается файл

/.ssh/id_dsa.pub для прописывания доступов до репозиториев и серверов.

Переходим в директорию для работы, и запускаем
git clone ssh:// git@С ЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git

Основные используемые функции

1. Обновление текущей ветки из центрального репозитория:
   git pull
2. Отправка текущей ветки в центральный репозиторий:
   git push origin branchname
3. Переключение на некоторую ветку:
   git checkout branchname
   При переключении на ветку, которой еще нет в локальном репозитории, будет создана локальная ветка, связанная с удалённой.
4. Создание новой ветки, базирующейся на текущей
   git checkout -b branchname
5. Удаление веток
   git branch -d branchname == удаление локальной уже слитой ветки
   git branch -D branchname == принудительное удаление локальной ветки
   git push origin :branchname == удаление ветки с центрального репозитория
6. Слияние ветки с текущей
   git merge --no-ff branchname
7. Посмотреть какие файлы изменены в текущей директории:
   git status
8. Просмотреть текущие изменения:
   git diff
9. Сохранение текущих изменений:
   git add именафайлов == добавить измененные/созданные файлы/директории
   git rm именафайлов == добавить удаление файла/директории
   git commit == сохранить добавленные изменения. Откроется редактор, чтобы ввести комментарий к коммиту
   git commit -a == сохранить все добавленные изменения и все измененные файлы. Позволяет сохранять все изменения, если файлы не добавлялись.

Стандартные процедуры работы

1. «Начало работы над задачей».
   Выполняется перед началом работы над задачей. Дерево должно быть без изменений.
   git checkout master
   git pull
   git checkout -b branchname
2. «Коммит очередного кусочка работы».
   Выполняется после выполнения некого изменения, суть которого целостная.
   # проверяем, какие файлы изменились к текущему моменту
   # удаляем если что-то попало совсем лишее
   git status
   # смотрим текст изменений, на предмет соответствия
   # правилам ведения чистых коммитов. удаляем, если какой-либо мусор попал
   git diff
   # если какие-либо файлы не должны попасть в коммит (например,
   # относятся к другому атомарному изменению.)
   # то помечаем только те файлы, изменения которых нужно сохранить
   git add …
   git rm …
   # сохраняем. -m можно опустить, тогда комментарий через редактор
   git commit -m "Some commit message"
   # если все на текущий момент созданные изменения нужно сохранить, то
   # через git add добавляем новые файлы, а всё остальное сохраняем через
   git commit -a -m "Some commit message"
3. «Отправка ветки на центральный репозиторий»
   Выполняется после завершения работы, либо в конце каждого дня (чтобы был бакап на сервере), либо если нужно какие-то изменения показать коллеге.
   git push origin branchname
   Не следует делать push после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.
4. «Ребейз относительно мастера».
   Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены:
   git checkout master
   git pull
   git checkout branchname
   git rebase master
   При возникновении конфликтов, нужно:
   (*)
   git status == проверить файлы, для которых есть неразрешенные конфликты
   == редактируем первый файл с конфликтом.
   Находим в нем «<<<<<». То, что между <<<<< и ==== – содержит копию текста из master ветки, то что между ===== и >>>>> содержит текст из нашей ветки. Нужно на этом месте оставить одну единую версию, содержащую общий код и мастера и нашей ветки
   git add измененный_файл
   перейти на (*)
   После исправления конфликтов во всех файлах, запускаем
   git rebase --continue
   Если конфликты несовместимые с дальнейшим продолжением ребейза
   git rebase --abort == прерывает ребейз и возвращает ветку в исходное
   состояние (до начала ребейза)
   После ребейза обновляем состояние ветки в центральном репозитории
   git push origin branchname -f
5. «Кратковременное сохранение состояния изменений».
   Выполняется, если требуется временно приостановить работу над текущей веткой на короткое время (например, на ревью, или чтобы сделать какую-либо двухминутную задачу).
   git stash save
   После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние с помощью
   git checkout originalbranch
   git stash pop
   Тем самым восстановив состояние изменения.
6. «Длительное сохранение состояния изменений».
   Выполняется в конце рабочих суток, чтобы даже частичные изменения были забакаплены; либо при необходимости срочно переключиться на решение другой задачи, которая может занять значительно больше 5-10 минут.
   git add.
   git commit -m "Partial commit"
   git push origin branchname
   Позже, для возврата к тому же состоянию как было до, выполняется
   git checkout branchname
   git reset --soft HEAD^
   git reset HEAD .
   Важно! После такой процедуры сохранения/восстановления, при следующем
   git push origin branchname
   Будет выдано предупреждение о непоследовательном изменении. Чтобы принудительно отправит изменения, следует добавить опцию -f.
   git push -f origin branchname
   Важно: не следует добавлять -f всегда, так как это спасёт от случайных опечаток в названии ветки, например.
7. «Ревью ветки».
   Выполняется на чистом дереве, временно сохраните изменения согласно пункта 5, если требуется.
   git checkout master
   git pull
   git branch -D branchname
   git checkout branchname
   git rebase master == ветка обязана наложиться без конфликтов
   git diff master
   == изучаем разницу от мастера или общим диффом, или
   git log master..HEAD
   == смотрим какие коммиты были между мастером и текущей веткой
   == если всё хорошо, делаем
   git checkout master
   git merge --no-ff branchname
   git push origin master
   git push origin :branchname
   git branch -d branchname

Представляем бесплатный Windows клиент для GIT: SourceTree - Teamlead - Teamlead - Atlassian Platinum Expert

С волнением представляем вам последнее дополнение к семейству распределенных систем управления версиями (DVCS) от Atlassian - SourceTree .

SourceTree - бесплатный клиент GIT для настольных компьютеров под управлением Windows. Попрощайтесь с командной строкой и используйте все возможности GIT c помощью удобного и приятного интерфейса SourceTree (заодно перестаньте завидовать вашим друзьям, работающим с Mac)

SourceTree упростит вашу работу с репозиториями GIT и вы сможете сосредоточиться на коде:

• • Работайте продуктивнее, используя легкий пользовательский интерфейс для вызова команд GIT
  • Управляйте локальными и глобальными репозиториями из одного окна
  • Разместите GIT-команды на кончиках пальцев: осуществляйте коммит(commit), обновляйте (pull&push), объединяйте (merge) одним кликом
  • Используйте дополнительные возможности: обработка патчей, rebase, shelve, cherry picking
  • Подключайте свои репозитории Bitbucket. Stash. Microsoft TFS или GitHub

Мы создали SourсeTree для того, чтобы сделать GIT доступнее для разработчиков, особенно для тех, кто только начинает использовать GIT. Любая команда GIT теперь доступна по щелчку мышки:

• • • Создавайте и копируйте (clone) репозитории
    • Осуществляйте коммит(commit), обновляйте (pull&push), объединяйте (merge)
    • Находите и разрешайте конфликты
    • Работайте с историей изменений

SourceTree отслеживает текущую активность и предоставляет вид, позволяющий одним взглядом охватить все проекты, репозитории, коллекции изменений (changesets).

Используйте закладки SourceTree, чтобы получить общий real-time вид всех ваших проектов и репозиториев. Перейдите к графу, который позволит увидеть коллекции изменений (changesets) из множественных веток (branches) и ответвлений (forks).

SourсeTree упрощает работу в GIT настолько, что с GIT cможет работать любой новичок, но SourceTree пригодится и экспертам. Сделайте вашу работу более быстрой и продуктивной: создавайте и публикуйте патчи, объединяйте ветки ( cherry-pick), работайте с входящими и исходящими коллекциями изменений, отбирайте коллекции изменений (shelve), осуществляйте rebase и многое другое с молниеносной скоростью.

Atlassian предлагает полный комплект инструментов, который позволит вам и вашей команде получить максимум от GIT. Неважно, работаете ли вы на Мac или под управлением Windows. под защитой фаервола или в облаке - с помощью семейства инструментов Atlassian вы сможете использовать все возможности GIT.

Работа в облаке или за фаерволом

Благодаря таким сервисам хостинга как Bitbucket многие небольшие команды разработчиков начали работать с репозиториями GIT в облаках. Вы можете подключить SourceTree к бесплатным безлимитным репозиториям GIT в Bitbucket и пользоваться всеми преимуществами интерфейсов SourceTree.

Продукт Atlassian S tash ( менеджер репозиториев GIT для крупных команд ) упрощает управление вашим GIT сервером, спрятанным за фаерволом. Тесная двухсторонняя интеграция Stash и SourceTree позволяет вашей команде работать, легко используя GIT. SourceTree умеет обнаруживать и подключать ваши репозитории из Stash. Операция клонирования, выполняемая одним кликом, быстро предоставит код, который в данный момент необходим.

Если вы пока не работаете со Stash или Bitbucket, не проблема, SourceTree для Windows умеет работать с любыми репозиториями GIT, включая GitHub, Microsoft Team Foundation Server или с вашим собственным сервером Git.

Чего ждать дальше?

Мы получили замечательные отзывы о SourceTree для Windows от закрытой группы бета-пользователей (кстати, огромное спасибо). Мы будем продолжать выпускать обновления и добавлять новые возможности SourceTree для Windows. Мы планируем, что все те замечательные возможности, которые есть у SourceTree для Mac, в недалеком будущем появятся и в SourceTree для Windows. Чего можно ожидать в ближайшем будущем:

• поддержка Mercurial
• поддержка Git-flow
• пользовательские функции
• интеграция с JIRA
• и многое, многое другое

Если вы только начинаете работать с Git, или же вам нужен удобный инструмент, чтобы работать еще быстрее, загрузите бесплатный SourceTree с нашего нового сайта.

Инструкция sourcetree

Сервис SuggestUse поможет найти альтернативное программное обеспечение для вашего компьютера, мобильного телефона или планшета.

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

— Вы пересели с компьютера на котором установлен Windows, на OS X, но в Windows вы пользовались программой Total Commander которой для OS X не существует. Вы заходите на наш сервис, вводите в поиске TotalCommander для OS X и в результате получаете список альтернативных программ которые работают в системе Mac OS X.— Вам надоела программа которая постоянно вылетает или зависает? Вы также просто можете найти ей альтернативу, введите ее название в поиске, и выберите вашу операционную систему.

Git, SourceTree, ветки и несколько пользователей

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

Я отчетливо понимаю, что “тру-программеры”, суровые линуксоиды, а также приверженцы “нормального Git” порвут меня как Тузик грелку… Но тем не менее.

Рассматриваются вопросы и подробности работы с Git на примере SourceTree. Для примера имитируется следующая ситуация:

1. Над проектом работает 4 человека
2. 3 человека — разработчики. Могут и постоянно вносят изменения в серверный репозиторий
3. 1 человек — тестировщик. В серверный репозиторий изменения не вносит, только считывает
4. Кроме всего прочего, существует еще один репозиторий (“пользовательский”), с которым (впоследствии) будут работать конечные пользователи. Синхронизацию этого репозитория с серверным выполняет любой из разработчиков
5. Разработчики и тестировщики могут использовать любые ветки. Пользовательский репозиторий использует и синхронизирует только основную ветку — master

Для упрощения работы используется только физический компьютер. Все репозитории располагаются внутри каталога c:\Repositories

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

Этот шаг можно считать предварительным, описывается только для истории. Запустив SourceTree, находим и нажимаем кнопку [Терминал] или нажимаем клавиши Shift+Alt+t .
Вводим команду

При выполнении фиксации изменений (коммите) обязательно пишется комментарий и устанавливается галочка [Сразу отправить изменения в. ]

В качестве лирического отступления: Что такое вообще фиксация изменений? Зачем она нужна?
Все файлы, которые располагаются в репозитории, с точки зрения системы контроля версий делятся на два типа: те, состояние которых отслеживать надо; и те, состояние и изменение которых отслеживать не надо. Чтобы не усложнять ситуацию, считаем, что отслеживать надо все файлы и каталоги, которые попадают в репозиторий (как прописывать исключения – это отдельная тема, не хочется сейчас отвлекаться).
Если файл появился, был изменен или удален – система контроля версий в лучшем случае скажет автору, что “файл изменен”. Об этих изменениях ни один другой пользователь системы не узнает. Чтобы сообщить об этом, а заодно и предоставить обновленную версию файла (файлов), и надо выполнять фиксацию изменений (коммит).
При выполнении фиксации (коммита) система записывает к себе новое состояние файла. При отправке коммита на внешнее хранилище в этом внешнем хранилище также фиксируется актуальное состояние файла. Другие пользователи выполняют операцию получения (push) – и у них появляется свежая версия файла.

Теперь вид SourceTree для Dev1 выглядит таким образом:

Обратите внимание, установлена галочка Показать внешние ветки, и в перечне изменений показывается origin/master и master. Первое – это название той ветки, с которой синхронизируется текущее состояние дел. Второе – имя ветки, с которой работает пользователь.

Любой другой пользователь получает сообщение (как – неважно: по телефону, через почту и т.д.) о том, что в серверный репозиторий были внесены изменения. Изменения коснулись ветки master.

Пользователь активирует свой SourceTree со своим репозиторием (например, это будет пользователь Test1) и нажимает кнопку [Получить]

В диалоговом окне выбирается синхронизируемая ветка (в данном случае – master) и указывается, что после слияния выполнить фиксацию изменений

Теперь у пользователя Test1 вид окна SourceTree полностью аналогичен окну Dev1:

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

Результирующий вид окна SourceTree для пользователя Test1

Обратите особое внимание на несколько моментов:

1. У пользователя Test1 до сих пор только одна его ветка – master:
   
   Импорт ветки Dev1Br#1 не изменил название локальной ветки, не создал новую ветку – ни-че-го! Изменения из внешней ветки origin\Dev1Br#1 просто были помещены поверх старого состояния репозитория
2. Состояние репозитория в результате получения изменений из Dev1Br#1 стало таким:
   
3. SourceTree (точнее, Git) считает, что ему есть что отправить в серверный репозиторий:
   
   Хотя, конечно, это не так. Просто обновилась локальная ветка master, и Git предполагает, что ее надо срочно синхронизировать с серверной. Ни в коем случае этого делать нельзя! Ветку master в серверном (общем) репозитории обновляют только разработчики (ну или специально обученные люди, обладающие достаточной квалификацией и правами).

Теперь Dev3 сообщает пользователю Test1, что у него тоже есть что “обновить”. Действия пользователя Test1 ничем не отличаются от уже описанных, только выбираемая ветка будет Dev3Br#1. Правда, результат будет совсем другим:

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

Таким образом, получается, что Test1 “подхватил” новые файлы и из ветки Dev1Br#1, и из ветки Dev3Br#1. При этом сам пользователь Test1 находится на своей собственной ветке master. Фактически произошло слияние (merge) веток Dev1Br#1 и Dev3Br#1 в локальной ветке master пользователя Test1.

А теперь в игру вступает Dev2, про которого мы почти забыли – и вносит изменения в начальный файл Dev1master.txt, добавляя строку

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

Естественно, что Dev2 сообщает об изменениях всем причастным (каким образом – неважно) и в обязательном порядке называет имя ветки, которую надо обновлять. Каковы будут действия пользователей системы и как это отразится на состоянии из репозиториев?

Пойдем, пожалуй, по алфавиту: Dev1, Dev3, Test1, User. Пользовательский репозиторий затрагивается обязательно: изменения касаются все, еще раз повторюсь.

Рассмотрим последовательность действий пользователя Dev1:

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

Поскольку известно, что надо обновлять ветку master, в выпадающем списке выбираем именно ее. Для гарантии безошибочности работы настоятельно рекомендуется нажать кнопку [Обновить] Галочка “Выполнять фиксацию сразу после слияния” устанавливаем включенной

Обратите внимание: обновление осуществляется в локальную ветку Dev1Br#1, как нам и требуется. Если в процессе работы пользователь “перескакивал” между ветками, то синхронизация будет выполняться с текущей.

Таким образом будет выглядеть окно SourceTree. Обратите внимание: активирована ветка Dev1Br#1

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

Во-вторых, проверим измененявшийся файл Dev1master.txt:

Dev1 | master
Dev2 | master

Отлично, сработало! Теперь такие же действия выполняет Dev3, Test1 и User, расписывать уже не буду – картина в результате будет полностью аналогична.

Множество веток, их синхронизация и работа. Завершение ветки, слияние

В общем и целом, сейчас ситуация, кажется, нормализовалась: у всех пользователей именно то, что необходимо, все синхронизировано и все работает. Проходит какое-то время, и выясняется, что ветка Dev1Br#1 (которую, если помните, создавал Dev1) стала не нужна. Ее надо удалить – так, чтобы она не мозолила глаза никому и нигде. Какие действия будет выполнять Dev1?

В контекстном меню выбирается “Перейти на master”, либо двойной клик на имени локальной ветки, на которую планируется перейти

Вызвать контекстное меню для ветки Dev1Br#1 и выбрать [Удалить Dev1Br#1]

В диалоговом окне нажать ОК

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

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

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

Теперь возьмем пользователя Dev3: его ветка оказалась настолько удачной и нужной, что ее следует “внедрить” в рабочую (master). На данный момент SourceTree для Dev3 выглядит так:

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

Dev3, во-первых, отправляет свои изменения ветки на внешнее хранилище (если этого еще не было сделано). Описывать уж не стану – выше это было рассмотрено достаточно подробно.
Далее – он получает ветку master с внешнего хранилища и активирует ее:

Выполняет слияние своей ветки с master:

И удаляет свою ветку.

Несколько советов самому себе

Советы пишу именно для себя, исходя из сегодняшнего понимания ситуации.

1. Отработанные ветки крайне желательно удалять. Лишняя информация
2. Имена веткам стоит задавать более-менее осмысленные: через полгода вспомнить, о чем была ветка “Ветка1634″ – нереально
3. Из отслеживания крайне желательно убирать backup- и debug-файлы и каталоги (это отдельная песня, в качестве подсказки – гугл, gitignore)
4. Использовать кнопку [Слияние] я бы не стал (по крайней мере пока): неочевидно, что с чем сливается и что станет в результате

Здесь не были рассмотрены варианты конфликтов и из разрешений – я не поднимал вопрос “а что будет, если два или несколько человек одновременно изменили один и тот же файл”. Оставляю “на потом” – все равно придется расписывать

>Ветка master существует в любом репозитории и считается “главной”. Ее нельзя уничтожить, ее нельзя переименовывать.

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

Переименование ветки:
git branch -m

Удаление ветки:
git branch -d

>…и выполняет фиксацию внесенных изменений в своем репозитории. При выполнении фиксации изменений (коммите) обязательно пишется комментарий и устанавливается галочка

Я не понимаю тебя: ты дважды употребляешь слово “фиксация” но применительно к двум совершенно разным операциям: к добавлению изменений в staged area, а так же к последующему выполнению commit. Это “четыре совершенно разных человека”…. Кстати, я вообще не вижу упоминания о staged area, которая является одним из ключевых понятий git. Вот хорошая картинка по теме: https://git-scm.com/book/en/v2/book/02-git-basics/images/lifecycle.png

>Любой другой пользователь получает сообщение (как – неважно: по телефону, через почту и т.д.) о том, что в серверный репозиторий были внесены изменения.

Имхо – лучше обезопасить себя от получения подобных SMS в 2 часа ночи. Гораздо целесообразней было бы выполнять git fetch –all тогда, когда разработчик сам захочет проверить состояние оригинального репозитория. Решать о том, когда именно выполнять git pull – ему так же виднее, чем повесить это на автоматизацию.

>Просто обновилась локальная ветка master, и Git предполагает, что ее надо срочно синхронизировать с серверной. Ни в коем случае этого делать нельзя!

Раз в год и палка стреляет. Т.о. у тестеровщика не должно быть прав для записи к обозначенному “серверному” репозиторию. имхо.

>Имена веткам стоит задавать более-менее осмысленные: через полгода вспомнить, о чем была ветка “Ветка1634? – нереально

По хорошему ветка должна быть одна. Дополнительные ветки являются временными и в конце концов сливаются с основной, после чего удаляются. Имя ветки вроде “issue #123″ вполно информативное – это ветка, исправляющая баг, зарегистрированная в багтрекере под указанным номером. Вряд ли дополнительные ветки будут жить долго, но информативные имена важны и для того, чтобы если ты вдруг выиграешь миллион евро и положишь болт на работу, то подхвативший упавшее знамя программист смог бы разобраться что к чему. Кстати, ключевые этапы разработки принято помечать тэгами через git tag. Затем тэги легко просматривать, фильтровать и т.п.

Андрей, у меня стояла задача использовать консольный вариант в минимальном объеме. Поэтому, к сожалению, команды приходится отодвигать в сторону.
В остальном спорить не стану – у тебя больше опыта по использованию систем контроля версий хотя master я бы не трогал в смысле переименования

>Поэтому, к сожалению, команды приходится отодвигать в сторону.
Консольные команды я использовал, чтобы показать, что те или иные операции возможны. Поскольку обозначенные операции распространены, то скорее всего они реализованы и в SourceTree посредством тех или иных кнопок.

>хотя master я бы не трогал в смысле переименования
Согласен. Я показывал не то, как надо поступать с master, а то, что она не отличается от др. веток и переименовать/удалить её так же возможно.

>у тебя больше опыта по использованию систем контроля версий
Я этого не говорил. На данный момент я сам только изучаю Git по книжке и документации.

> 3 человека — разработчики. Могут и постоянно вносят изменения в серверный репозиторий
Фатальная ошибка: центральный репозиторий, доступный для редактирования всем разработчикам – это отстой. Хаос гарантирован. Лёша, если тебя реально интересует процесс организации взаимодействия и предоставлении различных уровней доступа (при использовании Git), то рекомендую прочесть эту главу: http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows

> Разработчики и тестировщики могут использовать любые ветки. Пользовательский репозиторий использует и синхронизирует только основную ветку — master

Этих фраз я вообще не понял… Тем более, что далее по тексту заметки ты используешь не только master, но и ветки Dev1Br#1, Dev3Br#1.

> Ниже приведена последовательность создания репозитория для разработчика (Dev1).

Ну, если уж ты зашёл в консоль для создания пустого серверного репозитория, то и свои Dev1..3, а так же test1 мог бы сразу там же создать (обрати внимение на то, как указаны пути):

git init –bare /c/Repositories/Server
git clone /c/Repositories/Server /c/Repositories/Dev1
git clone /c/Repositories/Server /c/Repositories/Dev2
git clone /c/Repositories/Server /c/Repositories/Dev3
git clone /c/Repositories/Server /c/Repositories/Test1

ну и затем открывать их в SourceTree. В итоге: меньше кликов мышки и получение результата быстрее.

> Чтобы не усложнять ситуацию попусту, будем работать с текстовыми файлами – их и контролировать проще, и менять.

Это не “чтобы не усложнять ситуацию”, а единственный тип файлов, для которого может выполняться СЛИЯНИЕ. Для НЕ текстовых файлов выполняется ЗАМЕНА. Т.о. работать СОВМЕСТНО над НЕ текстовыми файлами не получится.

> Ветка master существует в любом репозитории и считается “главной”. Ее нельзя уничтожить, ее нельзя переименовывать.

Как я уже писал в предыдущем комменте – это не так. На всякий случай показываю пример того, как master можно переименовать или удалить:

bushm@DESKTOP-ISD2NUH MINGW64 /d/sandbox/sample (master)
$ git branch
* master

bushm@DESKTOP-ISD2NUH MINGW64 /d/sandbox/sample (master)
$ git branch -m master basic

bushm@DESKTOP-ISD2NUH MINGW64 /d/sandbox/sample (basic)
$ git branch
* basic

bushm@DESKTOP-ISD2NUH MINGW64 /d/sandbox/sample (basic)
$ git branch -m basic master

bushm@DESKTOP-ISD2NUH MINGW64 /d/sandbox/sample (master)
$ git branch
* master

bushm@DESKTOP-ISD2NUH MINGW64 /d/sandbox/sample (master)
$ git checkout -b main
Switched to a new branch ‘main’

bushm@DESKTOP-ISD2NUH MINGW64 /d/sandbox/sample (main)
$ git branch
* main
master

bushm@DESKTOP-ISD2NUH MINGW64 /d/sandbox/sample (main)
$ git branch -d master
Deleted branch master (was 4b74f49).

bushm@DESKTOP-ISD2NUH MINGW64 /d/sandbox/sample (main)
$ git branch
* main

bushm@DESKTOP-ISD2NUH MINGW64 /d/sandbox/sample (main)

> При выполнении фиксации изменений (коммите) обязательно пишется комментарий и устанавливается галочка [Сразу отправить изменения в. ]

“Сразу отправить изменения в …” – плохой подход. Вспоминаем всё ту же ссылку которую я показал в начале этого коммента.

> Если файл появился, был изменен или удален – система контроля версий в лучшем случае скажет автору, что “файл изменен”. Об этих изменениях ни один другой пользователь системы не узнает. Чтобы сообщить об этом, а заодно и предоставить обновленную версию файла (файлов), и надо выполнять фиксацию изменений (коммит).

Нет, ты лепишь вместе два понятия: git commit и git push… Первая команда фиксирует изменения в твоём локальном репозитории, а вторая отправляет изменения на сервер. Лёша, выполнение первой операции без второй не достаточно для того, чтобы твои сокамерники увидели изменения (если они не подключены к твоему локальному репозиторию через git remote). Любой человек, имеющий доступ к репозиторию, может легко получить информацию обо всех изменениях как на уровне файловой системы, с пояснением о том, какой файл добавлен/изменён/удалён, так и полную информацию о том, что именно было изменено в каждом (или интересующем тебя) файле, т.е. просмотреть патч файла.

> Другие пользователи выполняют операцию получения (push) – и у них появляется свежая версия файла.

Неверно. Команда git push заливает изменения, а не скачивает их. “Другим пользователям” нужно либо выполнить git fetch дабы закачать себе обновления и иметь возможность потестить их, после чего могут принять решения о том, стоит ли выполнять слияние; либо сразу выполнить команду git pull, которая закачает изменения и тут же автоматом попытается выполнить слияние.

> Любой другой пользователь получает сообщение (как – неважно: по телефону, через почту и т.д.) о том, что в серверный репозиторий были внесены изменения.

Пользователь и сам может проверить состояние серверного репозитория (поскольку ты в него лепишь всё без разбору) и увидеть все изменения, выполненные с момента его последнего получения оттуда данных (при условии, что серверный репозиторий подключен к локальному посредством git remote, обычно по умолчанию ему назначается имя origin; посмотреть подключенные репозитории можно с помощью команды git remote -v):

git remote show origin

> В диалоговом окне выбирается синхронизируемая ветка (в данном случае – master) и указывается, что после слияния выполнить фиксацию изменений

А если закачиваемый контент содержит чепуху? Лучше сначала потестить то, что скачал с удалённого репозитория и только убедившись, что изменённая версия работает корректно, заливать себе в локальный репозиторий и затем, при желании, выполнять слияние. Результатом слияния будет новый коммит.

> Dev1 создает отдельную ветку Dev1Br#1

Не самое информативное имя. Имхо – имя ветки должно отображать смысл того, ради чего она создана.

> При фиксации изменений галочка “Сразу отправить изменения в…” установлена.

Как я уже писал выше, сразу всё отправлять в центральный репозиторий – очень плохое решение.

> Он отправляет пользователю Test1 сообщение с указанием названия ветки, которую надо получить: Dev1Br#1.

Насколько я знаю, “получает” Test1 по любому полную версию сетевого репозитория а не только ветку Dev1Br#1, т.к. git fetch качает не какую-то отдельную ветку, но весь репозиторий в целом.

> У пользователя Test1 до сих пор только одна его ветка – master:

Всё правильно. А ты ожидал другого?

> Импорт ветки Dev1Br#1 не изменил название локальной ветки, не создал новую ветку – ни-че-го!

Ты так удивляешься… :))))) С какого перепугу ты ожидал получить изменения в локальной? На скрине у тебя показано, что локальная ветка master отстаёт от ветки origin\Dev1Br#1 на один коммит. Решение о переименовании или слиянии принимает юзер. Ты пока не давал ни одной из этих команд.

> Импорт ветки Dev1Br#1 не изменил название локальной ветки, не создал новую
> ветку – ни-че-го! Изменения из внешней ветки origin\Dev1Br#1 просто были
> помещены поверх старого состояния репозитория
> Состояние репозитория в результате получения изменений из Dev1Br#1 стало таким:

Маленький ликбез: у тебя произошло переключение на на ветку origin\Dev1Br#1 – это НЕ ЛОКАЛЬНАЯ ветка. Переключение на ветку автоматом заменяет содержимое рабочего дерева (working tree), т.е. содержимое каталога, который ты смотришь на скрине. В этот момент у тебя HEAD указывает на последний коммит ветки origin\Dev1Br#1. Так что ничего удивительного не произошло.

> SourceTree (точнее, Git) считает, что ему есть что отправить в серверный репозиторий:

Я не знаю, чего там “считает” SourceTree, но возможно ты не верно интерпретируешь то, что видишь на показанном скрине.

> Хотя, конечно, это не так. Просто обновилась ЛОКАЛЬНАЯ ветка master, и Git предполагает, что ее надо срочно синхронизировать с серверной.

Нет, ЛОКАЛЬНАЯ ветка master не обновилась. Как я уже писал выше, произошло ПЕРЕКЛЮЧЕНИЕ на ветку origin\Dev1Br#1 (т.е. HEAD указывает теперь на origin\Dev1Br#1).

> Ни в коем случае этого делать нельзя! Ветку master в серверном (общем) репозитории обновляют только разработчики

А нефиг кому попало раздавать права для записи в центральный репозиторий! Настрой ACL для каталога так, чтобы тестер имел права только на чтение. Конкретно В ДАННОМ случае ничего не случится страшного даже если юзер нажмёт кнопку записи на сервер – он просто не сможет залить что-либо на сервер до тех пор, пока предварительно не синхронизируется с текущим состоянием сервера. На данный момент его локальный репозиторий отличается от серверного.

> Таким образом, получается, что Test1 “подхватил” новые файлы и из ветки Dev1Br#1, и из ветки Dev3Br#1. При этом сам пользователь Test1 находится на своей собственной ветке master. Фактически произошло слияние (merge) веток Dev1Br#1 и Dev3Br#1 в локальной ветке master пользователя Test1.

Маленькая поправочка: не “Test1 “подхватил””, а ты своими шаловливыми пальчиками натворил чего не следовало… Согласно содержимому каталога, которое ты показываеш на скрине, очень пхоже на то, что ты действительно выполнил слияние. Вот только вопрос: ЗАЧЕМ. Я очень сомневаюсь что Test1 хотел именно этого…

>В общем и целом, сейчас ситуация, кажется, нормализовалась: у всех пользователей именно то, что необходимо, все синхронизировано и все работает.

Ничего не нормализовалось: у test1 в ветке каша,как мы помним и проскакивать этот момент не следует… Все дальнейшие перечисленные шаги повествуют о том, как делать НЕ НАДО. Вспоминаем всю ту же ссылку, приведённую мною в начале комментария.

Давай вернёмся к тому моменту, когда test1 получил кашу: слияние трёх веток вместо того, чтобы иметь возможность протестировать каждую в отдельности. Рассмотрим это более подробно, дабы показать что ты по факту сделал и что же нужно было сделать на самом деле… Сделаем так: я оформлю это в виде подробно комментированного sh-скрипта, который следует запускать в Git Bash. Скрипт выложил у себя в блоге, т.к. в комментах данной заметки это будет нечитабельно. Ссылка на скрипт: http://bushman-andrey.blogspot.ru/2015/09/blog-post.html#more

> Разработчики и тестировщики могут использовать любые ветки. Пользовательский репозиторий использует и синхронизирует только основную ветку — master

Всё, до меня дошла эта фраза.