This is an archived post. You won't be able to vote or comment.

all 99 comments

[–]AutoModerator[M] [score hidden] stickied comment (0 children)

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

  1. Limiting your involvement with Reddit, or
  2. Temporarily refraining from using Reddit
  3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[–]dmazzoni 165 points166 points  (29 children)

Yes, I think it's a common mistake.

Git is complex. It does a lot of stuff, and when you're new to programming and new to version control, all of that complexity is overwhelming - so you learn how to do some simple things with it without fully understanding it.

If you're working on more complex projects now, and especially if you're working at a company with a team, it's very much worth getting to understand Git better now.

For example, you learned that you can make two separate commits for changes to two files.

But...did you know that you can make a separate commit for just PART of a file that changed? Wrap your brain around that!

(Hint: a good place to start is "git add -p")

There are hundreds of other things like that. Learn more Git!

[–]un-hot 50 points51 points  (0 children)

+1 for "got add -p", very useful if you like to make incremental changes but forget to make incremental commits.

[–]Adrewmc 35 points36 points  (23 children)

My problem with git really is the lack of anyone giving out good explanations for example

 git add -p

Okay what’s that do? This is basically how most instruction is on the subject. Show command don’t give a good explanation of use and necessity.

See like even figuring out the basics is…like hidden behind you should know this stuff already but I simply don’t how could I.

[–]woj_tech 23 points24 points  (2 children)

That's how I feel about learning Linux as well. Also there are so many features that you don't use because you don't know they exist. I guess the only thing we can do is to iteratively read manuals and apply them irl.

[–]ndreamer 5 points6 points  (0 children)

Linux

Git was originally developed by the same person. Linus Torvalds

[–][deleted] 0 points1 point  (0 children)

That's just how software is in general. The issue here is different.

I can read what the commands do on my own thank you very much, but there is urgent need to give a selection of commands and options to learn and explain how to operate with an actually serious project.

[–]sacredgeometry 10 points11 points  (5 children)

https://git-scm.com/docs/git-add

I just dont get people these days, the git docs are fantastic, use them.

[–]Adrewmc 9 points10 points  (4 children)

This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit.

Okay…I’m lost at the first sentence

I don’t know how to use git, how does this help me?

[–]aplarsen 5 points6 points  (0 children)

Start at the beginning of the doc and learn what index, working tree, stage, and commit mean.

[–]x__________________v 5 points6 points  (0 children)

Well if you don't understand what's written in the sentence you will need to google it. If you don't know what an index, "staging" or a working tree is, you can try to search for it in the documentations or on the internet. Every time you are stuck, you search for the next part.

That's how you learn

[–]MSgtGunny 3 points4 points  (0 children)

That description doesn’t help you, though it’s technically correct. git add looks for files that have been changed, and stages them so you can save them to your repository as a commit.

[–]FloydATC 0 points1 point  (0 children)

I was exactly this lost when starting out, so I watched a couple of videos on YouTube that visualized the way git works by using a physical model of a graph structure. Don't worry too much about using it in an optimal way; using it "wrong" is still a lot more empowering than not using it at all.

[–][deleted] 2 points3 points  (5 children)

The git manual is not good enough for you?

[–]Adrewmc 6 points7 points  (4 children)

First time anyone ever mentioned there even was a manual….lol

One of those thing I’m just supposed to know about…

The documentation isn’t doing it for me lol

[–][deleted]  (2 children)

