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 people for which my boss created a repo on bitBucket.

I cloned it locally, and already did some commits to the master branch, and pulled some changes by others. I now want to do modifications on the long term. I will have to push some of them to the master branch, and keep other ones just for myself. I think that i could fork the master branch to have my own version(?).

I am a bit confused about what procedure i should follow. Should I create my own branch? or fork ?

If I'm right, forking will create another version located in myy BitBucket account that I should copy on my computer (in a different directory from the master branch project?) in order to do modifications.

On the other hand, it seems to me that a great feature of GIT is to work locally in a single directory with all different existing branches, switching from one to another, and pushing your modifications on your remote repo when you're done (and potentially to the master branch).

Before deciding, I have a few questions for you guys:

Question 1: If I modify files in my forked version, will I be able to push them to the master branch? how?

Question 2: How do I incorporate new commits (on the master branch) from other users into my forked version?

Question 4: Has the remote repo of my forked version anything to do with the master repo?

Question 5: Will my forked version contents be visible by others members of the team?

I'd appreciate A LOT if anyone could clarify this for me!

Thank you.

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.