Git в домашнем хозяйстве.


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

Имея высшее образование по специальности «Радиотехника», и программируя микроконтроллеры на самом нижнем уровне, исходя из сложившихся представлений о программировании (коих до определенного времени хватало), я время от времени от знакомых ребят-программистов, которые интересовались моей деятельностью, слышал о системах контроля версий исходного кода, а также удивленные возгласы после того, как они узнавали, что я таковыми не пользуюсь.

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

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

И, кончено же, я использую Git не только на работе, но и дома — потому что от его использования мы получаем следующий профит…


1. Вы никогда не потеряете свой код.
2. Вы можете параллельно работать сразу над несколькими фичами в разных ветках в одном и том же проекте, просто переключаясь между этими ветками.
3. При возникновении ошибок вы всегда можете откатить состояние проекта в состояние, когда ошибки еще не было, и найти после каких изменений появилась проблема.
4. Работа с Git помогает более тщательно подумать о работе над ПО.
5. Если вы хотите профессионального роста в области программирования, знание Git поможет вам независимо от выбранного языка программирования.
6. Вы сможете работать над проектами группой.

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

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

## Итак, как это работает, или немножко википедии.
Git — это распределенная система контроля версий исходного кода.
Смысл ее в том, что, имея какой-то общий репозиторий с кодом, каждая рабочая машина, которая работает с этим репозиторием, имеет локально полную копию репозитория, по-этому даже если локальный репозиторий будет полностью запорот, или машина обратится в пепел, код все равно сохранится, и с минимальными усилиями разработка продолжится. Здорово? Конечно здорово!

## Как установить git? Как с ним работать?
Как установить и настройить git на вашу платформу — лучше всего воспользоваться первой попавшейся инструкцией из google'а.
Пользоваться им я крайне рекомендую из командной строки — тогда вы точно сделаете с репозиторием именно то, что хотели. Но GUI-тулзы тоже есть. Я использую SourceTree от Atlassian — бесплатно и для некоторых задач удобно.

## Что за «репозиторий»?
Это отличный вопрос.
Репозиторий — это не просто папка с проектом. При инициализации git-репозитория в папке проекта создается скрытая папка .git, в которой хранятся настройки репозитория, и, собственно, вся история изменений проекта.
Каждое изменение проекта (репозитория) описывается так называемым коммитом.
Если сравнивать написание кода с рисованием картины, то коммит — это совокупность логически объединенных штрихов.
Например, художник поставил пустой холст на мольберт — это инициализация репозитория.
Потом он решил, что, возможно, не всем будет понятно, что он изображает, и на оборотной стороне холста подписал название картины, и примерное ее содержимое, как он его видит — это коммит с README.md
Потом он нарисовал землю — коммит с комментарием "[PIC-1] Add ground"
Нарисовал небо, и подправил землю, так как краска высохла и цвет получился не совсем нужный — коммит "[PIC-1] Add sky. Fix ground color."
И так далее…

Как видим, каждый коммит — это описание изменений рабочей папки репозитория по сравнению с предыдущим состоянием состояния рабочей папки (предыдущим коммитом).

Цепочки коммитов объединятся в ветки (branch). Веток может быть сколько угодно много (в разумном количестве), но главная ветка — всегда называется master. Она есть всегда и репозиторий инициируется как раз с одной единственной веткой master. Ветки могут ответвляться друг от друга и через некоторое время сливаться обратно друг в друга.

Git — это очень гибкая и мощная система, но по факту работа с репозиторием сводится к таким действиям:
1. Создаете ветку, в которой будете реализовывать новую функциональность.
2. Пишете код (или добавляете файлы — в общем как-то изменяете проект).
3. Добавляете все файлы с нужными изменениями в специальный список, называемый stage. Это еще не коммит, но это добавление состояния файлов в будущий коммит. То есть именно это состояние добавленных файлов попадет в коммит.
4. После того как вы добавили все необходимые файлы с изменениями в stage, вы можете закоммитать изменения.
5. После того как вы сделали все необходимые коммиты, вы можете отправить их на сервер, чтобы они были увековечены уже на сервере.
6. После того как вся функциональность реализована и оттестирована, вы схлопываете всю ветку до одного единственного коммита, и вливаете этот коммит в master.
7. Цикл повторяется с цифры 1)

