What are the top 3 things you wish you knew when you were getting started with Git and GitHub?

GitHub Help How to use Git and GitHub
#1

Hi Community Members :wave:

Excited to have you here! I’m Angela, one of the Program Managers here in the Community. We know getting started is hard and we also know we have some very knowledgeable experts in this Community. :rocket:

I’d love to gather some tips around what you found helpful when you were getting started to help those getting started now. :grinning_face_with_smiling_eyes:

We know this is a hot spot where we get tons of activity and we are trying new things to help. I’m open to new ideas on how we can help, let’s start with this topic.

What did you find most helpful when you were getting started?

13 Likes
#2
#5

When I first started, I would make a bunch of commits with rather meaningless commit messages. This would make it hard for me to find a good commit in my code to go back to if things went awry :grimacing:

I have only recently started making fewer changes between each commit and more meaningful commit messages. The message is not super long, but it does better convey what this change does.

13 Likes
#6

Here are some tools I wish I was aware of when I first started with Git.

Oh-My-Zsh for os X
A popular plugin framework for ZSH, and it comes with many built-in plugins and themes

Chocolatey package manager for Windows

These tools allow you to customize your terminal environment for a way more enjoyable experience when using the command line.

5 Likes
#7

I wish I had known (or found confusing):

  1. What a pull request was for (tl;dr answer: “Here are the changes I’d like to propose. Do you accept?”).
  2. You can use Git without using GitHub. I probably shouldn’t say that on the GitHub Community forum, but at first I didn’t realize that GitHub is based on Git.
  3. There are multiple tools that will allow you to create and commit to Git repositories without using the command line (although I personally like the command line). Many IDEs have built-in version control configuration. Also, GitHub Desktop lets you get used to how Git works using a GUI interface.

What I found helpful:

  1. Going through the workflow over and over (make a change, stage the change, commit, push to GitHub) until I internalized the flow
  2. Playing around (creating test repositories, playing with things like GitHub Pages, Actions, the API, etc.). You’re not going to break anything.
  3. Getting used to pull requests by…opening pull requests! Even if you’re the only contributor to the repo, it’s helpful to learn that flow as well. Also, they keep things organized! Not only is every change documented, by any discussion around the why of the change is also preserved.
14 Likes
#8

I absolutely agree with everything that’s already been highlighted above, but :point_up: I wish I had known that it really is hard to break anything by practicing.

I found the Learning Lab and free Udacity courses on Git super useful when I was starting out as well:

Lastly, never be afraid to ask. Everyone had to start at some time, so checking for prior solutions in the Community is a great resource.

7 Likes
#9

I started out in VS Code, so perhaps my experience is a little different. Here are the things that I found confusing …

  1. Because some items are untracked, there is a difference between the (local) repo and the (local) folder it is in.

BUT adding an existing file to .gitignore doesn’t make the file untracked. AFAIK, there is no way to make a tracked file untracked.

AND there is no way to create an untracked file on github, because there is no “save” button, just a “commit” button.

  1. I still find it confusing that I can log VS Code into github but I have to explicitly define a global user name and email.

2.5) When you create a new repo on github, it gives you a set of possible command sequences to link a local repo to the newly created github repo. These command sequences are wrong, since they do not include the step of defining a global name and email.

  1. Most tutorials won’t help you (or to be precise, me) since they deal with the case of cloning an existing repo, not creating one on your local machine and pushing it to a new repo on github.com

  2. The documentation for “git foo something something” is called “git-foo”, not “git foo”

4.1) The documentation for “git foo something something” will not distinguish the simple case – the caser you want – from every other case.

4.2) The documentation for “git foo something something” will use the term “refspec” Its meaning is ineffable.

4.3) If you get lost within the git man pages, you can find the way up at the bottom of the page.

  1. Creating a profile page by creating a repo whose name is your user name is not as complicated as it sounds. In fact, it is not a tenth as complicated as it sounds.

  2. AFAIK, there is no way in Markdown to refer to a file in another of your own repos except by using its full URL.

6.5) If my user name is dux and I have a repo foo containing a file some.txt, the url for the file is NOT github.com/dux/foo/some.txt

  1. AFAIK, there is no way to configure the “home page” of a repo so that someone sees the README first and not a pageful of commits.
5 Likes
#10
  1. git stash pop I wish I knew that I could “pop” my stash. I use that often when I accidentally start writing code on the wrong branch.
git stash
git checkout develop
git pull
git checkout -b feature-foo
git stash pop

  1. git commit --amend

  2. git remote: When I started, I would create a new repository and clone. I didn’t know what a remote was. Nowadays, tend to create my project locally with git init and git remote add origin. Useful for having multiple remotes as well, e.g., origin and upstream

5 Likes
#11

My workflow has also moved to creating a local repo first and then connecting to a remote. It was a little tricky to learn at first, but has become my preferred way of doing it.
It’s even more fun with the GitHub CLI

You can do something like the following for creating a repo from the command line:

# create a repository under your account using the current directory name
$ gh repo create

# create a repository with a specific name
$ gh repo create my-project

# create a repository in an organization
$ gh repo create cli/my-project

I don’t use stash at all. Having looked into what it can do, it looks like quite the useful tool within git. Thanks for the tip!

4 Likes
#12

This is a great question. I have several but for a top 3 these are the best practices that come to mind. I’ll also include a list of some resources that made a big impact and ones I wish I had from the beginning.

