What makes this tool, Git, useful to the typical software developer? Why would I need this in my day-to-day work?
Answer
When I think of Git, a few key things come to mind:
Peace of mind. I know that when I use Git, I have a history of changes I’ve made to my work, and I know I can access those old versions whenever I need to. So if I break something by trying to add some new feature, I can simply revert to an older, working version of the code.
Collaboration. Working on a team with other developers means, at least in part, knowing how to use Git. It allows you to work on the same project at the same time and not interfere with each other’s work. This is possible because of branching, which you’ll learn about soon.
Production. When you’re developing any non-trivial product, you’ll likely have a production version that is available to your end users, and versions that aren’t. The versions that aren’t are where you’re testing new features, working out bugs, and making improvements to existing code. This is all made possible, or at least much easier, through Git.
Blame. Git keeps track of who wrote what and made what changes in a project. This is called blame, and it’s not a bad thing like it might sound. It can be very useful to know who worked on a piece of code so you know who to talk to about it if it needs changing or if you’re curious about how it works.
Ubiquity. Git is used practically everywhere today, and for good reason! It saves a lot of headache in the development cycle, and has become a part of almost every developer’s toolkit.
There are a lot of other reasons to learn and love Git, but that comes with experience. Happy learning!
However, if “blame” is the correct term, then people should just remember that it’s doesn’t mean anything bad. Replacing terms could be a really good way to mix up communication.
I get it, though. English has a stunning capacity for imprecision, and it does create some confusion.
When people have to remember it does not mean anything bad that is a hallmark that the wrong word is being used. That is why @dubx86 made that comment. This is the price that we pay for people thinking it is ok failing to be accurate in English.
Very true. In project management we say, “we attack problems, not people”. E.g. during a daily standup meeting instead of saying, “John wrote really bad code and we need to fix it” you’d say, “we need to refactor this section of the codebase to make it more DRY”.
I had two quick doubts. I request you to clear them out.
While a project goes live after a UAT, the Clients sometimes ask for the code-base and a thorough understanding during hand-over. Is it true that Github comes handy at that time, making it easy for the Developers to share all their work which can be publicized to the Clients only be sharing their Repo Link with the Clients? As I am just starting to know about Project-Flow controls, my point of view might not be the case.
When do the developers use Git and when do they use Github? As of now I have seen that Git is a CUI based application which colabs with Bash. How is Github different from Git?
At first it would seem more logical, but many languages do that very thing you say is ambiguous an prefer descriptive an shortness. Why I choose that example is because until you read the functions description you don’t know if it means alphanumeric or alphabetic. Even the example isshort could of been used as a boolean to see if the integer is something called a short integer.
As for Git I do find it more helpful with what you suggested.
I’m not 100% sure, so anyone who know’s the answer, please correct me if I’m wrong
I imagine step 2 to be some kind of “I think I’m done, but do check”. So basically, if we went from working directory straight to production (the git repo), there might still be issues we didn’t know about which we published to the world. That, of course, isn’t good. So, instead, when we finish working on a feature, we stage it, someone checks it, then we push it to the production repo if it was good
I’m afraid I’ve not taken the web developer course but you can start working with git whenever you like. Even if you don’t bother with some or the more advanced tools used for working with a team it’s still useful to start versioning your own code and it’s probably worth getting the hang of before getting involved with larger projects.
I feel like instead of “blame”, they should have picked “who”, since it would cover everything from “wow, who completely f’ed up this feature” to “Who came up with this more efficient and concise code?”
