10 ms·

Comparing Git Workflows

268 points by AJAlabs 10y ago

useryMcUserface 10y ago
This article has actually been around for a while. Explains it really great. But one advice from me is that try to choose only what is sufficient to your project and team. No benefit in being overequipped for a simple job.
- scarecrowbob 10y ago
  I agree--- I've worked with several of these, but for most of the (smallish) projects we do, we end up coming back to a centralized repository, occasionally using feature branches if necessary. We're a small shop with only 1 or 2 folks working on the code at a time, and mostly are using git as part of our deploy process... so simplest is the best for us.
- edu 10y ago
  This, over complicating the git workflow will make people not using it. In my experience the feature branch works for 80% of the projects, gitflow works for bit projects and I guess (no experience there) that the forking will work for open source projects or HUGE code bases.
  - lamontcg 10y ago
    even reasonably large open source projects don't need anything beyond feature branches and one long-lived master branch. and if you're going to back port to historical releases and hotfix and or patch them, its better to fork off master and then cherry-pick back, and then eventually end those branches.
drewg123 10y ago
One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to history, and actually provide an impediment to bisecting (since a lot of these intermediate revisions will not even compile). At my previous job, we used gerrit. The nice thing about gerrit from my perspective is that it kind of "hid" all of the intermediary stages in the gerrit review. So you could push all you wanted to your gerrit review fake-branch thing, and when you finally pushed to master, there would just be a nice, clean atomic change for your feature. If you needed more detailed history of the steps during review, it was there in gerrit. But master was clean, and bisectable. Is there any git other git tool or workflow which both allows people to back things up to the central git repo AND which allows squashing changes down to meaningful bits, AND which does not loose the history of review iterations?
- edu 10y ago
  You could use `git merge --squash` with Feature Branch or Gitflow. But IMHO it's better not to squash.
- jedberg 10y ago
  A couple weeks ago GitHub added merge squash as an option for accepting pull requests (via the UI, you could always do it manually). As long as you don't delete the feature branch you'll still have the history of iterations in that branch.
  - sethherr 10y ago
    TAKE HEED! This is the solution to everything
  - heavenlyhash 10y ago
    > As long as you don't delete the feature branch This, unfortunately, is not a great thing to propose. Many of git's operations on refs are basically O(n). You really don't want to accumulate an unbounded number of them over time.
    - jedberg 10y ago
      I agree with you, but I was responding to the request to keep "all the history". My understanding is the ref count would be the same if you merge in all the history or keep the branches around, so in those cases it wouldn't make a difference. I could be wrong though -- I don't know enough about git internals to know if one is worse than the other.
- herge 10y ago
  I wonder if 'expandable commits' would be useful, where in the full history, a change (with all it's code review fixes, etc) would appear as one commit, but if you wanted to dig deeper, you could 'expand' that commit into all it's gory details of 'draft version before review', 'tried refactoring this part but gave up', etc.
sytse 10y ago
I think the ideal workflow depends on the complexity you need. I've tried to write about what kind of requirements cause what kind of workflow in http://docs.gitlab.com/ee/workflow/gitlab_flow.html http://docs.gitlab.com/ee/workflow/gitlab_flow.html What do you think?
kevinSuttle 10y ago
Was this updated recently? This has been up for awhile.
- AJAlabs 10y ago
  Yes, the article has been up for a while
jupp0r 10y ago
Those are general development models and not specific to git.
zamalek 10y ago
You can also evolve, basically, to each model in the order that they appear in the article. As an example: I've been working on a new spike for the past 2 weeks with one other developer. Maybe 10 times a day we'll need something that the other person has committed, so we work against one branch (master). The workflow suits this extremely rapid iteration. One repo has now matured to the point where developer branches make sense. We created "develop" on it as well as our own branches off that. We're not close to a v0.1 yet - but we'll be evolving to git flow the minute we want to ship. Eventually as more devs join, we'll need the full-blown PR workflow, that also naturally stems from its predecessor. There's a "meta-workflow" here, which implies which workflow to use.
- teen 10y ago
  developer branches never make sense
  - zamalek 10y ago
    Excluding the possibility of a laptop getting lost or stolen.
    - watersb 10y ago
      git is not [necessarily] a backup.
  - unethical_ban 10y ago
    There are many people in this conversation describing then as the Savior of comments for commits, as it not using them is a disservice to the team. I'm not much of a coder myself, but the suffering opinions are interesting.
  - qb45 10y ago
    Tell those guys ;) https://git.kernel.org/cgit/ https://git.kernel.org/cgit/
