4

I would like to work on a set of features in branch features and merge with master once a set of features is added. This will trigger a chnage in production.

I would then continue to work on the features, in the branch features (I do not want, if possible, to open a new branche for each feature of the planned features set).

Is there a specific risk to do so, from git's perspective ?

I know that there are "best practices" for branch reuse but this development would be better orchestrated through a set of work on branch features -> merge with master -> continue working on branch features -> merge with master -> ...

I am the only developer, so master does not change between the merges.

WoJ
  • 27,165
  • 48
  • 180
  • 345
  • No, I don't see any relevant risk. – C-Otto Jul 03 '17 at 14:14
  • I'm not sure if I understand your third paragraph correctly, due to multiple "not"s and "but"s. You might want to rephrase that for better clarity. – mkrieger1 Jul 03 '17 at 14:15
  • 1
    And for your own judgement, you should consider that a branch is merely a pointer to a commit, it has relatively little effect what name that pointer has, except that there can't be two with the same name. – mkrieger1 Jul 03 '17 at 14:20
  • @mkrieger1: thanks for the feedback, I clarified the third paragraph, which indeed was over-engineered. – WoJ Jul 03 '17 at 14:21

1 Answers1

5

git itself won't be bothered by this. Since you specified "from git's perspective", the short answer is "no".

There are two things to be aware of:

1) In the event you're preserving merge commits, the default commit messages reflect the branch name. This is only a concern if seeing repeated "merge from feature" messages in the master history were to be a problem in your review workflow.

2) Since you specified "from git's perspective", I'm assuming you've already evaluated how your build tools or other software that interacts with git will respond. As I can't evaluate what those (unspecified) tools will do, I am not endorsing this approach overall, but merely addressing the question of whether git cares one way or the other.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52