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.
Related
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".
I want to know what is the best way to use the command: Merge branch name into current branch
What i am doing (Let us suppose I want to merge master into develop):
I checkout to the master branch and pull all the recent changes.
Then I go back to the develop branch.
I right click on the master branch and click Merge branch name into current branch.
And the master branch will merge into the develop branch.
Is this correct?
Your methodology looks correct.
If you are not seeing any changes tothe branch you are merging into - then it is likely this branch is already up-to-date with the branch merged into it.
You can also look up the following references on the Merge comnmand you are using:
Git Tutorial (Beginner): Using GitLab & Source Tree
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.
We have a Master branch and a Develop branch for our repo. We are supposed to check-in (commit, push) to our Develop branch and then merge that with our Master branch. Then a build is run for the Master branch. I pushed my changes directly to Master (then tagged it), putting Master multiple commits ahead of Develop and now want to bring Develop in sync with Master. What is the best practice to do this? I use GitExtensions and Visual Studio 2015 (am ok doing the operation in either). Do I 'push' Master into Develop or do a check out of remote branch Master and merge with my local?
I would find it most clear to just check out both branches locally, merge in the changes from your local master to your local develop. Then push your local develop to remote.
The workflow I use works something like this in the scenario you describe:
Switch to Develop branch
Fetch All
Choose last (newest) commit in Master, right click => Rebase current branch on => (commit ID)
If Rebase works successfully you're done. If not, you may need to resolve conflicts or cancel the Rebase and merge from scratch.
The reason for using Rebase is that it maintains a single line of commits thus helping keep everything clear.
For more info on the difference between rebase and merge see:
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
I am using git-svn in my workplace since our current version control server is subversion and switching completely to git does not seem to be on the horizon for now (*cry*)
My workflow is as follows
I have the following branches
master tracks remotes/trunk
local/0.4 tracks remotes/0.4
work is my development branch for the master branch
work-0.4 is my development branch for the local/0.4 branch
I work in my work branches, then I merge to master and local/0.4 using
git merge --no-ff <branchname>
After that I check in to svn via
git svn dcommit
and I use
svn.pushmergeinfo=true
to update the svn:mergeinfo properties so my colleagues won't get angry with me messing up that metadata for them :)
However, I just had the following problem which stumps me.
I had done two commits on the work-0.4 branch, then I merged these to my local/0.4 branch with git merge --no-ff work-0.4. After this, I did git svn dcommit and recieved the following message
Committing to https://svn-server ...
e138050f6ebd2f2ca99cbefc5e48acae412e1f86 is merged into revision f5f2345e8e5fc64
20423bdc00397b5853b3759c4, but does not have git-svn metadata. Either dcommit the
branch or use a local cherry-pick, FF merge, or rebase instead of
an explicit merge commit.
After some rebasing and reset'ing of branches I managed to push everything to svn, but my solution entailed doing a rebase of my local/0.4 branch to the work-0.4 branch which in turn meant that I did not get to squash my two git-commits into one svn-commit :/
I feel that I'm probably doing something wrong with my workflow here, and it might be related to svn.pushmergeinfo. The docs for svn.pushmergeinfo says
config key: svn.pushmergeinfo
+
This option will cause git-svn to attempt to automatically populate the
svn:mergeinfo property in the SVN repository when possible. Currently, this can
only be done when dcommitting non-fast-forward merges where all parents but the
first have already been pushed into SVN.
and to be honest, I'm not quite sure that I understand that correctly? Am I doing something weird here that makes svn.pushmergeinfo not work correctly? How should I structure my workflow to optimally work with git-svn correctly (setting proper mergeinfos etc)?