0

I have a branch off of main called AI_feature.' When I first created the branch, it ended up copying the commits from main along with it. Now that I am trying to merge the branch back into main, I was asked to only commit files that were relevant to the feature I developed. Confused, I looked at the 'Changes' tab in Gitlab and discovered that Git decided that every file in the repo was a new change despite my not touching them. I figured I would use rebase to remove those commits since they belong to the main repo rather than my branch. The problem is that I don't really know what I am doing...

I used git rebase --interactive main to begin. This opens up the git-rebase-todo file in vim. I used :set number and :1,55s/pick/d/g to view line numbers and drop all commits that preceded mine. Saving the file continues the rebase until some merge conflicts arise. This is where I get lost. Git is telling me that there are conflicts with the first version of the files I created and the latest ones. But I am not sure how to tell it to ignore early versions and go with the latest files.

In the git-rebase-todo file, I had some ideas:

  1. Drop the irrelevant, preceding commits and squash my commits like so:
drop <hash_of irelevant>
pick <1st of my commits>
s <hash of next commits>
...
s <hash of my latest commits>

  1. Drop all commits but my latest one.

  2. Cry because I wasted my morning on this and its a Friday.

What do I need to do in order for git to drop commits preceding mine and accept the latest versions of my files as the final versions before merging? And how can I avoid the preceding commits issue in the future?

roscoe_turner
  • 1
  • Are you trying to merge into a branch different from the one you originally branched *from*? If you are merging back into the same branch you merged from, then the ones preceding your changes should already be ignored by the merge. – Raymond Chen Dec 02 '22 at 18:17
  • @RaymondChen I am pretty sure I am merging back into the same branch. Maybe I messed something up when I originally created the new one such that the commits from the original branch needed to be recommitted in the new one? – roscoe_turner Dec 02 '22 at 18:21
  • What do you mean, "copying the commits from main along with it". When you create a new branch from a commit, it starts out just another name for that commit. As you create *new* commits, the name is changed to point to the new commit, which is how the branch diverges from the starting point. – chepner Dec 02 '22 at 18:24
  • I'm pretty sure you are merging to a different branch from the one you branched off from. Merges pick up commits that are not present in the source, so all the commits at the point you branched off are already present in the source branch and are ignored by the merge back to that same branch. Another possibility is that the source branch had its history rewritten after you branched off from it. – Raymond Chen Dec 02 '22 at 18:28
  • @RaymondChen Feel free to post this as an answer so I can accept it. Thank you. As a note, running, `git log --oneline --decorate --graph --all` shed light on what I originally had branched from. Turns out it was `next`, not `main`! – roscoe_turner Dec 02 '22 at 18:53
  • Go ahead and can post the answer yourself and accept it. That way, you can describe it to the level of detail you feel is appropriate for the question. – Raymond Chen Dec 02 '22 at 20:04

0 Answers0