hate these ads?, log in or register to hide them
Page 1 of 6 1234 ... LastLast
Results 1 to 20 of 114

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

  1. #1

    Join Date
    May 31, 2011
    Posts
    3,180

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

    I've been using Git now for a while. Initially all through a GUI, meanwhile proficient enough to do the standard tasks from the command prompt.

    That said I'm still unsure what "the world out there" considers to be good commit practice. I'm struggling with what I would described as modular commits vs. logical commits.

    To illustrate: say I change something that i.e. adds another SELECT CASE (that's SWITCH in C) case and code to handle it in two different methods. Let's say the number of changed files here involves 3: a header where a new THIS_NEW_CASE constant is defined. And 2 physical files in which the above mentioned 2 methods reside.

    So, what do I commit then? All three files in one commit (=logical commit). Or each of the three file in a separate commit (=modular commit)?

    I recon that there might not be one silver bullet. But I'm confident that in general there's a preferred way to commit.

  2. #2
    roigon's Avatar
    Join Date
    May 23, 2012
    Location
    c4mel, Ostingele
    Posts
    1,690
    Personally I prefer commits that I can cherry pick and reverse without breaking things. So I'd say logical commit if that's what it's called.

    Sent from my XT1068 using Tapatalk

  3. #3

    Join Date
    May 31, 2011
    Posts
    3,180
    Quote Originally Posted by roigon View Post
    [...] logical commit if that's what it's called.
    No, I don't think it's called that way. That's just my made-up-on-the-spot term.

    Forgot to add: of course, I tried searching the web before posting. But there are tons of git commit best practice articles out there. But a big part of them deals with git commit messages, which is different topic altogether. As for the rest: it's hard to tell if the author knows what he's talking about or a Git noob like me talking out of his arse ...

  4. #4
    Donor Aea's Avatar
    Join Date
    April 13, 2011
    Location
    Colorado
    Posts
    13,525
    I've been using git for nearly a decade and I can't even imagine why you wouldn't have that as one single commit. In fact I've never seen it done the other way.

    This gets into a much more complicated discussion about the nature of rebasing, merging, and branching practices when you have multiple people simultaneously hammering on a feature. But that's on a larger scale than this.

    Is there a specific use case where the "modular" approach makes sense?

  5. #5

    Join Date
    April 13, 2011
    Posts
    5,199
    That kind of thinking is a hangover from terrible source control systems like clearcase. A commit should reflect a state change to the entire repository, not to individual files.

  6. #6

    Join Date
    May 31, 2011
    Posts
    3,180
    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.

  7. #7

    Join Date
    April 13, 2011
    Posts
    5,199
    Quote Originally Posted by Hel OWeen View Post
    ...One of the articles I've read mentioned that each file change should be commited right away...
    This is a valid approach. With a small caveat. Remember all repos are equal. Your local copy is a repo as much as the copy on the remote repo is a repo. Personally, I commit frequently (e.g. whenever a new test passes) and then use rebase to collapse those commits down into one fully functional commit before it's pushed up to the remote for others to use. This is much more about your branch/merge strategy than it is about committing. The end result of a commit, as seen by others, being a full-repo change in functionality doesn't change.

  8. #8

    Join Date
    June 6, 2011
    Posts
    548
    Quote Originally Posted by Hel OWeen View Post
    So, what do I commit then? All three files in one commit (=logical commit). Or each of the three file in a separate commit (=modular commit)?
    What you call logical commits is commonly referred to as atomic commits, except for working in a private branch this is best practice. As already mentioned it makes reverting/cherry picking much less error prone. Also keeps the commit history nice and tidy. In a private branch you can do as you please as long as you rebase before pushing your work back into non-private branches.

    Also try to avoid needless merge commits, usually this happens if you forgot to pull before commiting your stuff. Remember, unless you already pushed you can always fix your commits if you forgot. Merge commits always create a non-linear commit history, with a couple of lazy devs that just merge commit all day you end up with a commit history looking like a Picasso painting. At my workplace we have a 5€ fine if you get caught with a needless merge commit.
    “The first gulp from the glass of natural sciences will turn you into an atheist, but at the bottom of the glass God is waiting for you.”
    ― Werner Heisenberg

  9. #9
    Donor Aea's Avatar
    Join Date
    April 13, 2011
    Location
    Colorado
    Posts
    13,525
    Quote Originally Posted by elmicker View Post
    Quote Originally Posted by Hel OWeen View Post
    ...One of the articles I've read mentioned that each file change should be commited right away...
    This is a valid approach. With a small caveat. Remember all repos are equal. Your local copy is a repo as much as the copy on the remote repo is a repo. Personally, I commit frequently (e.g. whenever a new test passes) and then use rebase to collapse those commits down into one fully functional commit before it's pushed up to the remote for others to use. This is much more about your branch/merge strategy than it is about committing. The end result of a commit, as seen by others, being a full-repo change in functionality doesn't change.
    I've honestly ever seen this extreme mandated in places that are super micromanage-y and don't trust their engineers. I feel it's okay to do locally if it fits your workflow.

    If you aren't finished with a feature you commit something WIP at the end of the day. Then when you're ready to merge into develop you squash (i.e. `git rebase -i HEAD~N`) your changes into one logical changeset. This also eliminates all of the interim commits that are not interesting (e.g. the fixed a bug, changed a value, etc.).

    This gets complicated when you have multiple people working on the same feature, in which case you need to rebase carefully to preserve attribution or have sub-branches.

    There's always this balance between a clean mainline history and being able to do "archeology" and tie a commit to an individual, decision, etc.

  10. #10
    roigon's Avatar
    Join Date
    May 23, 2012
    Location
    c4mel, Ostingele
    Posts
    1,690
    Quote Originally Posted by Irrelephant View Post
    with a couple of lazy devs that just merge commit all day you end up with a commit history looking like a Picasso painting.
    I see you've met my co workers.

    At my workplace we have a 5€ fine if you get caught with a needless merge commit.
    This sounds like sound advice.


    Many of my co workers are used to svn and merge all day is their motto, In fact, the idea that a local branch might not even be named the same as the remote one is seen as sinister magic, and everyone is again and again baffled when the local version of their remote branch is behind.

    personally I've given up trying to explain.

  11. #11
    Specially Pegged Donor Overspark's Avatar
    Join Date
    April 10, 2011
    Location
    NL fuck yeah
    Posts
    2,983
    Commit early, commit often! That said, don't commit something just because it's the end of the day, commit whenever you've achieved something that (usually) still works. Best to test it locally before you commit it, but depending on environment that's not always possible. Sometimes you'll want to break up a bigger change that breaks stuff in-between, just so you can point to the individual steps you needed to take to get it working again in it's new shape.


    Also, one git command not everyone is aware of but can make your commits a lot better is:

    git add -i file

    This will give you a somewhat spartan interface (read the manual! git help add, "Interactive mode") where you can choose which bits of the changes you just made will be added to the next commit.

    Say you've started editing in one file and encountered a couple of different things that you changed, which don't have a lot to do with each other. You can push it as one big commit but that's ugly and difficult to merge or revert if only one change turns out to be a bad idea. With add -i you can choose which bits of the changes you want to add and which bits you'll leave behind for the commit after. So even though your git log won't necessarily reflect the order in which you made the changes it'll be a much more fluid and easier to read log of small but coherent changes, that are easily merged or reverted individually.
    Last edited by Overspark; August 24 2016 at 06:04:43 PM.

  12. #12

    Join Date
    June 6, 2011
    Posts
    548
    Quote Originally Posted by roigon View Post
    Many of my co workers are used to svn and merge all day is their motto, In fact, the idea that a local branch might not even be named the same as the remote one is seen as sinister magic, and everyone is again and again baffled when the local version of their remote branch is behind.

    personally I've given up trying to explain.
    Yea, sadly most people that use git have a lot of misconceptions about it. Don't give up or things won't improve! I'd push for a git workshop where you teach your team the inner workings of git. Once they understand that each repo is just one giant sea of commits connected via parent/child relations and that branches are just pointers to a single commit you will (hopefully) see some light bulbs over their heads.

    https://wildlyinaccurate.com/a-hackers-guide-to-git/ is really good for preparing an in-depth workshop btw.
    Last edited by Irrelephant; August 24 2016 at 06:32:21 PM.
    “The first gulp from the glass of natural sciences will turn you into an atheist, but at the bottom of the glass God is waiting for you.”
    ― Werner Heisenberg

  13. #13
    roigon's Avatar
    Join Date
    May 23, 2012
    Location
    c4mel, Ostingele
    Posts
    1,690
    nah, i've given up.

    In fact just on discord I was talking about my job and I realized it's definitely time to leave. Other non-git related reasons mostly though. But just to give a git related thing I have to put up with. Because of some reason I had no say in, our project group is using branch-x as our development branch, while TRUNK (if you will) development happens on the development branch, vaguely using git-flow.

    This one dev, every fucking time, makes his feature on the development branch. I think it's now literally been the 6th time I've told him, and his solution has always been to merge branch-x into his feature branch and call it a day. I've just mentally given up and now just cherry pick his commits and hope for the best.

  14. #14
    Donor Aea's Avatar
    Join Date
    April 13, 2011
    Location
    Colorado
    Posts
    13,525
    Quote Originally Posted by roigon View Post
    nah, i've given up.

    In fact just on discord I was talking about my job and I realized it's definitely time to leave. Other non-git related reasons mostly though. But just to give a git related thing I have to put up with. Because of some reason I had no say in, our project group is using branch-x as our development branch, while TRUNK (if you will) development happens on the development branch, vaguely using git-flow.

    This one dev, every fucking time, makes his feature on the development branch. I think it's now literally been the 6th time I've told him, and his solution has always been to merge branch-x into his feature branch and call it a day. I've just mentally given up and now just cherry pick his commits and hope for the best.
    https://dev.ghost.org/prevent-master-push/

    But the dev in question probably gives zero fucks about your opinion and process so that's probably the bigger issue that a client-side hook won't address.

    Quote Originally Posted by Overspark View Post
    Commit early, commit often! That said, don't commit something just because it's the end of the day, commit whenever you've achieved something that (usually) still works. Best to test it locally before you commit it, but depending on environment that's not always possible. Sometimes you'll want to break up a bigger change that breaks stuff in-between, just so you can point to the individual steps you needed to take to get it working again in it's new shape.
    EOD ensures that you don't lose any work if your machine goes kaput the next day or if somebody needs to pick your work up if you're sick, etc. It doesn't need to be production quality or even working, as long as it's in non-mainline branch you're okay pushing broken code IMHO.
    Last edited by Aea; August 24 2016 at 07:11:33 PM.

  15. #15
    Specially Pegged Donor Overspark's Avatar
    Join Date
    April 10, 2011
    Location
    NL fuck yeah
    Posts
    2,983
    Quote Originally Posted by Aea View Post
    Quote Originally Posted by Overspark View Post
    Commit early, commit often! That said, don't commit something just because it's the end of the day, commit whenever you've achieved something that (usually) still works. Best to test it locally before you commit it, but depending on environment that's not always possible. Sometimes you'll want to break up a bigger change that breaks stuff in-between, just so you can point to the individual steps you needed to take to get it working again in it's new shape.
    EOD ensures that you don't lose any work if your machine goes kaput the next day or if somebody needs to pick your work up if you're sick, etc. It doesn't need to be production quality or even working, as long as it's in non-mainline branch you're okay pushing broken code IMHO.
    Well that only works if you push it to a repo on another machine. Which means you can't rewrite the history any more, unless you force push which you should never do in the first place. So it'll give you a git log full of broken commits, or extra work to tidy things up, just because you're afraid of something that shouldn't happen in the first place and shouldn't matter if it did due to backups. Sounds quite undesirable IMHO.

  16. #16
    Donor Aea's Avatar
    Join Date
    April 13, 2011
    Location
    Colorado
    Posts
    13,525
    Quote Originally Posted by Overspark View Post
    Quote Originally Posted by Aea View Post
    Quote Originally Posted by Overspark View Post
    Commit early, commit often! That said, don't commit something just because it's the end of the day, commit whenever you've achieved something that (usually) still works. Best to test it locally before you commit it, but depending on environment that's not always possible. Sometimes you'll want to break up a bigger change that breaks stuff in-between, just so you can point to the individual steps you needed to take to get it working again in it's new shape.
    EOD ensures that you don't lose any work if your machine goes kaput the next day or if somebody needs to pick your work up if you're sick, etc. It doesn't need to be production quality or even working, as long as it's in non-mainline branch you're okay pushing broken code IMHO.
    Well that only works if you push it to a repo on another machine. Which means you can't rewrite the history any more, unless you force push which you should never do in the first place. So it'll give you a git log full of broken commits, or extra work to tidy things up, just because you're afraid of something that shouldn't happen in the first place and shouldn't matter if it did due to backups. Sounds quite undesirable IMHO.
    If you're the only one in a branch you can push there and squash and force push is NBD IMHO. If you're not you can commit ready changes to that branch and make a -name branch for your own "staging" work.

    No amount of backups in the world will save you when somebody can't reach their code (i.e. the hit by a bus scenario) and it's needed promptly. Backups take time to restore, etc.

    I just see no reason to have code lingering around uncommitted in a team environment.

  17. #17
    Donor erichkknaar's Avatar
    Join Date
    April 9, 2011
    Posts
    8,451
    You should totally save your work to a server as often as possible, but as one of my hats is technical lead on a big system, I have to view anything that touches the head of the mainline/trunk/develop/whatever you call it branch as coming in as a single cohesive feature that a decision to include in the bigger picture can be made about.

    We implement this through developer branches or feature branches with developer offshoots, that eventually flow back to trunk. I don't care what you do in there as long as what gets shipped to the trunk and eventually into the release describes a change that is encapsulated in that single commit to the trunk. I would urge you to check in your work as often as possible there in whatever state its in to avoid the inevitable laptop shitting itself event.
    meh

  18. #18
    מלך יהודים Zeekar's Avatar
    Join Date
    April 10, 2011
    Posts
    14,516
    While reading this thread I realized how lucky software engineers are with their version management systems. Try using VC for CAD files. It makes you cry


    

  19. #19
    Donor Aea's Avatar
    Join Date
    April 13, 2011
    Location
    Colorado
    Posts
    13,525
    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

  20. #20
    מלך יהודים Zeekar's Avatar
    Join Date
    April 10, 2011
    Posts
    14,516
    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
    Thats a gigantic bingo.

    All though 2D cad apparently has some text representation but not everybody adheres to it. And also only retards use only 2D CAD nowadays.


    

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
  •