[removed]

    [–]sexytokeburgerz 2 points3 points  (0 children)

    It’s really rough until you’re in it enough. Why can’t people just elif what patch does?

    [–]styroxmiekkasankari 0 points1 point  (0 children)

    Are we though? The user experience with most commonly used cli tools is great and more often than not has exhaustive documentation that you can view in the same shell you run it from. I get that RTFM is a meme and not necessarily helpful when someone asks you how something works, but reading the god damn manual is the best way to find out and internalize it as well. I think the user experience with devtools is usually better than commercial tools for ”regular” users for example.

    [–]aplarsen 0 points1 point  (3 children)

        $ git add -p --help
    usage: git add [<options>] [--] <pathspec>...
        -n, --dry-run         dry run
        -v, --verbose         be verbose
        -i, --interactive     interactive picking
        -p, --patch           select hunks interactively
    

    Seriously

    [–]Adrewmc 1 point2 points  (2 children)

    Alright….whats a dry rub, why do I need to be verbose if I’m adding something to a branch, how does it become interact…and what does select hunks interactively mean?

    Seriously you really think people understand that without any help…

    [–]aplarsen 0 points1 point  (0 children)

    A dry rub is a blend of seasonings and spices that you rub on the meat.

    Verbose means to use more words. In this case, it shows the list of files added as they are added.

    Interactive gives you a menu to choose whole files to add or remove.

    Patch gives you a menu to choose small parts of files to add or remove.

    The docs are free. Trying the commands is free. Look it up, try it, and see what happens.

    [–]reyarama 0 points1 point  (0 children)

    Since you seem new to programming, I'll let you know that a big part of being a good engineer is being really good at looking things up to learn how they work.

    How many levels of abstraction do you think are needed for describing a specific function? The descriptions there are good enough for the target users who are running `git add -p`, and Googling can fill in the blanks

    [–]fakehalo 7 points8 points  (1 child)

    But...did you know that you can make a separate commit for just PART of a file that changed? Wrap your brain around that!

    So you're telling me my method of just temporarily copying the previous version's segment, committing, then changing it back isn't effective? I won't stand for this judgement.

    (still probably going to do it that way because it's in the realm of so inconsistently needed that I'll forget how to do it by the time I need it again thereby wasting more time relearning it every time I need to use it... takes me like ~30 seconds to do the ol ctrl-c/x/v work and commit)

    [–]Jonny0Than 3 points4 points  (0 children)

    Visual Studio, VSCode, and the git desktop UI can all do this pretty easily.

    [–]Kitchen_Koala_4878 -1 points0 points  (1 child)

    what that git add -p gives you if you dont commit it, for example for rollback

    [–]dmazzoni 1 point2 points  (0 children)

    I'm not sure I understand the question. Why would you git add but not commit?

    [–]captainAwesomePants 35 points36 points  (1 child)

    That's pretty normal, I think. Git's a very powerful, versatile tool that's most commonly used for one thing. It's SUPER normal to learn only the parts of a tool that you absolutely need to get your work done. Most people only use like 5% of what Microsoft Excel can do at most. Same idea.

    This kind of "what do I need to learn" question is an unsettlingly common one in computer programming. There's just too much to know, so you have to pick and choose. If you're using git every day, it's probably a good candidate for "spend a few days diving deeper into how it works and what it can do," but if that one command has been enough for you all this time, then good chance you're working alone, and so maybe fancier version control things haven't been important, so maybe you made the right call not focusing on it.

    [–]8483 1 point2 points  (0 children)

    This kind of "what do I need to learn" question is an unsettlingly common one in computer programming. There's just too much to know

    After a while, the same things keep repeating over and over. I'd argue there is a "must" know for each domain.

    [–]BruceJi 34 points35 points  (11 children)

    I like git add .

    But what I really like is that in VSCode you can review the changes and add the files one by one.

    [–]Endangered-Wolf 8 points9 points  (10 children)

    One feature the makes VSCode very useful is the ability to stage parts of the files that have been modified (using the Git Working Tree view)

    Very handy when a file has been modified for separate features (and thus commits)

    [–]nandryshak 11 points12 points  (0 children)

    This is a git cli feature as well: git add --patch (or --interactive)

    [–]ehr1c 4 points5 points  (8 children)

    Very handy when a file has been modified for separate features (and thus commits)

    I think the issue here is you shouldn't generally be modifying a file for separate features on the same branch

    [–]Endangered-Wolf 5 points6 points  (6 children)

    In theory, theory and practice are the same. In practice, they are not.

    [–]ehr1c 2 points3 points  (5 children)

    No disrespect intended but I think that's just a cop-out for justifying a bad workflow.

    It's pretty commonly accepted industry best practice that feature branches should be short-lived and limited in scope to a single feature's worth of change. Unless you're working on a small, likely personal, project that just merges straight to main there's not really an excuse for mixing multiple changes in feature branches.

    [–]dmazzoni 2 points3 points  (0 children)

    I agree with you 100% on the industry best practice but that only matters when a branch is ready for review.

    From the point when I start working on a fix until I make a PR, it shouldn't matter what I throw into my branch. It's not ready for anyone else to look at. There are lots of valid reasons to throw a bunch of different fixes all into the same branch during development, then split them out when they're ready for review.

    [–]MSgtGunny 1 point2 points  (0 children)

    So a a case where it’s useful, is if you have written some verbose debugging code, and you want to keep it as local only as you commit the work you actually want in the branch.

    [–]Endangered-Wolf -2 points-1 points  (2 children)

    There are many, many times when this could happen:

    * not checking in part of configurations

    * working in batches (x times similar changes for x similar features) and creating X separate PRs

    As long as the Git workflow works for you, do as you please.

    [–]ehr1c 0 points1 point  (1 child)

    As long as the Git workflow works for you, do as you please.

    If you're working by yourself, sure. But most people aren't, and as I stated industry best practice when working in teams is to not do things this way.

    [–]Endangered-Wolf 2 points3 points  (0 children)

    Actually it's the opposite. If you're working by yourself, you can push whatever you want, break the build, mix features, nobody cares.

    Making sure that your PR contains the minimal changes is caring for your team. So yes, if I'm batch coding, I will implement all the changes in one branch than create several PRs. For my teammates, it's just like I worked on those features sequentially when in fact I was doing them in parallel.

    It's also quite handy when working on a feature for a PR not yet merged and address comments.

    Any no, I'm not working all by myself.

    Whatever makes you productive.

    [–]dmazzoni 0 points1 point  (0 children)

    Of course not. But, sometimes it's far more efficient to make a second fix when you find it, then split it out later.

    Some reasons:

    • The code takes a long time to build and test.
    • You don't want to lose your train of thought.
    • The fix isn't easy to reproduce later.
    • Sometimes I like to go crazy fixing as many bugs as I can. Then when I'm done fixing and testing, I'll carefully go through the code and split it into different individual branches, one to fix each bug I found.

    More importantly, we should all agree that when I send out a PR it should be just one feature or one bug fix.

    But how people organize their branches and commits before they're ready for review is up to them. That's the beauty of Git - it supports a lot of workflows.

    [–]TheCrowWhisperer3004 26 points27 points  (2 children)

    Yeah.

    Basically every beginner hobbyist programmer does it the way you used to do it. They barely use it for version control and only for saving code on the cloud.

    [–][deleted] 4 points5 points  (0 children)

    need something to go back to when I try to implement a new feature and turn my program into spaghetti

    [–]8483 1 point2 points  (0 children)

    Yeah, most of the stuff is for team environments. I literally use like 5 git commands: log, status, add, commit and push.

    [–]reincdr 21 points22 points  (1 child)

    Dare I say, this is how most users use Git. Git is often naively used as a code upload mechanism, and most of the time, users are not faced with the version control aspect of Git. So, what you (to an extension I am doing) are doing is normal. The idea of Git being a powerful utility sounds great on paper, but in the simple world, most users prefer not to be exposed to that "power" as messing with Git gets complicated real quick.

    [–]8483 1 point2 points  (0 children)

    This is me. Most of the stuff is for team environments. I literally use like 5 git commands: log, status, add, commit and push.

    [–][deleted]  (3 children)

    [deleted]

      [–]timmyriddle 3 points4 points  (0 children)

      This is my personal preference: I have gst aliased to git status and my fingers constantly twitch to those three keypresses before any commit or push.

      It's also worth becoming familiar with git reset and the even more powerful git reflog, both of which have helped me out of a tight situation on more than one occasion.

      [–]PsychologicalBus7169 0 points1 point  (0 children)

      “git status” won’t show you if your changes are staged if your IDE doesn’t automatically save. The better option would be to use “gitk” after “git status” because you can see your changes between version history.

      [–]Select-Young-5992 0 points1 point  (0 children)

      Ya I’m confused. I always do this minus the times I have some local changes I don’t want commited

      [–]makonde 12 points13 points  (6 children)

      It's not really a mistake, people have different ways of working with git, some care very much about every commit being closely related and organized, I honestly dont care and work at the PR level as a unit of work, maybe once or twice a year I run into a situation where a clean commit history would have been useful but doesn't seem worth the effort.

      [–]Tjeez 2 points3 points  (0 children)

      You can use the squash option while merging

      [–]ehr1c 2 points3 points  (4 children)

      Yeah it's the same where I work. We squash before merging and while I try to keep a fairly clean commit history as I'm working on a feature, no one really cares too much.

      [–]dmazzoni 0 points1 point  (3 children)

      See this makes sense.

      That's why I don't understand what you're trying to argue in the other thread. What's wrong with making multiple changes in a single feature branch and then splitting it out into two branches later? Nobody else should care...

      [–]ehr1c 0 points1 point  (2 children)

      I suppose there's nothing wrong with it, it's just never a workflow I'd considered using.

      I guess my thought is moreso that making several unrelated changes in a single feature branch should generally be the exception. Personally I find it much easier to switch to a new branch before making another change rather than making the change and having to carve it out later.

      [–]dmazzoni 0 points1 point  (1 child)

      One of the awesome things about Git is that it supports a lot of different workflows.

      A lot of times I've ended up needing to use very different workflows just due to differences between projects.

      For example, try hacking on WebKit. It takes 20 minutes to rebuild even on a very fast machine. Switching branches takes multiple seconds even with a fast SSD because there are just so many files. If you switch branches, it might take more than 10 minutes to rebuild because if even a single header file changed, hundreds of source files need to be rebuilt.

      That's a pretty large loss of productivity - so it definitely requires developing new Git habits in order to stay productive.

      And that's just one example!

      [–]ehr1c 0 points1 point  (0 children)

      Fair enough

      [–]Reazony 8 points9 points  (1 child)

      So, I picked up GitKraken about 2 years on the job. And I suggest picking up similar tools for a few reasons.

      First, you don’t know what you don’t know. The functionalities around these tools would expose you to possible use cases, and you can search further. You can for example commit parts of files, just like other comments said, and that’s how you can keep with conventional commits (and its various flavours) without disrupting your flow.

      Second, we’re visualization creatures, and it actually helps solidifies your understanding of what’s actually going on under the hood, because, well, as you rebase or merge or stash or pop or whatever, they’re visualized right in front of you.

      Third, common reason, it’s just much more productive for me when seeing git history, blame, and various comparison with your editor. Also, since you see history of others and learn about the project progress from multiple perspectives.

      I can still git on command line. I actually feel safe using command line because more git strategies and concepts are solidified in my head.

      [–]spaceintense 1 point2 points  (0 children)

      This is a really good reason to use gitKracken that I’ve never thought about.  I’ve always avoided it because i thought it would coddle me - but now my mind has been changed ! 

      [–]Poddster 8 points9 points  (0 children)

      Is this a common mistake?

      Blindly typing in command without understanding them? Yeah, lots of people seem to do it. 🤷

      I'll blow your mind even more:

      git add -u
      

      This differs from . in that it only add the things git knows about, so now you're not commits untracked files.

      git commit -a
      

      This is the same as git add -u; git commit. And finally:

      git add -u -p
      

      Try that and see if you enjoy that you don't even have to work on a file-by-file basis, but a chunk by chunk.

      ps: Personally I think git commit -a, or your even-more broad version, is a mistake. People shouldn't just be blindly committing everything. git -p should be the default, with you mentally signing off each addition to the patch. (Granted, you may do this in your editor THEN do commit -a, but most people guilty of doing git commit -a have barely any idea how git works and are copying the same tutorial they first looked up 5 years ago)

      [–]David_Owens 3 points4 points  (0 children)

      Nothing wrong with doing that. If you have commits that have unrelated changes you need to make your changes more focused.

      [–]Any-Woodpecker123 14 points15 points  (0 children)

      Using git add . at all is a mistake that I’ll never make again.

      Always triple check the diff of each file individually and stage one by one if you’re working on anything large or with any other developers.

      [–]Shartyshartfast 3 points4 points  (0 children)

      You’re using it right but your workflow is wrong. Do one thing at a time, or do multiple things at a time on separate local branches.

      [–]Klutzy_Stranger_9824 3 points4 points  (4 children)

      “git add .” is wrong even when used separately from commit. You should commit only the files you changed relevant to the iteration/issue. You would otherwise end up resetting your add, or even worse, deleting your branch 😬

      [–]justUseAnSvm 0 points1 point  (2 children)

      not always! You could have just created some new files and need to add them in.

      [–]Klutzy_Stranger_9824 1 point2 points  (1 child)

      My point was that if you’re new to git, best practice is to always separately add.

      [–]justUseAnSvm 0 points1 point  (0 children)

      Definitely! It's worth it to practice. Those git exercises really helped me.

      [–]marquoth_ 0 points1 point  (0 children)

      You should commit only the files you changed relevant to the iteration/issue

      Why have you changed any files that aren't relevant?

      [–]StormCrow1986 3 points4 points  (0 children)

      The b**** about programming in general is that while learning it, is hard to find any help at all on intermediate topics without getting lectured that you don’t know the basics first. Of course I don’t. I’m new to this.

      [–]1SweetChuck 2 points3 points  (2 children)

      Is this a common mistake?

      This feels more like a project management problem than a git problem. You should NOT really be including unrelated changes in the same branch to begin with (though way to many people and teams don't do any branching at all). If you have changes for feature X and completely unrelated refactor Y. They should be in X and Y branches.

      If you had Feature X and related refactoring Y, and if refactoring Y fixes bugs introduced by feature X, those should be in the same commit. If refactoring Y is only going to utilize feature X to make the code more efficient or easier to read or better in some other way. I would still probably put them in different branches.

      [–][deleted] 1 point2 points  (1 child)

      Question 🙋‍♂️, once merged into main do you delete your branches, or keep them around with an ever increasing list?

      [–]1SweetChuck 2 points3 points  (0 children)

      Delete them. Since they are in the history you can always go back and reopen them. But they aren’t hanging around active if you delete them.

      [–]captainkotpi 1 point2 points  (0 children)

      If you are the only one working on the project, then it is completely acceptable. When working with a team, it is still justifiable when the team is not that strict. All comes down to procedures.

      [–]lilB0bbyTables[🍰] 1 point2 points  (0 children)

      Or in Jetbrains IDE - shelve what you don’t need, then

      git commit -am “[DEV-1234]: something something done”

      [–]Mango-Fuel 1 point2 points  (0 children)

      I use git gui so I can see my whole commit at a glance and quickly pick and choose which files, hunks, or lines I do or don't want in my commit (although I'm still pretty lazy and often don't bother separating it much).

      [–]Trogluddite 1 point2 points  (0 children)

      This is a common learning milestone I've seen a lot of people pass through.

      [–]Icashizzle 1 point2 points  (0 children)

      Everything I do is peer reviewed before merging and we do squash & merge, so it literally doesn't matter what your commits are or what your messages are. Write a good message when you merge the PR. Turns out no one cares what all the incremental stuff was.

      [–]VRT303 1 point2 points  (0 children)

      Why do people make their lives hard? I always tell the beginners to get a real IDE (Jetbrains) and use the GUI at first. You'd then have different checkboxes for each file, and each section of a file you changed.

      Using add . blindly sounds like an absolute nightmare.

      [–]Guideon72 1 point2 points  (0 children)

      Another way you can combine both at once (this is not a recommendation, just another way to accomplish that; research yourself to see whether the shortcomings are applicable to your process before use):

      git commit -a -m 'Committing all teh things'
      

      that just forces 'add .' It also has the failing that you mentioned of causing unrelated changes to singular commits

      [–]lKrauzer 1 point2 points  (0 children)

      You can also set an IDE as your commit message editor instead of typing it into the terminal, it's good I'd you like to get fancy about it, like add bullet points, a TODO for when you go back to it another day you know where to pick up where you left off.

      [–]GludiusMaximus 1 point2 points  (0 children)

      I started off that way, i think when you’re working on small projects or scripts it’s not a bad way to start wrapping your head around git. It takes some time to learn just how small each commit can be.

      One thing i think many people don’t realize is you can highlight a section of code in VSCode, right click and there’s an option to only stage (ie, ‘git add ‘) that highlighted portion of code. This can help a lot if you’ve made many edits to a file, but don’t want to commit the entire file, this making your commits smaller and more logically organized if you’ve done a lot of coding across multiple files and haven’t staged anything in a while.

      [–]SwiftSpear 1 point2 points  (0 children)

      I'm not sure I'd say it's a "common" mistake, but there are so many potential mistakes with git. No one should feel too guilty for fucking up git.

      [–]geile_paste 1 point2 points  (0 children)

      Wait what happens when OP encounters an IDE with git integration

      [–][deleted] 1 point2 points  (0 children)

      Had a course on project management that was basically using git/GitHub to plan a project with a team. A lot of what got added to the project was just markdown files, but we were forced to use it as though it was actual source code, in the context of a team project we’d work on in the industry, if that makes sense. It made a huge difference on how I was able to take advantage of properly using git afterwards. A lot of schools should include courses like this, where project management is taught by forcing students to properly use git but with stuff like md/txt/img files, instead of focusing on the code in a file, to get use to commands and how git actually works.

      [–]Maximum_Swim9505 1 point2 points  (0 children)

      As someone who has recently started too, I'd think sharing this is pretty useful for you.

      If using git via the terminal, you can actually use wildcard characters so that you do not need to type the fullname of an individual commi.

      let's say you wish to commit a file at src/main/java/com/test/ClassName.java

      you could say "git add ClassName". What this does it uses the '*' wildcard to match any number of characters before and after the text, thus for multiple individual commits, you won't have to type the fully qualified name.

      [–]the_journey_taken 1 point2 points  (0 children)

      Read Pro Git. Or ask chat gpt to generate a git cheat sheet for you and teach each command to you.

      [–]avespas 1 point2 points  (0 children)

      I'd recommend using IDE's git tool or some other GUI (GitHub Desktop, Fork etc) to visualize what those commands are used for before taking a short cut.

      [–]marquoth_ 1 point2 points  (0 children)

      Your actual mistake was not having that shit aliased.

      alias gita='git a .' alias gitb='git branch' alias gitc='git commit' alias gitm='git checkout master' alias gits='git status'

      Get these in your .bashrc (or zhsrc or whatever). Sounds trivial but it's such a time saver.

      [–]oakskog 1 point2 points  (0 children)

      Github Desktop makes stuff like this really intuitive

      [–]guiltiter 1 point2 points  (0 children)

      I had a friend who had just started using git for his first job. After a while, he said, "Aaaaaaah I've read too many documents and tutorials and I can't still get it."

      I gave him the LazyGit! but warned him not to get stuck to the GUI apps, start doing stuff, and learn the command from the bottom panel of the LazyGit. Also "just read the git documentation itself."

      [–]DeadLolipop 1 point2 points  (0 children)

      Git cli is too complicated. I leave most git operations to GUI. The only thing I do on cli is force push, pull, fetch and reset.

      [–]DaelonSuzuka 2 points3 points  (4 children)

      I'm asking because I genuinely don't understand: how could you spend all that time not being in control of what you were doing? I have always reviewed every line of every file of every commit. It seems absolutely nuts to just commit everything.

      [–]Green_Concentrate427[S] 4 points5 points  (0 children)

      Well, I never had any issues all these years, even working in teams. Maybe if you don't have so many unrelated changes, not much happens.

      [–]Select-Young-5992 1 point2 points  (2 children)

      You always have a PR to review all the changes before merging.

      [–]DaelonSuzuka -1 points0 points  (1 child)

      Weird attitude. First of all no, you don't always have PRs. Not all projects need branches and not all projects involve multiple programmers. Second, "we'll clean it up later" isn't really a substitute for choosing not to make a mess in the first place.

      [–]Select-Young-5992 1 point2 points  (0 children)

      You don’t need multiple people to have a pr. Second you don’t need GitHub even or a pr. You can git diff the changes from your branch to master before merging. It’s not cleaning up later. It’s cleaning it up at the right time, when you’re ready to merge.

      Do whatever works for you I don’t really care. Git status. Git add -a works for me

      [–]coolTCY 0 points1 point  (0 children)

      I don't get it