The problem that i am facing is that when i merge my branch with the development branch to update my branch it deletes a big part of my work.
The strange thing is that when i try to solve it with Visual Studio to merge it doesn't not show any merge conflicts.
My branch is fairly up to date but the only diffrence is that the Entity frame work of our database is updated and the Entity frame work of your SQLite database is updated.
The are also placed in seprate projects should that should not effect my work.
The previous merge from dev did have some conflicts but all of them i had solved and my app work fine.
I got my work back with a Restoring a Revision in a New Local Branch but the problem still stay there that i have to merge my branch with dev to test the functions.
I couldn't find any solutions to the problem online.
File structure
Instead of merging dev to your branch, try instead to rebase your branch on top of dev (if you can afford to force push it, meaning if you are not several collaborator working on that same branch)
git checkout myBranch
git rebase dev
The rebase method that VonC suggest did not solve the problem.
But by creating a new branch with information of the older feature branch we could solve the problem by letting some other developer merge the dev branch to the new feature branch.
But i still don't know what the real cause is of the problem.
Related
For a project with multiple developers where one developer controls what goes to production: This developer pushes from his own branch <his_branch>, and everyone has to incorporate their changes into his branch. His branch contains his changes and the changes other developers' changes. How do I make sure I pull down his most recent branch and work from it on my local. I have tried so many different commands and approaches, with the most recent being:
Git clone the repository (done when I started the project)
Fetch his branch
Create a working branch <my_branch> from <his_branch>
git checkout -b my_branch origin/his_branch
(I get errors)
Create my branch on remote
Fetch all including my new branch (but my new branch contains code from Master)
Access my branch locally, work on it, commit changes, create a pull request for him to review
(I don't have his latest code) and there are many conflicts to resolve
I am new to GitHub and can't find a fairly straightforward answer to this question. Typically people who answer this question, make sure they provide the most complicated solution to follow to try to impress with their GitHub acumen.
Can someone provide a straightforward answer without snark, condescension, or derision?
Hi I'm using source tree with github for unity as an inexperienced user and have made a big mess. Basically I was making changes to a game in the master branch in a higher version of unity 2019.3 and decided to then revert back to a older version of unity earlier in the master branch.
I then created a new branch and started making new game changes in unity 2018.4. I have decided that I want to keep with unity 2018.4 but the problem I have now is that my master branch is behind and has different changes and in a totally different version of unity. I went to merge and resolve conflicts using theirs to keep changes for the 2018.4 branch but it has left a huge mess.
All I want to do is possible is to delete/remove all the changes I made in the master branch in unity 2019 and just make the top of the 2018 branch become the master so I can continue with that as the master branch.
Is this possible to do if so how, I hope my explanation made sense.
Sounds like you'll need to use rebase to remove the 2019 commits from master. Then you should be able to just merge into master.
Try this
Rebase master, drop bad commits, merge branch.
Should be run git rebase -i master replace the "bad" commits keyword with drop. You'll likely want to specify how many commits to edit, this can be relative like HEAD^x or a SHA of the last "good" commit. Then fix and merge conflicts and merge the second branch with git merge branchname.
You might want to make a copy of the repo on your machine or github before doing this as you could mess up pretty bad.
Get the latest master, revert your local version to the commit you want to be on the master (latest 2018) (find the commit and right click revert to this revision) and push that.
You have a nice answer just about what you are trying to do in an easier way here :D
I am quite new with Gitlab and I'm having an issue for merging in Eclipse.
We're working as a team, and we all have development branches that we are trying to merge into a single one. Unfortunately, when I did my merge, I have done a stupid mistake. Instead of merging my development branch to the main one, I have merged the main one into my development branch.
I have reversed the commit/merge on gitlab, but now as I try to merge back my development branch into the main one on Eclipse, it seems like I am 9 commits ahead of this branch (described as the arrows on Eclipse here: ), so the potential merge would basically replace everything by my code, when I should actually have merge conflicts to solve.
I am not quite sure how to merge properly so that I get back these merge conflicts.
Here is a screenshot of my network:
The ['1'] commit in the network on the left branch (my branch) corresponds to the merge from Week6AllIssues to my dev branch (the wrong merge). The last commit on this left branch is me reversing the commit.
Thanks a lot for your help !
If you're not using the remote branch with anyone else, the following series of steps might help.
First, remove the superfluous commits from the local branch. It can be achieved with git reset --hard <the commit before you merged master into your branch> command (see this link on how to do this with Eclipse).
Now make the remote branch match your local branch. You can do this with git push --force command. In Eclipse, this command corresponds to configure push - enable "force update" option.
Now the superfluous commits are gone.
I read all SO questions about this issue, and I still can't resolve it.
I am using TortoiseHg. I worked on a side-branch, and now I want to merge it back to the main branch. I pulled all changes made in both branches, updated to the main branch, and merged (and committed). But still when I try to push all this, I get the "abort:push creates new remote head" message.
I also tried (as was suggested in one of the questions in SO) to close the branch using the --close-branch option.
The only thing I did not try is to 'force' push.
Any suggestions? Or is force-pushing the only option?
Just for everyone else that runs into this problem.
What caused this problem for me were some local revisions on the default branch that I didn't push before I started to work on a new branch.
I had merged the latest revision I pulled for the default branch with my new branch, but these leaves your local changes to the default branch committed but un-pushed.
If you try to push them, it's not your new branch that is creating a remote head, it's the un-pushed revisions to the default branch that is creating a remote head.
When I stripped out those revision with hg strip -r 1234
hg push --new-branch
went perfect.
What put me on the right track was
hg heads
With showed I had two heads that both had the name of the default branch with different revision numbers.
I just tried a similar setup, and I get the same warning. Apparently, although the second head you are trying to push is closed, it is seen as another head during the push. And closing both heads does not seem to be pushable either.
You can force the push, it should be ok, but you could eventually get the same issue if you keep multiple heads on your visualization branch, like you already have with changesets 14 and 20. To solve the issue once and for all, I would instead suggest to merge both changesets (14 and 20) and reclose the final head.
Thanks for the answers, I definitely learned some new tricks.
What I ended up doing, is cloning an early revision from the remote repository, that is, a repository that doesn't have all the commits of my merges etc. I then pulled the change-sets, merged, and committed. Then the push finally succeeded.
It was basically the same steps I tried to do before, but apparently on the first (unsuccessful) trial I broke it down to more steps than were needed, and something went wrong at some point.
Try this solution,
Assumption. You have enough rights to close and create the branch in the remote
This happens because you are trying to rewrite the history. Just try hg push -f which will create two heads in the remote repo, which you might not
So the first login to your remote and close the branch, now come to your local and push using hg push -f. The necessary new branch will be created automatically with the original condition as it was before.
In our mercurial project configuration we have 3 branches in a single repository. One is a stable release branch where urgent bug fixes are done, one is a feature branch which contains new feature code and one is a UAT branch where both bug fixes and new features are merged into to provide the most up-to-date code base.
We have merged a whole load of new feature code into the UAT branch without any issues at all. Following that we merged the stable branch with the bug fixes into the UAT branch but this seems to have the effect of removing the new feature code. I have discovered that this problem has been caused by someone merging UAT into stable a while ago (which should have never happened!!). Now when I try to merge the bug fixes into UAT it removes all the new feature code.
Is there a way of removing the effects of the merge from UAT into stable, whilst still retaining the bug fixes that are descendents after this 'bad merge'? I've tried backing out the merge but it seems to have no effect at all. Can I do a strip and re-add the required changesets back in?
Thanks in advance.
I've actually managed to fix this one myself through a bit of trial and error.
First you need to enable the transplant and mqMerge extensions in your mercurial.ini file. Add the lines following lines below the extension header
transplant=
mq=
Clone a your repository to a new location.
In your new repo, remove the bad merge by using the strip command to clear history the effect of the bad merge is removed. (Beware that this will remove all descendent changesets)
Then you need to cherrypick all the required changesets in chronological order from the other repo by using a command similar to below
hg transplant -s "otherRepo" -b "branchName" "changesetHexNumber"
Repeat the transplant command for all the required changesets. Ouila!
NB: If you are using a central repository you will need to strip the offending merge/changset on there too otherwise your local repo will think you have outstanding changesets to pull.