Hi Konstantin
Thanks very much for your helpful reply. Please see my comments inline below. > How do you intend to make the developers cooperate? > Have you planned on this? Do you intend to use GitLab? We intend to use a centralised repository. Maybe GitLab initially so that it can be in-house. > > That is, I am hoping to see Git commands for the various stages of > > the workflow. > This question has little sense (please take no offence): the concept > of workflows comes into play precisely because you can use the same > commands to achieve different outcomes depending on what policy you > follow while using those commands. I mean, the commands really are the > same, no mater which workflow you implement. I accept what you say. My fear is that the flexibility of Git will lead to different working patterns and give uncertainty. For example, should a branch be merged using rebase? I was hoping to tie down the workflow with precise commands for each generic action. But perhaps that is unrealistic. > To recap, I feel like your request is a bit premature. Consider first > learning more on Git, and then try toying with the simplest workflow. > Also think through how you intend to organize sharing of work among the devs. Thanks, great advice. I will do that. BR David On Monday, July 31, 2023 at 6:46:11 PM UTC+1 Konstantin Khomoutov wrote: > On Mon, Jul 31, 2023 at 10:03:07AM -0700, David Aldrich wrote: > > > Hi, I am just getting started with Git. Our organization uses Subversion > > and we are thinking of moving to Git for new projects. I think it will > be > > crucial to standardize on an agreed branching workflow, which should be > as > > simple as possible. > > > > With Subversion, most of our development is on trunk, but we do use > > branches for features or personal work. We tend not to use release > branches. > > > > I have seen various workflow types. For example, GitLab documentation > > briefly describes Centralized, Feature branching and Trunk-based > > development workflows (though I can't quite see the difference between > > Centralized and Trunk-based). But there doesn't seem to be an > explanation > > of the commands needed for each workflow. > > > > Would it be possible to have a recommendation for a workflow and to > point > > me to an implementation of it? > > How do you intend to make the developers cooperate? I mean, with > Subversion, > you have to have a central server, hosting *the* repository. With Git, > which > is a distributed system, everyone has their own repository on their local > machine. Still, in many projects using Git, it's also customary to have a > "rendez-vouz" repository hosted somewhere, so that basically, everyone > eventually pushes their work to it and fetches the work of others from it. > Have you planned on this? Do you intend to use GitLab? > > > That is, I am hoping to see Git commands for the various stages of the > > workflow. > > This question has little sense (please take no offence): the concept of > workflows comes into play precisely because you can use the same commands > to > achieve different outcomes depending on what policy you follow while using > those commands. I mean, the commands really are the same, no mater which > workflow you implement. > > As to the essense of the question, I'd not put too much into that > workflow-y > buzzwordness: for a single project you can start with the simplest approach > and may be rethink it after you have the initial experience. The simplest > approach works almost like what you currently have with Subversion: > > - You have a central repository wihch you can consider to be "official". > > - Everyone fetches from it and pushes to it. > > - The development happens on a default branch (called "master" in Git, > or "main" - if you're into woke movements). > > - No one ever pushes into that branch (except for some emergency > situations, > and then it's performed by experienced folks such as team leads etc). > > - To develop a feature / fix a bug, a develer "forks" that branch and > commit > their stuff on the new branch. > > When the changes are ready, they are reviewed and then merged into the > mainline by someone in charge. > > I would say, that the sort-of tricky parts are these: > > - How to keep a long-running side branch up-to-date with the mainline > developments. Usually you either merge the mainline periodically into your > local branch or _rebase_ (that's a new term) your local branch on top of > the new state of the mainline. > > - How to review and how to merge. In the simplest case (no special hosting > solutions such as GitLab) a developer pushes their branch into the central > repository, tells the reviewer(s) about that, they fetch it and study its > commits. Merging is only different from Subversion in that it always > happens in some repository, and there are many of them (each developer has > one plus one central). In the simplest case, whoever merges a side branch, > does that locally and then pushes the result to the central repo. Turn-key > solutions such as GitLab can merge from web interface, and then the merge > appears to happen directly in the central repo (hosted by that solution). > > All-in-all, I think you should read something on Git _not_ about workflows, > but about its core ideas and commands. "The Book" [1] is OK for a start. > While reading the book, you play with toy Git repos and learn what its > commands do, and what is their meaning. Note that you will eventually start > reading on "remote" repositories; keep in mind that Git is fine if a > conceptially remote repository is located right there on the local > filesystem > (in a different directory) - all the commands such as `git push` and > `git fetch` will work just fine, IOW, you do not need to set up a real > remote > server to learn how two repositories exchange commit graphs. > > To recap, I feel like your request is a bit premature. Consider first > learning > more on Git, and then try toying with the simplest workflow. Also think > through how you intend to organize sharing of work among the devs. > > 1. https://git-scm.com/book/en/ > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/e5edadf7-beb3-4628-b781-28d1e2425c72n%40googlegroups.com.
