0

I have taken a branch(Branch A) from Master and done some commits on the Branch A, in the meantime, some Commits are merged on Master from Another Branch B Problem is: I have to Push my commits and Merge to Master so which approach will be best :

1)I Push My commits to remote Branch A, then checkout master, then take a pull and then merge the Branch A in master and Push the merged code in Master.

2)I check out master and git pull with rebasing the master and then Checkout Branch A and Push my commits to Branch A and then Checkout Master and merge Branch A in Master and Push the Master.

Kousei
  • 1,291
  • 1
  • 9
  • 16
  • 1
    Possible duplicate of [When do you use git rebase instead of git merge?](https://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge) – Dezza Apr 10 '18 at 11:43
  • read the question carefully, I'm asking about the approach which should prefer and I Know when to use the git rebase and and git merge – Kousei Apr 10 '18 at 11:45
  • 1
    There is no right answer to this question, both are perfectly valid, equally good, and which is best entirely depends on secondary preferences about workflow and history structure. If you go the merge route, be sure to merge master into branchA before merging branchA into master. that way any conflicts can be resolved and tested before updating your main line of code. – LightBender Apr 10 '18 at 11:52
  • merge master into BranchA after taking the (git pull --rebase on master)? or before @LightBender – Kousei Apr 10 '18 at 12:11
  • 1
    You always want to integrate code on the feature branch, doing a rebase will integrate your code on top of their code. Merging master into your branch will integrate their code into your code. Either way, you get code on a branch that can be tested *before* you merge it into the master branch. Not doing this step is one of the most common causes of production bugs I've encountered. – LightBender Apr 10 '18 at 12:16

2 Answers2

1

Push branchA to remote:

$ git push origin branchA

Checkout to master, update master with remote master. Pull branchA into master, then push to remote:

$ git checkout master      # master branch
$ git pull origin master   # update local master history = remote master history

$ git pull origin branchA  # pull 'branchA' changes into 'master' branch  
$ git push origin master   # update remote master with branchA changes
Sajib Khan
  • 22,878
  • 9
  • 63
  • 73
1

You need neither, assuming that you are working in a pure git environment (i.e., no "external" workflow management like Github's "pull requests" or something like that).

Simply merge your branch locally, and then push those of the two that you want to have remote (i.e., pushing branchA is only necessary if you want to keep that branch long-term, and also want to have it remotely viewable for posteriority).

git checkout master
git pull origin master    # just in case someone else changed it meanwhile...
git merge branchA
git push origin master branchA

Explanation:

First, you checkout master. This means your local "current" branch is master, and the working directory represents its current file tree.

Next, you pull the master from origin. This is useful if someone else, meanwhile, committed something onto the remote master; it means that you're now up to date. If you know that nobody could have done that (because you're the only one working on it), then you can skip this step.

Thirdly, you merge your branchA into your local master. I assume that you own branchA, that is, there is no chance that there could be a more recent branchAon origin, hence no further push/pull is necessary.

Finally, you push both master and branchA back to origin. The remote (and your local) master will now contain the merge commit that includes all changes originating in branchA. branchA will be unchanged and stick around for either historical purposes, or for further changes.

On rebase vs. merge

Some people never rebase, but always merge. Other people like to rebase.

You commented that you know about the difference, so I'll not write much. But for this particular usecase (getting changes from a feature branch back into master), merging is the correct operation, and there should not be a rebase involved.

If you were asking how to get changes from master back into branchA, then we would talk about whether you would use rebase or merge.

AnoE
  • 8,048
  • 1
  • 21
  • 36
  • I want both branches to be remotely available, can you explain a little bit more about your approach @AnoE – Kousei Apr 10 '18 at 11:56
  • 1
    Directly merging is not necessarily the correct option. You are correct a merge is necessary at some point, but it sounds like the questioner is looking at a direct three-way merge vs a rebase then fast-forward merge. Both will get you to the same merged codebase, only in different ways. Which is correct depends on the workflow of the project, the preferences of the team, etc. – LightBender Apr 10 '18 at 18:05
  • @LightBender, OP specifically states `I have to Push my commits [in branchA] and Merge to Master`. – AnoE Apr 10 '18 at 19:43
  • Agreed, but in the context of "maintaining [a] streamlined history" what you do with the commits on branchA before that merge is a consideration that needs to be addressed as well. – LightBender Apr 10 '18 at 20:31
  • thanks a lot for giving me a brief explanation for my query, @LightBender – Kousei Apr 11 '18 at 05:35
  • Also, @AnoE for a brief explanation and giving time to this question – Kousei Apr 11 '18 at 05:38