prc
prc

Reputation: 187

Question about merge branch and good practices

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 ?

Upvotes: 0

Views: 911

Answers (2)

JorgeZapatero
JorgeZapatero

Reputation: 123

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

Upvotes: 1

eftshift0
eftshift0

Reputation: 30212

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

Upvotes: 1

Related Questions