0

I'm managing a website code on github and I have two branches, main for production and dev for development. I don't want to merge .htaccess and robots.txt from dev to main branch.

Is there any why to ignore these files on git merge?

  • But in general this may be a case of the much large question of how to deal with config files. Basically these files should probably never have gotten into `dev` in the first place. – matt Feb 16 '21 at 03:53

2 Answers2

0

If you want to delete the file from git but keep it on your local filesystem, use the following command:

git rm --cached myfile

If you want to stop tracking some types of files, you can create a file called .gitignore in the directory and add each file type you don't want to keep track of.

Ex:

.htaccess
robots.txt
slumpyrat
  • 66
  • 2
  • 7
  • Don't think `.gitignore` is the preferred method here. Those files are already present in `main`. It's my understanding this person just doesn't want to include changes to `.htaccess` and `robots.txt`. Untracking it could be problematic and confusing down the road. Any changes in `main` to these files will not be possible until you remove it from `.gitignore` – astrochun Feb 16 '21 at 01:37
  • Yes, this is a good point. Thanks for pointing this out. – slumpyrat Feb 16 '21 at 01:55
0

No, there is no way to ignore the files during merge.

What you can do, if you don't like the result that Git produces by doing a three-way merge on the file, is provide your own corrected result. That is: run the merge. The merge produces a result. Then, replace the merge result with the corrected result, which preserves the version of the file that you want preserved, and commit that. Now you're done. This process is extremely simple—there's only one or two choices to make—but you do have to remember to do the process.

Your main choice (or choices, depending on how you want to count) here are:

  • Which version do you want to retain?
  • Do you want to do this as part of the merge commit, or as a subsequent commit?

There's no one right answer to either question: use whatever one suits you. If you'd like to control the version of the file that goes into the merge commit, and git merge itself doesn't complain about merge conflicts, use git merge --no-commit so that you can make an evil merge. See Evil merges in git? Note that despite the name, they're not technically evil, they're just a merge that was not, and therefore won't be, made by Git.

If you prefer to make a single followup commit that corrects the file(s), just do that. Note that this has the advantage of being obvious, when someone goes to look through the history, as they'll see a merge followed by a commit in which you write a log message that says: Files X and Y are automerged in the merge commit, but that's not the desired result because _______ (you should fill in this blank). Therefore we now replace those files with the versions that are the desired result.

torek
  • 448,244
  • 59
  • 642
  • 775