Git简化历史记录

Question

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.

Answer 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

Answer 2

You need neither, assuming that you are working in a pure git environment (ie, 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 (ie, 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 branchA on 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 .