Причем 90% времени вы будете повторять действия 2-3-4,
около 7% — действие 5,
около 3% — действия 1, 6 и 7)

## GitHub Flow
Каждая команда разработчиков, работающая с общими репозиториями, принимает определенный набор правил, как нужно работать с этими репозиториями. Этот набор правил называется flow. Есть общие рекомендации по работе с git-репозиториями, и они называются GitFlow. Но они довольно сложны, и часто применяется упрощенная схема, называемая GitHub Flow.
Эту схему я использую и дома, так как она проста и эффективна. Заключается она в следующем:

1. В ветке master _всегда_ только стабильные версии программы. Любая версия кода в master должна быть стабильна. В ней может не быть никаких фич, но она точно должна работать хорошо.
2. Каждая новая фича должна добавляться в отдельной ветке, которые ответвляются от мастера.
3. После того, как фича в ветке оттестирована, она сливается (мёржится — от слова merge) в master.

## Пример использования: создаем репозиторий
Например, я хочу начать написать две версии прошивки для мигания светодиодом — с freeRTOS, и без ее использования, и потом уже решить, как работать дальше.
Первое что я делаю, это создаю в Eclipse новый проект с названием, например, blink-led со стандартным кодом blinky a led.
Создается проект с диким количеством папок в папке ~/eclipse-workspace/blink-led.
Далее я хочу проект превратить в репозиторий:

cd ~/eclipse-workspace/blink-led
git init

Initialized empty Git repository in /Users/user/eclipse_workspace/blink-led/.git/

Отлично! Репозиторий у нас есть!

Просмотреть состояние репозитория можно командой git status:

git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	.cproject
        Debug/
	.project
	.settings/
	include/
	ldscripts/
	src/
	system/

nothing added to commit but untracked files present (use "git add" to track)


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

Теперь надо подумать, какие папки нам нужны в общем репозитории.
Хмм, ну папка Debug нам точно ни к чему — она сгенерится сама при сборке проекта.
Чтобы эта папка не попала в stage, потом в коммит, и потом на сервер — возьмем и скажем гиту, чтобы он ее игнорировал.

vim .gitignore

Далее Shift+i пишем Debug/, нажимаем ESC, потом :(двоеточие), пишем wq, ентер. Мы создали файлик, в котором будет список всего того, что нам не нужно в репозитории.

Теперь добавляем все новые файлы в репозиторий:
git add -A


И коммитим изменения:
git commit -m "Add dummy blink files to project"


Далее можем посмотреть состояние репозитория:
git status
On branch master
nothing to commit, working directory clean


Собственно, мы в ветке мастер добавили коммит с пустым проектом, в котором сейчас код мигающего светодиода, сгенерированный Eclipse'ом.

## Пушим!
Чтобы куда-то пушить, надо сначала создать удаленный репозиторий. Для этого идем на bitbucket.org и регистрируемся там. Bitbucket, а не GitHub — исключительно только потому что там можно создавать приватные репозитории бесплатно.
После регистрации нажимаем кнопку Create, вводим имя репозитория и описание содержимого. Нажимаем Create repository.
В следующей страничке выбираем I have an existing project, жмем, и видим предельно простые инструкции, что нужно сделать, чтобы связать наш локальный репозиторий с удаленным.

git remote add origin https://your-login@bitbucket.org/your-login/blink-led.git
git push -u origin --all
git push -u origin --tags


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

## Бранчуем
Теперь я хочу добавить файлы freeRTOS в проект.
Для этого нам нужно создать новую ветку и переключиться на нее:
git checkout -b feature-freertos
Switched to a new branch 'feature-freertos'


Теперь мы просто добавляем нужные файлы freeRTOS, работаем с другими файлами и коммитаем изменения.
Можем запушить новую ветку на удаленный репозиторий:
git push origin feature-freertos


Эти изменения никак не отразятся на ветке master.
Если мы хотим переключиться обратно на master и побилдить проект из мастера, мы можем использовать команду:
git checkout master


Если мы хотим посмотреть состояние репозитория на коммит раньше, пишем команду:
git checkout HEAD^

