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:

  • How to use .jar tool BFG Repo Cleaner and reduce git repository?
  • Installing PhoneGap getting “error not found: git”
  • Visual Studio 2013 coexisting Ankh SVN and Git
  • Make git master HEAD point to current HEAD of branch
  • In git, how do I sync my tags against a remote server?
  • Cannot find FileMerge (opendiff tool) but I have xcode 4.6 installed
    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!

  • Git remove root commit
  • Why is Google Drive deleting my Git files?
  • fatal: error when closing sha1 file: Input/output error
  • Using git with ssh-agent on Windows
  • What exactly does the ReCommit feature in TortoiseGit do?
  • remove deleted files from git: Argument list too long
  • 2 Solutions collect form web for “Getting the hang of git workflow for a small team”

    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.

    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.

    Git Baby is a git and github fan, let's start git clone.