Search Unity

Was it always this easy?

Discussion in 'General Discussion' started by Deleted User, Apr 21, 2020.

  1. Deleted User

    Deleted User

    Guest

    Soo in 2016 I lost about two months of game dev work due to being unacquainted with the use of Git. Its something I've struggled with for a while...

    And then the other day I tried something different. Instead of trying to "merge unrelated histories" among a few other stupid moves, I made my local commit, branched, and pushed that branch to the remote.

    No conflicts.

    Worked like a charm.

    I'm left wondering if I really did just miss the point of Git this whole time? lmao Now that I understand what a pull request is and how to push new changes to a repo (commit --> branch --> push --> merge into master) I feel dumbfounded...

    Lesson to be learned here is: don't, just don't add collaborators. If someone wants to contribute use proper git workflow. Clone, make changes, commit, issue pull-request.

    Flying-fibbing-dutchman! I feel silly.
     
    Circool likes this.
  2. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    I'm pretty new to git myself. I haven't had to issue a pull request yet, as I'm working solo, but it's definitely a little bit more of a learning curve than the other VCS's I've used (Perforce and SVN). Branches, on the other hand, I haven't used much of yet, unless they're largish features that have the possibility of being implemented wrong, or just won't pan out. But yeah, it's great that branching feels pretty seamless from master. I'd also recommend using gitkraken. I haven't shelled out money for it (yet), but it's a great GUI for navigating diffs and staging files for commit. I can then just use the command line to do the commit and push.
     
  3. PerfidiousLeaf

    PerfidiousLeaf

    Joined:
    Aug 30, 2019
    Posts:
    20
    When looking through commits I just use the gitk command for the in-built GUI. I find things are actually easier using the terminal than a GUI. The last decent GUI I used for Git was SourceTree.

    But yeah, Git, and VCS in general, is heaven on earth. I even use it for non-programming things because at it's core, it's a space-efficient, snapshot backup and restore system. At my college, there were only a minority of people who knew how to use VCSs like Git, most people hadn't been even introduced to it properly, and they're CompSci Majors!
     
    Deleted User likes this.
  4. EternalAmbiguity

    EternalAmbiguity

    Joined:
    Dec 27, 2014
    Posts:
    3,144
    commit, then branch? Sure it wasn't branch, then commit? I'm a little confused by that.

    On a previous project we kept various branches alive persistently for different ongoing tasks. We used git kraken and merged into/from development periodically. Everything was fine.

    About a week ago in gitlab's web interface I merged a branch into development. It seems gitlab takes the approach that branches are to be created and deleted for specific features, so I didn't think to uncheck the "delete branch after merge" button. Lost my branch. Tried to get it back by reverting the commit...20 minutes later I was nuking development from orbit and rebasing on a branch of a branch of development.

    But most of the time it's great!
     
  5. Deleted User

    Deleted User

    Guest

    @EternalAmbiguity You know I'm not sure about that question. Let's leave it ambiguous. :)

    Actually for the un-informed I think I was on a local branch from a new repo on my local machine so it wasn't being tracked. So maybe that had something to do with it.

    @aer0ace honestly dude if you don't use the revert or PR features you're doing something improperly. As EternalAmbiguity said, before you start work on a new feature or line of development its best to create a new branch. A single person can use Git well enough but if you do something sketchy to your project, you may have some trouble trying to apply your new changes to the remote. Been there many times, though fortunately I 'discovered' this.

    PRs are super useful. If you're looking to contribute to a project, be it open source or private, it helps to 1. make your changes in your own local repo copy, and then issue that PR so that people more acquainted with the project can make sure your code is good, what they want, etc.

    Dude tell me about it. My sophomore year I barely knew what it was, our professor introduced us to it very briefly.

    A bit of advice: unless you're going for an early internship, don't bother putting your class projects on Git. When you get to upperclassman status you'll look back on that with fondness and a bit of incredulity. "That was so simple, easy I can do that in my sleep why would anyone care about my LinkedList implementation?"

    source: personal experience :p