Где количество крышечек равно количеству коммитов, на которые хочется вернуться назад.

Чтобы вернуться обратно, пишем опять:
git checkout master


Если мы сделали плохой коммит и хотим его отменить, пишем:
git reset --hard HEAD^

Про количество крышечек вы поняли) С этой командой будьте очень аккуратны, обратно вернуть коммит куда сложнее, чем ресетнуть.

## Мёржим
Итак, мы сделали все нужные изменения в ветке feature-freertos, оттестировали ее и хотим залить в мастер, чтобы дальше любая ветка, которая будет бранчеваться от мастера, уже содержала изменения из feature-freertos.

Чтобы смержить в нашем случае мы просто переключаемся на мастер и применяем команду merge:
git checkout master
git merge feature-freertos


И после этого отправляем уже измененный мастер в удаленный репозиторий:
git push origin master


## Трудности, с которыми вы столкнетесь.
Трудности — это rebase, rebase -i, и разрешение конфликтов.
Вообще это темы для отдельных статей, и этих статей написано великое множество — было бы желание их читать)

А здесь я просто хотел показать, вот что:
— из всех сотен команд git'а в повседневной жизни сталкиваешься буквально с десятком, которые учатся за неделю
— привыкнуть к логике GitHub Flow можно за ту же неделю, при этом облегчив себе написание и тестирование кода
— git — это очень полезный инструмент, освоив который, жизнь становится проще.

Комментарии (74)

RSS свернуть / развернуть
Для менее хардкорных любителей консоли под винду есть превосходная накладка TortoiseGit, сидящая в контекстном меню.
Работать в одно рыло с CVS прельстиво и любовно, но если имеет доступ к репо 2 и более долбоёбовчеловек, надо строго придерживаться процедуры пулл-мерж-пуш, иначе лечить похеренные бранчи придётся ежедневно.
+3
Да, точно! Про черепашку я и забыл)
Согласен, при работе с командой нужно хорошо понимать операции создания веток, и их сливания. Я бы даже сказал, придерживаться процедуры фетч-мерж-пуш)
У нас в команде принято работать в своей ветке feature-[название feature], потом созается пулл-реквест в мастер, исправляются CR, и далее делается rebase на текущее положение HEAD master, ветка схлопывается в 1 коммит при помощи rebase -i, и мержится одним коммитом в мастер, чтобы была всегда красивая история.
Действий получается довольно много, но в итоге история действительно красива и довольно прозрачна. Нет никаких сложных конфликтов при мерже, опять же.
0
Тоже использую TortoiseGit.
0
По мне TortoiseGit весьма неудобен, особенно если сравнивать с TortoiseHg. Как его форкнули от свн версии, так интерфейсом никто и не занимался. На мой взгляд Git Extensions намного приятней выглядят, удобней в работе и дружелюбней к начинающим.
0
Вопрос от чайника:)
Допустим создали две ветки (условно):
1. feature button1
2. feature button2
добавили функционал, сделали слияние «мастер» ветки с «feature button1». Получился «мастер» с функционалом «button1». Далее нужно сделать слияние «мастера», у которого уже есть функционал «button1» с веткой «feature button2». Не получится ли так, что после слияния «мастера» с «feature button2» потеряется код от «button1»? Ведь эти ветки разрабатывались параллельно и ветка «button1» не подозревает о коде с «button2».
0
Это отличный вопрос!
Как раз такая ситуация и называется merge conflict — когда master ушел вверх от состояния, из которого отбранчевалась ветка, при этом одни и те же файлы изменялись и в master, и в feature-ветке.
Процесс мержа у гита довольно прост — берутся 2 исходных коммита, и объединяются в один _новый_ коммит.
Когда гит понимает, что существуют изменения файлов в обоих сливаемых ветках, он останавливает процесс мержа, добавляя в конфликтующие файлы информацию о «старых» и «новых» конфликтующих изменениях — соответственно из ветки куда мержат, и ветки откуда мержат. При этом новый коммит не создается, и гит предлагает вручную разрешить конфликт. После этого открываем так называемый merge tool — фактически это выглядит как 3 текстовых редактора в одном окне — левая часть содержит то, что было, правая часть содержит то, что стало, нижняя часть содержит то, что в итоге получится. Вручную просто либо выбираем то, что нужно оставить, либо объединяем изменения, либо старые заменяем новыми — третьего не дано)
После того как все конфликты во всех файлах разрешены, вручную делаем коммит с удачным мержем.

