Git workflow that allow new hire to work on feature without polluting git history

This is what I do to ensure a clean Git history. There may be a faster way to achieve the same thing with fewer commands. In summary:

• Create a feature branch;
• Work on the branch;
• Review the branch;
• Squash the feature into a single commit (note that this is not a great plan unless the scope of the feature is small);
• Rebase the feature onto the main branch (to ensure a linear history);
• Perform a fast-forward merge.

Different folks will argue that squashing commits is bad; this works for me. Do whatever works for you.

Start a new branch for the feature:

git checkout -b some_user/some_feature

Write some code.

Add changes to the branch:

git add .
git commit -m "I did some stuff."

Write some code.

Add changes to the branch:

git add .
git commit -m "I did some more stuff."

Review the changes.

Update master:

git checkout master
git pull origin master

Switch back to the feature branch:

git checkout some_user/some_feature

Squash the feature’s commits into a single commit:

git rebase -i HEAD~2

Rebase the commit onto master to ensure that the merge will be a fast-forward:

git rebase master

Deal with any merge conflicts.

Merge the feature into master:

git checkout master
git merge some_user/some_feature

Push to the server:

git push origin master

Get rid of the feature branch:

git branch -d some_user/some_feature

We want a new hire to work on some features of our current project, however, since he is a new hire, we would like to do code review before he can commit into master branch.

Create a separate feature branch (or several, if this person will be working on multiple unrelated features) with the git branch command. Periodically merge from master into the feature branch(es) (that is, run git merge master while standing on the feature branch). Once you’ve reviewed the code, merge the feature branch(es) into master (run git merge feature while standing on master).

Some people will tell you to use rebases instead of merges in some or all cases. A rebase turns your history into a straight line, so that this:

A ----> B
 
  
   ---> C

…becomes this (C is rebased onto B, creating C’):

A ----> B ----> C'

…rather than this (C is merged with B, creating D):

A ----> B -----> D
             /
            /
   ---> C ---

Rebased history is easier to read and (marginally) easier to bisect, but may provide a less accurate picture of how your code was developed, which might make it harder to reason about what actually happened. Rebasing is also more complicated if the commit you are rebasing (C in our example) has already been pushed or pulled into another repository, while merging does not have this issue. Ultimately, you will need to decide for yourself which is the more appropriate course of action for your use case.

Also, we don’t want his changes which is rejected by our code review and get into the history.

Delete the branch (with git branch -D feature) without merging it into master, and wait for Git to garbage collect the orphaned commits automatically. Note the changes are gone for good after that, so be very sure you no longer want to keep them before running this command.

If you accidentally delete the wrong branch and notice the problem immediately (or soon after), you can recover it from the reflog.