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
Related
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.
I have 2 branches - master and develop
I have been doing some pull requests in my develop branch where it contains 5 items, in which it is the same as the number of items in master.
However, someone did some commits and pushed in a few more items into the master branch, and hence now it has 8 items.
As my pull request in the develop is still not yet approved/merged, whenever I tried to update my pull request, I am getting the message stating that This pull request can't be merged. You will need to resolve conflicts to be able to merge and asked me to do the following:
git fetch origin master
git checkout develop
git merge FETCH_HEAD
git commit
git push origin HEAD
And this happens after I have 'pushed' out my commits, making me confused at times. Then I realized that it is asking me to re-add and re-commit in the additional 3 new items. So does this means I must ensure that the items and contents between these 2 branches of mine should be the same as always? I have always used git pull/fetch but will there be a better way for me to make sure?
What this means is that GitHub would like to merge your PR branch into master, but it can't, because there are conflicts. As you've discussed in the question comments, the best way to deal with this (usually) is to merge your master branch into develop on the command line. That will show you the conflicts and ask you to resolve them. Once you've completed and pushed that merge, the PR will be mergeable back into master using the green button on GitHub.
You could simply merge your deploy branch into master (which I realize sounds a bit more sensible). In that case, you'd be bypassing the PR entirely. You'd have to close the PR "unmerged", and separately you'd manually push the merge commit to master.
By doing it the first way,
you make a better audit trail by merging to master on GitHub, using the PR;
you give your team a chance to review your code after the merge, before it lands on master; and
if you have automatic tests (such as Travis CI or CircleCI) which check PRs, you give them a chance to run your merged code as well.
This is the first time I am using Git Hub. So please co-operate with me.
I am working on an iOS project with another developer. Now since we are working on 2 different functionalities, I thought making separate branches for each developer is good way. So my plan in to follow below steps
Create a local branches named functionality1 from the current one using
git checkout -b functionality1
Commit my code in functionality1 branch
Push that branch to the remote using
git push origin functionality1
This will add my branch to remote server. I need branches on remote because I can work from anywhere.
I will merge it in Master branch using
git checkout master
git merge functionality1
Now functionality1 is merged into master branch (provided no conflicts occurred)
Other developer will follow same steps.
We don't want to delete the branches yet.
Now once both branches are merged into master, how can each developer will get the merged code from master branch into their respective branches (functionality1 & functionality2) & then continue on working on same branch (functionality1 & functionality2)?
IMHO you shouldn't unless you really need the new functionality. Because by merging e.g. master back into functionality1 you make it dependend upon the other feature branch. A good read is the gitworkflows(7) man-page.
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.