CODEWITHSUNDEEP
gitgithubversion-control
Yuvraj Singh Shekhawat
Yuvraj Singh Shekhawat

Reputation: 323

Don't want to remove branch x after merge with branch y and master is it posible?

Example :

I have three branch x, y and master.

I am working on branch "x" after done I want to merge branch "x" with "y" and continue to work on branch "x" after fixing all bugs merge branch "x" with "y" as well as with "master" is it possible.

In other words I have 2 server I want to manage them with two separate branch.

Upvotes: 0

Views: 113

Answers (4)

Marina Liu
Marina Liu

Reputation: 38136

It seems branch x and y are in a server (let's call it server1), and master branch is in another (server2). And it’s possible to merge x into y and master separately.

Merge x into y:

# In the local repo of server 1 (git clone <URL for server1>)
git checkout y 
git merge x

Merge x into master:

# In local repo of server2 (git clone <URL for server2>)
git remote add server1 <URL for server2> -f
git checkout master
git merge server1/x

Now changes on x branch in server1 is merged in server2 master branch.

Note: If there has merge conflict during merge, you need to modify and save the conflict files, and then use git add . and git commit.

Upvotes: 0

mhannachi
mhannachi

Reputation: 109

Assuming that you have forked the branch x from y to fix bugs that are already mentioned in your backlog, merging x into y via a PR(pull request) would generate the status merged of this PR, as well as it's closed status.

Deleting x branch is done manually in github, and that might not be the case for BitBucket, it seems that in your case the branch is deleted automatically once the PR is merged.

This is BAD for your development experience? > The answer is NO.

Why? > The concept of version control repository is that the PR of every bug fix should be elaborated from a new forked branch.

Consider the case of multiple developers working on different bug fixes. So that the job needs to be done seamlessly, every bug should be treated in a separate PR;think about the code review discussion for each one. If all those subjects are treated in the same context(PR), it will be a real mess for your working velocity.

Upvotes: 0

gerard
gerard

Reputation: 1000

You have 3 branches in your local repository. Firstly you want to push those branches to BitBucket so they are visible in BitBucket. You do that using the commands

git push -u origin master
git push -u origin x
git push -u origin y

Now you make changes on x and then want to merge that with y.

git checkout y
git merge x

Now push branch x and y to BitBucket as before.

After more changes you want to merge x to y and to master. Use the commands

git checkout y
git merge x
git checkout master
git merge x

Now push all Branches to BitBucket as before.

Notes:

  1. BitBucket does not delete merged branches. Are you sure you are pushing the branches?
  2. After the steps above all three branches will be the same. Are you sure that's what you want?
  3. You might want to consider creating a branch per feature, rather than for each server. See https://www.atlassian.com/git/tutorials/comparing-workflows for popular Git workflows.
  4. Assuming x and y represent pre-production servers and master represents the production server, you can easily just move the feature branches to the x and y servers, then merge to master when you're happy. When everything is correct all servers should match master.

Upvotes: 1

AnoE
AnoE

Reputation: 8355

I do not use bitbucket, but if it automatically cleans up merged branches for you (and you checked that there is no option to disable this behaviour), then rest assured that this is bitbucket's doing, not git.

A merge works like this in git. Assume a and b are two commits, and A and B are two branches pointing to those commits respectively (a branch is nothing more than such a pointer, in git).

  • Mix the contents of a and b.
  • Create a new commit c, with parent-commits a, b.
  • Change the pointer A to point at c (assuming you had a/A checked out during the merge and merged b "into" a).
  • Check-out the contents of c into the working directory (a.k.a. HEAD).

B is not touched at all. a and b are not touched either (commits never change in any way in git, they absolutely cannot, except for eventually being removed by garbage collection if nothing points to them anymore).

So, either do your merge in your local git commandline and thus avoid whatever bitbucket did to your branch B. Or explicitely recreate the B branch to point at b again after the merge.

Upvotes: 0

Related Questions