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/20230731174602.nbim4tbvpn36xrqu%40carbon.
