On Mon, 11 Oct 2021 10:48:25 -0400, Mr wrote:

> Please the experts correct me if I'm wrong, but here is the beliefs that
> have kept me relatively out trouble for a while:
> Almost number one thing to understand, maybe someone already explained:
> but
> 
> Remember that commit and push are two different actions (picture
> attached) and that you have to do both every time you "finalize" some
> changes so that your local(commit) and remote(push) repositories stay in
> synch.

That is correct.  Commit just creates a revision in the local repo.  Push 
uploads your commits to the remote repo.

> 
> Git is specific because it is decentralized (every developer works on a
> local duplicate copy of the whole project tree) and its workflow can be
> pictured as a raft boat floating on the water of that remote whole
> project, because you can keep your local changes floating over the
> changes made by other people while you were working, by doing a pull
> --rebase (think of your changes as being held aside, the other dev's
> update done and then your updates layered over as if they had been made
> after.)
> 
> So, it is best practice to *always* do that pull --rebase (avoiding many
> blocking  "repo not clean" error) at least before pushing your changes
> and also additionally anytime you suspect some remote changes may impact
> your current work to correct it accordingly and avoid drafty history.

That is a good practice, certainly - I was going with the assumption that 
Ricky was the only committer to his repo.

It's generally considered best practice for developers to work in their 
own branches, and then to merge their branch back with the main branch 
when their work is done.

That way, multiple developers can be working on different things without 
stepping on each other - and the merge is the right place to resolve any 
conflicts.  This also encourages (per Linus' intention in the design of 
git) communication between developers, since file locking isn't a thing 
that happens in git (some see that as a weakness; but file locking 
encourages less communication, so I see where he's coming from).

(I'm nowhere near an expert, but this is just based on my experience 
working with a development team)



-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message