TL/DR: We don't need everything Git does, and transitioning to Git is going to add more steps to our job. How can we ease the pain?
I'm invol...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for tagging me in this Katie! I don't post on here nearly enough. :)
So, interesting story on my end... my first dev job was a teeny tiny Cold Fusion shop on Cape Cod. It was two guys, a dog, and myself.
The first day on the job, I was met with a disastrous server with many, many files cluttering it up. If you didn't know what file was what, and weren't paying attention, things would get messy fast. The dog barked at me once for touching a file and saving it without changes, which updated the modified date and supposedly making things difficult for someone. I couldn't help but think to myself that I wasn't the one who initiated that process.
There was constant "who dis?" discussions in our open-plan office space, which took away a lot of time and added confusion to the experience. I suggested Git, but they did not know ANYTHING about version control. I mean, they thought it was a great idea, but also were totally unwilling to switch to anything new during such a busy time.
Now, that's a pretty extreme example of SFTP gone awry, but the lessons I took from it were three-fold:
I'd ask myself (and your coworker) if the trade-off is sound. On one hand, if it ain't broke don't fix it totally applies. But I wasn't sure if y'all were more "let's try something new" compared to "this is broken". So that's going to be totally relative and based on your prior experience with SFTP.
If it really comes down to multiple steps being an issue, you can set up some Git workflows that might help create your own customized "best practices" for your team.
I'm excited to read others' advice! This is a really interesting issue that affects smaller teams in unique ways.
I think people are definitely excited about the promise of:
Everyone seems to be pretty open to it, so to me, what I guess I'm really hoping to get a better sense of is "Git workflows and concepts that might ease our lives."
I think "foolproofing" is a good part of a smooth transition. The easier it is to avoid getting into pickles that require people who don't know Git to spend an afternoon researching Git, the better.
Sort of like when I suggested to my colleague, "Hey, what if we taught everyone to hard-reset before they muck around, so it feels more like a slightly-convoluted SFTP upload than a whole new concept?"
Only I don't actually have experience to know if that is a good idea.
So looking for ... the actual good ideas. :-)
For the your query about the merge issues, you could look at a workflow like Git Flow to ease the problem of having messy merges.
Each update lives on its own feature branch (
feature/my-updateetc.) which is merged intodevelopwhen completed - if you have people working on files simultaneously the most you need to do usually is make sure yougit pullandgit merge developinto your feature before PRing. Features are cheap and offer a lot of the benefits you've mentioned above about granularity.Im not sure if it's 100% relevant to your use case, and I'm not a git jedi by any stretch of the imagination, but if you have questions about this, I'd be happy to try and answer.
Thanks; this is exactly the kind of comment I was hoping to hear! Will read this doc and practice a bit ... maybe on my next updates to my blog.
Consider this: if a merge conflict occurs with git, two people have changed the same file. If you just replaced the file in the normal system, then you lost the previous changes.
If you only do a small change, and you forgot to pull before changing the file, then it's still not too late to pull. Just pull, commit, then push, and no merging is needed unless two people have changed the same file.
And in the scenario that you comitted once before pulling, just soft reset to master, pull, and do the commit again.
Thanks -- I haven't done the things you described, but your comment is very clear, so I know what to Google and practice next so that I can help be a point-person for my team!
If you make changes and then pull you will be fine, rest is not needed and makes it complicated.
You can look into the rebase workflow for some more advanced tools.
Next up on my "to practice" list: editing my blog directly through the web interface, editing the same file on my computer on a different line w/o first fetching a fresh copy, and learning to pull & merge. Thanks for the idea!
This will help, and it doesn't require doing changes (your idea is probably still valuable though)
learngitbranching.js.org/
i'm giving you some opinions and french training ;)
alors d'abord GIT est le meilleur moyen de tracer tout changement.
MAIS il faut avoir un workflow clair et suivi par tout le monde.
Le Merge est l’étape finale : avant ça chaque Dev doit apprendre à gérer son GIT local de manière propre.
Ca veut dire que chaque nouveau développement doit avoir les phases suivantes :
En résumé : c'est toute une autre façon de gérer son code. Ça permet de revenir à une version précise , d'identifier les auteurs, si les demandes sont passées en production (est-ce que le Fix-454654 est merged en production ?) et globalement ça permet aussi de prendre du recul sur l'architecture du code : 2 fichiers modifiés pour un même besoin = possibilité de créer un module qui concentre la fonctionnalité.
Concernant ces scripts spécifiques le 1er gain ça va être de pouvoir avoir des Dev différents qui travaillent - en même temps - sur un script et de pouvoir intégrer chacune des modifications sans devoir éditer manuellement.
J'espère que ça te sera utile.
C'est parfait; merci ! :-D
I believe utilizing git is the right choice, and will try to argue the system was broken (but may fail not being in the system)
Git's distributed nature provides an architecture with benefits not related to work distribution.
It sounds like these files drive an important function, I would expect issues could come from incorrect edits. Git will provide the simplicity of allowing any member to roll back without knowledge of the edit causing this issue.
On the matter of merging, you'll have issues when there are two edits and those edits are in the same area. If you choose a hard reset then you prevent the tool from helping you keep all changes happening.
If there are patterns to the changes then history provides a list of example edits.
My claim that the old system is broken comes from the idea that mistakes get made and versions history gives insight to those mistakes for the better.
Thanks for the insight about the added benefit of easy rollback, as well as the encouragement/rationale for me to learn more about merging!
Interesting thought; thanks for kicking off the discussion!