0

My question could go into the basics of git but I have some misunderstanding and I wanted to have advice from the most experienced developers of git.

My scenario is as follows:

For some projet, I have two branch preprod and master

preprod : this branch is used to receive local developments from all developers, once the client validates these developments, I merge this preprod branch into master

master : is for the production environment.

Scenario :

I created a new branch to develop auto-login feature,

  1. git checkout preprod
  2. git pull
  3. git checkout -b auto_login_v1

I developped this feature, I commited (2 files), pushed then I merged auto_login_v1 branch into preprod. *Until here everything is good.

Now I create a new branch for another feature newsletter,

  1. git checkout preprod
  2. git pull
  3. git checkout -b newsletter_v1

And like the first step, I commited (1 file), pushed then I merged newsletter_v1 branch into preprod.

Now my client told me to deploy the newsletter feature in the production environment, so I merged newsletter_v1 branch into master.

The problem with that is by merging just the 2nd branch newsletter_v1 which contains (1 file basically), unintentionally, I also merged the (2 files) of the first branch auto_login_v1 while I just wanted the second branch newsletter_v1 with (1 file).

Why I got this (deployed 3 files instead of 1) ? because I merged the first branch in preprod then I pulled it ?

2) What is the recommended good practice in the case where we just want to merge one feature (branch) without another ?

prc
  • 187
  • 2
  • 14
  • 1
    To answer question 2: If you want to hold off on releasing all in-flight ready features, don't merge them into the branch that will go into prod just yet. You should read up on [git flow](https://nvie.com/posts/a-successful-git-branching-model/). – Lasse V. Karlsen Jan 26 '20 at 22:52
  • Ok @Lasse V. Karlsen, thank you – prc Jan 29 '20 at 18:51
  • @Lasse V. Karlsen So if I understood correctly, we must merge the feature branches only into `develop` ? So in my scenario, I create a new branch `release` (intermediary between develop and master), I merge develop into `release`, then in this `release`, I revert the merged branch that i didn't want in master `auto_login_v1` and finally, I merge the `release` into `master` and into 'develop' ? After that if I want to re-apply `auto_login_v1` because the client has just validated it, I create a new branch `auto_login_v2` with the same work as `auto_login_v1` and I merge it into develop ? – prc Jan 29 '20 at 19:21

2 Answers2

1

I developped this feature, I commited (2 files), pushed then I merged auto_login_v1 branch into preprod. *Until here everything is good.

Well... I guess it all depends on what you call good. You are pushing code into develop that might not be finished and then when you start branches from it, you might have code from other features.... and then if you them merge this other feature (as you did on the second branch) into master, you are for sure carrying unfinished code... actually unwanted code because the client only requested a feature and you carried a lot more than that by merging develop.

So.... even if you push feature branches directly into develop (I don't agree with that workflow but, hey! If you like it like that, who am I to judge?), if you are asked to bring a single feature into master, you will not merge develop into master.... you don't merge the feature branch into master... you bring over the revisions related to the feature only on top of master.

so... good practice:

there are countless workflows you can try but probably gitflow is the most popular... you might add stuff you like on top of it, but it is definitely a good starting point.

https://datasift.github.io/gitflow/IntroducingGitFlow.html

Good luck

eftshift0
  • 26,375
  • 3
  • 36
  • 60
1

I followed the commits you described and took screenshots from a program called SourceTree to help visualize the branches.

Git history as described by the asker

Hopefully you can see that once you merge a branch into preprod, any branch checked out from preprod will necessarily inherit the merged changes.

In terms of best practices, a popular branching strategy is called GitFlow and it is similar to what you are already doing. GitFlow designates specific branches for specific purposes:

  • master: reserved for version releases
  • develop: reserved for merging feature branches (equivalent to your preprod branch)
  • release branches: Before merging develop into master, you should checkout an intermediate "release" branch. The commit you branch from on develop does not have to be the head of develop.

Here's an in-depth article on GitFlow because there's more to it: https://learn.microsoft.com/en-us/azure/architecture/framework/devops/gitflow-branch-workflow

In the future you should not merge a feature branch into develop until you are sure you want to include it in the next release.

One way to "remove" the merged changes from auto_login_v1 in preprod is git revert.

Take a look at How to revert a merge commit that's already pushed to remote branch? or look at the git revert documentation

JorgeZapatero
  • 123
  • 11
  • Thank you for your time +1, I didn't understand the solution for only merging `newsletter_v1` without the other branch ? – prc Jan 26 '20 at 15:50
  • `In the future you should not merge...` But develop is linked to the test environment that the client tests the features, is this case, if I understood correctly, we must merge the feature branches only into `develop` ? So in my scenario, I create a new branch `release` (intermediary between develop and master), I merge develop into `release`, then in this `release`, I revert the merged feature that i didn't want `auto_login_v1` and finally, I merge the `release` into `master` and into 'develop' ? – prc Jan 29 '20 at 19:16