Changes in branch after merge in git

Question

I have two branches, foo and bar under master in a project that I'm managing with git. Let's suppose I work under foo and after being done with it, I merge the changes with master . Then I go to bar and repeat the process. But then someone tells me there's something I have to change on foo , so my first idea was to repeat again, but then I lose all the work done under bar branch. How do I achieve my purpose of coming back to a branch and then when I merge with master I don't override the changes made under bar

I tried creating a new branch for those new changes but if this is the approach, I find the branches a bit useless. But I think git is smart enough to do what I want.

Answer 1

Answering with a series of diagrams:

--

create foo and bar off master after commit C:

                       foo
                      /
master A ---- B ---- C
                      \
                       bar

---

work on foo and merge into master : ( git checkout master && git merge foo )

foo                    D ---- E ---- F
                      /               \ (merge-commit)
master A ---- B ---- C --------------- G 
                      \
                       bar

---

meanwhile, bar progressed independently..

foo                    D ---- E ---- F
                      /               \
master A ---- B ---- C --------------- G 
                      \
bar                    D' ---- E' ----- F'

---

you now wish to update bar with changes to master ( git pull origin master )

foo                    D ---- E ----------- F
                      /                      \
master A ---- B ---- C ---------------------- G 
                      \                        \
bar                    D' ---- E' ----- F' ---- G' (another merge-commit)

---

another change commited on foo

foo                    D ---- E ----------- F ---- H
                      /                      \
master A ---- B ---- C ---------------------- G 
                      \                        \
bar                    D' ---- E' ----- F' ---- G'

---

then, to sync bar with new foo ( git checkout bar && git pull origin foo )

foo                    D ---- E ----------- F ---- H
                      /                      \      \
master A ---- B ---- C ---------------------- G      \
                      \                        \      \
bar                    D' ---- E' ----- F' ---- G'---- H' (another merge-commit) 

---

then merge bar into master (with master as active branch, git merge bar )

foo                    D ---- E ----------- F ---- H
                      /                      \      \
master A ---- B ---- C ---------------------- G -----}-------- I (latest merge-commit)
                      \                        \      \      /
bar                    D' ---- E' ----- F' ---- G'---- H' ---

Answer 2

Then I go to bar and repeat the process

Why don't you merge master or foo in bar? That's unclear to me.

But then someone tells me there's something I have to change on foo, so my first idea was to repeat again, but then I lose all the work done under bar branch.

What do you mean with repeat? Commit you last changes and checkout the other branch.

Also if you made changes that you won't commit you can use git stash for storing the changes temporary.

Please specify your question for more detailed help.

Answer 3

If your foo and bar branch is not yet deleted, you can rebase

git checkout master
git pull
git checkout foo
git rebase master
git checkout bar
git rebase master

But ideally, if your foo and bar branch is a feature/issue, you should only merge them to master when it's done. If it's too big, break it down to smaller branches (nester or flat).

I don't override the changes made under bar

this depends on your changes and why care, you merge bar branch to master anyway. It's none of bar business if the work he have done is modify because that feature/fix is done (that's why you merge it). Actually, when you finished a feature/fix branch and merge it master, ideally you delete it cause it's done.