5 ms·

Can you clarify why branching helps collaboration? In other words, why is it harder to commit to trunk when you have several developers working on a feature?

by _cs2017_ 8y ago

weinzierl 8y ago
Branching enables me to share unfinished work with my collaborators. Sometimes I don't want to commit to trunk yet but still share code and collaborate on a part of the code base.
- majikandy 8y ago
  Make the changes smaller and more valuable and do it on trunk.
  - weinzierl 8y ago
    This should always be Plan A but in my experience it is not always possible. Think of untangling dependencies between a large number of components as an example.
    - fergus_google 8y ago
      Untangle one dependency at a time.
- hknd 8y ago
  So you can prepare a change for trunk, and share the change with your colleagues to collaborate on. Don't see why branching should be needed for this.
  - weinzierl 8y ago
    That's what I meant in my question with "share code by other means". It works but in my opinion it is a large pain and I can't believe people at Google work by sending patches back and forth.
    - hknd 8y ago
      It's actually really easy to create a "patch", so people usually create small "patches" and send them to people if they need any feedback on those. A "patch" is actually just a commit (actually a changelist) which can be viewed, commented and edited in the browser based code review and IDE tool. Imho I find it much easier to get an url of a "patch" and comment on it inline, instead of having to checkout a branch etc. If you have a question to a specific example I'm happy to answer it in the way it would've been done within Google/Facebook.
      - weinzierl 8y ago
        Thank you, I appreciate your effort to help me understand this better and our exchange helped me to make progress. One thing I infer from your answer is that it seems that there is an established process and dedicated tooling for working with patches at Google. I think a lot of my pain with patches stems more from the lack of process and lack of an agreement on formats and standards in my environment than from the use of patches per se. Where I still see an advantage of branches is that they facilitate documentation of what has been done by whom and when. All of this documentation is in the same place and form as the documentation of changes in the trunk. It all is in commit messages whereas patches are only documented somewhere else, possibly in the Email or IM used to send the patch. Even if most of the branch documentation does not survive on trunk when we squash the final merge it is still there and easy to find as long as the branch doesn't get deleted. When I want to look up why I applied a certain patch I'll have to dig through my messages. I think that makes it harder to work with patches than with branches.
        hknd 8y ago
        A "patch" in Google/Facebook/Twitter is the same as a commit. It has a (mostly) descriptive commit message, references to bug tickets and might contain links to documentation, screenshots and mocks. You basically work on a "patch" (changelist), get feedback from others and send it out to review at the end. Before you can submit (commit) it, you'll have to sync to "head" (to have the latest changes) and run all tests. ^ most of this happens automatically, and as most changelists ("patches") are small, this happens very fast and async in the background.
- jahaja 8y ago
  If they're using Perforce one can "Shelve" a CL (changelist, similar to a commit in git) to make it available for others to unshelve. This can be used as a workaround, albeit limited, to share work-in-progress stuff.

Can you clarify why branching helps collaboration? In other words, why is it harder to commit to trunk when you have several developers working on a feature?

weinzierl 8y ago

Branching enables me to share unfinished work with my collaborators. Sometimes I don't want to commit to trunk yet but still share code and collaborate on a part of the code base.

majikandy 8y ago
Make the changes smaller and more valuable and do it on trunk.
- weinzierl 8y ago
  This should always be Plan A but in my experience it is not always possible. Think of untangling dependencies between a large number of components as an example.
  - fergus_google 8y ago
    Untangle one dependency at a time.
hknd 8y ago
So you can prepare a change for trunk, and share the change with your colleagues to collaborate on. Don't see why branching should be needed for this.
- weinzierl 8y ago
  That's what I meant in my question with "share code by other means". It works but in my opinion it is a large pain and I can't believe people at Google work by sending patches back and forth.
  - hknd 8y ago
    It's actually really easy to create a "patch", so people usually create small "patches" and send them to people if they need any feedback on those. A "patch" is actually just a commit (actually a changelist) which can be viewed, commented and edited in the browser based code review and IDE tool. Imho I find it much easier to get an url of a "patch" and comment on it inline, instead of having to checkout a branch etc. If you have a question to a specific example I'm happy to answer it in the way it would've been done within Google/Facebook.
    - weinzierl 8y ago
      Thank you, I appreciate your effort to help me understand this better and our exchange helped me to make progress. One thing I infer from your answer is that it seems that there is an established process and dedicated tooling for working with patches at Google. I think a lot of my pain with patches stems more from the lack of process and lack of an agreement on formats and standards in my environment than from the use of patches per se. Where I still see an advantage of branches is that they facilitate documentation of what has been done by whom and when. All of this documentation is in the same place and form as the documentation of changes in the trunk. It all is in commit messages whereas patches are only documented somewhere else, possibly in the Email or IM used to send the patch. Even if most of the branch documentation does not survive on trunk when we squash the final merge it is still there and easy to find as long as the branch doesn't get deleted. When I want to look up why I applied a certain patch I'll have to dig through my messages. I think that makes it harder to work with patches than with branches.
      - hknd 8y ago
        A "patch" in Google/Facebook/Twitter is the same as a commit. It has a (mostly) descriptive commit message, references to bug tickets and might contain links to documentation, screenshots and mocks. You basically work on a "patch" (changelist), get feedback from others and send it out to review at the end. Before you can submit (commit) it, you'll have to sync to "head" (to have the latest changes) and run all tests. ^ most of this happens automatically, and as most changelists ("patches") are small, this happens very fast and async in the background.
jahaja 8y ago
If they're using Perforce one can "Shelve" a CL (changelist, similar to a commit in git) to make it available for others to unshelve. This can be used as a workaround, albeit limited, to share work-in-progress stuff.