Advertisement
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Tutorial Git

Comments in 'Resources' started by PEMapModder, Jan 10, 2015.

  1. PEMapModder
    Offline

    PEMapModder Notable Member Plugin Developer

    Joined:
    Oct 9, 2013
    Posts:
    7,294
    Plugins:
    11
    Minecraft User:
    PEMapModder
    This tutorial assumes you use GitHub as your Git server, and teaches you to use the Git Bash application installed from http://git-scm.com

    Installation
    1. Download a Git client from http://git-scm.com/downloads
    2. Run it to install
      • If you are using Windows, you should select checkout as Windows style and commit as Unix style to be compatible with all systems.
    3. On https://github.com, register a new account.
    4. Open Git Bash on any directory.
      • For Windows users, you can right-click your desktop and choose "Git Bash here".
      • On some systems you may just need to run in terminal. I only have Windows so idk.
    5. Run these commands:
      Code:
      git config --global user.name "<your name, can be your real name or contain spaces>"
      git config --global user.email "<your email used to register your GitHub account" 
    Using on repositories: Initialization
    • If you already have some code... Assume your code is at /parent/root/
      1. Go to https://github/new and create a new repository. Do not initialize the repository with a README, LICENSE or a .gitignore
        • At the middle of the right sidebar (just below the Settings button) of the repo main page, there should be a link called "HTTPS clone URL". This will be the "remote URL" mentioned later.
        • If you really want to use the readme or license things, run
          Code:
          git pull
          after step 3
      2. Open Git Bash in /parent/root/ (for Windows, open that folder and right-click empty space, then choose Git Bash here). Or if you use terminal, cd (change-directory) to it.
      3. Run the commands:
        Code:
        git init
        git remote add origin <the git clone URL mentioned above>
      4. Run:
        Code:
        git add .
        git commit -m "Initial commit"
        git push -u origin master
    • If you already have some code on the repository, OR if you don't have any code at all... Assume you want to put the repo at /parent/root/, where "root" is a folder that didn't exist yet
      1. Go to https://github.com/new to create a new repository. Tick this:
        • If you already have some code on the repository, skip this step, obviously.
      2. Go to the repo home page (you should be redirected to it after step 1) and look at the right sidebar of the repo page. Search for "HTTPS clone URL"; it should be right below the Settings button. Remember the URL. (Copy it if you want, but on Windows you can't copy&paste on Git Bash command line)
      3. Open Git Bash in (or change directory in terminal to) /parent/ and run the command
        Code:
        git clone <URL> root
        cd root
        where <URL> is the URl found in step 2, and root is the name of the folder to clone the repo into (as mentioned in above, /parent/root/.
    Using on repositories: Committing your changes and pushing them to the Git server (GitHub)
    Let's go through some basic terms in Git first:
    • Stage: This is the place where Git looks at the files from (instead of from your working directory). The stage is in a hidden place that you won't want to look at (because it actually isn't a folder with files you expect to see). If files are changed in your working directory, they won't be committed. But if you add the changes into the stage, Git will handle them.
    • Working directory: This is the place where your files actually are at (comapred to the stage). You see and edit these files directly.
    • HEAD: The code from the latest commit (or the commit you are checking out). Note that this is, to Git, not a folder, but a commit reference. If your working directory is same as HEAD, the working directory is considered as "clean".
    • Staging/Adding to stage: Add the changes in your workspace into the stage. So later when you commit, Git will only look at the files you added/staged, but not those files in your workspace.
    • Committing: Compare the code in the stage and from the HEAD, and create a commit based on these changes, and set this commit to HEAD.
    • Commit: A commit has these things: (look at https://github.com/PocketMine/PocketMine-MP/commit/1b3568301299cc0c2fc832c5c2fc93326abc565d for example)
      • The changes from the last commit (or from an empty directory if it is the first commit), i.e. what lines are changed in each file
      • A unique commit SHA (a string with 40 characters of 0-F)
      • A commit message
      • An author (name and email)
      • A committer (name and email)
      When you commit, the author and committer are taken from the user.name and user.email you have given to git config when you install. Git compares files in a per-line basis (unless the files are binary files that should not be read line by line). After committing, you cannot reverse the action (unless you recreate the repo/branch).
    • Pushing: Upload the commits on your local repo to the remote (GitHub).
    • Pulling: Download the changes from the remote (GitHub) to your local repo. If both your repo and the remote contain different, new commits, your Git client will try to merge the commits on both places and create a commit. If there are conflicts (e.g. one side deletes a line but another side changes the line), it will show a CONFLICT warning and you have to fix the conflicts yourself and commit again.
      • Note that CONFLICT will corrupt your files if you don't fix them yourself, because Git will put both the local and remote lines together, and then add some "<<<<<<<<<<<<<<" and "=============" and some words to describe the conflict there.
    Actually, you don't need to understand them all. You can still use Git if you understand none of the above concepts, except "push", "pull" and the simple concept of "commit" (i.e. changes). :p
    Now, to actually commit and push changes...
    1. Open Git Bash in (or change directory in terminal to) the topmost folder inside the repository (not outside).
    2. Run the following commands:
      Code:
      git add -A
      git commit -m "<commit message>"
      git push
      • <commit message> is a brief description of the change. If you are observant enough, you would find that this is same as the `git commit -m "First commit"` mentioned above.
      • When you run `git push`, it may tell you that "remote ref has new commits". In this case, you should run `git pull` first, and possibly fix the conflicts first.
      • If you want to make multiple commits but don't want to push them one by one (for example not to spam watcher's dashboards (;) @Gamecrafter)), you can `git push` after you have done all commits.
    Using on repositories: Pulling from remotes
    Run the command `git pull` anywhere within the working directory. Fix the conflicts in the way I explained when I explained the term "pull".


    To be continued.
    Last edited: Jan 14, 2015
  2. Gamecrafter
    Offline

    Gamecrafter

    Joined:
    Nov 20, 2014
    Posts:
    978
    Plugins:
    9
    Thanks! Just what I need to stop spamming your dashboard! XD
    PEMapModder likes this.
  3. GlaciercreepsMC
    Offline

    GlaciercreepsMC Active Member Plugin Developer

    Joined:
    Jan 21, 2014
    Posts:
    91
    Plugins:
    1
    Minecraft User:
    GlaciercreepsMC
    I'd also like to mention this free book that was listed on the git website. :)

Share This Page

Advertisement