CODEWITHSUNDEEP
gitversion-control
user291701
user291701

Reputation: 39681

Getting the hang of git workflow for a small team

Wondering if this is a reasonable approach to using git with a small team:

  1. We have the "master" branch. Git creates this branch for us by default.
  2. Developer A and B clone "master" to their local machines.
  3. Developer A runs: [git branch devA] to create a local branch. They switch to it by running: [git checkout devA].
  4. Developer B runs: [git branch devB] to create a local branch. They switch to it by running: [git checkout devB].
  5. For Developer A to turn their local branch into a remote branch, they would run: [git push origin devA]. Developer B does the same thing to their local branch.
  6. Now if using GitHub, we would see these two remote branches on our project page.
  7. Both developers make changes to their local branches, and running [git push] will push their commits to their respective remote branches (we would see this reflected on github).

That seems like a reasonable workflow to me. Now it comes time for the developers to merge all their work for a release of the app they're working on. My understanding:

  1. Developer A wants to get Developer B's changes into their branch. Developer A would run: [git pull origin devB].
  2. We might create yet another remote branch named "dev" which acts as a central repository for everyone's changes: [git branch dev], [git push origin dev].
  3. One of the developers switches to branch "dev". They pull everyone's changes into it: [git pull origin devA], [git pull origin devB]. All conflicts are fixed etc.
  4. After all conflicts are fixed on "dev", we then switch to branch "master", and pull "dev" into it: [git branch master], [git pull origin dev].

So the idea is that all developers work on their own local branches, and periodically merge stuff into "dev". Only at release time does someone pull changes from "dev" into "master". So "master" always contains the last-released code.

Does that seem reasonable?

Thank you!

Upvotes: 4

Views: 2613

Answers (2)

Emil Sit
Emil Sit

Reputation: 23542

This workflow would probably be fine, though it has some points that you may want to think about.

It does not reflect a common Git philosophy of having each branch represent one "feature" or "topic"-worth of work (see, for example, Junio Hamano on the purpose of branches). However, that wouldn't stop it from being a workable workflow for your team.

A popular workflow that reflects this philosophy is git flow.

Another popular workflow is the workflow that the GitHub dev team uses which directly goes against what Junio writes about merging master into feature branches, in favor presumably of keeping the mental model simpler and avoiding having to explain about rebasing to developers.

Another issue is that this workflow discourages frequent integrations. So devA and devB may diverge significantly and the developers may have to do a lot of work to merge when the time comes.

Git itself does not care so if your developers are happy, then what you propose seems workable.

Upvotes: 4

smendola
smendola

Reputation: 2311

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 the other developers? If not, I don't see a need to create any developer branches at all. Everyone checks in to master on their own repository; everyone pushes to master on the origin; everyone gets all pushed changes, merged from all developers, on every pull.

As for the master vs. dev branch on the origin, you could do that; more typically though, I think, master is ongoing work, and each stable release has its own branch.

Upvotes: 2

Related Questions