Cooperative development workflow using git branch

When we work cooperatively with other people in a team using git, the common practice is to use git’s branch to
manage our local changes, once we are done with the changes (committed), we merge them to the master or a main branch that we work on.

For example, we create a featured branch(e.g. feat-branch) with a team of 5 people working on it, each one should pull this branch to their own local system, then create his own local branch(e.g. me-branch), based off this featured branch, to manage his own changes. After done with the changes, he should commit them, and then checkout to feat-branch, using git merge me-branch command to merge the changes from me-branch onto feat-branch.

Note that this is a very common practice that many developers are using.
However, this pactice has a flaw, which is that it convolutes the commit history of the main-line. By another word, it makes the feat-branch commit history non-linear and thus hard to read and track.

A recommended practice would be to use git rebase <base> on our local branch before we merge it to the feat-branch or master branch. git rebase is very powerful command that help us keep the commit history clean and linear, it replays all commits from the base we branch out and modifies (actuall create new) the commits that we have done since in our own local branch.

see this:

As explained above, let’s see what the workflow would look like:
Assume we work on master branch in a team of five, each member creates his own local branch to make changes.
Note: local branch name doesn’t matter (even if it conflicts with others’ branch names) as it only stays on our own local system and never been pushed to the public.

##### step 1 Checkout to local branch, make changes and commit

git checkout -b me-branch

# Start(edit some files)
....
# End

git add .
git commit -am "me-1"

##### step 2 Go back to master branch and get the latest updates from remote repo

git checkout master
git pull --rebase

Note:
Since we don’t make any changes to master on local, git pull --rebase has the same effects as git pull.

##### step 3 Again, checkout back to local branch `me-branch`, then rebase the commits to master

git checkout me-branch
git rebase master

Note:
In rebasing process, it’s possible that we encounter conflicts, use mergetool to sovle them and then
use git rebase --continue as instructed until we’re done with it. Once we’re done, the changes should have been committed successfully. Go to the next step.

##### step 4

git checkout master
git merge me-branch

Note:
When we execute git merge me-branch, it will use a fast-forward fashion to merge all commits from me-branch onto master branch.
Since we have rebased in me-branch, the commits history is clean and linear therefore fast-forward will succeed.

By now, all changes are merged and committed in a clean and graceful way, we are ready to push it to the public.

##### step 5

git push -u origin master

You may think step2 and step 3 are boring and tedious, I found out a way that can shorten this process.
that is:
Stay in your local branch, and pull the latest updates from remote master branch, and rebase our local commits on it.

git pull origin master --rebase

---

More thoughts:

###### Side effects of rebase --- The rebase moves all of the commits in master onto the tip of your dedicated branch. The problem is that this only happened in your local repository. All of the other developers are still working with the original master. Since rebasing results in brand new commits, Git will think that your master branch’s history has diverged from everybody else’s.
##### Advanced If you want to re-write the entire local branch's commit history, use `git merge-base` command. e.g. The below command returns the commit ID of the original base, which you can then pass to git rebase:

git merge-base feature master

Note: This only works for private local branches. If you’re collaborating with other developers via the same feature branch, and that branch is public, you’re not allowed to re-write its history.

##### References https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing