-1

In a feature branch (cloned from master) we added some files and than deleted them. The same files where added to the master branch.

When we now try to merge back the feature to the master the files in the master get deleted (my understanding is, because the information "we don't need these files" is stored in the feature branch)

Which git command can we use to ignore or delete this "historic knowledge" in the feature branch?

golfo
  • 85
  • 5
  • 2
    https://www.biteinteractive.com/understanding-git-merge/ – matt Feb 09 '23 at 09:52
  • `git revert` the commits that added and then deleted them the cherry-pick them form master. Or interactive rebase the feature branch and delete the commit that deleted these files. – jessehouwing Feb 09 '23 at 09:55
  • Your description does not look consistent to me. If one side says "add X", then "remove X", it essentially said "no change to X". At the same time, when the other side says "add X", then the merge would add X, because one side said nothing about X and the other side said something about X. Please clarify, otherwise the given answers are possibly inaccurate. – j6t Feb 09 '23 at 10:47

2 Answers2

0

Once you merge your feature branch into the master branch, git checks for any changes in your feature branch to apply to master. Therefore, if a file is deleted from your feature branch, after merge to master, the file will also be deleted from master. So you either need to add the file back to the feature branch and merge to master or just readd the file to master.

Joshua Zeltser
  • 488
  • 2
  • 9
0

You can :

  • live with the merge commit that "deleted" those files, and create a new commit on top which re-adds them :
# <sha> should refer to a commit where the files exist, and have the content you want
git restore --source=<sha> -SW -- path/to/file1.txt path/to/file2.txt

# create a commit, with a meaningful comment
git commit -m "restore files"
  • modify the merge commit itself, and push that (or force push if the merge commit was already shared) :
# assuming you are on the merge commit itself:
git restore --source=<sha> -SW -- path/to/file1.txt path/to/file2.txt

# use --amend to edit it:
git commit --amend

# force push the result:
git push --force-with-lease

If you are on the merge commit, and the files were on the current branch right before merging, you can use HEAD~ to point at "the commit right before":

git restore --source=HEAD~ -SW -- path/to/file1.txt path/to/file2.txt

before the facts:

it is a good idea to have a clear view of your commits and branches before doing a merge (even if you go through a Pull Request)

You can use git log with a few options to have a nice view in your terminal:

$ git log --oneline --graph master feature

you may read git help log to see all the options you can have, or google for "how can I view [this and that] with git log ?"

or use a graphical frontend with a clear view of your repo history.

LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • Nothing about `git log` predicts what a merge will do. There is a way to predict what a merge will do but that isn't it. Feels like the wrong advice. – matt Feb 09 '23 at 13:25
  • @matt : what I had in mind is: at least you can see if a commit such as "delete these 2 files" appears *before* or *after* the fork point of your branch. You can get a view of what sections of your history will need combining. I completely agree with you on the fact that you somehow need to merge (or use some plumbing commands) to undertsand what's really going to happen. – LeGEC Feb 09 '23 at 13:28