В результате мержа можно сломать проект — если что-то сделать не так. По-этому обычно перед мержем делают rebase — это когда вся наша конфликтующая ветка как бы стартует с нового мастера (то есть не с того места, откуда она бранчевалась, а с того, где теперь находится мастер). При ребэйзе все конфликты разрешаются последовательно не в мастере, а в feature-ветке. Таким образом мастер от этого никак не пострадает. После того как ветку отребэйзили, тестируем что получилось, и уже спокойно мержим в мастер без риска что-то сломать.

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

Если хотите, я могу написать статейку про конфликты, мерж и ребэйз с картинками)
0
Обязательно надо статью! А то иногда в логике последовательности действий сам чёрт ногу сломает. Особенно если надо один файл откатить на пару версий назад, отредактировать, а получившийся бранч втиснуть в дерево. Я обычно решаю все проблемы методом научного тыка. Действует всегда, но времени уходит немеряно.
+1
Да, дело обычно осложняется тьмой команд гита, которые дублируют функциональность друг друга.
Окей, как будет время, напишу про решение популярных задач гита — такого чтива, конечно, завались в интернете, но постараюсь сделать упор на практическую часть применения)
0
А на сколько Bitbucket и GitHub не подвержены модным санкциям? Другими словами, каков риск не достучаться в течении нескольких рабочих дней, плодя версии всей командой (не останавливаться же). На сколько наработки защищены от посторонних глаз?
+1
  • avatar
  • DVF
  • 01 февраля 2015, 18:35
Хмм, недавно была проблема с GitHub — его блокировали на какое-то непродолжительное время.
С BitBucket пока подобных прецедентов не было.
Но эти сервисы при разработке необходимы в основном для вспомогательных вещей — создания пул-реквестов, отслеживания их, комментирования кода и так далее. Ну и конечно же как источник сторонних библиотек, коих там просто пруд пруди.

Если представить, что вы этим не пользуетесь, и вам просто нужен общий репозиторий для работы нескольких человек, то даже при отключенных GitHub/BitBucket проблему синхронизации разработчиков можно решить следующим образом (в общем-то, можно так сделать даже изначально, но у вас не будет тех самых крайне полезных вспомогательных функций):

В принципе, гиту без разницы где находится репозиторий, который используется как удаленный. То есть вы можете на локальной машине создать один репозиторий, в папке ~/Remote/Project, потом его склонировать в папку ~/Local/Project, работать в ~/Local/Project, а пушить в ~/Remote/Project, при этом оба репозитория будут на одной машине.
По аналогии можно в локальной сети поднять небольшой сервер, на котором создать самую свежую версию репозитория (либо просто скопировать готовый репозиторий, либо инициировать новый, и запушить в него самый свежий). Потом каждый разработчик изменяет в git config адрес репозитория и пушит в него свою ветку.
Все — можно работать.

По поводу защиты — я работал в outsource-компании, которая вообще не держала никаких серверов — все размещалось в облачних сервисах. Все репозитории компании были на BitBucket (только платная лицензия — бесплатная ограничена работой 5 человек в команде). Доступ до репозитория можно настроить либо по ssh, либо логин+пароль, если работать по https. И BitBucket и GitHub могут быть предоставлять услуги и за деньги, так что безопасность с их стороны, думаю, обеспечивается на должном уровне. Я не знаю ни одного случая кражи исходного кода из-за беспечности сервисов.
0
Перекинь в общий блог "софт для электронщика".
0
  • avatar
  • Vga
  • 02 февраля 2015, 00:17
