Use GIT fork / branches

Question

I am using Git for a while but i still have trouble understanding some features despite hours spent on blogs and tutorials... :)

I am working on a project with other

Answer 1

No fork: fork is cloning that repo on BitBucket to get your own (on BitBucket): it is a clone on the server side.
See, for illustrations:

• "Git fork is git clone?",
• "What is the difference between origin and upstream in GitHub?".

You need a fork only when you cannot push directly to the upstream repo: you push to your fork, and make a pull request to the upstream repo.
This is not the case here.

Just branch and push your branch to the one and only BitBucket repo you need (to which you have write access).

Whenever you have modifications you need to publish both on master and on your branch,

x--x--x                  (master => origin/master)
       \ 
        y--y--c--y--c--y (yourBranch  => origin/yourBranch)

• reorder said branch (rebase interactive) for the common commits to appear first,

x--x--x                  (master => origin/master)
       \ 
        c--c--y--y--y--y (yourBranch  => origin/yourBranch)

• git pull master (in order to make sure master on your local clone reflects the latest commits published by other on BitBucket)

x--x--x--x--x            (master => origin/master)
       \ 
        c--c--y--y--y--y (yourBranch  => origin/yourBranch)

• rebase your branch on top of master and test if everything still compile and pass the tests

x--x--x--x--x                  (master => origin/master)
             \ 
              c--c1-y--y--y--y (yourBranch  => origin/yourBranch)

• merge the new common commits from your branch to master:
  git checkout master; git merge c1

x--x--x--x--x--c--c1                 (master => origin/master)
                   \ 
                    y--y--y--y (yourBranch  => origin/yourBranch)

• git push master (since you have pulled master before pushing: your local master was up-to-date relative to BitBucket 'origin' master. Your push is a trivial merge on the BitBucket side: you are only introducing new commits)

• git checkout yourBranch && git push -f origin yourBranch
  Since you have rebased yourBranch, you have rewritten its history, you need to forced push to BitBucket side.
  But since it is your branch, it is ok (nobody else would have pulled from it, and would need to reset it in order to take into account your new history).

---

Note that another way avoiding the rebase --interactive step to reorder your common commits would be to cherry-pick them directly from yourBranch to master.
But I dislike cherry-picking, in that it:

• introduces duplicate commits and complexify the final merge you will do between yourBtranch and master.
  See "Git cherry pick and datamodel integrity" for illustration.
• ignore functional dependencies.
  See "How to merge a specific commit in git" for illustration.