Git工作流程和基础

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, ie 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.