4

The production file edited in March was way more advanced than the development file edited in July... what happened here?

I want to implement Git on this one so bad. :( I wish I found the way and the time already (it's a very complicated situation).

Comments
  • 6
    Setting up git on an existing code base takes 5 min (with installation)

    Getting the team to change from "just fix it in prod" to actually working with git, that's the hard part.
  • 1
    @C0D4 It's actually many projects in one folder (a website) so there's a bit more to do...
    Also... I am the team. X'd
  • 1
    @c3r38r170 I'm not a git expert, basiclly I only use git with GUI ;p

    But git submodules seems like a thing for your case ?

    https://git-scm.com/book/en/...
  • 2
    As for me, the use of Git is simply necessary, I can’t understand how a team can not use it.
  • 0
    @NoToJavaScript Submodules, subtrees... I'm on it, don't worry. Thank you!
  • 1
    @c3r38r170 Be VERY careful with submodules.

    As long as it is a single project, it's fine.

    If you use submodules as a replacement for versioned artifacts, e.g. JARs / composer packages / python packages / ... - very bad idea.

    Submodules are code only.

    Which is a very different thing from a versioned artifact which is compiled code.
  • 1
    @c3r38r170 if it's many websites, use a repo per websites

    If it's many projects under a single website, sub modules could be the ticket out otherwise a huge ass repo may be the answer.

    Got an example folder structure?
  • 1
    @C0D4 Yeah, something like:
    api/
    projects/
    index.php
    ...
    proj1/
    entityX/
    ...
    proj2/
    entityY/
    ...
    proj1/
    index.php
    ...
    proj2/
    index.php
    ...

    And there's a bit more but that's about how complex the situation is.
    So I should compile every folder, get them into a different repo per project, then make branches for each different folder and have each branch as a submodule on a website repo in the respective places. And then have proper documentation of each "submodule" and a production branch without this (although it could go to a wiki, I haven't thought things this far).
    That's the solution I've been thinking to implement.
    I will try to make everything as contained as possible in the future, but there are some things that should remain available for everyone like api/projects/ in this example but in reality it's libs, utils, a ui-kit, and a couple more things I think.
    I already turned some projects into folders and have them as repos, so I'm on it.
  • 1
    @C0D4 I'm really thankful for your question, I've been thinking about who to consult to find the best approach.
    This happened because I was pressed for time and a junior, and this was the easiest and fastest way I found.
    Learned from my mistakes, and looking to fix them.
  • 1
    @c3r38r170

    If you want to track each /api/project separately then submodules would be the way to go here, plus you only need to pull the specific folder down then rather then deal with the monolithic repo, unless there's dependencies but that's a whole other chapter 😅

    We, (read dev ranters) don't like helping people who wont appreciate the information, But we will go to good lengths when it's worth it.

    A good read up on submodules and how to get them running:

    https://github.blog/2016-02-01-work...
Add Comment