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

Bit late to the party, but I wish I had learned properly what “rebasing” is exactly a bit earlier down the line… It took me so long to figure it out while it’s useful to me now.

What I loved (and actually still do very much) about GitHub is that it provides that visual assistance in the form of a handy GUI when it comes to my Git repository - it’s something else than the command line over and over. I know there are other tools out there that run locally, but GitHub proves to be sufficient for my needs.

Oh, and also that I can easily check a bit of code out from my phone or (more often) iPad is pretty neat!


The one thing I wanted was better documentation.

Having used other source code control systems, I understand the value of SSC.

I first encountered Git and Git Hub while working on a team project, part of a college course for a Master. Several knew OF Git and Git Hub was just a source for code we could base a project on.

A Computer Science Club talk on GIt from an undergrad CS major who had just finished an internship explained Git calls and arcane switches, but not how to use Git and Git Hub. He also had been inculcated into the guild of “Command Line Only” wonks. His responses to why the command line was better boiled down to that was how everyone, where he worked, did it, and doing it differently was looked down upon.

Another project had a teammate who explained the rudiments of GIt Hub but next to nothing about Git. He -said- he explained Git but I did it want to learn. What he explained was commands but not showing me how to do what I wanted to do.

1 Like
  1. Branches aren’t magic, they’re just pointers (or links, if you prefer) to commits. Switching between them doesn’t change anything else, and their names don’t mean anything to Git either.

  2. git checkout can do so much more than just switch and create branches. I get any file at the state of any commit. In practice I most often use that latter option to reset a file to the last committed state if I decide to discard changes, but it’s also useful in debugging or restructuring commits.

  3. git stash, already mentioned above. It’s very useful to be able to just put WIP aside for later.

Honorary mention for one I learned fairly early, but it doesn’t seem to be common knowledge: git add -p. You can choose which changes within a file you want to stage for the next commit, and which not. For example when you made some changes you want to commit but also added a few debug messages that should stay local for now. :slightly_smiling_face:


Me resultó y me resulta muy útil para ver los ejercicios y demostraciones de mis instructores en la plataforma de free code camp y Udemy, por ejemplo.

1 Like

Hi @rodnaph :wave: Welcome! Thank you so much for providing your insight!!

Hi @Wolvie74 :wave: Thank you for being here and sharing what you found helpful. :tada:

1 Like

I wish I knew more on basic codes and HTTP, API, etc.

I’m new at this and teaching myself.

1 Like

Hi @BeautifuldiasterCreations :wave:

Thanks for sharing! Was there anything specific about those topics that you find challenging?
I would be happy to point you towards some other resources or forum topics that address that information.

1 Like


  • git rebase allows you to execute a command for each commit, such as git rebase HEAD~5 -x "git commit --amend --no-edit --reset-author". This is useful if you made several commits on a PR branch with a wrong email address and want to correct that quickly without having to resort to filter branches.
  • git cherry-pick has a --strategy-option (-X) to favor the source or the target for all conflicts.
  • In the rare case that you want to interactively rebase commits including the initial commit, you can use git rebase -i --root <ref>. It’s not possible to achieve this using the root commit (empty tree object) with hash 4b825dc642cb6eb9a060e54bf8d69288fbee4904.


  • You can not only change the title of a PR, but also change the target branch of an existing PR. No need to close the PR and create a new one with another base branch.
  • If you change the base branch when you are about to create a new PR, it clears all of the following: reviewers, assignees, project, milestone. This gets me every so often because I realize too late that the target branch isn’t the right one.
  • There is no option to create a new project board in the + icon dropdown menu in the top right when you are looking at a repository. If you want to create a board bound to your account, then you need to go to the homepage or your user profile page. To add a project to a repository, you need to go to the Projects tab of that repo.

Thank you, @Simran-B :tada: for sharing those tips.


Top 3 things I wish I knew!

  1. Everyone has Git Problems: Sounds funny but true, I use to beat myself up about pushing and pulling my commits, I always had errors, sometimes I still do. This concept basically applies to even programming, googling stuff is no sin. With practice, you get used to solve those errors.

  2. A TL;DR section for creating repositories, pushing and pulling your code, just a generic straight workflow. This will really help than a cheatsheet

  3. Starting I did not know and understand you can redo commits so I kept deleting and starting afresh,lol.


Especially if it’s not the latest commit that can be changed with --amend! It takes a while to understand all the options and to get the hang of interactive rebase for instance.

I still get confused what changes are “theirs” and which are “ours” sometimes, because it can be counterintuitive, such as when doing a pull --rebase.


Thanks so much for sharing @Ruth-ikegah :tada: It’s true everyone does have Git problems :blush:

1 Like

What I wish I knew when I was just getting started with Git & GitHub :tipping_hand_man:

  • On a Mac, once Git is installed, it can be “called” upon using a command line application, like the Terminal. While there is no Application Icon for Git, there are several graphical user interfaces of varying capabilities. My personal favorite is GitHub Desktop, though there are several others to choose from depending on your needs.
    • Aside: I learned how to use the command line via Zed Shaw’s The Command Line Crash Course. The knowledge there continues to pay dividends in my day-to-day work. :wink:
  • Take 30 minutes for yourself to learn Markdown. Mastering Markdown is a 3 minute read. If you have another 20-25 minutes to spare, MarkdownTutorial by my colleague Garen is pretty fantastic. If you want to go deeper, the GitHub Flavored Markdown Spec is very interesting. Ultimately, the goal is to be able to use Markdown since most (if not all) of GitHub’s platform supports it.
  • When I first started my software development journey, I didn’t have a website, nor did I know where to start. So many frameworks! So many tutorials! But if I could do it all over again, it would be getting started with GitHub Pages, a free service with extensive documentation and a wonderful community of enthusiasts.