- deleted 10y ago
  [deleted]
crispyambulance 10y ago
Kudos to atlassian for bringing some much needed clarity to a confusing topic. So many people that claim mastery of git only know particular workflows and, when attempting to mentor others, just mansplain whatever they know without consideration that there are alternative valid ways of doing things. Without a firm grasp of one's intent(workflow) learning git commands is pointless and leads to people desperately flailing out commands.
- recursive 10y ago
  > mansplain Sexist language has no place on HN.
zmmmmm 10y ago
It amazes me how the entire software industry seems to be adapting its workflows around the necessity of making Git usable. While there are certainly other positive attributes about some of these workflows, the main reason people use them in my experience is because "if you don't use workflow X you get undesirable problem Y with Git". Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems, so we never needed these elaborate workflows. Now suddenly Git is considered a defacto tool, and downstream effects of using it are transforming the entire software development process.
- dpc_pw 10y ago
  "Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems" Are you kidding? :) CVS, Subversion, Perforce, and some propriety revisioning systems were HUGE PITA. People used to lock files, so noone else could change them when they were working with them. Merging different feature branches was like locking whole repository with huge lock, so noone else could touch anything at the time. Any time I had to work with legacy revisioning systems I wanted to kill myself. Git workflows are conventions to help improve small issues with staff that wasn't even possible befor (before Distributed VCS). And a lot of these problems are superficial ("oh those merge commit are annoying in `git log`"). It reminds me: https://www.youtube.com/watch?v=ZFsOUbZ0Lr0 https://www.youtube.com/watch?v=ZFsOUbZ0Lr0
  - jimbobimbo 10y ago
    In Subversion you'd need to explicitly lock the file, it doesn't require it. Merge the is also not as bad as you're describing. I actually had more headaches with merges in Git than in Subversion.
- nlawalker 10y ago
  >> Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems They generally don't exist with Git, either, if you limit yourself to the same set of features and capabilities that other revision control systems have. Take Microsoft Team Foundation version control for example. All of the "problems" with Git disappear if you use a workflow that gives you the same features as TFVC and have the same expectations (especially around history): collaborate around a single shared repo instance, push every commit when it's made, and allow fast-forward merges only. Conflict? Rebase locally. Personally, I think a good idea for a Git tutorial would be to recreate the workflow of another version control product into Git in order to introduce some of the new ideas in a familiar war.
Bromskloss 10y ago
What was the workflow in mind when Git was designed?
nwatson 10y ago
The article completely mischaracterizes Subversion workflows, making the mistake of treating a Subversion repo just like developers typically use git repos ... one-repo-per-project. Subversion instead is a tree with projects as nodes toward the leaves, each project with its own trunk, branch, tags. It's each of these projects that corresponds to a git repo. Teams I worked on always treated each project as its own "repo" ... so the central single Subversion tree became like our 'github' or 'bitbucket' ... and one could do all the lockless branching within each project, no problem. YOU COULD BE AS NON-LINEAR IN THIS APPROACH AS YOU NEED TO BE, with full support for branching, tagging, merging, etc. Where Subversion was much better was in supporting consolidated views of multi-project build / release environments, or in mixing sub-project code in parent-project code. Using svn:external it was each to put "that subproject in this place in my own project". Using git submodules and other approaches is a pain. You end up having to check out a bunch of git repos and managing your own glue.
EnderMB 10y ago
It'd be nice to see someone collate more git workflows, and what the advantages and disadvantages of these are. Over time, my workflow has become simpler and simpler. I've worked with some weird and wacky workflows before, which have been born from a given requirement, such as quick deployment to a number of different environments, or two separate teams working on separate parts of one codebase while maintaining separate CI workflows. Some of these workflows have seemed absolutely mental, but I've seen them several times over in different places, so there must be some kind of logic to the madness. Different dev teams have wildly different practices, so it'd be good to acknowledge the "typical" way of doing things, and embracing the workflows that work if you need to do something out of the ordinary.
axelfontaine 10y ago
Or you could actually practice continuous integration and let everyone work on master. Much simpler, opens the door for feature toggles, continuous delivery and more without any merge headaches.

