Despite using git for a considerable time, I am still regularly confused by it, and waste time "fixing" things that turned out to work differently from what I had expected would / should / could happen. To avoid this, what is the correct approach in this situation: I have worked on a branch (from

dev

) for a long time, and by now this branch contains a bunch of commits that largely replace what previous commits (in the same branch) did, etc.

dev

has also been updated with template updates meanwhile. In this case, what can I do to make this the less of a mess? I am aware that the number of commits do not matter so much for reviews, but a bunch of them are simply obsolete by now. Is it considered a major git-crime if I simply create a new branch from current dev and copy all of my changes that are not part of the template into that clean branch and create reasonable commits? There is no one else working on this branch.

If you are not confident with rebasing, there is no shame doing what you suggested..it works 😉

I am not even sure if rebasing would be the correct approach, but if that is the thing to do I will give it a try

Or merge dev into your branch and solve merge conflicts

Title is promising

It's a personal preference IMO. I don't really care about a clean git history personally, as a history of different things I've tried etc is much more helpful, particularly when I came across a knotty problem (I'm not scared of showing when I've made stupid mistakes). But no doing what you say is fine if you prefer. I've seen similar blog posts. Rebate still scares the shit out of me.

Its less that I do not want to display my stupidity / inability to type (probably wouldn't work anyway), but more that the things i did turned out to be a bad idea overall. I will see if i manage to rebase, for nerd-cred, if that fails i will do the other thing..

If you have commits touching the same areas in both your branch and the source branch, rebasing/merging tends to see a lot of conflict and be real tedious. In such situations starting with a new branch from the current

dev

, copying in your changes and working with

git diff

to check that you don't undo any changes from the source branch tends to be the least bad experience.

another option is to sqash some commits (where you can also drop some which turned out to be dead ends)

Luckily all the commits are in the same branch, so at least i don't have to deal with that. I think squashing would be nice, do i understand correctly that only consecutive commits can be squashed? Or is there a way to squash commits affecting the same file(s), even if there are unrelated commits to other files in between?

I think you can reorder commit with sqash as well.

I don't think there's any

git squash

comnand, right? You can either do a squash with

git rebase

(which allows for reordering) or

git merge

(which will squash everything that applies)?

yes, what i mean with squashing is an interactive rebase

Thanks for advice! I think what i will do is rebase without squashing, and then simply squash when I merge 😄

I am a bit late to the party, but I think there are two options. • One is starting from a clean new branch off your current

dev

. Then you can use

git cherry-pick SHA

to selectively apply commits from your long-term working branch to the clean new branch. If you do it approximately chronologically and performed relatively atomic commits, you should not get terribly many merge conflicts. • The actually not too scary alternative is exactly what @mashehu suggested: An interactive rebase on the branch itself. After creating a backup of your branch (!), you can run

git rebase --interactive HEAD~10

. In this case, the last 10 commits on that branch are being included into your operation. You will see a text file that represents the working plan for the rebase. In this text file, you see the SHAs and commit messages of all relevant commits:

pick 110c33e Something 
pick 01c131a Something else
pick 39fba8c Another thing

The word pick indicates that these commits should be kept as they are. But you can (it is described in the text) also choose other actions such as

drop 110c33e Something 
squash 01c131a Something else
reword 39fba8c Another thing

In this case, the commit Something would be skipped and ignored, Something else would be combined with the changes in Another thing and you could edit the commit message to e.g. say Something and another thing added. If you hit a merge conflict, you can manually resolve that, run

git add file

to indicate that everything has been resolved in that file and then

git rebase --interactive --continue

to proceed.

I recommend using a GUI for the interactive rebase, makes it a bit easier to understand what is going on imo

If you do it approximately chronologically and performed relatively atomic commits, you should not get terribly many merge conflicts.

Around half of my commits are "here is what I managed to do today" the other half is "fixing yesterdays mistake", so they are not atomic... A GUI for rebase would be really nice, but anyways, since I will squash-merge this, I realize there is not much of point in cleaning up the commit history of the branch

I personally use https://git-fork.com/ but also liked https://www.git-tower.com/