hate these ads?, log in or register to hide them
Page 2 of 6 FirstFirst 12345 ... LastLast
Results 21 to 40 of 114

Thread: Git - what's the consensus on best commit practice?

  1. #21
    NoirAvlaa's Avatar
    Join Date
    April 12, 2011
    Location
    Liverpool, laaaa
    Posts
    4,905
    Came into this company who'd hired a 3rd party to Dev their app... Looked at their git, each of their devs just had their own branch ("aea-branch", "noir-branch" etc) that they did everything in before merging into dev/master every week or so.

    Let them know pretty quickly how fucking terrible they all are.

    Sent from my Nexus 5X using Tapatalk

  2. #22
    FatFreddy's Avatar
    Join Date
    April 10, 2011
    Posts
    14,174
    Quote Originally Posted by Aea View Post

    Is there a specific use case where the "modular" approach makes sense?
    Agile Development
    Quote Originally Posted by QuackBot
    Pastry.. That the best you can do?
    Quote Originally Posted by NotXenosis View Post

    M8, i have discussions that spam multiple accounts, you aren't even on my level

  3. #23
    Donor Aea's Avatar
    Join Date
    April 13, 2011
    Location
    Colorado
    Posts
    14,392
    Quote Originally Posted by FatFreddy View Post
    Quote Originally Posted by Aea View Post

    Is there a specific use case where the "modular" approach makes sense?
    Agile Development
    This reminds me of an Indian "QA" Team a company I used for hired against all recommendation to the contrary. We got thousands of QA issues, they were all variations of the same trivial to fix and uninteresting UI problems.

    Like, if you typed in
    "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

    into a field it wouldn't display properly or shift the UI a bit.


    There was also an bug report with a screenshot. In the screenshot they captured big large bold red text saying "THIS IS A DEVELOPMENT FEATURE, DO NOT REPORT BUGS."

    /rant

  4. #24
    Dee Jiensai's Avatar
    Join Date
    February 23, 2012
    Posts
    341
    Quote Originally Posted by Aea View Post
    Mostly because we have an easy to reason with file structure and the raw file is what we're working with.

    If CAD used some sort of plaintext structured representation it would probably be easier to VC.

    I bet it's a giant proprietary binary blob instead.


    Sent from my iPhone using Tapatalk
    Same reason we started using AsciiDoc to write our documentation. Works well with VC.

    edit: to clarify: as opposed to use word or some shit.

  5. #25
    Donor Aea's Avatar
    Join Date
    April 13, 2011
    Location
    Colorado
    Posts
    14,392
    Quote Originally Posted by Dee Jiensai View Post
    Quote Originally Posted by Aea View Post
    Mostly because we have an easy to reason with file structure and the raw file is what we're working with.

    If CAD used some sort of plaintext structured representation it would probably be easier to VC.

    I bet it's a giant proprietary binary blob instead.


    Sent from my iPhone using Tapatalk
    Same reason we started using AsciiDoc to write our documentation. Works well with VC.

    edit: to clarify: as opposed to use word or some shit.
    Markdown all that shit. Images aren't very convenient but otherwise easy.

  6. #26
    Dee Jiensai's Avatar
    Join Date
    February 23, 2012
    Posts
    341
    Quote Originally Posted by Hel OWeen View Post
    Quote Originally Posted by Aea View Post
    Is there a specific use case where the "modular" approach makes sense?
    Not sure, that's why I'm asking. One of the articles I've read mentioned that each file change should be commited right away, not waiting 'til the feature/fix is complete. This somehow implied committing single files, what I termed " modular". Or at least I read it that way. As of now, I intuitively commit related files together. I've done this since I started using Git, without thinking too much of it. Which also seems to be what you guys are practicing.

    What I had to learn though, was to commit different changes separately.
    I think what that article tried to say was not to commit every file separately but commit changes while you are working on them. Which is good advice.
    I usually commit when I tested some part/function/view/whatever and it mostly works, before moving on to the next part.
    If I break something later, I can go back to the working version, or just show a diff easily, to see how I broke it.

    Commiting single files just because, seems rather wrong to me.

  7. #27
    Daneel Trevize's Avatar
    Join Date
    April 10, 2011
    Location
    T L A
    Posts
    12,344
    An obvious reason why the every-file-individually is retarded backwards thinking is: one runs a regex to rename a class or public variable in all places within (a portion of) the codebase. Bam, all changes were made at the same time (and tests continue to pass), there's no excuse about one file should be committed before the others for having been manually changed/saved first.
    Who can't handle having to specify a file along with a commit in order to (re)create some mixed state?
    Quote Originally Posted by QuackBot View Post
    Idk about that, and i'm fucking stupid.

  8. #28
    big diiiiiiiiick Movember 2012Donor Dark Flare's Avatar
    Join Date
    April 9, 2011
    Posts
    7,675
    Commit strategy depends on branch strategy.

    We have:
    Master
    |
    |
    V
    Dev
    |
    |
    V
    Feature/BugFix

    Create branch for feature/bugfix, commit whenever (usually EoD or when a piece of functionality goes from WIP to Actually Working), merge into Dev when feature complete, Dev into Master when Changeset complete.

    Though we're experimenting with VSTS at the mo. I quite like the integration with VS and the traceback of who made changes when and where, but it's a lot of clicks to do the above strat with it.
    Quote Originally Posted by Amantus
    whats tyhe appear of a shnitifuck cu nt eve onlio9ne corpotraTION DICKOLHEAD FUCKIN AS

  9. #29

    Join Date
    May 31, 2011
    Posts
    3,939
    Quote Originally Posted by Irrelephant View Post
    Also try to avoid needless merge commits, usually this happens if you forgot to pull before commiting your stuff.
    See, that may be part of why I'm wondering what's preferred: I'm the only developer here. I've never done development in a team, so the only one I'm annoying with my shitty commits is me.

    I'm using Gitlab though, which at first glance seems like total overkill for a sole developer, but it serves two purposes for me: 1) it's an additional backup for my source code. 2) I share documentation/change logs with my users through it.

  10. #30

    Join Date
    May 31, 2011
    Posts
    3,939
    Quote Originally Posted by Dee Jiensai View Post
    edit: to clarify: as opposed to use word or some shit.
    Given that both current OpenOffice and MS Office file formats are a bunch of XMLs wrapped in a ZIP, this works pretty well these days. But yeah - some plain text format is still preferrable.

  11. #31
    Banned
    Join Date
    April 18, 2011
    Location
    Only one here to predict a win for God Emperor
    Posts
    12,463
    Quote Originally Posted by Dark Flare View Post
    Commit strategy depends on branch strategy.

    We have:
    Master
    |
    |
    V
    Dev
    |
    |
    V
    Feature/BugFix

    Create branch for feature/bugfix, commit whenever (usually EoD or when a piece of functionality goes from WIP to Actually Working), merge into Dev when feature complete, Dev into Master when Changeset complete.

    Though we're experimenting with VSTS at the mo. I quite like the integration with VS and the traceback of who made changes when and where, but it's a lot of clicks to do the above strat with it.
    We got the same branch policy as above, except you should commit early and often to your own branch so that you know when the Continuous Integration tests fail. That greatly reduces the time and effort required to debug issues as you know exactly what (often minor) changes caused things to fail.

    Besides how slow are you that EoD commits are required? If a unit of change takes that many hours to complete you're likely doing it wrong.
    Are you an engineer? -- Quack

  12. #32
    big diiiiiiiiick Movember 2012Donor Dark Flare's Avatar
    Join Date
    April 9, 2011
    Posts
    7,675
    Quote Originally Posted by Rakshasa The Cat View Post
    Quote Originally Posted by Dark Flare View Post
    Commit strategy depends on branch strategy.

    We have:
    Master
    |
    |
    V
    Dev
    |
    |
    V
    Feature/BugFix

    Create branch for feature/bugfix, commit whenever (usually EoD or when a piece of functionality goes from WIP to Actually Working), merge into Dev when feature complete, Dev into Master when Changeset complete.

    Though we're experimenting with VSTS at the mo. I quite like the integration with VS and the traceback of who made changes when and where, but it's a lot of clicks to do the above strat with it.
    We got the same branch policy as above, except you should commit early and often to your own branch so that you know when the Continuous Integration tests fail. That greatly reduces the time and effort required to debug issues as you know exactly what (often minor) changes caused things to fail.

    Besides how slow are you that EoD commits are required? If a unit of change takes that many hours to complete you're likely doing it wrong.
    Let me introduce you to my two favourite things.
    1. Project Managers
    2. Uncontrolled spec creep
    Quote Originally Posted by Amantus
    whats tyhe appear of a shnitifuck cu nt eve onlio9ne corpotraTION DICKOLHEAD FUCKIN AS

  13. #33
    Movember 2012 I Legionnaire's Avatar
    Join Date
    April 9, 2011
    Posts
    1,714
    We're a pretty small team atm (5) and use rebasing as our strat. Basically, check a new branch out from master for your feature, rebase on to any extant branches in development that you have dependencies on and go about your business. Rebase early & often, and squash your commit down to one after your PR is approved. There should only be merges into master, nowhere else.

    It's a workflow that almost assuredly doesn't scale well, but it's pretty nice for now.

  14. #34
    Donor Aea's Avatar
    Join Date
    April 13, 2011
    Location
    Colorado
    Posts
    14,392
    It's far easier to branch from develop isn't it? Otherwise what you're describing isn't all that unusual.


    Sent from my iPhone using Tapatalk

  15. #35
    Daneel Trevize's Avatar
    Join Date
    April 10, 2011
    Location
    T L A
    Posts
    12,344
    Wait, didn't anyone link this yet? http://nvie.com/posts/a-successful-git-branching-model/
    Quote Originally Posted by QuackBot View Post
    Idk about that, and i'm fucking stupid.

  16. #36
    Specially Pegged Donor Overspark's Avatar
    Join Date
    April 10, 2011
    Location
    NL fuck yeah
    Posts
    3,272
    Quote Originally Posted by Hel OWeen View Post
    Quote Originally Posted by Irrelephant View Post
    Also try to avoid needless merge commits, usually this happens if you forgot to pull before commiting your stuff.
    See, that may be part of why I'm wondering what's preferred: I'm the only developer here. I've never done development in a team, so the only one I'm annoying with my shitty commits is me.

    I'm using Gitlab though, which at first glance seems like total overkill for a sole developer, but it serves two purposes for me: 1) it's an additional backup for my source code. 2) I share documentation/change logs with my users through it.
    Everything I code is in git, even if no-one but me will ever see it. Hell, even a large part of my homedir is in git.

    If I don't use a vcs I have the tendency to comment old code and leave it lying around "because I might need it at some point in the future" and obviously I rarely do. Having a vcs allows me to rigorously remove stuff the minute it becomes superfluous and keep everything nice and tidy. Also looking back to see when and why you did something can be a major help in tracking down misbehaving code. git blame is obviously nicest in a team environment to see who made what, but it's also useful to see which lines went in at the same time.

  17. #37

    Join Date
    April 16, 2011
    Posts
    269
    I work primarily alone but still use a VCS for the reasons Overspark stated. I use Mercurial however, so all this rewriting history sound strange to me as you can't do that (easily) in Mercurial. I like being able to see how I got to somewhere but maybe that becomes too cluttered when a lot of people are working on a project.

  18. #38
    Banned
    Join Date
    April 18, 2011
    Location
    Only one here to predict a win for God Emperor
    Posts
    12,463
    Quote Originally Posted by Renox View Post
    I work primarily alone but still use a VCS for the reasons Overspark stated. I use Mercurial however, so all this rewriting history sound strange to me as you can't do that (easily) in Mercurial. I like being able to see how I got to somewhere but maybe that becomes too cluttered when a lot of people are working on a project.
    The decision to thrash how you got to a place is all up to you in git, you don't need to delete the history if you don't want to. The power of git is how easy it is to change, to transform your branch into something else, something that is less ugly and more likely to be merged.
    Are you an engineer? -- Quack

  19. #39
    roigon's Avatar
    Join Date
    May 23, 2012
    Location
    c4mel, Ostingele
    Posts
    1,690
    I don't do EOD. I get the practice, but I just can't be arsed, it would be like committing my train of thought and then magically resuming it the next day. Yeah sure, soft reset and force push, but I just can't be arsed. If the code I write is so important that half a days worth of code is irreplaceable then they probably just get backup software instead of using the vcs as a backup.

  20. #40
    FatFreddy's Avatar
    Join Date
    April 10, 2011
    Posts
    14,174
    Quote Originally Posted by Aea View Post
    Quote Originally Posted by FatFreddy View Post
    Quote Originally Posted by Aea View Post

    Is there a specific use case where the "modular" approach makes sense?
    Agile Development
    This reminds me of an Indian "QA" Team a company I used for hired against all recommendation to the contrary. We got thousands of QA issues, they were all variations of the same trivial to fix and uninteresting UI problems.

    Like, if you typed in
    "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

    into a field it wouldn't display properly or shift the UI a bit.


    There was also an bug report with a screenshot. In the screenshot they captured big large bold red text saying "THIS IS A DEVELOPMENT FEATURE, DO NOT REPORT BUGS."

    /rant
    I'm amazed
    Quote Originally Posted by QuackBot
    Pastry.. That the best you can do?
    Quote Originally Posted by NotXenosis View Post

    M8, i have discussions that spam multiple accounts, you aren't even on my level

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •