I have two different branches release/ver1 and release/ver2 and code base are completely different.
My requirement is to merge to the following:
1) Merge release/ver1 branch to the master and do the build.
2) Followed by the same day, Merge release/ver2 branch to the master and do the build.
Note: I can merge only to the master ( web hooks PR notifications are configured like this and I cannot create new release branches and merge to it)
Whenever I merge, I am getting merge conflict and every time, I need to manually resolve the conflict and as the code base are totally different, it takes lot of time to resolve manually the merge conflict error.
What would be the best resolution for the above situation?
Try at least to activate first git rerere
cd /path/to/repo
git config rerere.enabled true
If the same conflicts are involved in your different merges, git rerere would have recorded their resolution and can apply them automatically.
See "Git Tools - Rerere".
Related
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 have two branches, develop and master. I push all my new work into develop and when done I need to merge it into master. I ran git merge --no-ff develop when in the master branch, but now I have a lot of merge conflicts. Is there a quick way to resolve these so I always use the develop version, instead of having to open each file and resolving them that way? Thanks
If you're in a merge you don't want to go forward with right now, the first thing to do would be to abort that merge with git merge --abort
Then if you want to merge your 'develop' branch into checked out branch 'master' while always taking changes from 'develop' where conflicts arise, the way to do that is with git merge -X theirs develop where master is checked out already.
See:
Is there a "theirs" version of "git merge -s ours"?
and: I ran into a merge conflict. How can I abort the merge?
for reference.
I was working locally on master branch. (by mistake) but it's ok with me this time as I control my code.
I took the following steps:
Egit->commit and push (to master)
Egit -> pull (to get other developers changes)
I got a message that there is a conflict with one file and I merged it.
Now I see: [My Product | Merged Master (up arrow)2 (down arrow)1]
I see in the symbols next to the files that the other developers created - black sign as if there are uncommitted.
A. What does the 2 up arrow and 1 down arrow mean?
B. Why do I see uncommitted changes? they are not mine
C. How can I work out on master after my merge?
D. I looked in bitbucket and didn't see that my changes were committed to the remote branch. What is wrong?
I know that I am supposed to work on branches - but for now - how do I fix the situation?
A. Two arrows up means you have two commits in your local branch that aren't in the remove branch. The one arrow down means there is one commit in the remote branch that you don't have locally. The solution is to do a git pull followed by a git push
B. Uncommitted changes are probably from your conflict. After a conflict, you have to resolve the conflict, add it to index and then commit that change. This is known as a merge commit. My guess is you have not done this.
C. Work out on master? You mean you want to work directly on top of master? After you resolve your conflict, you should be all set to do that. Branching is better though. To create your own branch just do git checkout -b my_featue_branch
Currently am working with Git Repo and i have a fellow team mate also ,after he commit to the remote repo and i get all the changes . I have couple of questions
When i merge the code with Changes then the changed file in my work space is marked as staged, do i need to commit to local repo?
I have a read lot of documentation and still am confused with the best way of sync,
Currently i do following steps:
Go to Team->Sync Workspace-> Fetch From Upstream->Mege . Please correct if am wrong
Note, the Egit manual includes a "pull" operation which would do the fetch+merge in one operation.
Right-click on a project in the Package Explorer and select Team > Pull or right-click on a repository in the Git Repositories view and select Pull to pull new changes from the upstream branch your local branch is tracking.
Doing a fetch + merge (as in Egit Merging) will result in a merge commit unless there is a conflict.
Real merge: When neither of the conditions above apply egit triggers a merge of the commits. There are two possible outcomes:
If no conflicts occur the current branch will point to a newly created merge commit;
if conflicts occur the conflicting files will be marked with label decorators (see Resolving a merge conflict for further actions in case of merge conflicts).
You should see staged changes only in the second case (merge conflict to resolve), or you would see stage changes because you previously added to the index files which are not part of the merge (they remain staged until you commit them)
I'm trying to figure out whether I should do my development on my clone of an upstream branch or create a local branch of it first, i.e.
fork upstream
work on my master
issue pull-request against my master
... time passes ...
merge upstream/master into my master
back to 2.
or
fork upstream
branch my master into dev
work on dev
issue pull-request against dev
... time passes ...
merge upstream/master into my master
rebranch master or merge master into dev
back to 2
The reason i consider the second workflow is for scenarios where my pull request isn't accepted or only partially accepted and once i merge upstream i want to make sure that my local is identical to upstream so i don't base future work on a divergent mutation of upstream. Or is there a command when i pull from upstream to master to make my local master identical to it (i.e. discard all local changes?)
When dealing with an upstream repo, I usually do what I think your second workflow suggests. To wit:
I create a branch from upstream's master. If I'm working on a specific feature or bug, I'll name the branch to reflect that; otherwise, I'll call it dev or whatnot.
Work on dev, rebasing from upstream's master as necessary.
Push dev (or whatever I called the branch) and issue my pull request.
Continue pulling upstream's changes down into my master branch.
I.e., I don't do any work on master. This creates a simple, clean branch/pull request for the upstream maintainer.
There's also the very important git rebase that pulls/merges any external changes to the branch you rebase to. That's the way I committed changes to Qt in the past (which is hosted on gitorious which has the great merge request feature). Steps 1 and 2 will probably just be number two for you.
create own clone of "master" on a seperate project
work on the branch currently developed or create a new work branch.
before making the pull request, do a git rebase origin/masteror something similar to make sure your commit applies cleanly to the current master. This has the nice side effect that your changes appear "on top of the stack", ie after all other commits.
Hope this helps you in what you're trying to do.