Git Workflow and Rebase

Question

Just starting out with Git and want to start off on the right foot. I've done some research (eg. Git workflow and rebase vs merge questions, "git pull" or "git merge" between master and development branches) and a recommended workflow seems to be:

-One time only: clone central repo to personal repo

-Create a develop branch

-Do commits on develop branch

-Every so often pull on the master branch (getting changes from central repo) and rebase develop branch on updated master branch if master has indeed been updated

-When done developing a feature on the develop branch merge master and develop branch (after pulling on master once again)

I have a few questions about this:

1. When a rebase fails due to a merge conflict between the updated master branch and your develop branch (from developers editing the same file), should you abort and switch to a merge instead?

2. Why merge when a feature is complete rather than rebasing again?

3. Should I push as well every time I finish developing a feature or fixing a bug?

Answer 1

1. When you get a conflict during a rebase, you may simply resolve it and continue rebasing. Aborting and doing a merge instead won't help, you'll still get the conflict anyways.

2. You'll want to merge when you're done with a feature whether you rebase your feature/develop branch on top of master or not. The difference that a rebase makes beforehand is that it gives you an opportunity to rewrite, structure, shape, and present your history in a (hopefully) clearer way than just doing a merge that results in a merge-commit (also known as a "non-fast-forward" merge).

   However, some people like to create a merge commit anyways, just to show where a branch occurred. You can force a merge commit even after a rebase by using the "non-fast-forward" flag, i.e. git merge --no-ff.

3. Whether to push after finishing a feature or bug fix depends on the project, and how you want to share your code with other people, if you're sharing it at all.