Getting a git workflow for a small team

Question

Wonder if this is a smart approach to using git with a small command:

• We have a "leading" branch. git creates this branch for us by default.
• Developer A and B clone the host to their local machines.
• Developer A runs: [git devA branch] to create a local branch. They switch to it by running: [git checkout devA].
• Developer B runs: [git branch devB] to create a local branch. They switch to it by running: [git checkout devB].
• In order for developer A to move his local branch to the remote branch, they will run: [git push origin devA]. Developer B does the same in his local branch.
• Now, if you use GitHub, we will see these two remote branches on our project page.
• Both developers make changes to their local branches, and the launch of [git push] will push their commits to their respective remote branches (we would see this, having reflected on github).

It seems to me that this is a reasonable workflow. Now it's time for the developers to combine all their work to release the application they are working on. My understanding:

• Developer A wants to get changes from Developer B to his branch. Developer A will run: [git pull origin devB].
• We could create another remote branch named "dev" that acts as the central repository for all changes: [git branch dev], [git push origin dev].
• One of the developers switches to the "dev" branch. They pull all the changes into it: [git pull origin devA], [git pull origin devB]. All conflicts are fixed, etc.
• After all conflicts are fixed on "dev", we then go to the "master" branch and pull "dev" into it: [git master branch], [git pull origin dev].

So, the idea is that all developers work on their local branches and periodically merge things into "dev". Only during the release does someone push the changes from "dev" to "master". Thus, "master" always contains the most recently issued code.

Does that seem reasonable?

Thanks!

Answer 1

This workflow is likely to be great, although there are some points you might think about.

This does not reflect the general philosophy of Git that each branch represents one “feature” or “theme” - the cost of the work (see, for example, Junio ​​Hamano for the purpose of branches ). However, this will not prevent him from becoming a workable workflow for your team.

A popular workflow that reflects this philosophy is git flow .

Another popular workflow is the workflow used by the GitHub development team , which directly contradicts what Junio ​​writes about merging the wizard with branch functions, presumably in order to keep the mental model simpler and to avoid the need to explain the abandonment of developers.

Another problem is that this workflow prevents frequent integration. Thus, devA and devB can diverge significantly, and developers may have to work hard to team up when the time comes.

git alone does not care if your developers are happy, then what you offer seems to work.

Answer 2

Assuming you have more than two developers, do you want one developer to be able to pull changes from one other specific developer, but not include changes from all other developers? If not, I do not see the need to create any branches of the developer at all. Each checks to take possession of its own repository; all are pushing for origin; each gets all pushed changes merged from all developers with each click.

As for the master or dev branch at the origin, you can do this; more typically, although, I think, the wizard works constantly, and each stable release has its own branch.