[X] Помощник

[fedornabilkin Topic Starter]

Git - одна из мощнейших систем контроля версий. Дання система обладает одной важной деталью - экономит огромное количество времени.
 
Некоторые преимущества использования систем контроля версий:

•  


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


• При тестировании новой фичи, можно переключиться на ветку с новой фичей, если что-то пошло не так, переключаемся на рабочую ветку (master) и проект продолжает работать в прежнем режиме.


• При совместной разработке не надо уточнять кто и в какие файлы вносил изменения.


• Удалил кусок рабочего кода, можно откатить изменения и вернуть как было.


• Работали над одной задачей, не доделали, переключились на другую ветку, исправили срочный косяк (сделали bugfix) и вернулись к своей разработке.

Несколько отговорок (жирных), которые мешают начать использовать git (другие vcs):

• У каждого есть своя уникальная.


• Я очень организованный разработчик и всегда делаю резервные копии. Это хорошо, но со временем (с ростом проекта или их количества) возникают некоторые сложности. Как назвать изменения, хранить только измененные файлы или целиком проект? Как узнать разницу между текущей версией проекта и предпоследней копией?


• Git слишком сложный и на изучение надо потратить много времени. На изучение чего-то нового всегда приходится тратить время, но всякий раз, потраченное время с лихвой себя окупает. В будущем полученные знания позволяют экономить гораздо больше времени. Git действительно достаточно сложный, если изучить его полностью. Но для того, что бы начать с ним работать, необходимо знать десяток команд и понимать как они работают. Дальше, при возникновении какой-то потребности, будет очень приятно узнать, что разработчики git это уже предусмотрели.


• Я работаю один, а git для команды. Один разработчик пользуется такими же преимуществами, как и команда. К примеру github позволяет иметь резервную и актуальную копию проекта. Можно работать на нескольких машинах (дома/на работе).


• В командной строке работать слишком сложно. Опять же, не надо быть экспертом, достаточно знать основные команды. Для начала работы, на изучение надо будет потратить не более одного дня (обычно знакомство происходит за вечер). Если совсем беда со строкой, есть программы с графическим интерфейсом.


• Из-за отсутствия должного опыта я могу испортить проект. Испортить проект скорее получится не используя контроль версий, потому что сложно отслеживать изменения. Если изменения сделаны неудачно, то всегда можно вернуться на предыдущую версию.

Важно знать, что гит не хранить копии файлов разных версий. Он сохраняет лог изменений. Т.е. записывает в каком файле и что было изменено/удалено/добавлено.
 
Основные команды для начала работы
 
Настройка репозитория
git config --global user.name "Your Name" - глобально добавляем имя пользователя (один раз для пользователя)
git config --global user.email "youremail@domain.com" - глобально добавляем электронный адрес (один раз для пользователя)
git init - инициализирует репозиторий git, в котором будет хранится информация о сделанных изменениях в файлах проекта, а также конфигурация.
git remote add origin https://github.com/user_login/project_name.git - добавляет адрес удаленного репозитория.
git remote -v - отображает список удаленных репозиториев.
 
Работа с проектом
git branch -a - отображает существующие ветки (локальные и удаленные). Текущая ветка будет отмечена.
git branch add_search_widget - создает новую ветку с названием add_search_widget.
git checkout add_search_widget - переключает на ветку с названием add_search_widget.
git checkout -b test - создает ветку test и переключает на нее (чтобы не выполнять две команды).
 
git status - отображает измененные/удаленные/добавленные файлы.
git add . - (после add точка) добавляет изменения, которые надо будет зафиксировать (сделать commit). Вместо точки можно указать адрес файла. Используется при добавлении новых файлов в проект.
git commit -am "first commit comment" - фиксирует изменения и добавляет комментарий (-a фиксировать все измененные файлы, -m комментарий, либо -am)
git pull origin master - скачивает (вытягивает) изменения из удаленного репозитория из ветки master (если кто-то уже внес свои правки).
git push origin add_search_widget - заливает (выталкивает) локальные изменения в удаленный репозиторий из ветки add_search_widget в одноименную ветку (обычно в мастере не работают и выталкивают другие ветки, а кто-то один из команды мерджит (сливает изменения) новую ветку с мастером).
git merge add_search_widget - сливает текущую ветку с веткой add_search_widget
 
Вот этой небольшой горстки команд достаточно для такого, чтобы начать работать с системой контроля версий git. А теперь обезьянний алгоритм, чтобы с самого начала выработать последовательность действий более правильную и не засовывать мух в котлеты.
 
Инициализируем репозиторий гит и добавляем адрес удаленного репозитория (один раз для проекта). Для этого переходим в директорию проекта и выполняем команды

git init
git remote add origin https://github.com/user_login/project_name.git

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

git checkout -b new_name_branch

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

git status
git add .
git commit -am "Текст комментария что и для чего изменяли"
git pull origin master
git push origin new_name_branch

Что бы минимизировать возможные конфликтные ситуации, обычно переключаемся на master, делаем git pull, чтобы получить актуальные изменения, а уже затем создаем новую ветку. При создании новой ветки получается так, что мы отпочковались от мастера и начали жить в этой ветке своей жизнью.

После выполнения команд git, обычно, что-то там пишет в консоль. Особое внимание необходимо обращать на CONFLICT, Aborting и/или Error. Значит что-то пошло не так. Я обычно кидаю в переводчик, тогда более менее понятно, что произошло и что делать.

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

Помните, что изучая что-то новое, вы приобретаете опыт, навык и восходите на одну ступень выше. А это хорошая инвестиция в себя.

[TimurR]

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


Сообщение отредактировал TimurR - 6.4.2018, 0:42

[fedornabilkin Topic Starter]

TimurR, gulp на очереди. Но я опишу только лишь самые основы и как начать работать с ним. Все тонкости и нюансы надо самому изучать. Хорошо, если кто-то в теме опишет свой опыт работы.
У меня нет опыта работы с битбакет (пока я такого понимания, что с ним хуже работать чем с гитхабом и гитлабом). Если у тебя есть, пожалуйста, опиши его здесь.

[TimurR]

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

Замечание модератора: Эта тема была закрыта автоматически ввиду отсутствия активности в ней на протяжении 100+ дней. Если Вы считаете ее актуальной и хотите оставить сообщение, то воспользуйтесь кнопкой или обратитесь к любому из модераторов.