Как эти удалённые сервисы отреагируют, если перед отправкой файлы кода будут зашифрованы? Есть ли встроенный механизм предобработки перед отправкой и постобработки сразу после получения файлов в Git?
0
Ты промахнулся веточкой.
Если ты о сервисах Git — скорее всего просто работать нормально перестанет.
Есть ли встроенный механизм предобработки перед отправкой и постобработки сразу после получения файлов в Git?
Должны быть хуки, хотя подробно этот вопрос я не изучал.
0
Плохо реагируют, т.к. все эти системы сохраняют дифф файла, и большинство операций требует явно или неявно побитового сравнения двух файлов. Шифрованные файлы же будут отличаться почти всем, и работа системы будет медленной, печальной и без многих встроенных плюшек. Проще купить себе что-то типв AWS, зашифровать раздел и поставить на нём гит.
+1
Git не сохраняет дельты, он сохраняет сами файлы.
0
Перенес.
0
На работе работаю с Subversion дома с GITом — он мне больше нравиться. Для тех кно не в курсе, Altium Designer имеет встроенную поддерку для работи с системами контроля версий, чем мы успешно пользуемся (правда Subversion) — намного удобнее чем с папками с версиями.
0
  • avatar
  • Nemo
  • 02 февраля 2015, 18:52
На работе работаю с Subversion дома с GITом — он мне больше нравиться
Какие именно черты гита тебе нравятся?
0
Отсутствие локального сервера, ветки для разработки. Для меня возможность работать с разных мест над своим проэктом (дома и на работе).
0
Отсутствие локального сервера
В смысле работа с локальным репозиторием напрямую? SVN в принципе тоже так умеет, если репоз локальный, но в отличие от DVCS наличие локального сервера означает отсутствие удаленного)
0
Может я не совсем точно выразился. У нас на работе есть свн сервер, всё класно можно работать, но дома у меня нет к нему доступа что очень не удобно. С Гит намного проще, сихнонизируюсь з Bitbucket с работы и с дома, захотел в другом городе, стране, поделиться репозиторием, пожалуйста :)
0
т.е. вы используете «глобальный» сервер гита.
для svn не надо отдельного сервера, он прекласно работает с локальными папками. просто всесто адреса сервера пишется не http а локальный путь. и этот «локальный» путь можно разместить на флешке и не зависить от интернетов (как и гитовский).
0
+ гит работатает даже когда интернета нет, появился — синхронизировал. с СВН нужен постоянний конекшын для работы в команде.
0
Отлично. Я начал писать статью про TortuaseHG (Mercurial) но не дописал…
Надо доделать…
+2
тут неплохой пример: tqfp.org/best_practices/sistemy-kontrolya-versiy.html
+1
Спасибо за статью. Буду пробовать на базе hello world.
Так понимаю, все под командную строку, и придется на все делать ярлыки?

Ну и все помнят панику, когда роскомнадзор закрыл GitHUB, как бы не оказаться потом отдельно от своих исходников.
0
  • avatar
  • igorp
  • 03 февраля 2015, 12:32
