Git

Dec 6, 2020 · 7 min read  ·
Share on:

About

The idea of version control can take many different forms, from including the date in the file name to a specific version control application. The goals are to track changes to files over time. Specifically with applications, the differences are mostly due to age/order of implementation of features. Git has become the defacto version control because it does one thing very well- it maintains both a local and a remote repository and comes with the logic to manage working through that potentially complex relationship.

Key Concepts

Git maintains a local repository. It's a database, stored in the .git directory within a project. I've personally never had interact with it directly, instead Git has a robust set of command line tools that can be very useful. Additionally, most IDEs provide a GUI that can manage most of the functions of git for you.

Git also has the concept of a remote repository. This is usually hosted through some service such as Github, BitBucket, etc, but can also be a private server.

This dual repository structure does create some complexity in keeping everything in sync, so it's important to understand the workflow. Changes between the local and remote repositories are managed through Push (push change up to remote repository) and Pull (pull change down to the local repository). Changes to the local repository are done in batches, called commits. Building the commit is called staging. So the flow is something like this: Chanage a file, Stage the Change, Commit the file to the local repo, Push the commit to the remote repo.

Usage

Git does have a software component that needs to be installed. Package managers can be used, otherwise go to the website Git.scm.

Note: I think most people will skip ahead to a Level 1 user, but I think it's worthwhile to know that it isn't necessary to find value in git. Also, these levels build upon one another.

Level 0 - Using by yourself, local version

Scenario: You're just getting started with git and want to use it some to track changes to files. You're not worried about backing up to cloud. The commands below will get you basically rolling with git locally. This will give you the ability to "rewind" time, which should eliminate that feeling when you realize that file you deleted a few days ago, now you need it.

Level 0 - Commands you need

  • git init will create a .git directory in the folder you run this command in. This is your local git database
  • git status will give you messages if you have outstanding files to commit or other various information
  • git add [filepath] will add files to tracking in git. When getting started, you can just run git add . to add all the files in your directory.
  • git diff [filepath
  • git commit -m "message" will create a local commit (save point) with whatever message you give it.
  • git log will list your commits with the message for each. notice the id for each commit- it's used in the next command
  • git checkout [id] will allow you to go back in time to a prior state of the project directory.

Level 1 - Using by yourself, cloud version

Scenario: You're fairly new to the concept of git, but you want to use it on some personal projects. You want to back it up to the cloud.

I'm intentionally holding branching back from this level because it adds a level of complexity that I think you don't need to think about at the beginning. Once you have a good feel on this basic flow, then you can use branches to isolate project changes from the main codebase.

Level 1 - Commands you need

  • git config --global user.email "you@example.com" set the email address that gets pushed along with commits to a remote (cloud) repo. The --global tag sets it for the entire machine, you can omit if you only want to set for the current project.
  • git config --global user.name "Your Name" set the name that gets pushed along with commmits to your remote (cloud) repo. The --global tag sets it for the entire machine, you can omit if you only want to set for the current project.
  • git clone [address] [filepath] will clone your project from the web (for instance Github) to your local machine. The easiest workflow in this scenario is you create the project on the web, and then clone it locally. It is possible to run git init locally and then add your remotes to it, just a little more complicated.
  • git config credential.helper store This will store your git credentials in the project so you don't have to reauthenticate each time to work with the remote. IMPORTANT: Do not use your real password. Github and other sites allow for a personal access token that can be generated and used in place of your password. It's best to create a separate one for at least each device so you can revoke as needed. In Github, these are in Settings > Developer Settings > Personal Access Tokens. Ideally, your personal access token will only have limited access. Once you've made this change, the first time you run a command that reaches out (such as git pull), it will prompt you for your username and password. It will save those, and use your PAT for the password.
  • git reset --hard This will reset both working area and index to match latest commit. This is useful if you've been trying some things but want to quickly get back to clean quickly.
  • git push This will push any commits you've created locally to the remote repository.
  • git pull This will pull any commits from the remote repository that aren't local.

Level 1 - Other things you need to know

  • touch .gitignore This is a file to include in your project space that specifies file you don't want to be stored in git. Why would you do such a thing? Well, for starters, your project may have passwords or other information you want to keep secret. This comes into play at higher levels, but it's something to start keeping in mind at this level. While you can get secrets out of git, it's really difficult and it's much easier to just keep them out of the file in the first place.

Level 2 - Using on a team Simple

Scenario: You're working on a project within a team. Because there are multiple people working on the project at once, it's a bad idea to keep all your work in the main branch. As mentioned above, this is also your more experienced git user who's being more organized.

Level 2 - Commands you need

Level 2 - Other things you need to know

Level 3 - Using on a team Complex

Scenario: You're working on a project within a team as in Level 2. However, there are multiple remote branches and other complexities to the project (Git Flow style).

Level 3 - Well Structured Commits

  • git config --global core.editor vim
  • Basic Rules
    • Atomic Commits
    • 50 character subject
    • Separate Subject and Body with empty line
    • 72 character wrap on body
  • git commit -m "Subject" -m "Description..."
  • git mv <old> <new> Handy to rename files and display correctly in commit (as opposed to delete + add)

Level 4 - Using in a community

Scenario: You want to start contributing to an Open Source project. The project has 2 roles of users, contributors and maintainers. As such, you only have pull access to the main project repo.

Gotchas

Recommendations

  • Establish norms/constraints for the project
  • Build a solid README.md

Reference