Git: Невозможно понять, почему в основной ветке происходят коммиты / слияния ветки (темы)

Question

Примечание: я не уверен, что это уже было задано, так как я не могу найти какой-либо вопрос, подходящий для моего контекста (или я не могу понять существующие контексты вопросов)

Я люблю Git в эти дни. Особенно тема веток. Я работаю над небольшим приложением для обмена кодами. И у меня есть (локальные) ветки, такие как "мастер", "аутентификация", "закладки", "комментарии", "нос" и т.д ...

Мой (предполагаемый) рабочий процесс выглядит примерно так: Создайте ветку темы ==> Работайте над веткой темы ==> Зафиксируйте файлы в ветке ==> Объедините изменения ветки темы с веткой "master". (А позже удали ветку темы)

Я попытался сделать то же самое для пары веток. Работало нормально. Но позже, когда я проверил граф Git, даже если я следовал тому же рабочему процессу, все шансы происходили на «мастере». Нет линий дерева расходящихся и сходящихся! Он показывает одну строку с несколькими коммитами с тех пор. Я не уверен почему? У меня такое впечатление, я что-то прикрутил с указателем HEAD?

Чтобы дать практическое представление, вот мой граф git: http://github.com/none-da/zeshare/network

Вот команды, которые я использовал:

>> git branch authentication_feature
>> git checkout authentication_feature
>> # I work with all the files here in "authentication_feature" branch
>> git commit -m "Authentication_feature is up" # commiting to the branch
>> git branch # just to confirm, which branch I am working on
>> git checkout master # trying to shift to master branch
>> git merge --no-commit authentication_feature # I merge in two steps. This is step 1
>> git status;git add; git commit -m "Authentication_feature" merged to "master". # This is the step 2
>> git log --graph --pretty=oneline # confirming the graph
>> git push origin master # pushing to the remote server(github)

Answer 1

Бьюсь об заклад, вы ищете --no-ff переключатель на git merge.По умолчанию merge просто обновит HEAD до конца новой ветви, если нет промежуточного коммита.

Если вы хотите оставить коммит слияния вокруг, чтобы помочь с группировкой ваших коммитов, передайте--no-ff.

Answer 2

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

Ну ... я вижу некоторые твои ветви и слияния.

На этой странице вы найдете все возможные сценарии слияния
(составлено в то время - в конце 2007 г. - к настоящему моменту ТАК: Jakub Narębski )

Вы могли бы быть в ускоренном рассмотрении, которое объясняет, почему ваши слияния заставят все ваши коммиты казаться освоенными, как только они будут сделаны:

2 / Перемотка вперед; нет коммитов A, B, C, и мы начните со следующей ситуации:

   1---2---3               <-- trunk    <-- HEAD
            \
             \-a---b---c   <-- branch

2,1 / "git merge branch"

   1---2---3            /----- trunk    <-- HEAD
            \          v
             \-a---b---c   <-- branch

Перемотка вперед приводит к простому перемещению головки туловища.
Он не создает коммит, следовательно:

2.2 / "git merge --no-commit branch"

Как и в 2.1, потому что ускоренная перемотка не создает фиксацию.

Так что, если вы не сделали коммит на мастере, так как вы разветвились, а затем выполните слияние на мастере, все, что вам нужно сделать, это сбросить мастер HEAD ...

---

Другой причиной, по которой ветви не отображаются, является «эффект списка дел», описанный на странице презентации визуализатора GitHub Network Graph (то есть «git graph»). "Вы имеете в виду здесь)

Но вы видите каждый коммит только один раз. Позвольте этому погрузиться на секунду.
Я считаю, что многие кодеры настолько привыкли к централизованному SCM, что упускают тот факт, что наш Graph Visualizer фактически показывает и соединяет разрозненные репозитории.

Если я рисую график с собой в качестве пользователя root, тогда на графике будет отображаться некий список задач, которые я еще не добавил в репо.
Когда я хочу узнать о том, что сообщество делало в своих ветках моего репо, я могу просмотреть график и сразу увидеть, чем занимались другие.
Если бы я должен был внести изменения Бертга, в следующий раз, когда я увижу график, Бертг больше не будет отображаться вообще, потому что у него больше не будет никаких коммитов, которых у меня нет.
Подумайте над списком текущих дел, и вы поймете график.

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

Но я делаю, так как:

• Я не являюсь владельцем проекта.
• Я могу захотеть получить изменения в репо из любой вашей ветки.

Answer 3

В качестве альтернативы использованию git merge --no-ff:

Если вы хотите зафиксировать эффект разработки ветки темы в основной ветке, но не во всех отдельных коммитах, тогда вы можете использовать git merge --squash.Когда вы делаете это, коммит не помечается как слияние и не имеет второго родителя ветки темы.Список отдельных коммитов включен в комментарий коммита для сжатого слияния, так как они будут перечислены git log.

Мы использовали это в проекте, связанном с SVN ().git svn), так что наша основная ветвь имеет линейную историю.Таким образом, перед запуском git svn dcommit.

нам не нужно выравнивать граф git commit.

Answer 4

Я новичок в git и github сам (и ссылка все еще не работает), но, посмотрев на ваши шаги, может ли это быть из-за того, что вы не выдвинули фактическую ветку на github? Это, кажется, работает для меня до сих пор (я вставил команду push):

...
>> git commit -m "Authentication_feature is up" # commiting to the branch
>> git branch # just to confirm, which branch I am working on
>> git push origin authentication_feature # push the branch to github
>> git checkout master # trying to shift to master branch
...

Answer 5

Используете ли вы что-то вроде

git show-branch

, чтобы показать вам ветки и проверки, после того, как вы объединили свои ветви с мастером, вы больше не увидите ревизии - не знаете почему.

Я не могу найти объяснения по поводу поведения, но, похоже, нет никаких проблем с git-репозиторием, поскольку git log показывает все коммиты для каждой ветви.

Так что я думаю, что это просто способ инструментаотображает график ответвления.

Answer 6

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

git checkout master -b topic22

Это снижает вероятность того, что вы непреднамеренно совершите мастеринг.

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

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