4 ms·

January 05, 2010

by abraham 16y ago

January 05, 2010

brown9-2 16y ago
Has working with Git on a team changed much in nine months?
- abraham 16y ago
  Significantly? Probably not. Ten months is a long time in technology and best practice/process will have changed. The age is yet another factor to consider while reading the article.
  - sanswork 16y ago
    Best practices change a lot more slowly than the emergence of new technologies. For the good reason that to determine something is a best practice takes time and finding something even better takes even more time. When considering core/base technologies it's usually safe to give it a lot more than ten months before dismissing it and even in that case only in the presence of something known that could improve on it. Replacing your best practices/processes every couple months to keep up with the latest trends is a recipe for disaster in any multi-person development environment and change breeds confusion. That said this setup won't work for everyone nor does the author claim it should do. It's another possible tool for your belt to consider depending on your work and the team you're working with. I guess the to short version is don't be so quick to dismiss things based off age(or lack thereof in this case) unless you can dismiss it with a proven replacement.
    - abraham 16y ago
      personally how I do things is constantly changing. Usually in small increments but I am always looking for new and better methods. Many will just just be used for a short period. You should not however be so quick in concluding that I said to dismiss the article. I am nearly bringing attention to the fact that it is nearly a year old and to consider it while making your own evaluation of the article.
      - sanswork 16y ago
        Some things I've found are best to keep fairly stable for longer periods of time. Branching policy with git is one of these. I'm not sure of your experiences with managing development teams using git but from mine I've found setting a branching policy(this one actually) and making sure people stick to it is the best way to minimize confusion and keep people on track. Side note: I think the reason your previous comments were down voted wasn't your concern about the age of the article so much as your lack of a better alternative. If you could say "This was from Jan and this has been shown to be better" people would probably be posting stories about your new technique. To just say it is 10 months old though adds nothing to the conversation.
silentbicycle 16y ago
Which basically makes it ancient history, right? I dare you to implement a compiler with only stuff invented since January 6, 2010. Or do basically anything (including eat). Eventually, we'll pity you and bring you antibiotics and parsing algorithms.

January 05, 2010

by abraham 16y ago

January 05, 2010

brown9-2 16y ago

Has working with Git on a team changed much in nine months?

abraham 16y ago
Significantly? Probably not. Ten months is a long time in technology and best practice/process will have changed. The age is yet another factor to consider while reading the article.
- sanswork 16y ago
  Best practices change a lot more slowly than the emergence of new technologies. For the good reason that to determine something is a best practice takes time and finding something even better takes even more time. When considering core/base technologies it's usually safe to give it a lot more than ten months before dismissing it and even in that case only in the presence of something known that could improve on it. Replacing your best practices/processes every couple months to keep up with the latest trends is a recipe for disaster in any multi-person development environment and change breeds confusion. That said this setup won't work for everyone nor does the author claim it should do. It's another possible tool for your belt to consider depending on your work and the team you're working with. I guess the to short version is don't be so quick to dismiss things based off age(or lack thereof in this case) unless you can dismiss it with a proven replacement.
  - abraham 16y ago
    personally how I do things is constantly changing. Usually in small increments but I am always looking for new and better methods. Many will just just be used for a short period. You should not however be so quick in concluding that I said to dismiss the article. I am nearly bringing attention to the fact that it is nearly a year old and to consider it while making your own evaluation of the article.
    - sanswork 16y ago
      Some things I've found are best to keep fairly stable for longer periods of time. Branching policy with git is one of these. I'm not sure of your experiences with managing development teams using git but from mine I've found setting a branching policy(this one actually) and making sure people stick to it is the best way to minimize confusion and keep people on track. Side note: I think the reason your previous comments were down voted wasn't your concern about the age of the article so much as your lack of a better alternative. If you could say "This was from Jan and this has been shown to be better" people would probably be posting stories about your new technique. To just say it is 10 months old though adds nothing to the conversation.

silentbicycle 16y ago

Which basically makes it ancient history, right? I dare you to implement a compiler with only stuff invented since January 6, 2010. Or do basically anything (including eat). Eventually, we'll pity you and bring you antibiotics and parsing algorithms.