свою систему контроля версий можно поднять хоть дома, хоть на купленной виртуалке. Примерчик: habrahabr.ru/post/43806/
0
Отдельно не окажешься в принципе — git работает только с локальным репозиторием. Удаленный с ним просто сихронизируется. Хотя если при клонировании ограничивать глубину клонирования — можно потерять историю, утратив основной репозиторий.
SVN в этом плане хуже. Когда хакнули и потерли какой-то VCS-хостинг, SVN-щики оказались в глубокой жопе — имея на руках только последнюю версию сорцов. Пользователи же гита и ртути потеряли только хостинг.
0
Нет, можно пользоваться и GUI-оболочкой (я использую SourceTree). В оболочке удобно можно смотреть диффы (разницу между тем что было и тем что стало), дерево коммитов, добавлять файлы в стэйдж тоже удобно. Но все операции с репозиторием я делаю из командной строки — тогда точно получится именно то, что хотел)
Если не нужно создавать пул-реквесты (например, если работать одному), то можно спокойно работать с сохранением репозитория в Dropbox, например. Просто устанавливаем Dropbox, в нем создаем репозиторий, как будто он remote, а потом его клонируем в папку, в которой будем работать. Могу показать в следующей статье как это делать.
0
хотелось заставить себя использовать CVS гораздо раньше, чем я начал
Работать в одно рыло с CVS прельстиво и любовно
Такие системы называют VCS, а не CVS. CVS — это самая первая такая система и старая как гумно мамонта, если не вспоминать про diff. Я впервые столкнулся с CVS в начале 2000-х (ей уже тогда было под 10 лет), в 2006-7-м ее полностью вытеснила SVN, затем уже SVN был вытеснен git'ом.
+1
Да, действительно, я ошибся — имел ввиду именно VCS. Не конкретную систему, а любую систему управления версиями)
0
Для себя в своё время выбрал Mercurial вместо Git. Мне Hg показался полегче в плане команд. Читая мануал по Git, ловил себя на мысли, что он написан для инопланетян, как-то тяжело он понимался(в плане команд и их ключей) В противовес, меркуриал пошёл как-то проще и легче, всё как-то логичней и понятней. Не знаю, может быть сейчас у Гита уже попроще стало, всё субъективно же :)
0
Читая мануал по Git, ловил себя на мысли, что он написан для инопланетян
Дык его же (git) САМ (Линус) говнокодернул на старости лет, типа: есть еще ягоды в ягодицах!
+1
Присматриваюсь к связке Меркурию+Bitbucket (W7-64), но для mP там пока что нет поддержки (всё руками надо).
0
Для такой IDE поддержка особо и не нужна. Для Delphi есть интеграция SVN, но я ей не пользуюсь.
Другое дело — поддержка шита в продвинутых IDE, когда прмо в редакторе построчно отображается статус исходника — подсветка изменений, подсветка «кто что написал» и так далее. А для коммитов и пуш-пулов более чем достаточно командной строки или клиента вроде SourceTree.
0
Да там не интеграция нужна, а поддержка тех расширений, что что в среде (файлы-исходники и проекты). Добавило бы удобства (меньше руками делать).
0
Гм? Каких расширений?
Я, правда, с гитом работал только из командной строки, а в SVN из расширений требовалось только игнор-лист заполнить, причем он был пустым и я вбивал туда на равной основе расширения мусора и для С, и для Delphi.
0
Как я понял, если в битбукете в списке есть нужный язык, оно автоматом ставит в выборку для репозитория только те расширения, которые должны обрабатываться. Или заблуждаюсь?
0
Битбакет вообще просто сервер для удаленного репозитория. Что класть в репозиторий, а что нет — определяешь ты. Не уверен только, в файле .hgignore или в момент добавления исходника под контроль (если говорить о других системах, то в гите в первую очередь первое, а в SVN в первую очередь второе).
0
Надо будет SourceTree с черепашкой сравнить.
0
В общем, BitBucket+Mercurial+SourceTree. У черепашки какие-то проблемы с кодировками при вводе паролей под W7 x64. Правда, и у SourceTree не всё Ок: есть глюки с русским текстом внутри обслуживаемых файлов.
0
У черепашки какие-то проблемы с кодировками при вводе паролей под W7 x64
А как проявляется? У нас черепаха работает и под семёркой и под 8.1 64-битными никогда с паролями проблем не было.
0
Что-то типа «… не может быть преобразовано в текущую кодировку»
0
Когда вводишь пароль
0
Кстати, а какая у вас версия черепашки? x64 или x86? У меня это проявлялось на x64.
0
Хорошей практикой является мерджить в свою ветку из мастера и ребейзить (черрпикать) обратно в мастер.
Чтобы посмотреть на ветки и коммиты использую SourceTree (на линухе так же есть xgit), все действия — только из консоли.
Никогда не пользуйтесь git add . (ну кроме начального коммита)), при работе в команде — огребете очень быстро. Только git add -i — сразу поймете что окажется в репе, а что нет.
Никогда не делайте git pull. Делайте git pull --rebase. Пруф
Команда git rebase -i номер_коммита — ваш друг! Можно проделывать с коммитами почти что угодно.
Коммиты — это всего лишь diff файлы выстроенные в цепочку. Если вы осознаете это — вы сможете делать с вашим деревом что угодно.
В репозитории можно хранить не только свои проекты но и, например, содержимое dot-файлов вашей домашней директории. Хороший пример примера
0
Трудности — это rebase, rebase -i, и разрешение конфликтов.
Вообще это темы для отдельных статей, и этих статей написано великое множество — было бы желание их читать)
Вот какраз таки таких статей как ваша полно.банально вбиваем в поисковик GIT на «Мне повезет» и вы получите такую статью. А вот статьи по разрешеню конфликтов всегда запрятаны поглубже, что бы не пугать народ. Ибо если вы напоролись на конфликт — вы отправляетесь туда же, где статья.
Мое мнение о GIT — да ну на… в *****. Сколько я намудохался с ним в достаточно простых ситуациях. Консоль обязательно — без неё невозможно. Чуть сделал что-то не по инструкции — репка в ***** и у вас 2 выбора, либо снести на… репку, либо снести свои правки, «третьего не дано». На любой чих обязательно делать отдельную ветку (иначе читаем с начала абзаца).
В SVN конфликты разрешаются на порядок проще.
0
Не совсем понятно, что можно такое сделать с репозиторием чтобы приходилось его сносить. Даже ветку мастер можно целиком пересоздать как надо, счерепикав коммиты в новую ветку master_new и переименовав их местами.
Если вы совсем запутались в процессе ребейза и хотитет вернуть как было — достаточно сделать git rebase/cherry-pick --abort.
Конфликты решаются выбором правильно куска кода нижний/верхний, а если вы делали правки для уже неактуальной точки дерева — тот тут вы сами себе злобный буратин, делайте ребейз и ручками двигайте свои коммиты вверх по ветке.
Названия веток — это просто указатели на хеши коммитов, с названиями можно делать что угодно, с коммитами тоже.
0
Банально берем 2 компа и льем изменения в одной строке.
Все (как и Вы) показывают как с ним «легко», и все (как и Вы) абсолютно игнорируют решение конфликтов. Самые хитро… пишут «конфликты решаются элементарно, по скольку гит к ним готов».
гит это репка для тех, кто привык быть рутом (банально взгляните как все писают кипятком по поводу того, что он «позволяет править комментарии»). В этом и его проблема.
0
Банально, мержим у себя с удалённой веткой, решаем конфликты, потом пушим изменения в репозиторий.
0
Когда пользовался SVN, решение конфликтов при объединении веток было сущим кошмаром. Затем перешёл на Hg, стало гораздо удобнее, SVN ушёл в прошлое. Потом попробовал Git и забыл про Hg тоже.
Просто надо научиться пользоваться.
0
Решение конфликтов при объединении веток в свн было «основным» (не по времени, а по сваливанию на меня) моим занятием. И мне это занятие нравлось. Элементарно. Да, надо время на их разрешение, надо подключить мозги, что бы определить что где лишнее, но с самим свн делается все элементарно. Я сконцентрирован на решении задачи, а не на е*ле с репозиторием.
Конфликты в свн достаточно редки и легко разрешимы.
При банальном коммите с 2х компов в гит же, я должен знатно поснашаться с консолью, только что бы мне поззволили начать разрешать конфликт. Про сам коммит вооще лучше не заикаться.
Конфликты в гите постоянны и долбаться с ними надо постоянно. Естественно когда оно в итоге «зазубривается» и дальше «можно пользоваться», но нафиг надо.
0
Да нифига подобного. Вы же уже зазубрили ветки в SVN и как там решаются конфликты? Какая разница, где зубрить?
0
githowto.com/ru/resolving_conflicts
При merge обнаруживается конфликт.
merge останавливается, выводится в каких файлах конфликт.
Открываете файл, там строки из одной ветки и из другой, показано где какие.
Исправляете строки на нужные. добавляете в stage и продолжаете merge.
Какие проблемы? Включить мозги точно так же можно.
0
Вот стедж отказывается принимать файлы, говорит обновитесь. Обновление не работает, говорит конфликт. Откат не работает, говорит у вас же есть правки (кто бы сомневался). Удаление файла из контроля не работает, в нем конфликт и он считается не под контролем. добавление файла не работает, говорит уже есть (оппа). Переключить ветку нельзя, есть правки. Репка попросту парализуется в таком виде.
Интернет предлагает в правилах хорошего тона «любое изменение делать исключительно в отдельной ветке, и только после этого мержится в основную» и тогда подобных проблем не будет — это работает. Получается очень «удобно», когда для того, что бы пофиксить пропущенную запятую я должен делать ветку, править, заливать, мержить, заливать. А если я так не сделаю — то попросту наверну свою репку (по скольку другой член команды «успел» пофиксить ту же ошибку). И перед этим хорошо бы сделать бекап.
Иными словами гит позволяет работать нескольким пользователям с одним проектом, только если каждый из пользователей работает со своей отдельной веткой, и отдельно у себя мержит коммиты остальных пользователей (пока свой код еще завершен, а наработки остальных пользователей уже нужны). Одновременная работа с одной веткой несколькими пользователями не представляется возможной.
P.S.: Тот githowto.com я изучил весь. Вы удивитесь, но с начала я читаю доки, а потом приступаю к практике. На уровне док все превосходно и легко, как и в Вашей статье, но когда доходит до практики…
0
Это не Stage может отказаться, а репозиторий от приёма коммитов, если его состояние ушло вперёд.
Обновление вызывает конфликт, значит файлы находятся в промежуточном состоянии.
Откат — это git checkout., git merge --abort или что? Отменить merge можно без потерь.
Удаление файла из контроля в неопределённом состоянии — выстрел себе в ногу.
Переключить нельзя, да, надо сначала отменить merge, раз приспичило. Репка не парализуется, ей вообще пофиг на несохранённые изменения.

