1

I have a web application that I store on Github. I created a dev branch for this project a couple of years ago but since that time, I have never merged "dev" into "master". I've been doing all my work in "dev" (or feature-related sub-branches of dev) and then pulling that dev branch down to my production server. I know this is stupid but it's what I did. Today I decided to finally merge my dev branch into my master branch so I can start pulling master down to my production server. I came across this question which suggests merging master into dev first and resolving any conflicts in dev before merging dev into master. This seemed like a good idea since I'd never merged my dev into my master. But when I followed those instructions and merged master into dev, Git said "Already up-to-date.":

    $ git br
    * dev
      master
    $ git checkout dev
    Already on 'dev'
    Your branch is up-to-date with 'origin/dev'.
    $ git merge --no-ff master
    Already up-to-date.

Could I have unwittingly been pushing my dev commits to my master branch all this time? If so, once I push master back up to my remote repo and switch back to my dev branch to continue work, should I ensure that I'm creating a separate remote copy of my dev branch on Bitbucket (for backup purposes) with this "push... --set-upstream" command...

    $ git checkout dev
    (do work and commit it)
    $ git push --set-upstream origin dev

and then follow the procedure I initially described above whenever I want to merge any additional changes in my dev branch to my master branch? From this point on, I want to make sure I keep dev separate from master but I always want to keep a copy of my dev branch on Github for backup purposes.

Thanks!

Community
  • 1
  • 1
Jim
  • 13,430
  • 26
  • 104
  • 155
  • if you never pushed anything to master since splitting off on dev, there would be nothing to do in the merge from master -> dev – Levi Dec 09 '15 at 20:57

2 Answers2

1

You are merging your local master with that command. You want to be merging origin/master instead.

git fetch
git checkout develop
git merge origin/master

Its very possible that that branch is up to date too ( this means there are no exists that exist on master which do not also exist in dev)

That's possible due to how you described it. There would be more issues if you continued working in separate features for master and dev and wanted to merge the results

exussum
  • 18,275
  • 8
  • 32
  • 65
  • Could you illustrate how the command you described would look? – Jim Dec 09 '15 at 21:19
  • Updated answer if that still says up to date your OK to just merge to master – exussum Dec 09 '15 at 21:34
  • Thanks but now I'm really confused. I don't understand what my git workflow should be or how these commands should fit into that workflow. Git is simply too complicated and the terminology makes no sense. I think I'll have to stick with what I've been doing until I have time to study Git further. For now, I'll have to stick with what I've been doing. I haven't broken anything yet doing it the "wrong" way. – Jim Dec 09 '15 at 22:19
  • Your not doing anything wrong. What most people would call their master branch your calling develop. – exussum Dec 09 '15 at 22:20
0

First of all You should know if your branches will have conflicts after merging. You can test it with this command: https://stackoverflow.com/a/501461/4430543.

If not there is no reason to merge twice and You can without any problem merge directly development into master.

Otherwise You should resolve conflicts on development branch due to fact that mainly your changes produce some conflicts. Anyone can merge to master and it should be stable for all time. How to resolve conflicts? You can use merge or rebase command. Personally I prefer rebase command because it does not introduce any additional commit, unfortunately it reaply all commits on this rebasing branch.

Community
  • 1
  • 1
gauee
  • 305
  • 3
  • 13