Хорошо ли часто фиксировать файлы при использовании Mercurial или Git?

Question

Похоже, что мы можем часто совершать попытки отслеживать промежуточные изменения кода, который мы написали ... например, на hginit.com, при использовании Mercurial или Git.

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

Answer 1

Лучший способ справиться с этим (используете ли вы Mercurial, Git или любая другая система контроля версий), чтобы убедиться, что ваша работа делается на ветвях, которые соответствуют этим "частям функции ". Если есть даже небольшая вероятность того, что какая-то часть работа должна быть освобождена независимо от другой работы, это должна иметь собственную ветку с самого начала.

Это дает вам возможность толкать только «часть функция ", и гораздо лучше подходит в случае, когда" часть функции "и некоторые другие" части функции "оба содержат изменяется на тот же файл.

Хорошая вещь об использовании Mercurial или Git заключается в том, что управление эти ветви тривиальны, поэтому стоимость создания и использования их (даже если они оказываются ненужными) минимально.

Теперь вы не можете всегда все предвидеть. Если вы застряли в ситуации, которую вы описываете, легко выбраться из. Скажем, у вас было 100 наборов изменений локально (еще не на сервере), и вы хотели просто нажмите текущее содержимое 1 файла. Создать клон репозиторий, над которым вы работаете, вернитесь к ревизии сервера, скопируйте файл завершен, зафиксирован, передан и интегрирован обратно. В ртутном это будет выглядеть примерно так:

$ cd ~/project
$ hg clone http://server/project/trunk trunk-oops
$ cp trunk/shouldve-branched trunk-oops/shouldve-branched
$ cd trunk-oops; hg addrem; hg ci -m "We need to organize better!"; hg push
$ cd ../trunk; hg fetch ../trunk-oops

Answer 2

Разработка по веткам.

Имеет ветку релиза и функциональные ветки.Объедините каждую функцию, когда она станет доступной.

Answer 3

Хорошей практикой является частая фиксация.В вашем случае кажется, что вам нужно чаще начинать тегирование и / или ветвление.

Answer 4

Чтобы расширить и уточнить то, что сказали другие: частые коммиты и гибкие нажатия не являются взаимоисключающими.

Вы действительно хотите планировать заранее и делать свои коммиты такими, чтобы вы могли адаптироваться.Это означает две вещи: вам нужно убедиться, что вы действительно часто делаете коммиты, и вам нужно часто переходить (как в git).Если ваши коммиты небольшие, вам будет легче реорганизовать их позже, если вам нужно будет выборочно сгруппировать часть вашей работы.И если ваши ветви хорошо организованы, возможно, у вас уже есть ветвь, и это именно то, что вы хотите нажать.

Сравните эти два:

One branch, few commits:

- A1 - B1 - C1 - B2 - A2 - B3 - C3 (master)

Many branches, many commits:

  M1 - M2 (master)
 /
o - A1 - A2 - A3 - A4 - A5 - A6 (topicA)
|\
| B1 - B2 - B3 - B4 - B5 - B6 - B7 (topicB)
\ 
 C1 - C2 - C3 - C4 - C5 (topicC)

Теперь, если вы хотите выпуститьлюбая из этих трех тем, как есть, все, что вам нужно сделать, это объединить ее, чтобы освоить и подтолкнуть!Если вы хотите освободить половину темы A, и эта половина рассматривается в коммитах A1, A3, A4 и A6, все, что вам нужно сделать, это перебазировать топик A, чтобы поместить эти четыре коммита первыми, объединить последний из них с master,и нажмите.Остальная часть темы A (A2 и A5) может зависать для дальнейшей работы.

  M1 - M2 ------------- X (master)
 /                     /
o - A1 - A3' - A4' - A6' - A2' - A5' (topicA)

(коммиты, обозначенные A1 ', ... потому что с git два коммита с одинаковым содержимым, но разные родителина самом деле разные коммиты.)