268 points by AJAlabs 10y ago

This article has actually been around for a while. Explains it really great. But one advice from me is that try to choose only what is sufficient to your project and team. No benefit in being overequipped for a simple job.

scarecrowbob 10y ago
I agree--- I've worked with several of these, but for most of the (smallish) projects we do, we end up coming back to a centralized repository, occasionally using feature branches if necessary. We're a small shop with only 1 or 2 folks working on the code at a time, and mostly are using git as part of our deploy process... so simplest is the best for us.
edu 10y ago
This, over complicating the git workflow will make people not using it. In my experience the feature branch works for 80% of the projects, gitflow works for bit projects and I guess (no experience there) that the forking will work for open source projects or HUGE code bases.
- lamontcg 10y ago
  even reasonably large open source projects don't need anything beyond feature branches and one long-lived master branch. and if you're going to back port to historical releases and hotfix and or patch them, its better to fork off master and then cherry-pick back, and then eventually end those branches.

drewg123 10y ago

One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to history, and actually provide an impediment to bisecting (since a lot of these intermediate revisions will not even compile). At my previous job, we used gerrit. The nice thing about gerrit from my perspective is that it kind of "hid" all of the intermediary stages in the gerrit review. So you could push all you wanted to your gerrit review fake-branch thing, and when you finally pushed to master, there would just be a nice, clean atomic change for your feature. If you needed more detailed history of the steps during review, it was there in gerrit. But master was clean, and bisectable. Is there any git other git tool or workflow which both allows people to back things up to the central git repo AND which allows squashing changes down to meaningful bits, AND which does not loose the history of review iterations?

edu 10y ago
You could use `git merge --squash` with Feature Branch or Gitflow. But IMHO it's better not to squash.
jedberg 10y ago
A couple weeks ago GitHub added merge squash as an option for accepting pull requests (via the UI, you could always do it manually). As long as you don't delete the feature branch you'll still have the history of iterations in that branch.
- sethherr 10y ago
  TAKE HEED! This is the solution to everything
- heavenlyhash 10y ago
  > As long as you don't delete the feature branch This, unfortunately, is not a great thing to propose. Many of git's operations on refs are basically O(n). You really don't want to accumulate an unbounded number of them over time.
  - jedberg 10y ago
    I agree with you, but I was responding to the request to keep "all the history". My understanding is the ref count would be the same if you merge in all the history or keep the branches around, so in those cases it wouldn't make a difference. I could be wrong though -- I don't know enough about git internals to know if one is worse than the other.
herge 10y ago
I wonder if 'expandable commits' would be useful, where in the full history, a change (with all it's code review fixes, etc) would appear as one commit, but if you wanted to dig deeper, you could 'expand' that commit into all it's gory details of 'draft version before review', 'tried refactoring this part but gave up', etc.

sytse 10y ago

I think the ideal workflow depends on the complexity you need. I've tried to write about what kind of requirements cause what kind of workflow in http://docs.gitlab.com/ee/workflow/gitlab_flow.html http://docs.gitlab.com/ee/workflow/gitlab_flow.html What do you think?

kevinSuttle 10y ago

Was this updated recently? This has been up for awhile.

AJAlabs 10y ago
Yes, the article has been up for a while

jupp0r 10y ago

Those are general development models and not specific to git.

zamalek 10y ago

You can also evolve, basically, to each model in the order that they appear in the article. As an example: I've been working on a new spike for the past 2 weeks with one other developer. Maybe 10 times a day we'll need something that the other person has committed, so we work against one branch (master). The workflow suits this extremely rapid iteration. One repo has now matured to the point where developer branches make sense. We created "develop" on it as well as our own branches off that. We're not close to a v0.1 yet - but we'll be evolving to git flow the minute we want to ship. Eventually as more devs join, we'll need the full-blown PR workflow, that also naturally stems from its predecessor. There's a "meta-workflow" here, which implies which workflow to use.

teen 10y ago
developer branches never make sense
- zamalek 10y ago
  Excluding the possibility of a laptop getting lost or stolen.
  - watersb 10y ago
    git is not [necessarily] a backup.
- unethical_ban 10y ago
  There are many people in this conversation describing then as the Savior of comments for commits, as it not using them is a disservice to the team. I'm not much of a coder myself, but the suffering opinions are interesting.
- qb45 10y ago
  Tell those guys ;) https://git.kernel.org/cgit/ https://git.kernel.org/cgit/
