1

I've a branch develop with files:

  • index.php
  • test.php

I'm creating branch release from it, where I set versions, make small bugfixes, etc, and delete test.php which doesn't go into production release. Then I want to merge this branch into develop but want to keep test.php in develop branch. How to do it? Default behaviour of git merge just deletes the file.

galymzhan
  • 5,505
  • 2
  • 29
  • 45

2 Answers2

3

1/ I would rather rebase develop branch (if you haven't pushed it to a remote repo yet) on top of master, to make sure all my development is still compatible with the latest release (and all its bug-fixes).
If your current development is really different from release (massive refactoring), then and only then I would consider cherry-picking the bug-fixes.

2/ If a file needs to be kept as is during a merge, you can set a merge manager in a .gitattribute file only in the develop branch.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
2

The conventional wisdom is that you never merge from a release branch into a development branch. Instead, apply the bugfixes commits to the development branch using git cherry-pick.

cdhowie
  • 158,093
  • 24
  • 286
  • 300
  • And then the deletion of test.php happens in its own commit, and that commit doesn't get cherry-picked? – Tyler Dec 07 '10 at 07:47
  • Correct. The bug fixes should all be represented in self-contained commits. Then the specific commits that need to be backported to the development branch can be cherry-picked. – cdhowie Dec 07 '10 at 07:49
  • 1
    +1. I would add: **write the bugfixes in the release branch** if you can. Then, you can import the fixes into the development branch with `git merge`. – Eric O. Lebigot Dec 07 '10 at 07:57
  • @EOL: Yes, that would definitely be the preferred way to do it. – cdhowie Dec 07 '10 at 08:17
  • I'm following branching model described here: http://nvie.com/posts/a-successful-git-branching-model/, so while techincally I can do cherry-pick I want to see actual branch merging in development history. – galymzhan Dec 08 '10 at 01:41
  • @galymzhan: That model does not include "production" branches, that is, branches that contain changes specific to a production environment. **The moment you committed the deletion of `test.php`, you decided not to use the branching model described there.** – cdhowie Dec 08 '10 at 01:46
  • The model has definition of `release` branches. What model says: "Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s". So deletion of test.php is definitely a *preparation for production release* because leaving that file introduces security issue. On the other hand, it should be kept in develop branch, where it is used for testing purposes. – galymzhan Dec 08 '10 at 02:18
  • "Last-minute dotting of i's and crossing of t's" means "bumping version numbers, patching bugs, etc." It does not mean "removing files not meant for deployment." `test.php` is part of the codebase -- if it needs to be removed, it should be by some install process, and this change *should not be committed.* By committing the removal of this file, you give up any possibility of a clean merge back into the development branch. `cherry-pick` and `rebase` are your only options at this point. – cdhowie Dec 08 '10 at 02:49