Git centralized workflow

Question

Suppose developers are using git centralized workflow and github has 2 files a.txt and b.txt.

Now dev1 pushes c.txt successfully. Now if dev2 pushes d.txt, it's non fast-forward and he can't push and RIGHTLY SO, because he must first merge changes of dev1 locally and then push.

Now another scenario, Suppose dev1 creates branch featureC and has file c.txt in it along with a.txt, b.txt and pushes. Similarlty dev2 creates branch featureD and has file d.txt in it along with a.txt, b.txt and pushes.

Now pull request is made to merge featureC with master and it's successful. Again pull request is made to merge featureD with master and this SHOULD NOT be successful, but IT IS. IT CAN'T BE!! HOW COULD IT BE? Doesn't it match the above scenario?

Answer 1

There is a substant difference between push and pull. When you want to push commits onto a remote branch, you local repo needs all commits from the remote and of course the commits you want to push. That is not the case when dev2 pushes the commit for d.txt, while not knowing anything of the previous commit, that introduced c.txt.

Now with pull requests, the situation is different. You always can savely pull anything that does not conflict, which is the case when the commits affect different files only.

Actually it's a pull request, in your first case, when git tells dev2 to pull (merge) before he pushes.

You can always pull (fast-forward or merge) when there are no conflicts but you can only push when your branch is up-to-date with the remote branch you want to push to.

How to understand what gets commited

It's quite easy for a developer in a local repository to see what changes actually are requested by a commit. Assumed dev1 branched to featureA to develop some feature from master, this morning. In the evening he wants to see all changes he did and when he checked in, he yould do

git format-patch master..featureA

All commits numbered in order are written to files NUMBER-TITLE.patch.

All these patches can be merged to origin/master regardless of the state of origin/master (if there are already new changes went to origin/master, or not), when no patch fails to apply to origin/master, ordered by the number.

Answer 2

The situation you describe

dev1:

a---b - master
     \
      c - featureC

dev2:

a---b - master
     \
      d - featureD

centralized repo:

a---b - master

---

In your first scenario (which you seem to agree with), it looks like both devs are trying to push directly to the same branch on the centarlized repo:

After dev1 pushes its local master to the centralized one:

a---b---c - master

Then if dev2 has locally a---b---d - master and tries to push that to master on the centralized repo, git complains. What should it do?

This:

a---b---d - master #nope

would be wrong since c is discarded.

This:

a---b---c    #nope
     \
      +---d

would also be wrong, where should master point to? No way for git to know. Hence the complaint, master has diverged.

---

Now to your second scenario.

I'll assume the pull requests results in pulls in the centralized repo.

"pull request is made to merge featureC with master and it's successful":

centralized repo:

      c - featureC
     / \
a---b---x - master

Then "pull request is made to merge featureD with master":

      c - featureC
     / \
a---b---x---y - master
     \     /
      +---d - featureD

I see no reason why this should not work! Since in the centralized repo, featureD is merged in a master that is up-to-date, and master has not diverged.