Ветки это удобно. Это не ветки в SVN, ваши привычки оттуда здесь заставляют делать вас неправильные предположения. Если вся ваша команда ведёт работу в одной ветке master, то ССЗБ.
Посмотрите в A successful Git branching model, как с этим удобнее работать. Методы SVN здесь не в тему совсем.
Нет, я не удивлюсь. Сам так реагировал на конфликты в merge, когда-то. Надо применять к механизму его методы работы, а не чужие.
Если хотите, в Skype покажите эту проблему. Может быть покажу, как решается.
0
подскажите а если я создал свой репозиторий в облаке как с такм вариатом работать тогда? у меня еще ключики есть ssh. Собственно не совсем могу понять — мой комп на винде а на удаленном сервере крутится git с созданым bare репозиторием. мне нужно создавать локальный репо и их синхронизировать?
0
Если на сервере поднят gitosis, то нужно делать вот так ssteiner.wordpress.com/2009/05/13/adding-a-new-repository-under-gitosis-2/
0
Нужно просто склонировать репозиторий: git clone <repository-address.git>
Ключ нужен для того, чтобы авторизоваться в удаленном репозитории по ssh. Но можно и без него — по https с паролем.
0
ну и каким софтом на винде пользоваться? я поставил git gui и git bush но не могу понять как работать с удаленными репозиториями с ними
0
SourceTree но это как секс в акваланге, вы не будете понимать что происходит и как работает, но для жизни под виндой хватит.
+2
пробовал соурс три или что-то непонимаю но он работает только со своими сервисами типа гитхаб, битбакет а что бы свой сервак ввести так и не нашел. Если у меня софт в котором работаю KEIL под виндоус стоит. То работа с репозиторием тоже соответственно будет из под винды
0
В SourceTree есть кнопочка + New Repository — и там на выбор: склонировать, создать новый, добавить существующий и что-то еще. Но вообще я бы не рекомендовал работать с git исключительно с GUI.
0
есть ли какой-то хороший шелл для виндоус? что бы как в bash удобно было пути и команды набирать
0
0
0
С Git'ом в комплекте идёт bash под винду, разве нет?
0
Идёт с msysgit.
0
Да все верно. с софтинкой github for windows Идет хорошая оболочка на основе power shell со вкусностями bash
0
А есть что-то похожее, но для олдфагов, до сих пор сидящих на WinXP? Если оно еще и будет одновременно поддерживать mercurial, как SourceTree — совсем хорошо.
0
Ещё есть gitlab. Приватные репозитории для команды до 5 человек.
0
А, кстати, может кто напишет статью по вопросу GitLab в случае работы с GitLab.com и развертывания на сервере предприятия (дома) со статичным IP?
0
а можно на гитхабе попробовать. Просто интересно во всем разобраться. Как-то раньше пробовал свой сервер svn и софтинку под винду не помню уже как называется. но как-то запутано мне показалось тогда все
0
могу порекомендовать еще от Лины — неплохо о ГИТ с переводом nnm-club.me/forum/viewtopic.php?t=861329
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.