Best practices

  • Commit structure - When first working in Git I would make two mistakes that made it difficult for collaboration and iterations. My commit messages were ambiguous or something meaningless like, “Update file”. There were a handful of times I needed to recall a commit and I couldn’t remember which commit it was and my commit message was useless. The second was making small, bit-sized commits. It was frustrating to revert a change introduced in a commit but find out that that commit contained changes completely unrelated to each other. Large commits are messy, hard to review, and create complications down the road. Commit early and often!

  • Opening a pull request as early as possible - When I first started, I would wait until I had made all of mange changes before pushing them to GitHub and opening a pull request. Perhaps it was fear of others looking at an incomplete set of changes or something else, but with almost every pull request I make, even today, I make changes based on the collaboration from others and feedback I receive. Receiving this feedback early in the process often reduces rework that can be avoided.

  • Viewing local changes across working, staging, and history with git diff - This is one I use all the time and something I didn’t learn/use for a while after getting started. It’s incredibly helpful when crafting commits when you’ve made several changes in a file but only want to commit certain ones. This gives you the visibility into what is currently in your working and staging areas. This goes well with the command git add -p or git add --patch which lets you move some changes of a file to the staging area while keeping other changes in the working directory.

diff-options
diff-options1540×778 30.2 KB

Resources

There is so much information available. It was hard for me to filter through resources that contained real-world best practices and easy to understand application. Here are a few I wish I knew from the beginning:

4 Likes
#13

Thanks for sharing your experience here! It sounds like some of these are unresolved issues for you. I would encourage you to take a look around the forum, as other users have run into similar situations.

If you can’t find just the right answer to any of these questions, then it would be great to create a new post in the appropriate category. It is best to make a separate post for each question in order to keep a narrow focus in the thread.

2 Likes
#14

Hi @djbreen7 :wave:

Thanks so much for sharing your top 3 things you wish you knew. :tada:
Those are very helpful!

3 Likes
#17

This is a great topic! :star_struck:

Apologies for the shameless plugs that this will contain…

  1. The staging area. My mental model of Git history is relatively linear, but the staging area, and its relationship to HEAD create another dimension. The staging area allows you to really CRAFT commits, rather than “check-in” based on time. You can see me explain it in my own words here: Git & GiHub: Saved Changes - YouTube
  2. REMOTES! Git is distributed, and this also adds complexity to my mental model! I could understand a bunch of branches pretty quickly, but the complexity scaling from that once it’s all happening on remotes was also like adding another dimension. More videos for those interested: Git & GitHub: Working Locally - YouTube, and Git & GitHub: Cloning & Working Locally - YouTube.
  3. Play around and break stuff - but COMMIT them first. I’m sorry I don’t have a video to share here, but do some research on git reflog. As long as you have committed your work, and you don’t delete your repo, you’ll be able to get it back with git reflog. Use Git with less stress, knowing that as long as it’s committed, you can get it back. (Sorry, no video on this…yet!)
4 Likes
#19

This post was flagged by the community and is temporarily hidden.

1 Like
#20

When getting start with Git and GitHub, I wish I knew the importance of creating descriptive commits. Back when I just started using Git, I would make a bunch of commits with either duplicating summaries or names. At the time I thought it was okay, but after running into issues and needing to refer back to old commits, it came evidently clear that this is not a good practice. Without descriptive commit messages, I was left scraping through old code to see what was changed, which takes way more time to do compared to summarized messages :slight_smile:

4 Likes
#21
  1. That as an average, mostly RIGHT-brain user, I had easier (more obvious) ‘user -friendly’ directions. - after receiving the github email with your requests, I looked/ tried for some 10 minutes on where to enter my ‘reply.’ … Only then, did I think of ‘logging in,’ in case maybe there was the need for it. - Only THEN did I see the Reply Arrow.
  2. Mostly a conceptualist Entrepreneur, (used to be a theatre and film director) I have been working on a Niche-Market part e-commerce, part social, Community oriented web-site. A wiser person last year suggested (for safety) I open an account with Github and have my developers down-load the site in an account. In case I lost any files, should I change Hosts during a Transfer, I would have my GitHub files safe & sound allowing for a FULL BACK-UP of all files! / The worst happened! A transfer became a botch-up, and I gave the new Devs entry to my Git-Hub Account! / Only THEN was I told they did NOT contain the DATABASE! / i.e., I did NOT have a full site recovery and still paying new Devs to recreate the the whole site! /
  3. When this Nightmare occurred, I looked to GitHub to Team up with an honourable/ affordable PHP & JS Coder. … I never managed to put the request out properly! i.e. again, to this conceptualist luddite, do not know what I did wrong?
#22

This post was flagged by the community and is temporarily hidden.

#23

Haj, Ďakujem, a oceňujem,

#24

Hey every1ne,

First of all, Thanks to everyone for these wonderful messages/experiences! The following comment is about my young and fresh experience. I am still a student in Computer Science (master’s level).

About Git: During my First year I wish I knew how to well-managed rebase/fixup/ammend approaches! My school taught us how to do the basis with create/remove/rename branches - merge and resolve conflicts / having a good git flow commits and all the stuffs to run project between students! However, the use of Rebasing is very helpful and make you gain in productivity, I am using them daily at my placement.

  1. Rebase Approach.
  2. Fixup management.
  3. Ammend command.

About Github: I have performed numerous group project throughout my BSc in Computer Science, and in my experience, Pull Requests would have been very useful for branch management and all that stuff. As we were not much experienced, we did not know the benefits that it gives! After discussions and placements, we have all agreed that Git Pull Request, is the most useful tool to use for a group projects (university at least).

  1. Pull Request and his powerful implementation in @Github .

Hope it helps for your study ! see you guys.

Simon. :microscope: Looking for a PhD - Here’s My LinkedIn - Here’s My Twitter

#25

Incase it’s useful, I tend to prefer apply to pop as it allows me to retry if the result is a conflict.

2 Likes