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 

Reply via email to