Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. git poll

git poll

Scheduled Pinned Locked Moved The Lounge
collaborationcsharpcomquestionlearning
24 Posts 19 Posters 2 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Super Lloyd

    Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?

    A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

    L Offline
    L Offline
    Lost User
    wrote on last edited by
    #21

    I guess that is why I could never get my head around "version control" if one was a one man band. A typical "project" includes images, pdf's, text files, utilities, etc. Accumulating over time. I zip everything every day or 2 and create 10 or more generations. Covered most brain fogs.

    "(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal

    1 Reply Last reply
    0
    • J Jeff Buxton

      Rule 1: you never really know what you are doing, so we will come to your office and kill you if you edit directly on the production branch Rule 2: if you think you know what you are doing, please refer to Rule 1.

      E Offline
      E Offline
      Eytukan
      wrote on last edited by
      #22

      rofl . Okay. Point noted. :laugh:

      Full Reset

      1 Reply Last reply
      0
      • S Super Lloyd

        Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?

        A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

        J Offline
        J Offline
        John Stewien
        wrote on last edited by
        #23

        All features should be on a different branch. If you are getting lots of conflicts then I have to wonder about your project architecture. Are you using something like PrismLibrary to separate out your modules?

        1 Reply Last reply
        0
        • S Super Lloyd

          Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?

          A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

          M Offline
          M Offline
          Mark J Miller
          wrote on last edited by
          #24

          Plan your work in small units (1 day) if possible. Except where specifically required squash the history of your local branch (`git rebase -i`) down to a single commit. You'll simplify resolution of merge conflicts, keep your features as atomic units, and keep your history clean of junk comments. Your workflow should look something like: pull master -> branch -> commit -> squash -> rebase -> push pull request -> review -> ff merge -> repeat. Commit -> squash -> rebase gets repeated as a whole or individually as needed.

          www.developMENTALmadness.com

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups