Git log, чтобы возвращать только фиксации, сделанные в ведущую ветвь?

Я немного искал и нашел:

git log myBranchName

как возможное решение. Но что происходит, когда моя ветка является главной ветвью? когда я запускаю:

git log master

Кажется, все возвращается к любой ветки. На основании того, что я прочитал, в нем перечислены все коммиты, связанные с главной ветвью. Зная, как я могу вызвать историю фиксации только ведущей ветки?

Ответы

Ответ 1

Я думаю, что это то, что вы хотите

git log --first-parent master

Процитировать руководство

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

Ответ 2

Благодаря ветвящейся модели Git s, фиксации не относятся к одному или нескольким ветвям. Ветви являются указателями на отдельные объекты фиксации во всем графе фиксации. Поэтому, когда вы говорите, что фиксация "на ветке X" в X, вы обычно подразумеваете, что она достижима при запуске с фиксации, на которую указывает ветвь X.

Для git log поведение по умолчанию равно git log HEAD, где HEAD ссылается на фиксацию текущей текущей ветки. Поэтому, если вы находитесь на главной ветки, она равна git log master, показывая все коммиты, которые достижимы при запуске с самого последнего фиксации.

К сожалению, то, что вы называете фиксацией, сделанной для определенной ветки, четко не определено в Git. Если я сделаю фиксацию на главном, а затем создаю новую ветвь, указывающую на тот же фиксат (например, используя git branch newbranch), то эта ветвь буквально идентична основной ветке, кроме имени. Таким образом, каждое свойство, "сделанное на ветке", теперь также подразумевает "сделанное на ветке newbranch". Таким образом, вы не можете иметь это свойство в Git.

Даже решение parkydrs, которое показывает все фиксации, которые были сделаны только на одной стороне слияний, не является отказоустойчивым решением. В идеале это скроет все те коммиты, которые были сделаны на отдельной ветке, отличной от мастера, и которые затем были объединены обратно в мастера. Таким образом, вы получите только коммиты, которые либо сделаны непосредственно в магистральную линию, либо являются слияниями, которые объединяются в некоторые другие коммиты. Однако есть две вещи, которые мешают этому работать:

  • Объединение с быстрой перемоткой вперед: когда вы отключаетесь от мастера и создаете некоторые коммиты, не создавая новых объектов непосредственно на главном, тогда git merge somebranch на хозяине будет быстро перематывать коммиты, в результате чего главная ветвь указывает на такая же фиксация, как somebranch. Таким образом, вы "теряете" информацию о том, что эти коммиты были первоначально созданы на отдельной ветке. Вы можете заставить Git всегда создавать комманды слияния, используя git merge --no-ff, но это не поможет вам впоследствии.
  • Порядок слияния не гарантируется: когда вы находитесь на хозяине и объединяете ветвь, тогда предыдущий мастер-фиксация всегда будет первым родителем. Таким образом, вы получите желаемое поведение. Однако вполне возможно быть на указанной ветке и вместо этого объединять мастер, в результате чего главная фиксация является вторым родителем. Затем мастер может быть быстро перенаправлен (или reset) на новый коммит, что приведет к "обратному" представлению.

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