Best practice advice? merging previous commits - not concurrent

GitHub Help How to use Git and GitHub
#1

Whilst getting to grips with github, I was working in a single master branch only.

During my work, I’ve made several commits which cover the adding of a new feature to an application.
In between a few of these commits I’ve had other bug fixes to contend with.
My intention is to somehow merge the commits which all relate to this new feature into one commit “going-forward” so I can understand all of the changes which had to be made to get this new feature in place by looking at this one single commit rather than looking across the several I made prior.

I seem to be coming unstuck in that a) I didn’t create a new branch for this new feature (which I know I should have done, b) the commits don’t run concurrently so I can’t seem to easily merge them.

Is there a best practice I should do at this point to try and get this back to how I would like it, and also what ‘should’ have I done on the outset of this , so I understand how to get it right the next time I need to add something.

Many thanks for any replies.

#2

Hi @mtm81,

There may be other ways to do this that are easier, but I believe that you would have to cherry-pick the commits that you want to be separate from the other commits into a separate branch and then do a rewrite of history in order to get what you want from what you’ve done. This is a complicated procedure that I’m not sure I can guide you through though other members in the community might be able to.

Looking to the future, it looks like what you want to use is a feature branch strategy that uses a squash & merge technique. This GitHub Blog post on squashing and merging might be helpful in planning your future strategy.

#3

Cherry-picking is definitely an option here, another might be an interactive rebase. The Rewriting History chapter of the Git Book describes how to do that, including an example on how to reorder commits. Note however that rebasing may lead to trouble if you have already shared the existing history.

Using feature branches for larger work (and often smaller, too) is generally considered best practice. So is keeping your commit small, so squashing commits can be a mixed bag.

Two tools that may be helpful when working on multiple things in parallel or getting interrupted:

  • git stash is great when you’re in the middle of something and need to put your work in progress aside for a moment, but it’s not ready to commit yet. Maybe there’s an urgent bugfix to do, or you want to try another approach. See Stashing and Cleaning.
  • git worktree lets you have multiple working trees, so you can have different branches checked out at the same time in different directories.

What do you mean by “concurrent” here? That’s not a commonly used git term, so you might get more helpful replies if you explain a bit more what you mean.

#4

Hi, thank you for the replies - much appreciated. It does appear that best practice IS to ensure that I make a couple of branches (one for bug fixes and one for major features)

However I will look further into those other git commands that have been mentioned.

Finally, in terms of what concurrent means -

Obviously concurrent as a word means happening at the same time (or one after the other). So lets say I wanted to merge that last two commits - those are concurrent (one after the other). However I wanted to merge my most recent commit plus a one two further back. In between those had been two other bug fix (unrelated) commits…

Thanks for the replies again!

:slight_smile: