Какой опыт Git нужен веб-разработчику для работы в команде в компании?

Question

[Александр]

Опыт работы с СКВ небольшой - я единственный фронт- и бекенд разработчик на моей первой офисной работе, делаю просто коммиты нашего проекта через Git GUI и с помощью SourceTree заливаю иногда как резервную копию на BitBucket. Какой уровень работы с Git обычно требуется (в деталях)? Кто как в командах работает? Изучать ли консольные комманды linux для Git или через клиенты обычно работают? Что в этом плане нужно уметь делать?

Answer 1

[Yustas Alexu]

Желательно понимать, что делают и зачем нужны следующие команды:

git status
git checkout
git reset
git fetch
git pull
git push
git diff
git add
git commit
git stash

Comments

[mvsavkin]

git log

[Yustas Alexu]

Артём Петренков: не пользуюсь ими совсем. Ветки создаю на гитхабе.

[Yustas Alexu]

Артём Петренков: нет. работаю в команде.

[Yustas Alexu]

Артём Петренков: вы считаете, что git merge или git rebase как-то помогает решать merge-конфликты? Я это делаю через GUI. Но такое происходит редко, потому что у нас в проекте модульная архитектура и все разделено на маленькие модули.

[Vitaliy Orlov]

+ к вышеупомянутому:
git checkout
git reset

[vism]

всё это делаю через шторм)

[Finsh]

vism: та же ситуация, но знать что они делают все равно нужно

Answer 2

[Карина]

как я обычно делаю:
1)создаю новую ветку со своей фичей(и ты автоматически в нее перейдешь):
git checkout -b name-branch
2)делаю что надо
3)коммичу

git add -A
git commit -m "Name commit"
git push origin name-branch

4)Обновляю свою ветку по отношению к master (так образом твой последний коммит будет стоять на вершине)
git pull --rebase origin master

5)Возвращаюсь в нужную ветку (master или developer)
git checkout master
6)Обновляю свою локальную ветку
git pull origin master
7)Сливаю изменения и делаю пуш

git merge name-branch
git push origin master

Comments

[Сергей]

А я обычно 2 кликами в GUI все это)
В консоли только делать init lдля нового проекта

[Карина]

да, в GUI это удобнее.

[Игорь Воротнёв]

Сергей: откройте для себя мир alias'ов. Сделайте одну команду, которая выполнит 4-6, например. Условно:
git push origin name-branch && fucktherest
где fucktherest - алиас команд:

git pull --rebase origin master
git checkout master
git pull origin master

А еще это может быть простенький bash-скрипт, которому вы передадите имя своей ветки, и тогда он может выполнить все что после коммита. Да и первые шаги можно обернуть так же. В общем, есть варианты, не обязательно все это строчить руками каждый раз. Хороший программист = ленивый программист.

[Виолетта Морозова]

Самый лучший и полезный ответ! Больше этого вам не понадобится пока на проекте не появятся какие-нибудь особенности.

[Snorway]

iKapex: а если между вторым и третьи пунктом, вам срочно нужно закоммитить багфикс или какую-то мелкую правку? Как в таком случае выпутаться?

[Карина]

Snorway: закоммитить куда? в мастер? и из какой ветки закоммитить?

[Snorway]

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

[Карина]

ну вот ты в ветке name-branch и тебе надо сделать багфикс:
1) коммитишься в name-branch (потом этот коммит можно будет продолжить с помощью git commit --amend)
2)переходишь в мастер
3)создаешь ветку git checkout -b bugfix
4)делаешь что надо
5)коммитишься и пушишься в bugfix
6)потом переходишь в мастер git checkout master
7)обновляешь git pull origin master и сливаешь изменения и всё - git merge bugfix
8)и пушишь это дело в мастер
9)ну и потом опять переходи в свою ветку name-branch; делай что надо и как сделаешь - делай git add -A, а потом git commit --amend - твой коммит продолжится

[Snorway]

iKapex: Спасибо. Как вам git flow?

[Карина]

Snorway: не знаю, не пользовалась

Answer 3

[gaxetasok]

Достаточно

git push
git pull
git commit
git add

Comments

[Александр]

А типа основы командной строки Линукс не нужно?) И что, все работают с консолью Линукс что на Windows, что на Mac?

[Ivanq]

Александр: git bash - наше все :)

[Александр]

Ivanq: ясно, значит нужно начинать и Линукс практиковать...никогда не сталкивался. А как git bash "попробовать" на Windows?

[Yustas Alexu]

Александр: установите git на винду. Там будет и git-bash.

[Yustas Alexu]

Александр: по поводу линуксовых комманд - все придет с опытом. Проблемы надо решать по мере поступления.

[gaxetasok]

Александр:

А типа основы командной строки Линукс не нужно?) И что, все работают с консолью Линукс что на Windows, что на Mac?

А умение включать компьютер нужно?

Какая разница? Гит что на Винде что на Линухе - едиными командами обладает.

Answer 4

[Maxim Firsov]

Откажитесь от GitGUI и перейдите на консоль в своих проектах, этого будет достаточно.

Comments

[Александр]

Просто срашиваю - зачем? Почему нужно через консоль команды писать, а не с интерфейсом работать? Особенно как увидеть визуально список коммитов и изменений в файлах. Видимо я чего-то не понимаю, раз мне это кажется "старомодным"...

[Maxim Firsov]

Александр:
плюсы:
+ независимо от платформы, git консоль работает одинаково на 99% (Win, Mac, Lin)
+ очевидно что GUI строится на консольных командах, поэтому знать их - это git-азбука

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

Список коммитов и изменений в файлах - стандартные команды, для diff можно вызывать отдельную настраиваемую утилиту, также как для комментов.

Моя история простая - я тоже долгое время использовал GUI, но на одном проекте (весьма хорошем как по задачам так и по оплате), менеджер попросил (настоятельно так) перейти на консоль. С тех пор только она.

[Виолетта Морозова]

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

[Виолетта Морозова]

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

[Maxim Firsov]

Виолетта Морозова: да кстати :)

Answer 5

[Ильдар В]

я на собеседованиях спрашивал про git только для понимания общего развития. Это не критерий приемки на работу. Адекватный кандидат потратит на освоение гита не больше недели.
Команды git может совсем не знать. Достаточно того, чтобы работал с какой-нибудь системой контроля версий.

Если конечно это не специалист по DevOps)

Answer 6

[Сергей Горностаев]

Пятнадцатиминутный.

Answer 7

[John_Nash]

Никакой не нужен, если вы не архитектор, которому срочно нужно выбрать какую СКВ использовать

Answer 8

[Евгений Педя]

Есть основные команды. Их указали выше.
Можно и через GUI работать, но всё же понимать, какая команда вызывается.

И есть поток разработки. Его то же не плохо понимать.
Вот старая, но не устаревшая статья https://habrahabr.ru/post/106912/

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