У меня нет опыта работы с Git, но я изо всех сил стараюсь привыкнуть к нему, и пока что я использую его только для проектов, над которыми я работаю один.
Когда я пишу код, есть какой-то нисходящий подход естественным образом (поскольку я не знаю будущего), и возникает повторяющаяся тема:
Я делаю некоторую работу.
Я узнаю, что для того, чтобы моя работа стала чем-то «обязательным», мне нужно заниматься другой работой.
Другая работа заслуживает отдельного коммита.
Под чем-то обязательным я подразумеваю то, что компилируется, или что-то, что не является полным беспорядком.
И что-то, что заслуживает отдельного коммита, я имею в виду, что я узнал, что коммиты должны делать только одно.
То, как я это решаю, громоздко. Если другая работа находится в другом файле, я создаю новую ветку, фиксирую там и объединяю. Если работа находится в том же файле ... тьфу ... Я делаю локальную копию и возвращаю файл в его состояние в HEAD, делаю необходимый коммит и затем начинаю восстанавливать мою работу из копии. Как мне на самом деле справиться с этим? Я не думаю, что это так, не так ли? Я так не думаю, потому что это должно приходить довольно часто всем (кто, по крайней мере, не знает будущего). Или, может быть, кажется, что мой рабочий процесс может быть ошибочным?
git status
чтобы увидеть все измененные файлы, и сделать два или более коммитов, используяgit add
с конкретными файлами (вместоgit add --all
), и коммит по частям.git add -p
а затем зафиксировать только эти части. Это очень мощная техника, и я использую ее почти все время.Ответы:
Есть несколько способов решить эту проблему.
Если вы хотите внести изменения для первого коммита, не мешая текущим изменениям, вы можете использовать их
git stash
. Это уберет все ваши открытые изменения, что позволит вам восстановить их позже. Используйте,git status
чтобы увидеть, что их больше нет. Теперь создайте первый коммит, как вы привыкли. Далее вы можете использовать,git stash pop
чтобы восстановить ваши исходные изменения и создать второй коммит, выполняя вашу основную работу.Другой способ - сделать все необходимые изменения, а затем создать два коммита, каждый из которых содержит часть вашей работы. Для этого вы можете использовать индекс (также известный как промежуточная область), предоставляемый git. Это специальная область, которую вы можете использовать для подготовки коммитов. Предполагая, что вы изменили несколько файлов, вы можете добавить каждый из них в индекс с помощью
git add
. При этомgit commit
будут зафиксированы только файлы, добавленные в индекс.git status
покажет вам, какие части ваших изменений будут приняты, а какие нет. Например, это будет выглядеть после изменения файлов a.txt, b.txt и c.txt и после этогоgit add a.txt
:Когда вы делаете
git commit
в этом состоянии, только изменения в .txt будут добавлены в ваш коммит.Дополнительно вы можете просмотреть точные изменения, которые будут зафиксированы с помощью
git diff --cached
, который покажет вам разницу всех изменений, которые будут зафиксированы.Если один файл содержит изменения для обеих фиксаций, вы также можете добавить в индекс только его части, используя «git add --patch b.txt». git предоставит вам интерактивный режим, который запрашивает каждое изменение в данном файле, следует ли его добавить в индекс. Это может усложниться, если у вас есть изменения в строках рядом друг с другом, которые нужно разделить в двух коммитах, однако есть способы решить и это.
Если вы хотите узнать больше об области подготовки, вы можете прочитать это: http://gitready.com/beginner/2009/01/18/the-staging-area.html
Вы также можете узнать больше об интерактивном добавлении здесь: http://nuclearsquid.com/writings/git-add/
источник
Если вы используете графический интерфейс для Git, такой как SourceTree от Atlassian, или
git gui
вы можете зафиксировать части файлов и оставить другие части незафиксированными. Фактически, вы можете фиксировать отдельные строки кода.Я делаю это часто, когда падаю в кроличьи норы, как вы описываете. Это отличный способ сделать разумный коммит или коммит как предвестник основного коммита.
Вы можете сделать это из командной строки, но это немного неуклюже.
Когда вы можете фиксировать на уровне патча Git и отдельных строках, вам не нужно создавать новые ветви, копить, фиксировать, копить и объединять. Просто продолжайте работать и не нарушайте поток. У тебя хорошо получается.
источник