Как работает git. Как начать работать с GitHub: быстрый старт
Свойство z-index управляет порядком наложения позиционированных элементов в случае, когда они накладываются друг на друга. Свойство принимает целые положительные и отрицательные значения.
В нормальном потоке position: static элементы располагаются последовательно один за другим в том порядке, в котором они определены в html-документе. По умолчанию установлен z-index: auto; .
Рис. 1. Позиционирование элементов вдоль оси Z
Свойство z-index задает порядок расположения элементов вдоль оси Z. В обычной ситуации элементы с высоким значением индекса будут перекрывать элементы с меньшим значением и значением auto , располагаясь на переднем плане.
Рис. 2. Воздействие свойства z-index на позиционированные элементы
Контекст наложения
Если для элементов свойства z-index и position не заданы явно, контекст наложения равен порядку их расположения в исходном коде. Если для элементов не задан z-index , браузер отображает элементы на странице в следующем порядке:
Корневой элемент
Позиционированные position элементы в порядке их следования в исходном коде. Последний из них будет расположен на переднем плане.
Рис. 3. Порядок расположения элементов в 3D пространстве по умолчанию
Lorem ipsum dolor sit amet, consectetur adipiscing elit...
Как видно из рисунка, элемент с position: absolute; находится на переднем плане, далее идет текст, под ним располагаются плавающие элементы с float: left; , не позиционированные блочные элементы расположены на заднем плане (так как плавающие и позиционированные элементы удаляются из потока, то блочные не позиционированные элементы их игнорируют и располагаются друг за другом, в соответствии с разметкой, поэтому элемент .
Свойство z-index создает новый контекст наложения. Оно позволяет изменить порядок наложения позиционированных элементов . Элементы будут отображаться на странице в следующем порядке (если для них не заданы свойства, влияющие на контекст наложения — opacity , filter , transform):
Корневой элемент , который содержит все элементы веб-странице.
Позиционированные элементы с отрицательным значением z-index .
Блочные элементы, не плавающие и не позиционированные.
Плавающие float не позиционированные элементы в порядке их расположения в исходном коде.
Строковые не позиционированные элементы (текст, изображения).
Позиционированные элементы со значениями z-index: 0; и z-index: auto; .
Позиционированные элементы с положительными значениями z-index . Высокое значение индекса отобразит элемент на переднем плане. Элементы с равными значениями z-index будут отображаться согласно их расположения в исходном коде.
Рис. 4. Свойство z-index создает новый контекст наложения элементов в 3D пространстве
Большинство CSS свойств просты для понимания. Зачастую, применения какого-либо из них к элементу разметки даёт немедленный результат - стоит только обновить страницу, как видно эффект применения. Однако, есть некоторые свойства, которые сложнее и будут работать только в случае определённых обстоятельств.
Свойство z-index относится ко второй группе, которое несомненно вызывает больше смятения, чем любое другое. По иронии, однако, при полном понимании того, что такое z-index , он очень прост в использовании и часто является эффективным способом преодоления многих проблем макета.
В этой статье, мы рассмотрим что такое z-index , какие есть проблемы в его понимании, а также обсудим некоторые примеры его использования. Также рассмотрим разницу его обработки браузерами, особенно в предыдущих версиях Internet Explorer и FireFox.
Так что же это за свойство?
Свойство z-index определяет уровень размещения в стеке, глубины html-элемента. "Уровень глубины" означает позицию элемента по оси Z (как перпендикулярную осям X и Y экрана). Чем больше значение z-index , тем элемент будет выше.
Естественное расположение элементов
На странице, обычное размещение элементов (я имею в виду расположение вдоль оси Z) определяется несколькими факторами. Ниже представлен список этих факторов, начиная с самых нижних элементов. В этом списке подразумевается, что ни одному из элементов явно не присваивается свойство z-index .
- Фон и границы элемента, определяющего контекст стека.
- Элементы с отрицательным контекстом стека, в порядке отображения.
- Непозиционированные (position: static), а также без установленного свойства float (float: none) блочные элементы (display: block), в порядке отображения.
- Непозиционированные, с установленным свойством float , блочные элементы, в порядке отображения.
- Строчные (inline) элементы, в порядке отображения.
- Элементы с установленным свойством position , в порядке отображения.
Корректное применение свойства z-index , может изменить естественное расположение в стеке.
Конечно, порядок элементов в стеке не очевиден, до тех пор пока не потребуется отобразить элементы один над другим. Поэтому, чтобы увидеть обычный порядок элементов, на примере ниже применены отицательные внешние отступы (margin).
У этих элементов разные цвета фона и границ, а последние два смещены за счёт установленного отрицательного свойства margin . Таким образом видно естественное размещение элементов, каждый следующий находится "выше" предыдущего. У этих элементов не установлено свойство z-index , их порядок размещения в стеке является естественным.
Где могут быть проблемы?
Давайте рассмотрим самую популярную проблему у начинающих разработчиков. Дело в том, что свойство z-index работает только с элементами, для которых свойство position установлено в absolute , fixed или relative .
Чтобы продемонстрировать это, выведем те же самые три элемента, но с установленным свойством z-index , чтобы попытаться изменить порядок расположения вдоль оси Z.
Установим серому элементу z-index равным 9999, синему - 500, а коричневому - 1. Логично ожидать, что порядок изменится. Но не в этом случае, поскольку свойство position по-умолчанию равно static .
Установим свойство position в relative и посмотрим что получилось:
А вот теперь у нас получился ожидаемый результат. Порядок элементов изменился, серый элемент находится над всеми, а коричневый в самом низу.
Синтаксис
Свойство z-index влияет как на блочные элементы, так и на строчные (inline). Значением может быть положительное или отрицательное число, либо значение по умолчанию - auto . Значение по умолчанию означает что элемент находится на том же уровне как и его родитель.
Ниже представлен CSS для третьего примера, где свойство z-index применяется корректно:
#grey_box { width: 200px; height: 200px; border: solid 1px #ccc; background: #ddd; position: relative; z-index: 9999; } #blue_box { width: 200px; height: 200px; border: solid 1px #4a7497; background: #8daac3; position: relative; z-index: 500; } #gold_box { width: 200px; height: 200px; border: solid 1px #8b6125; background: #ba945d; position: relative; z-index: 1; }
И снова повторюсь, специально для новичков в CSS: свойство z-index не будет работать, пока вы не установите свойство position .
Использование в javaScript
Вы можете повлиять на свойство z-index динамически, используя javaScript. Синтаксис похож на обычный для большинства CSS свойств, с использованием camel-нотации для замены дефиса в свойствах CSS.
Var myElement = document.getElementById("gold_box"); myElement.style.position = "relative"; myElement.style.zIndex = "9999";
Некорректная реализация в IE и FireFox
В некоторых случаях, в IE6, IE7 и FireFox 2, встречается неверная реализация свойства z-index .
Элемент select в IE6
В Internet Explorer 6, элемент select является windows-контролом, по этой причине он всегда отображается поверх всех элементов, игнорируя обычный порядок размещения, а также свойства position и z-index . Проблема показана на картинке ниже:
Элемент select находится в документе первым, его свойство z-index равно 1, а position установлен в relative . Div выводится после select , а его z-index равен "9999". Исходя из всего этого, div должен находится над select , как это происходит в других браузерах:
Choose Year - 2009 2010 2011
Если вы просматриваете эту статью не в IE6, вы увидите что div расположен выше select .
Эта ошибка IE6, является большой проблемой для выпадающих меню, когда они должны перекрывать элемент select . Решением может быть использование javaScript для того чтобы временно скрыть select -ы, а потом, после исчезновения меню, показать опять. Другим решением может быть использование iframe .
Позиционированные родители в IE6/IE7
Internet Explorer версий 6 и 7 некорректно сбрасывают контекст стека в отношении ближайшего позиционированного родителя. Чтобы продемонстрировать эту ошибку, мы опять отобразим два div -а. Но в этот раз мы обернём первый из них в позиционированный элемент.
У серого элемента z-index равен 9999, у синего - 1, оба элемента позиционированы. Поэтому, при корректной реализации, серый элемент отобразится поверх синего.
Если же вы откроете эту страницу в IE6 или IE7, вы увидите что синий элемент перекрывает серый. Это происходит по причине того, что серый элемент обёрнут в ещё один div , которому position установлен в relative .
Оба браузера "сбрасывают" контекст стека в относительно позиционированных элементах, хотя и не должны этого делать. У серого элемента z-index больше, чем у синего, поэтому он должен отображаться выше. С остальными браузерами такой проблемы нет.
Отрицательные значения в FireFox 2
В FireFox 2, элементы с отрицательным z-index находятся под контекстом стека, вместо того, чтобы быть над фоном и границами элемента, который формирует контекст стека. Пример вы можете увидеть на картинке:
Ниже представлена html-версия
Как видите, фон серого элемента (который формирует контекст стека) находится под синим, а текст (который является inline -элементом в сером элементе) находится над ним, что соответствует правилам естественного расположения, описанным выше.
Примеры использования
В оригинальной статье приведено много примеров использования свойства. Честно говоря мне лень это переводить, в основном - это скриншот, небольшой комментарий и ссылка. Если же всё-таки вам это действительно надо, то пишите, выделю время.
Противостояние изменениям - основная черта человека. Если в то время, когда вы начинали работу с системами контроля версий, не было Git - весьма вероятно, что вы начинали с Subversion. Часто люди говорят, что Git слишком сложен для начинающих. Тем не менее, я позволю себе с вами не согласиться.
В этой статье я расскажу, как можно использовать Git в работе с вашими проектами. Будем считать, что вы создаете проект с нуля, и хотите использовать Git в качестве системы контроля версий. После ознакомления с основными командами, мы ознакомимся с тем, как можно выложить ваш код на GitHub.
В этой статье речь пойдет об основных вещах - как инициализировать проект, как управлять новыми и уже существующими файлами, и как хранить свой код в облаке. Мы опустим некоторые сложные вещи, как ветвление, так как статья ориентирована на начинающих.
Установка Git
На официальном сайте Git есть на различные системы - Linux, Mac, Windows. В нашем случае мы будем использовать Ubuntu 13.04, и Git мы будем устанавливать посредством apt-get .
Sudo apt-get install git
Начальная конфигуация
Создадим директорию, в которой мы будем работать. Также вы можете использовать Git для работы с уже существующим проектом, и в таком случае вы не будете создавать демонстрационную директорию, как это описано ниже.
Mkdir my_git_project cd my_git_project
Первым делом надо инициализировать Git-репозитарий в директории проекта. Сделать это можно командой init , которая создает директорию.git со всей информацией о вашем проекте.
Git config --global user.name "Shaumik" git config --global user.email "[email protected]" git config --global color.ui "auto"
Стоит отметить, что если вы не укажете ваш адрес и имя, то вместо них будут использоваться значения по умолчанию. В нашем случае значениями по умолчанию будут donny и donny@ubuntu.
Также мы устанавливаем цвет интерфейса в значение auto , так что вывод команд Git будет цветным. Мы добавляем префикс --global к этим командам для того, чтобы эти значения использовались во всей системе, и не было необходимости их задавать для каждого отдельного проекта.
Готовим файлы для коммита
Следующим шагом мы создадим несколько файлов. Можно использовать для этого любой текстовый редактор. Заметьте, что если вы инициализируете Git в уже существующем проекте, вам не нужно делать этот шаг.
Проверяем состояние репозитария
Теперь, когда в вашем проекте есть файлы, давайте посмотрим, как Git с ними обращается. Чтобы проверить текущий статус репозитария, используйте команду git status
Добавляем файлы в Git
На этом этапе Git не следит ни за одним из наших файлов. Необходимо специально добавить файлы в Git, чтобы это происходило. Для этого воспользуемся командой add.
Git add my_file
Проверив статус репозитария видим, что один из файлов уже добавлен в него.
Чтобы добавить несколько файлов, используем следующее (заметьте, что первый файл мы добавили ранее, так что добавляем только оставшиеся два).
Git add myfile2 myfile3
Можно использовать git add рекурсивно, но будьте осторожны с этой командой. Есть некоторые файлы (например, скомпилированные программы), которые не должны быть добавлены в систему контроля версий. Если вы используете git add рекурсивно, такие файлы также попадут в репозитарий.
Удаляем файлы
Представим, что вы случайно добавили в репозитарий файл, который не должен был туда попасть. Или же вы хотите убрать из системы контроля версий какой-либо файл. В общем, команда git rm не просто удалит файл из репозитария, но и физически удалит его с диска. Чтобы Git перестал отслеживать файл, но он остался на диске, используйте следующую команду:
Git rm --cached [имя_файла]
Коммитим изменения
Как только вы добавили все необходимые файлы, вы можете закоммитить (зафиксировать) их в Git. Представьте, что коммит - это снимок состояния проекта на определенном этапе, к которому вы можете вернуться в любой момент времени, и увидеть состояние проекта на тот момент. С каждым коммитом ассоциируется сообщение, которое задается аргументом после префикса -m
Git commit -m "Мой первый коммит"
Указывайте сообщение, которое будет содержать полезную информацию, так как они помогают понять, что же именно было изменено в рамках данного коммита. Избегайте каких-то общих сообщений, типа “Правил баги”. Если у вас есть баг-трекер, вы можете указать сообщение типа “Поправлен баг #123”. Хорошая практика - указывать в сообщении имя ветки или улучшения. Например, “Управление активами - добавлена возможность генерировать PDF на основе актива” - понятное и доходчивое сообщение.
Git определяет коммит длинным шестнадцатеричным номером. Обычно, нет необходимости копировать всю строку, первых 5-6 символов достаточно для идентификации конкретного коммита. По скриншоту видно, что наш коммит идентифицируется числом 8dd76fc .
Дальнейшие коммиты
Давайте изменим несколько файлов после того, как мы их закоммитили. После того, как мы их изменили, git status сообщит о том, что у нас есть измененные файлы.
Можно посмотреть, что же изменилось в этих файлах с момента предыдущего коммита, с помощью команды git diff . Если вы хотите просмотреть изменения для конкретного файла, можно использовать git diff <файл> .
Необходимо проиндексировать изменения, и закоммитить их. Все измененные файлы проекта можно добавить на коммит следующей командой:
Можно избежать использования этой команды, если добавить параметр -a к git commit . Эта команда проиндексирует все измененные файлы, и закоммитит их. Но такой подход может быть довольно опасным, так по ошибке можно закоммитить то, что не хотелось. Например, скажем, что вы открыли файл, и случайно его изменили. При индексировании измененных файлов вы будете оповещены об изменениях в каждом файле. Но если вы отправите на коммит все измененные файлы не глядя с помощь. git commit -a , то будут закоммичены все файлы, включая те, которые вы коммитить не хотели.
Как только вы проиндексировали файлы, можно приступать к коммиту. Как упоминалось ранее, к коммиту можно указать сообщение с помощью ключа -m . Но также можно указывать и многострочные комментарии с помощью команды git commit , которая открывает консольный редактор для ввода комментария.
Управление проеком
Чтобы просмотреть историю проекта, можно воспользоваться следующей командой:
Она отобразит полную историю проекта в виде списка коммитов и информацию о них. Информация о коммите содержит хеш коммита, автора, время и сообщение коммита. Есть множество видов команды git log , с которыми придется познакомиться в случае использования ветвления в Git. Чтобы посмотреть детали конкретного коммита, и измененные файлы, выполните следующую команду:
Git show <хеш_коммита>
где <хеш_коммита> - шестнадцатеричный номер, ассоциированный с коммитом. Так как данное руководство предназначено новичкам, мы не будем рассматривать, как вернуть состояние на момент конкретного коммита, или как управлять ветками.
Работа с 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, содержащий информацию о том, что в этом месте сливается текущая ветка с дополнительной.
Алгоритм работы над задачей
Стандартный алгоритм работы над какой-либо задачей выглядит так:
- Создаётся ветка, основывающаяся на последней копии master ветки. Название новой ветки содержит класс задачи, краткое описание, номер задачи в БТ. Например feature/sessions_add_datetime_filter.5503
- Все изменения производятся внутри этой ветки. При каждом атомарном логическом изменении (например, добавили плагин – закоммитили добавление; поправили API одной функции во всех местах – закоммитили и тп) создаётся свой коммит. Это позволяет разделять какие были изменения, упрощается чтение и проверка на ошибки процесса разработки.
- После того как код в ветке сделан и отлажен, все изменения закоммичены, данная ветка ребейзится относительно последнего мастера, и пушится в центральный репозиторий.
- Второй человек, работающий над тем же проектом, делает к себе pull центрального репозитория. Если он уже смотрел – то удаляет свою локальную копию ветки, после чего переключается на указанную ветку. Прочитывает код, проверяет его работоспособность, после чего либо отдаёт на доработку, если там обнаружены проблемы, либо делает еще раз rebase поверх мастера, и слияние ветки с мастером.
- После слияния с мастером, ревьюер пушит новый мастер в центральный репозиторий, удаляет у себя локальную ветку задачи, пушит в мастер удаление ветки задачи.
- Разработчик удаляет локальную ветку задачи после того как задача была закрыта и изменения попали в master.
Правила ведения чистых коммитов
Все коммиты, которые попадают в центральную ветку, должны следовать следующим правилам:
- Автором должен быть прописан разработчик – Имя, Фамилия, рабочий e-mail.
- Текст комментария должен содержать краткое описание изменения. Для зарубежных проектов описание обязано быть на английском языке, для проектов российского бранча приемлемо комментировать на русском.
- Коммит не должен содержать в себе файлы, не относящиеся к изменениям. Если ваша IDE, OS, какой-то плагин какому-либо софту использующемуся при разработке создают технические файлы, либо добавьте их в.gitignore, либо не добавляйте к коммиту, либо удаляйте перед коммитом.
- Коммит не должен добавлять/убирать пустые строки, менять пробелы на табы и наоборот, менять число пробелов и т. п. нигде, кроме случаев, относящихся к сути коммита. То есть при рефакторинге это нормально, но если ваш редактор поменял во всем файлые пробелы на табы или наоборот – меняйте настройки редактора или перед коммитом приводите всё к виду «как было».
- Стиль исходного кода и отступов должен совпадать с текстом вокруг. То есть, если всюду в файле используются табы для отступа, не следует вставлять еще один case выровненный пробелами.
- Минимизация конфликтов. При добавлении кода следует стараться форматировать код так, чтобы модификация его приводила к минимуму конфликтов при слиянии.
Работа под Windows
Для работы с Git под Windows самое удобное – использовать TortoiseGit. Однако следует знать, что на 2017 год есть более удобный инструмент - SmartGit.
Подготовка к работе
- Устанавливается putty со страницы http://www.chiark.greenend.org.uk/~sgtatham/putty/
Лучше всего ставить полный пакет, со всеми программами. По надобятся как минимум plink, puttygen. - Устанавливается msysGit из проекта http://code.google.com/p/msysgit/
Выбрать опции при установке «Add “Git Bash here”», «Run Git from the Windows Command Prompt», «Use Windows style line endings», когда спросит – дать путь до plink.exe - Устанавливается TortoiseGit из проекта http://code.google.com/p/tortoisegit/
После установки зайти в TortoiseGit → Settings → Git → Config, убедиться что путь до msysgit задан, и что опции AutoCRLF и SafeCRLF установлены, настроены имя, фамилия, email разработчика. - С помощью puttygen создаётся пара приватный+публичный ключ.
Публичный ключ высылается админам для добавления в доступы репозиториев и серверов.
Приватный ключ добавляется в pagent через клик правой кнопкой → add key.
Получение репозитория
В папке, где будут размещаться все рабочие проекты, жмём
Правой кнопкой→TortoiseGit→Clone, вводим адрес центрального репозитория
ssh:
//git@
СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git
В поле «Load Putty Key» выбираем путь до приватного ключа.
При работе используются либо консольные утилиты, аналогично linux, либо графический интерфейс.
Стандартные процедуры работы
- «Начало работы над задачей»
,
Branch: master
Меню → TortoiseGit → Pull
Меню → TortoiseGit → Create Branch
Name Branch: название новой ветки
Base On: HEAD (master)
[x] Switch to new branch - «Коммит очередного кусочка работы»
Меню → Git commit -> “имя ветки”
Отметить файлы, только нужные для данного конкретного коммита
Обязательно щелкнуть на «View Patch», и убедиться
в соответствии правилам ведения чистых коммита
В message ввести описание изменения, соответствующее правилам
Меню → TortoiseGit → Push
Выбираем в Local сперва master, потом нашу текущую ветку.
Remote заполняется при этом автоматически.
Название remote ветки должно быть идентично local- «Ребейз относительно мастера»
Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены.
Меню → 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 - «Кратковременное сохранение состояния изменений»
Меню → TortoiseGit → Stash Save
После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние, если переключиться обратно на рабочую ветку, и сделать
Меню → TortoiseGit → Stash Pop - «Длительное сохранение состояния изменений»
Меню → Git Commit -> “ветка”
Отмечаем все-все изменения (Select/Deselect All)
В текст сообщения пишем «Partial commit»
Позже, для возврата к тому же состоянию как было до, переключаемся на рабочую ветку, и делаем
Меню → TortoiseGit → Show Log
Выделяем коммит, который идет в дереве сразу перед «Partial commit»
Правой кнопкой → Reset <ветка> to this
Reset type: Mixed - «Ревью ветки»
Меню → 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
Подготовка к работе
- Устанавливаются системные пакеты ssh-client и git
- Создаётся приватный ключ:
ssh-keygen -t dsa -C "Ivan Petrov
- Настраивается ФИО и Емейл автора:
git config --global user.name "Ivan Petrov"
git config --global user.email work@mail" - Админу отсылается файл ~/.ssh/id_dsa.pub для прописывания доступов до репозиториев и серверов.
Получение репозитория
Переходим в директорию для работы, и запускаем
git clone ssh://git@СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git
Основные используемые функции
- Обновление текущей ветки из центрального репозитория:
git pull
- Отправка текущей ветки в центральный репозиторий:
git push origin branchname
- Переключение на некоторую ветку:
git checkout branchname
При переключении на ветку, которой еще нет в локальном репозитории, будет создана локальная ветка, связанная с удалённой.
- Создание новой ветки, базирующейся на текущей
git checkout -b branchname
- Удаление веток
git branch -d branchname == удаление локальной уже слитой ветки
git branch -D branchname == принудительное удаление локальной ветки
git push origin:branchname == удаление ветки с центрального репозитория - Слияние ветки с текущей
git merge --no-ff branchname
- Посмотреть какие файлы изменены в текущей директории:
git status
- Просмотреть текущие изменения:
git diff
- Сохранение текущих изменений:
git add именафайлов == добавить измененные/созданные файлы/директории
git rm именафайлов == добавить удаление файла/директории
git commit == сохранить добавленные изменения. Откроется редактор, чтобы ввести комментарий к коммиту
git commit -a == сохранить все добавленные изменения и все измененные файлы. Позволяет сохранять все изменения, если файлы не добавлялись.
Стандартные процедуры работы
- «Начало работы над задачей».
Выполняется перед началом работы над задачей. Дерево должно быть без изменений.git checkout master
git pull
git checkout -b branchname - «Коммит очередного кусочка работы».
Выполняется после выполнения некого изменения, суть которого целостная.# проверяем, какие файлы изменились к текущему моменту
# удаляем если что-то попало совсем лишее
git status# смотрим текст изменений, на предмет соответствия
# правилам ведения чистых коммитов. удаляем, если какой-либо мусор попал
git diff# если какие-либо файлы не должны попасть в коммит (например,
# относятся к другому атомарному изменению.)
# то помечаем только те файлы, изменения которых нужно сохранить
git add …
git rm …# сохраняем. -m можно опустить, тогда комментарий через редактор
git commit -m "Some commit message"# если все на текущий момент созданные изменения нужно сохранить, то
# через git add добавляем новые файлы, а всё остальное сохраняем через
git commit -a -m "Some commit message" - «Отправка ветки на центральный репозиторий»
Выполняется после завершения работы, либо в конце каждого дня (чтобы был бакап на сервере), либо если нужно какие-то изменения показать коллеге.git push origin branchname
Не следует делать push после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.
- «Ребейз относительно мастера».
Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены: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
- «Кратковременное сохранение состояния изменений».
Выполняется, если требуется временно приостановить работу над текущей веткой на короткое время (например, на ревью, или чтобы сделать какую-либо двухминутную задачу).git stash save
После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние с помощью
git checkout originalbranch
git stash popТем самым восстановив состояние изменения.
- «Длительное сохранение состояния изменений».
Выполняется в конце рабочих суток, чтобы даже частичные изменения были забакаплены; либо при необходимости срочно переключиться на решение другой задачи, которая может занять значительно больше 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 всегда, так как это спасёт от случайных опечаток в названии ветки, например.
- «Ревью ветки».
Выполняется на чистом дереве, временно сохраните изменения согласно пункта 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
Git GUI
Входит в комплект git - Запустите git gui из командной строки, а установщик Windows msysgit добавит его в меню "Пуск".
Git GUI может сделать большинство того, что вам нужно сделать с git. Включая изменения сцены, настройте git и репозитории, нажмите изменения, создайте/просмотрите/удалите ветки, слейте и многое другое.
Одна из моих любимых функций - ярлыки "сценарий" и "сценарий" в меню правой кнопки мыши, что позволяет фиксировать определенные части файла. Вы можете достичь того же через git add -i , но мне легче его использовать.
Это не самое приятное приложение, но оно работает практически на всех платформах (основано на Tcl/Tk)
GitK
Также включен в git. Это средство просмотра истории git и позволяет визуализировать историю репозитория (включая ветки, когда они созданы и объединены). Вы можете просматривать и выполнять поиск.
Хорошо сочетается с git -gui.
Gitnub
Приложение Mac OS X. В основном эквивалент git log , но имеет некоторую интеграцию с github (например, "Сетевой вид").
Выглядит красиво и подходит для Mac OS X. Вы можете искать репозитории. Самая большая критика Gitnub заключается в том, что он показывает историю линейным образом (по одной ветки за раз) - она не визуализирует ветвление и слияние, что может быть важно с git, хотя это плановое улучшение.
GitX
Предназначен для "клонирования gitk для OS X".
Он может визуализировать нелинейную историю ветвления, выполнять коммиты, просматривать и выполнять поиск, а также имеет некоторые другие приятные функции, такие как возможность "Quicklook" любого файла в любой редакции (нажмите пробел в представлении списка файлов) экспортировать любой файл (с помощью перетаскивания).
Он намного лучше интегрирован в OS X, чем git-gui / gitk , и является быстрым и стабильным даже при исключительно больших репозиториях.
Оригинальный репозиторий git pieter не обновлялся недавно (более года на момент написания). Более активно поддерживаемая ветвь доступна в brotherbard/gitx - она добавляет "боковую панель, выборку, вытягивание, толчок, добавление удаленного, слияния, выбирать, переустанавливать, клонировать, клонировать до"
SmartGit
На главной странице:
SmartGit - это интерфейс для распределенная система управления версиями Gitи работает на Windows, Mac OS X и Linux. SmartGit предназначен для разработчики, предпочитающие графического пользователя интерфейс через клиент командной строки, быть еще более продуктивным с помощью git - самый мощный DVCS сегодня.
TortoiseGit
Версия TortoiseSVN git для пользователей Windows.
Он переносит TortoiseSVN на TortoiseGit. Последняя версия 1.2.1.0. Эта версия может выполнять обычную задачу, такую фиксацию, журнал показа, разницу двух версий, создавать ветку и тег, создавать патч и т.д. Подробнее см. ReleaseNotes . Добро пожаловать, чтобы внести свой вклад в этот проект.
QGit
QGit - это средство просмотра git GUI, построенное на Qt/С++.
С помощью qgit вы сможете просматривать история изменений, просмотр содержимого патча и измененные файлы, графически после различной разработки ветки.
gitg
gitg - просмотрщик репозитория gitориентация gtk +/GNOME. Один из основных задача состоит в том, чтобы обеспечить более унифицированный пользовательский интерфейс для Gitинтерфейсы на нескольких рабочих столах. Это это не означает кросс-платформенное приложение, но тесное сотрудничество с аналогичными клиенты для других операционных систем (например, GitX для OS X).
Особенности
- Просмотр истории изменений.
- Обрабатывать большие репозитории (загружает репозиторий linux, 17000+ ревизий, менее 1 секунды).
- Зафиксировать изменения.
- Ступени/неустановленные отдельные куски.
- Отменить изменения.
- Показать расцветку изменений изменений в версиях.
- Просмотр дерева для данной версии.
- Экспортировать части дерева данной версии.
- Поставьте любой refspec, который команда, например "git log", может понять, чтобы построить историю.
- Показывать и переключаться между ветвями в виде истории.
Gitbox
Gitbox - графический Mac OS X интерфейс для управления версиями gitсистема. В одном окне вы видите веток, истории и работы статус каталога.
Ежедневные операции легки: этап и нестационарные изменения с помощью флажка. Зафиксировать, вытащить, слить и нажать с помощью один клик. Дважды щелкните изменение на показать diff с FileMerge.app.
Gity
На веб-сайте Gity не так много информации, но на скриншотах там есть полнофункциональный открытый OS X git gui с открытым исходным кодом.
Meld - инструмент визуального разграничения и слияния. Вы можете сравнить два или три файла и редактировать их на месте (diffs update динамически). Вы можете сравнить два или три папки и файл запуска сравнения. Вы можете просматривать и просматривать рабочая копия из популярной версии такие системы управления, как CVS, Subversion, Bazaar-ng и Mercurial [и Git].
Katana
A git GUI для OSX от Steve Dekorte.
Взгляните, какие удаленные ветки имеют изменения в pull и локальные репозитории имеют изменения в push. Операции gitдобавить, зафиксировать, нажать, потянуть, пометить и resetподдерживаются, а также визуальные различия и визуальный просмотр иерархии проекта который выделяет локальные изменения и дополнения.
Бесплатно для 1 репозитория, $25 для более.
Sprout (ранее GitMac)
Ориентация на создание git проста в использовании. Имеет собственный пользовательский интерфейс Cocoa (mac-like), быстрый просмотр репозитория, клонирование, push/pull, разветвление/слияние, визуальный diff, удаленные ветки, легкий доступ к терминалу и т.д.
Используя наиболее часто используемые действия git, интуитивно понятные и легко выполняемые, Sprout (ранее GitMac) делает git удобным для пользователя. Совместимость с большинством рабочих процессов git, Sprout отлично подходит для разработчиков и разработчиков, коллективной работы и продвинутых и начинающих пользователей.
Tower
Богатый графический интерфейс git для Mac OSX. 30-дневная бесплатная пробная версия, $59USD для однопользовательской лицензии.
Поиск
Мы можем оповещать вас о новых статьях,