loading...

re: How should my team use Git for this specific project? VIEW POST

FULL DISCUSSION
 

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:

  • Your code needs to be safely stored in multiple locations, BUT
  • You need to know who's doing what with your code and when, AND
  • Figuring that out can't take too much time out of your normal flow

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:

  • More granularity about who changed what when
  • ... backups? I haven't actually been on the team long enough to know if it's already backed up through other means (e.g. some sort of simple nightly clone), and if this would just be a different sort of backup

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-update etc.) which is merged into develop when completed - if you have people working on files simultaneously the most you need to do usually is make sure you git pull and git merge develop into 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.

code of conduct - report abuse