git (possible) conflict resolution workflow

Question

I'm trying to determine a proper git workflow. There are couple of issues that confuse me.

You're working on a feature branch. Once you've commited you're supposed to:

1) Pull on feature branch (optional if you're the only one working on that).

2) Merge (or better yet rebase) from master and resolve the conflicts (if any).

3) Checkout master.

4) Pull from remote master.

5) Merge the feature branch (which should result in fast-forward if all is well).

6) Push to remote.

As I have mentioned, some things don't sit well with me.

1. Step 2 assumes that master is up to date, does it not?

2. If it is not (step 4 actually pulls some changes in) then what? Are you supposed to go back to feature branch and repeat step 2?

3. I'm not sure where from, but I have a notion that all merge (or alternatively rebase) conflicts should be resolved in a feature branch. Is that correct? If so, why?

4. If 3 is true, then should I go to master, pull (to ensure I have latest master), go back to feature branch and do merge/rebase (aka include extra step to ensure master is at the latest)?

EDIT1:

For example, a scenario:

You finished working on a feature branch and want to put those changs onto master. You're in local feature branch currently. There are no changes on local master since you have started work on the feature branch. However, there are changes on remote master. How should one handle this scenario?

Answer 1

Assuming there is more than one person working on the repository at a time and the remote Source control management (SCM) is GitHub. You're supposed to create a Pull Request (this also referred to as Merge Request by other SCM providers) for your work.

This then should be reviewed by another member of the project and merged. It will not let you merge the PR if there are conflicts. Which then you need resolve on the remote SCM or locally depending on the SCM provider.

In the case of you're having to rebase the master locally. you've two approaches you can take.

1. The approach you mentioned above. Where you switch branches and do the rebase
2. You can use the git fetch feature of Git to pull all branches present on the remote.

Using the second approach saves you from having to switch branches but still have the same effect as the first approach.

With the second approach, you'll need to run:

• git fetch to pull all changes on the remote. This will update the origin index of the repository.
• git rebase origin/master . Since we only updated the origin index with fist command you'll need to say that you want to rebase from the master branch of the origin ; hence origin/master

Here's an example

Here develop is your master

• Update the origin index to match the remote

users:() ➜  (10/02 22:52) ~/dummy git:(feature/rebase-test) ✗ git fetch
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:praveenprem/dummy
   5029e07..429a6e6  develop    -> origin/develop

• Rebase using the updated origin/develop index instead of the local index develop .

users:() ➜  (10/02 22:52) ~/dummy git:(feature/rebase-test) ✗ git rebase origin/develop
First, rewinding head to replay your work on top of it...
Fast-forwarded feature/rebase-test to origin/develop.

users:() ➜  (10/02 22:53) ~/dummy git:(feature/rebase-test) ✗ git add .
users:() ➜  (10/02 22:53) ~/dummy git:(feature/rebase-test) ✗ git commit
[feature/rebase-test 9cb6ad0] Add test file 3
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test-3.txt

users:() ➜  (10/02 22:54) ~/dummy git:(feature/rebase-test) git flow feature finish rebase-test
Switched to branch 'develop'
Your branch is behind 'origin/develop' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)
Merge made by the 'recursive' strategy.
 test-2.txt | 1 +
 test-3.txt | 0
 2 files changed, 1 insertion(+)
 create mode 100644 test-2.txt
 create mode 100644 test-3.txt
Deleted branch feature/rebase-test (was 9cb6ad0).

Summary of actions:
- The feature branch 'feature/rebase-test' was merged into 'develop'
- Feature branch 'feature/rebase-test' has been removed
- You are now on branch 'develop'

users:() ➜  (10/02 22:54) ~/dummy git:(develop) git pull
Already up to date.

users:() ➜  (10/02 22:55) ~/dummy git:(develop) git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 1.77 KiB | 452.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To github.com:praveenprem/dummy.git
   429a6e6..ae38b95  develop -> develop

You probably notice that when I mered the brach it told me that my develop branch is behind 1 commit. But when the merge did a git pull at before pushing the merge, there were no changes to pull.

Hope this help with your use case.