Вже були статті про основи гіта (0, 1, 2), були і статті про внутрішній пристрій репозитарію. Сьогодні поговоримо, як простому смертному працювати з гітом на автопілоті і не морочити собі голову.
По-перше, шорткати (в порядку убування популярності):
alias gst='git-status'
alias ga='git-add'
alias gc='git-commit -m'
alias gp='git pull && git push'
alias gull='git pull'
alias gush='git push'
alias gb='git-branch'
alias gco='git-checkout'
alias gd='git-diff'
По-друге, відображення поточної гілки в командному рядку:
export PS1='`__git_ps1 ""%s""` \w \$ '
Виглядає так:
lazy-args-in-futures ~/Work/io/oleganza-io.git $
(Як встановити: ericgoodwin.com/2008/4/10/auto-completion-with-git)
Типовий потік роботи в одній гілці
1) Щось пописали, прогнали тести
2) $ gst - побачили, які файли нові, які оновлені.
3) $ ga a b c - додали нові та оновлені файли до індексу.
4) $ gc'something is done'- записали коміт у репозитарій
5) Знову щось написали, знову закомітили.
6) $ gp - злили чужі зміни, залили свої зміни. Якщо раптом виник конфлікт, вам про це напишуть, будете мерджити.
Щоб просто підтягнути оновлення, набираємо $ gull (git pull).
Локальні гілки
Принцип: одна фіча - одна гілка. Один багфікс (якщо передбачається довше двох коммітів) - одна гілка. Один експеримент - одна гілка. Одна фіча всередині експерименту - гілка від гілки. Ну, ви вловили ідею.
Навіщо воно потрібно? Уявіть, що ви почали день з фічі А, а до вас підійшли і сказали, що потрібно зафіксувати і перевірити Б. А через п'ять хвилин з'ясувалося, що для того, щоб по-людськи зафіксувати Б, потрібно прикрутити і перевірити Ц. Якщо кожну з цих завдань тримати в окремих гілках, то голова не піде кругом, і робота не встане поперек горла.
Набираємо:
master ~/project $ gco -b my-feature
Отримуємо:
my-feature ~/project $
Список всіх гілок: $ gb
Перемкнутися на іншу гілку: $ gco some-branch
Не забувайте, що ви завжди можете підлити якусь гілку в поточну за допомогою git merge other-branch.
Життєві ситуації з гілками
1) Виправлення бага/додавання фічі. Робимо гілку, все тестуємо, підливаємо в неї master: gull & & git merge master, знову тестуємо, виходимо в майстер (gco master), підливаємо гілку (git merge my-branch), тестуємо, заливаємо майстер (gush) і видаляємо гілку (gb -D my-branch).
2) Публікація гілки для спільної роботи: gush origin my-branch:refs/heads/my-branch
Вилучення гілки: gush origin :refs/heads/my-branch (увага на пробіл перед двокрапкою)
3) Ви сидите в одній гілці і зробили щось, що хотіли б закомітити в іншу гілку. Якщо ви ще не закомітили, то робимо git reset HEAD для вже доданих файлів (через ga/git-add), потім git-stash, виходимо в потрібну гілку, робимо git-stash apply і далі діємо так, як ніби ми прямо тут все і змінювали.
4) Ви зробили коміт в деяку експериментальну гілку, який має сенс залити в майстер, але git merge my-branch не підходить, тому що після цього кімміту були ще кілька експериментальних коммітів.
На цей випадок є git-cherry-pick. Спочатку, подивіться git-log і скопіюйте номер потрібного комміту. Далі, ви повинні закомітити всі зміни в тій гілці, в яку будете кидати висмикнутий коміт. Потім, робите git-cherry-pick і розрулюєте конфлікти, якщо виникли.
У мене така ситуація була саме з додаванням кімміту в майстер, тому після цих хірургічних маніпуляцій мені потрібно було підлити майстер в локальну гілку. Оскільки cherry-pick лише застосовує дифф (номер кімміту стає іншим), то гілка не знає, що внесена зміна у неї вже є, і не може нормально його смерджити. Тому, при мерджі майстра в гілку ви гарантовано отримаєте дурні конфлікти а-ля «рядок АБВ конфліктує з АБВ».
Якщо хтось знає, як уникнути конфліктів у такій ситуації (і заощадити 5 хвилин часу), поділіться досвідом.
Нудні вчення наостанок
1) Кімити повинні бути дрібними. Дифф на п'ять екранів повинен бути винятком, а не правилом.
2) На перших порах не морочте собі голову з rebase і «чистотою» лінії коммітів. Це турбує тільки останніх естетів або Лінуса (який мерджить десяток гілок на день). Читати git-log і ігнорувати банальні merge commits немає ніякої проблеми.
3) Читайте git-log після pull, лайте своїх колег за незрозумілі описи кімтів.
4) Вивчіть .git/config:-)
Наступного разу потрібно написати пару слів про комфортну роботу з git-submodule і git-svn.