Merging my branch with Master in my local repo before pushing to remote origin in Github

Question

I would like to know what is the best practice for this I have a cloned repo from a remote bitbucket repo and i have created a branch out of the repo where i have created a.json file inside a particular folder. After i am happy with my file and would like to push to origin branch, should i be in my local master first and do a "git merge branch" before i am in my branch and do "git push origin/branch "? Looking forward to any help. Also i was told that before pushing to origin branch i should do a "git rebase master" by being on the branch So should i do "git rebase master" after i am done with working on the file in my local repo branch and then first do a "git pull origin/branch" and then do "git rebase master"?

Answer 1

Rebasing and Merging are two different way of combining two or more development histories together. The technique you pick basically comes down to what you want your branches to look like when combined or your preferences. (when I say you, that may include other people working on the same codebase).

To pick one, the best start would be the docs, here's the doc for git merge , and git rebase .

let me quote a few sections from the docs that might help clear the ideas around how they both behave:

---

GIT MERGE

Assume the following history exists and the current branch is "master":

  A---B---C topic
 /
D---E---F---G master

Then "git merge topic" will replay the changes made on the topic branch since it diverged from master (ie, E) until its current commit (C) on top of master, and record the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes.

  A---B---C topic
 /         \
D---E---F---G---H master

---

GIT REBASE

Assume the following history exists and the current branch is "topic":

      A---B---C topic
     /
D---E---F---G master

From this point, the result of either of the following commands:

git rebase master git rebase master topic would be:

              A'--B'--C' topic
             /
D---E---F---G master

---

Notice what the branches look like after they are combined. Git merge will combine multiple sequences of commits into one unified history where git rebase reapplies the changes on top of another base.

Now, when you clone a repo and commit changes, your local branch diverges from the remote branch. By the time you're ready to push new changes to the remote branch, it is possible for the remote branch to contain a different history than your local branch. That's why you'd want to update your local branch to reflect the changes made in the remote branch before you push your local changes to remote. For that, you can use git fetch or git pull depending on what you're trying to accomplish. When you do a git pull by default it will do a git fetch followed by a git merge . If you look through the doc you'll find ways to change this default behaviour. Just as I can't tell you that the only way to sort your books in a bookshelf is by alphabetically sorting them, I can't directly tell you what your flow should be. If you try to push diverged refs to a branch, you'll face a conflict that you'll have to sort out before the operation can continue further.

The convention that I usually currently follow is a git pull and then commits , and when I'm ready to get the changes merged to a branch I do a git rebase and a pull request that finally merges the branches together when accepted. When you do a git rebase, you get a much linear history.

Previously when I wanted two branches to combine, I used do a git merge locally after updating my history with remote and followed by a git push to update the remote branch.