deleted 10y ago
[deleted]

crispyambulance 10y ago

Kudos to atlassian for bringing some much needed clarity to a confusing topic. So many people that claim mastery of git only know particular workflows and, when attempting to mentor others, just mansplain whatever they know without consideration that there are alternative valid ways of doing things. Without a firm grasp of one's intent(workflow) learning git commands is pointless and leads to people desperately flailing out commands.

recursive 10y ago
> mansplain Sexist language has no place on HN.

zmmmmm 10y ago

It amazes me how the entire software industry seems to be adapting its workflows around the necessity of making Git usable. While there are certainly other positive attributes about some of these workflows, the main reason people use them in my experience is because "if you don't use workflow X you get undesirable problem Y with Git". Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems, so we never needed these elaborate workflows. Now suddenly Git is considered a defacto tool, and downstream effects of using it are transforming the entire software development process.

dpc_pw 10y ago
"Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems" Are you kidding? :) CVS, Subversion, Perforce, and some propriety revisioning systems were HUGE PITA. People used to lock files, so noone else could change them when they were working with them. Merging different feature branches was like locking whole repository with huge lock, so noone else could touch anything at the time. Any time I had to work with legacy revisioning systems I wanted to kill myself. Git workflows are conventions to help improve small issues with staff that wasn't even possible befor (before Distributed VCS). And a lot of these problems are superficial ("oh those merge commit are annoying in `git log`"). It reminds me: https://www.youtube.com/watch?v=ZFsOUbZ0Lr0 https://www.youtube.com/watch?v=ZFsOUbZ0Lr0
- jimbobimbo 10y ago
  In Subversion you'd need to explicitly lock the file, it doesn't require it. Merge the is also not as bad as you're describing. I actually had more headaches with merges in Git than in Subversion.
nlawalker 10y ago
>> Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems They generally don't exist with Git, either, if you limit yourself to the same set of features and capabilities that other revision control systems have. Take Microsoft Team Foundation version control for example. All of the "problems" with Git disappear if you use a workflow that gives you the same features as TFVC and have the same expectations (especially around history): collaborate around a single shared repo instance, push every commit when it's made, and allow fast-forward merges only. Conflict? Rebase locally. Personally, I think a good idea for a Git tutorial would be to recreate the workflow of another version control product into Git in order to introduce some of the new ideas in a familiar war.

Bromskloss 10y ago

What was the workflow in mind when Git was designed?

nwatson 10y ago

The article completely mischaracterizes Subversion workflows, making the mistake of treating a Subversion repo just like developers typically use git repos ... one-repo-per-project. Subversion instead is a tree with projects as nodes toward the leaves, each project with its own trunk, branch, tags. It's each of these projects that corresponds to a git repo. Teams I worked on always treated each project as its own "repo" ... so the central single Subversion tree became like our 'github' or 'bitbucket' ... and one could do all the lockless branching within each project, no problem. YOU COULD BE AS NON-LINEAR IN THIS APPROACH AS YOU NEED TO BE, with full support for branching, tagging, merging, etc. Where Subversion was much better was in supporting consolidated views of multi-project build / release environments, or in mixing sub-project code in parent-project code. Using svn:external it was each to put "that subproject in this place in my own project". Using git submodules and other approaches is a pain. You end up having to check out a bunch of git repos and managing your own glue.

EnderMB 10y ago

It'd be nice to see someone collate more git workflows, and what the advantages and disadvantages of these are. Over time, my workflow has become simpler and simpler. I've worked with some weird and wacky workflows before, which have been born from a given requirement, such as quick deployment to a number of different environments, or two separate teams working on separate parts of one codebase while maintaining separate CI workflows. Some of these workflows have seemed absolutely mental, but I've seen them several times over in different places, so there must be some kind of logic to the madness. Different dev teams have wildly different practices, so it'd be good to acknowledge the "typical" way of doing things, and embracing the workflows that work if you need to do something out of the ordinary.

axelfontaine 10y ago

Or you could actually practice continuous integration and let everyone work on master. Much simpler, opens the door for feature toggles, continuous delivery and more without any merge headaches.