In order to migrate from SVN to Git, you will need time, discipline, and be willing to learn as you go. Here are a number of ways to complete the SVN to Git migration, so I tried to search out the easiest way to accomplish this.

Get to Know the Git-SVN Command

Getting to know the git-svn command at a high level is probably the best place to start. Basically, the git-svn command is a command that allows Git to interact with Subversion repositories. The git-svn command is actually part of Git, which means it is NOT a plugin but is indeed bundled with your Git installation.

Migrating From SVN to Git Repositories

Let’s get started. First off you need to create a new local copy of the repository by using the following command:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git svn clone SVN_REPO [DEST_DIR] -T TRUNK -t TAGS -b BRANCHES[/ht_message]

If your current SVN repository follows the usual, standard layout of trunk, branches, tag folders, the command above will look like this:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git svn clone -s SVN_REPO [DEST_DIR][/ht_message]

The git-svn clone part of the command will check out each SVN revision and also make a Git commit in your local repository in order to recreate the history.

Note: If the SVN repository has a lot of commits this process will take a while, so find something else to do in the meantime.

Once this command has finished up you will have an entire Git repository with a local branch called master that will track the trunk branch in the SVN repository.

Note: If the SVN repository has a very long history, then the git svn clone operation might crash or hang. If it does crash or stall you can kill the entire process by using CTRL-C on your keyboard. When or if this happens you do not have to worry, as the Git repository has already been created, but there is just some SVN history that has yet to be retrieved from the server. To resume the operation, just change to the git repository folder and issue the command git svn fetch.

Pull Latest Changes From SVN Repository

When you want to receive the latest changes from your Git server use git pull. The equivalent to git pull in your git-svn journey is the git svn rebase command.

This command retrieves all the changes from the SVN repository and applies them on top of your local commits in your current branch. You can also use git svn fetch to retrieve all the changes from the SVN, but this allows you to do it without applying them to your local branch.

Add Changes

After you pull the work from SVN, you can use your local Git repository as a normal Git repository, with the normal Git commands (git add, git commit, git stash).

Push Local Changes to SVN

The git svn dcommit –rmdir command will create an SVN commit for each of your local Git commits. Just like SVN, your local Git history must be in sync with the latest changes in the SVN repository. If the command fails, try performing a git svn rebase command first.

Note: Remember, your local Git commits will be rewritten when using the command git svn dcommit. The solution is to create a new commit with the same contents and the new message. Technically speaking, this is a new commit anyway.

Things to Keep in Mind

Keep the History Linear: This means you can make all sorts of local operations. You can remove, reorder, or squash commits. Move history around, etc. Pretty much anything except merging.

Merges: Don’t merge local branches. If you find yourself in a position where you need to reintegrate the history of local branches, then use the git rebase command instead.

How To Handle Empty Folders

If you are familiar with Git (and chances are you are since you are performing a migration), you know that Git does not recognize the concept of folders. Git works with files and their file paths. What this means is that Git does not track empty folders.

On the other hand, SVN does. So by using the git svn command, by default any change you do involving empty folders with Git will not be propagated to SVN. To remove existing empty folders you have to do it manually.

To avoid needing to issue the flag each time you do a dcommit, just issue the following command:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git config –global svn.rmdir true[/ht_message]

This will change your .gitconfig file and will add these lines:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ][svn]
rmdir = true  [/ht_message]

Please be cautious if you use the git clean –d command , as this will remove all untracked files, including folders that should be kept empty for SVN. If you need to generate aging the empty folders tracked by SVN use the command git svn mkdirs.I f you want to cleanup your workspace from untracked files and folders you should always use both commands:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git clean -fd && git svn mkdirs[/ht_message]

Performing a migration from SVN to Git is a challenging and detailed process. The more you know about both the better off you will be. Hopefully this gives you a starting point and explains some of the things that will happen during the migration process.

The post How To Migrate From SVN to Git appeared first on GreenGeeks.

What is a Git Pull Request?

In even more basic terms, this command is a mechanism for a developer to notify team members that they have completed a feature. The main issue with Git is always how technical it is and how long it takes to learn. So, in an effort to better understand a Git pull request, think of it like this:

You are working on a project as part of a team and make some code changes. You then submit your code changes to a remote project maintainer (like GitHub) where the code updates are reviewed and approved before being implemented or merged. In essence, this is called a “pull request.”

An interesting thing to know and remember. Pull requests are not actually a core feature of Git. They are commonplace because they work as an essential function when teams are working with open-source projects.

What You Need in Place to Perform a Git Pull Request

In order to even create a Git pull request, you need to have three main things in place. Along with these three things, it will also help if you already know and understand how to use Git. Here is what you need to have in place:

• You need to have Git installed and running on your machine. There is the option to install it on Windows or install it on Mac OS and Linux.
• You will need to have a GitHub account as well. You can open an account through the GitHub website or log in to an already existing account there.
• Last but not least. You should have an already existing open-source project to contribute to. Or, you need to find one that interests you.

Remember, the key here is open-source. You want to contribute to a project that others are working on, so identify one, then use the pull request to submit so that you can work on it.

As far as creating a Git pull request goes, let’s try to keep it as simple as possible. There will be a lot of different commands involved sometimes, so you will need to know these and they will vary based on what you are doing. However, if you are familiar with the top 20 Git commands, then you should be fine.

Create a Pull Request

Step 1: Log in to Your GitHub Account

Head over to GitHub and log in to your account. If you don’t have one, then create one as described above. You will need an account to create a Git pull request.

Step 2: Navigate to Main Page of Repository

Once inside your account, navigate to the main page of the repository and choose what project you want to create a pull request for. I am jumping into a demo repository I made, but select the one you want.

Step 3: Click on Pull Requests

Click on the “Pull Request” option in the menu area.

Step 4: Click on New Pull Request Button

On this page, you will see a green “New Pull Request” button. Go ahead and click on that.

Step 5: Upload New Code and Submit Request

You will be taken back to the main repository you are working on. Go to the bottom of the page and click on the “Import Code” button.

Step 6: Import Clone URL and Submit Pull Request

Last, but not least, import all files from the clone URL and submit the pull request.

That’s it. Your pull request has been submitted.

How the Pull Request Works

Basically, a Git pull request goes through five main steps from start to finish. Now, it is important to remember that pull requests in distinctive workflows may be a little different in small areas. However, for the most part, this following process remains the same.

1. A developer creates an open-source project in a dedicated branch on their local repository.
2. Once ready, the developer then pushes the branch to a public repository like Bitbucket.
3. The developer then files a pull request.
4. The rest of the team goes over the code together. They review, discuss, and alter it where and if needed.
5. When it is done and ready, the project maintainer adds (merges) the feature into the official repository. Then that pull request is closed.

How to Get Changes Approved With a Git Pull Request

Obviously, you need to understand forking and how all that works. However, to try to explain this in the easiest way possible, you fork a repository on a remote hosting service, then clone it to your machine. At that point, you can start working on the code and changing it.

When you are happy with all the code changes you made, you can perform a push to the fork and then open up a pull request. This signals the main repo and asks the maintainer to review the code and request any changes or edits needed.

If the pull request you made is approved, then those changes are added (merged) into the main repo. If not, the update requests are sent back and the process repeats itself.

Summary

This should be enough to get you started in the right direction when it comes to integrating pull requests into your existing workflow. Try and remember that Git pull requests are not a replacement for any Git-based collaboration workflows. They are, however, a convenient addition to the workflow that makes collaboration easier for all team members involved.

Learning and understanding how a Git pull request works will allow you to work on open-source projects using Git and GitHub. This means that you can submit Git pull requests and, if your code submissions are accepted, you are a part of building something that everyone can use.

The post How To Make a Pull Request in Git appeared first on GreenGeeks.

How Does the Git Remote Command Work?

The git remote command actually works as one piece of a much broader system that is responsible for Git syncing. Records that are registered through the git remote command are used in conjunction with the git fetch, git push, and git pull commands.

Let’s take a quick look at Git syncing and how it actually works using the git remote command.

How to Run the Git Remote Command for Git Syncing

Understand Git Remote

The git remote command allows you to create, view, and delete connections to other Git repositories. This means that remote connections are more like bookmarks rather than direct links to other repositories.

Instead of providing you real-time access to another repository, they serve as convenient, or easy to read names, that can be used to reference a not so convenient, or not so easy to read, URL. You can see some synchronizing changes command examples below.

Learn Git Remote Usage

Basically, the git remote command is used as an interface for managing a list of remote entries that are stored in the repository’s ./.git/config file. To view some git remote configurations you would use the following command lines:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git remote[/ht_message]

This command will list the remote connections you have in other repositories.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git remote -v[/ht_message]

This command is the same as the first git remote command, except that it will include a URL of each connection.

Git is specifically designed to give each developer a stand-alone, or isolated, environment. What this means is that information is not automatically passed back and forth between repositories.

Instead, developers have to manually pull upstream commits into their local, or stand-alone, repository, or manually push their local commits back up to the central repository. So essentially, the git remote command is just an easier way to pass URLs to these “sharing” commands.

Synchronize Changes

Some commands to register a remote (URL) and exchange repository history.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git fetch [remote][/ht_message]

This command downloads all history from the remote repository.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git merge [remote]/[branch][/ht_message]

This command combines the remote branch into the current local branch.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git push [remote] [branch][/ht_message]

This command uploads all local branch commits to GitHub.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git pull[/ht_message]

This command downloads bookmark history and incorporates changes.

Final Thoughts

Learning how to use Git properly can be a real undertaking. However, just like anything else, if it is important enough to you, then a little time and patience go a long way. Once you learn how to properly use the system, then functions like Git syncing and all other Got commands and features will start to fall in place.

A great way to start learning Git is to learn 20 of the most popular commands available. Then work down from there.

The post Git Syncing Using Git Remote appeared first on GreenGeeks.

GitHub provides desktop clients that include a graphical user interface for the most common repository actions and an automatically updating command line edition of Git for advanced scenarios.

Here is a little Git cheat sheet for you to reference for all things Git.

GitHub Desktop and Platform Installations

Find the GitHub desktop here: https://desktop.github.com/

You can find Git for any platforms here: https://git-scm.com/

If you want to know how to install Git on any platform please review these detailed articles:

How To Install Git on MAC OS and Linux

How To Install Git on Windows

Configure Tooling Commands

Some commands to configure user information for all local repositories.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git config –global user.name “[name]”[/ht_message]

This sets the name you want attached to your commit transactions.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git config –global user.email “[email address]”[/ht_message]

This sets the email you want attached to your commit transactions.

Create Repositories

Some commands to start a new repository or obtain one from an existing URL.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git init [project-name][/ht_message]

This command creates a new local repository with the specified name.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git clone [url][/ht_message]

This command downloads a project and its entire version.

For more information on repositories please review the following articles:

How To Create a Git Repository

How To Manage a Git Repository

How To Inspect a Git Repository

Git Repository Structure

Refactor File Names

Some commands to relocate and remove versioned files.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git rm [file][/ht_message]

This command deletes the file from the working directory and stages the deletion.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ $ git rm –cached [file][/ht_message]

This command removes the file from version control but preserves the file locally.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git mv [file-original] [file-renamed][/ht_message]

This command changes the file name and prepares it for commit.

Suppress Tracking

Exclude temporary files and paths.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]*.log
build/
temp-*[/ht_message]

A text file named .gitignore suppresses accidental versioning of files and paths matching the specified patterns.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git ls-files –others –ignored –exclude-standard[/ht_message]

This command lists all ignored files in the project.

Save Fragments

Commands to shelve and restore incomplete changes.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git stash[/ht_message]

This will temporarily store all modifies tracked files.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git stash pop[/ht_message]

This command restores the most recently stashed files.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git stash list[/ht_message]

This command lists all stashed changesets.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git stash drop[/ht_message]

This command discards the most recently stashed changeset.

Make Changes

Commands for reviewing edits and crafting a commit transaction.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git status[/ht_message]

This command lists all new or modified files to be committed.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git diff[/ht_message]

This command shows file differences that are not yet staged.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git add [file][/ht_message]

This command snapshots the file in preparation for versioning.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git diff –staged[/ht_message]

This command shows file differences between staging and the last file version.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git reset [file][/ht_message]

This command unstages the file, but preserves its contents.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git commit -m”[descriptive message]”[/ht_message]

This command records file snapshots permanently in version history.

Group Changes

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git branch[/ht_message]

This command lists all local branches in the current repository.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git branch [branch-name][/ht_message]

This command creates a new branch.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git checkout [branch-name][/ht_message]

This command switches to the specified branch and updates working directory.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git merge [branch-name][/ht_message]

This command combines the specified branch’s history into the current branch.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git branch -d [branch-name][/ht_message]

This command will delete a specified branch.

Review History

Here are some commands that will allow you to browse and inspect the the evolution of project files.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git log[/ht_message]

This command lists version history for the current branch.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git log –follow [file][/ht_message]

This command lists version history for the file, including renames.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git diff [first-branch]…[second-branch][/ht_message]

This command shows content differences between two branches.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git show [commit][/ht_message]

This command outputs metadata and content changes of the specified commit.

Redo Commits

Some commands to erase mistakes.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git reset [commit][/ht_message]

This command Undoes all commits after [commit], preserving changes locally.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git reset –hard [commit][/ht_message]

This command discards all history and changes back to the specified commit.

Synchronize Changes

Some commands to register a remote (URL) and exchange repository history.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git fetch [remote][/ht_message]

This command downloads all history from the remote repository.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git merge [remote]/[branch][/ht_message]

This command combines the remote branch into the current local branch.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git push [remote] [branch][/ht_message]

This command uploads all local branch commits to GitHub.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]$ git pull[/ht_message]

This command downloads bookmark history and incorporates changes.

A Little More

For an overview of even more top Git commands and examples view this article:

Top 20 Git Commands and Examples

For more detailed information on how to undo changes in Git please read:

How To Undo Changes in Git

There you go. A little Git cheat sheet to help you on your journey.

The post Cheat Sheet For All Things Git appeared first on GreenGeeks.

What Do These Git Commands Accomplish?

Not only are these three commands arguably three of the most useful ones within your Git toolbox,  but all three of these commands also allow you to undo some kind of change in your repository. On top of that, the git reset and git checkout commands can also be used to manipulate either commits or individual files.

Commits: Basically, the “commit” command is used to save all of your changes to the local repository. It is important to remember though that using the “git commit” command only saves a new commit object in the local Git repository. Exchanging commits has to be performed manually and explicitly (with the “git fetch”, “git pull“, and “git push” commands).

Git Command Differences

Since all three of these Git commands are very similar, it might be a little confusing at times regarding which command to use in any given development scenario. There is already a pretty steep learning curve when it comes to understanding how to use Git properly. So anything that can be broken down to help the overall aspect of the tool is always valuable to have at your fingertips.

In this article, I will give you some useful information on the git reset, git checkout, and git revert commands. Learning the little Git command differences will definitely help you along the way when it comes to properly using the relevant command at the relevant time.

Remember, Git is a vast system, and can be difficult to learn. Articles like this are a great way to learn the different parts of how it all works. If used correctly, Git can be a very useful tool to have in your back pocket.

I will also give you some reference points and talk a little about what each command does. This should at least help you differentiate the Git command differences when using them, as well as help you use them appropriately.

After reading this you should have a little more confidence navigating your repository and using the three commands correctly.

Git Reset, Revert, Checkout Reference Points

To better understand the Git command differences between these three, it will help if you think about each command in terms of their effect on the three-state management mechanisms of a Git repository. Those three state management mechanisms include:

• The working directory
• The staged snapshot
• The commit history

The above components are oftentimes referred to as “the three trees” of Git.

The examples below sum up some of the most common use cases for all three of these commands. You could bookmark this page and keep these references handy. At some point, you will need to use at least some of them if you work with Git often.

Having access to the top 20 Git commands and examples will also be very useful as well. Learn the Git command differences and examples not only between these three, but between all the Git commands. This will put you on the road to becoming an expert Git user.

Git Command Differences References and Examples

Below you will find some references and examples for each of the three git commands we are talking about together in this article. You can view the command, scope, and a common use examples. This should help you even more when it comes to understanding the Git command differences between the three.

Below these examples, we go into the differences in a little more depth.

Git Reset

• Command: git reset
• Scope: Commit-level
• Common Use Example: When you need to discard commits in a private branch or throw away uncommitted changes.

• Command: git reset
• Scope: File-level
• Common Use Example: When you need to unstage a file.

• Command: git checkout
• Scope: Commit-level
• Common Use Example: When you want to switch between branches or inspect old snapshots.

Git Checkout

• Command: git checkout
• Scope: File-level
• Common Use Example: When you want to discard changes in the working directory.

Git Revert

• Command: git revert
• Scope: Commit-level
• Common Use Example: When you want to undo commits in a public branch.

• Command: git revert
• Scope: File-level
• Common Use Example: This is not applicable here.

Git Reset, Revert, Checkout Differences

The reference points above give you a good idea of when to use these three commands and at what level. Let’s take a look at the differences in a more defined layout.

git reset: This command is somewhat complicated. It actually does a couple of different things depending on how it is invoked. The command modifies the index (the so-called “staging area”). It can also change which commit a branch head is currently pointing at. This command may alter existing history (by changing the commit that a branch references).

git revert: This command can be considered an ‘undo’ type command. However, it is not a traditional undo operation. Instead of removing the commit from the project history, it figures out how to invert the changes introduced by the commit and appends a new commit with the resulting inverse content. This prevents Git from losing history, which is important for the integrity of your revision history and for reliable collaboration.

git checkout: This command operates on three distinct entities: files, commits, and branches. In addition to the definition of “checkout,” the phrase “checking out” is commonly used to imply the act of executing the git checkout command. The git checkout command allows you to navigate between the branches that are created by git branch. Checking out a branch updates the files in the working directory to match the version stored in that branch, and it tells Git to record all new commits on that branch.

Between the command scopes and examples above, as well as the more detailed paragraphs regarding the commands, you should be in a much better position when it comes to understanding how it all works.

Summing It All Up

These three commands, while different, should give you all the tools you need to undo any changes in your Git repository. The git reset, git revert, and git checkout commands can be confusing at times, especially because they are similar, while at the same time being very different.

However, now you have more of an idea about how they all work when it comes to the working directory, staged snapshot, and commit history of your Git project. Understanding Git command differences is one of the biggest aspects of learning how to use the Git system properly, and when to use the commands.

Remember, as stated above, Git will take some time to learn and understand. Hopefully, this rundown of git reset, git checkout, and git revert gives you a better understanding of how the commands work, when to use them, and above all, the differences between them.

When you learn proper Git command differences, you will put yourself in a much better spot when it comes to understanding how much the tool can actually do.

The post The Difference Between Git Reset, Git Checkout, and Git Revert appeared first on GreenGeeks.

Git hooks have several common uses that include:

• Encouraging a commit policy.
• Altering a project environment, depending on the state of the repository.
• Implementing continuous integration workflows.

Since Git hooks are very customizable, you can use them to automate or optimize virtually any aspect of your development workflow.

In this article, I will give you a quick overview of Git hooks and how they work. Then, I will show you some common Git hooks and the definitions of what they do.

Git Hook Overview

Just like many other Version Control Systems, Git provides a way for you to fire off custom scripts when certain important actions occur in the repository. In turn, this makes them easy to install and configure.

There are two groups of hooks, client-side and server-side. Client-side hooks are triggered by operations such as committing and merging, while server-side hooks run on network operations such as receiving pushed commits.

Installing Git Hooks

Hooks reside in the .git/hooks directory of every Git repository. Git automatically populates this directory with example scripts when you initialize a repository. If you take a look inside .git/hooks, you will find the following files:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]applypatch-msg.sample pre-push.sample
commit-msg.sample pre-rebase.sample
post-update.sample prepare-commit-msg.sample
pre-applypatch.sample update.sample
pre-commit.sample[/ht_message]

These represent most of the available hooks, but the .sample extension prevents them from executing by default. To “install” a hook, all you have to do is remove the .sample extension. Or, if you’re writing a new script from scratch, you can simply add a new file matching one of the above filenames, minus the .sample extension.

Try the example below and see how you do. Install a simple prepare-commit-msg hook. Remove the .sample extension from this script, and add the following to the file:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]#!/bin/sh
echo “# Please include a useful commit message!” > $1[/ht_message]

Hooks need to be executable, so you might have to change the file permissions of the script if you are creating from scratch. For example, to make sure that prepare-commit-msg is executable, you would run the following command:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]chmod +x prepare-commit-msg[/ht_message]

The built-in sample scripts above are very useful references, as they document the parameters that are passed in to each hook (they vary from hook to hook).

Client-Side Hooks

Let’s take a look at the client-side Git hooks and see what each one does.

Committing-Workflow Hooks

pre-commit: This Git hook is used to inspect the snapshot that’s about to be committed, to see if you’ve forgotten something, to make sure tests run, or to examine whatever you need to inspect in the code.

prepare-commit-msg: This Git hook is run before the commit message editor is fired up but after the default message is created. It lets you edit the default message before the commit author sees it. This hook takes a few parameters: the path to the file that holds the commit message so far, the type of commit, and the commit SHA-1 if this is an amended commit.

commit-msg: This Git hook takes one parameter, which again is the path to a temporary file that contains the commit message written by the developer. If this script exits non-zero, Git aborts the commit process, so you can use it to validate your project state or commit message before allowing a commit to go through.

post-commit: This Git hook runs after the entire commit process is completed. It doesn’t take any parameters, but you can easily get the last commit by running git log -1 HEAD. Generally, this script is used for notification or something similar.

Email Workflow Hooks

 applypatch-msg: This Git hook takes a single argument: the name of the temporary file that contains the proposed commit message. Git aborts the patch if this script exits non-zero. You can use this to make sure a commit message is properly formatted or to normalize the message by having the script edit it in place.

pre-applypatch: This Git hook is a little confusing because it is run after the patch is applied but before a commit is made, so you can use it to inspect the snapshot before making the commit.

post-applypatch: This Git hook runs after the commit is made. You can use it to notify a group or the author of the patch you pulled in that you’ve done so. You can’t stop the patching process with this script.

Other Client Hooks

pre-rebase: This Git hook runs before you rebase anything and can halt the process by exiting non-zero. You can use this hook to disallow rebasing any commits that have already been pushed.

post-rewrite: is run by commands that replace commits, such as git commit –amend and git rebase (though not by git filter-branch). Its single argument is which command triggered the rewrite, and it receives a list of rewrites on stdin. This hook has many of the same uses as the post-checkout and post-merge hooks.

post-merge: This Git hook runs after a successful merge command. You can use it to restore data in the working tree that Git can’t track, such as permissions data. This hook can likewise validate the presence of files external to Git control that you may want copied in when the working tree changes.

pre-push: This Git hook runs during git push. It runs after the remote refs have been updated but before any objects have been transferred. It receives the name and location of the remote as parameters and a list of to-be-updated refs through stdin. You can use it to validate a set of ref updates before a push occurs (a non-zero exit code will abort the push).

Server-Side Hooks

pre-receive: This Git hook is the first script to run when handling a push from a client is pre-receive. It takes a list of references that are being pushed from stdin; if it exits non-zero, none of them are accepted. You can use this hook to do things like making sure none of the updated references are non-fast-forwards. Also use it to do access control for all the refs and files they’re modifying with the push.

update: This Git hook is very similar to the pre-receive script, except that it’s run once for each branch the pusher is trying to update. If the pusher is trying to push to multiple branches, pre-receive runs only once, whereas update runs once per branch they’re pushing to. Instead of reading from stdin, this script takes three arguments: the name of the reference (branch), the SHA-1 that reference pointed to before the push, and the SHA-1 the user is trying to push. If the update script exits non-zero, only that reference is rejected; other references can still be updated.

post-receive: This Git hook runs after the entire process is completed and can be used to update other services or notify users. It takes the same stdin data as the pre-receive hook. Examples include:

• Emailing a List
• Notifying a Continuous Integration Server
• Updating a Ticket-Tracking System

You can even parse the commit messages to see if any tickets need to be opened, modified, or closed. This script can’t stop the push process, but the client doesn’t disconnect until it has completed. Be careful if you try to do anything that may take a long time.

Managing Git Hooks

Here are some fantastic options for managing your Git hooks. Take a look and see if they are of any interest to you.

Awesome Git Hooks

Awesome Git Hooks is a collection library of excellent Git hooks to have at hand.

Git Hooks

Git Hooks is a full git hook manager at your disposal.

Overcommit

Overcommit is a very well-maintained, up-to-date, flexible Git hook manager.

Git Hooks Summary

Now we know that Git hooks can be used to alter internal behavior and receive notifications when certain events occur in a repository. Git hooks are ordinary scripts that reside in the .git/hooks repository, and they are pretty easy to install and customize if you are familiar with Git.

This article also gave you the client-side and server-side hooks available and a definition of what they all do.

The post An Overview of Git Hooks appeared first on GreenGeeks.

Let’s take a quick look and compare the git rebase command with the related git merge command and identify all of the potential opportunities that are presented to incorporate rebasing into the typical Git workflow.

Overview of Rebase and Merge Git Commands

The first thing you want to remember is that both the git rebase command and the git merge command are used to solve the same problem. Both commands are designed to integrate changes from one branch into another branch. That being said, they just do it in very different ways. These commands are two of many that Git has. It may benefit you to learn about the most popular Git commands as well.

When you start working on a new feature in a dedicated branch, and another team member updates the master branch with new commits, it results in a forked history. Anyone who has used Git as a collaboration tool will be familiar with this.

So now let’s say all the new commits in master are now relevant to the feature you are working on. In order to incorporate these new commits into your feature branch, you have two options: Git rebasing or Git merging.

The Git Merging Option

The easiest way to merge the master branch into the feature branch in Git is to use the git merge command. That will look something like this:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git checkout feature
git merge master[/ht_message]

Or if you prefer, you can condense that into one line:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git merge feature master[/ht_message]

What this does is create a new “merge commit” in the feature branch that will tie together the history of both branches.

Git merging is a great way to go because it is considered a non-destructive operation. This is because the existing branches are not changed in any way. It also helps you avoid the potential pitfalls that come with rebasing, which we will take a look at below.

That being said, the downside means that the feature branch will have an irrelevant or unrelated merge commit every time you need to incorporate upstream changes.

In other words, if the master is very active, then you can pollute your feature branch’s history quite a bit. While you can lessen the damage using advanced git log options, it can still make it hard for other developers to understand the history of the project. You don’t want to continually have to undo changes in Git.

The Git Rebase Option

Git offers an alternative to the git merge command. You can also rebase the feature branch onto master branch using the following commands:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git checkout feature
git rebase master[/ht_message]

What this does is move the entire feature branch to begin on the tip of the master branch, effectively incorporating all of the new commits in master. However, instead of using a merge commit, Git rebasing re-writes the project history by creating brand new commits for each commit in the original branch.

The biggest benefit of Git rebasing is that you will get a much cleaner project history because it will eliminate the unnecessary merge commits required by git merge.

Another benefit of using Git rebasing is the fact that it also results in a perfectly linear project history—you can follow the tip of feature all the way to the beginning of the project without any forks. This does make it a lot easier to navigate around your project the git log, git bisect, and gitk commands.

There are in fact a couple of downsides though to Git rebasing and the pristine commit history that comes with it.

Re-writing project history can be potentially catastrophic for your collaboration workflow. Rebasing also loses the context provided by a merge commit, as you can’t see when upstream changes were incorporated into the feature.

Should You Use Rebase or Merge?

Well, let’s sum this up. If you would prefer a clean, linear history free of unnecessary merge commits, you should go for the for the git rebase option when integrating changes from another branch.

However, if you would like to preserve the entire history of your project and also avoid the risk of re-writing public commits, then you should probably stick with git merge.

Both the option of rebasing in Git and merging in Git are valid and workable options. The choice is really up to you and will depend a lot on project and personal opinion.

The post Overview of Git Rebasing vs. Git Merging appeared first on GreenGeeks.

The concept of Git changes and undos is the same as it would be anywhere else, but the set of Git commands and how it operates is definitely different than it is for most other applications.

If you understand how Git commits work (saving in Git), then you will at least have a basic understanding that undoing Git commits and changes are also based on a set of different commands.

Let’s take a look at how to undo changes in Git.

Git as a Timeline Management Utility

Just as the title of this section states, a great way to think of Git is as a timeline management utility.

Commits are snapshots of a point in time or points of interest along the timeline of a project’s history. Multiple timelines can be managed through the use of branches. When we speak of undoing changes in Git, we are usually moving back in time, or to another timeline where mistakes didn’t happen.

Reviewing Old Commits

As is the case with any version control system, the idea is to store “safe” copies of a project so that you never have to worry about irreparably breaking your code base.

After you have built up a project history of commits, then you are able to review and revisit any commit in the history. The best option for reviewing the overall history of a Git repository is the git log command.

In the example below, the git log command is used to get a list of the latest commits to a popular open-source graphics library.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git log –oneline
e2f9a78fe Replaced FlyControls with OrbitControls
d35ce0178 Editor: Shortcuts panel Safari support.
9dbe8d0cf Editor: Sidebar.Controls to Sidebar.Settings.Shortcuts. Clean up.
05c5288fc Merge pull request #12612 from TyLindberg/editor-controls-panel
0d8b6e74b Merge pull request #12805 from harto/patch-1
23b20c22e Merge pull request #12801 from gam0022/improve-raymarching-example-v2
fe78029f1 Fix typo in documentation
7ce43c448 Merge pull request #12794 from WestLangley/dev-x
17452bb93 Merge pull request #12778 from OndrejSpanel/unitTestFixes
b5c1b5c70 Merge pull request #12799 from dhritzkiv/patch-21
1b48ff4d2 Updated builds.
88adbcdf6 WebVRManager: Clean up.
2720fbb08 Merge pull request #12803 from dmarcos/parentPoseObject
9ed629301 Check parent of poseObject instead of camera
219f3eb13 Update GLTFLoader.js
15f13bb3c Update GLTFLoader.js
6d9c22a3b Update uniforms only when onWindowResize
881b25b58 Update ProjectionMatrix on change aspect[/ht_message]

As you can see, each commit has a unique SHA-1 identifying hash. The IDs are used as place marks so you can travel through the entire committed timeline and revisit commits.

The git log command will only show commits for the currently selected branch by default. So what if the commit you are searching for is located in another branch? To solve this issue can view all commits across all branches by executing the following command:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git log –branches=*[/ht_message]

Once you have found the commit reference to the point in history you want to visit, you can then utilize the git checkout command to visit that commit.

The git checkout command is an easy way to load any saved snapshots right onto your development machine.

In case you need to be reminded, checking out an old file does not move the HEAD pointer. It remains on the same branch and same commit, avoiding a ‘detached head’ state. You can then commit the old version of the file in a new snapshot as you would any other changes.

So basically, using the git checkout command on a file acts as a way to revert back to the old version of an individual file.

How To View an Old Revision

In the example below let’s just assume that you are developing something but you aren’t sure whether or not you want to keep it. In order to make a decision, you want to take a look at the state of the project before you started. First, you’ll need to find the ID of the revision you want to see.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git log –oneline[/ht_message]

Now, say your project history looks something like this:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]b7119f2 Continue doing weird things
872fa7e Try something weird
a1e8fb5 Make some important changes to example.txt
435b61d Create example.txt
9773e52 Initial import[/ht_message]

You can use the git checkout command to view the “Make some import changes to example.txt” commit as follows:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git checkout a1e8fb5[/ht_message]

This command makes your working directory match the exact state of the a1e8fb5 commit. This allows you to look at files, compile the project, run tests, and even edit files all without having to worry about losing the current state of the project.

Remember, nothing you do in here will be saved in your repository. To continue developing, you need to get back to the “current” state of your project by using the following command:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git checkout master[/ht_message]

Once you’re back in the master branch, you can use either the git revert command or git reset command to undo any changes you want.

Options For Undoing Committed Snapshots

There are actually several different strategies to use when you want to undo a commit. The most commonly used Git commands for undoing and making changes are git checkout, git revert, and git reset.

Some important points to remember include:

• Once changes have been committed they are usually permanent.
• Use the git checkout command to move around and review the commit history.
• The git revert command is the best tool for undoing shared public changes.
• The git reset command is best used for undoing local private changes.

Finally, in addition to the primary and popular Git undo commands, you can also use commands like git log for finding lost commits, git clean for undoing all those uncommitted changes, and git add for modifying the staging index.

The post How To Undo Changes in Git appeared first on GreenGeeks.

You should try and remember that status output does not show you any information regarding the committed project history. For this, you need to use the git log command.

Before I jump into the git status command and how to use it to inspect a Git repository let’s take a look at some related Git commands that may be useful for this portion.

Some Related Git Commands

• git tag: Tags are references that point to specific points in Git history. git tag is generally used to capture a point in history that is used for a marked version release.
• git blame: The high-level function of git blame is the display of author metadata attached to specific committed lines in a file. This is used to explore the history of specific code and answer questions about what, how, and why the code was added to a repository.
• git log: The git log command displays committed snapshots. It lets you list the project history, filter it, and search for specific changes. This is used often when you are saving changes in Git.

Git Status Command Usage

git status

As mentioned above, this lists which files are staged, unstaged, and untracked.

While Git can be complicated at first, especially for a beginner, the git status command is a pretty straightforward Git command. Basically, it shows what has been going on with git add and git commit.

Status messages will also show relevant instructions for staging and/or unstaging files. Below is a sample output showing the three main categories of a git status call:

# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#modified: hello.py
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#modified: main.py
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#hello.pyc

Ignoring Files When Needed

More often than not untracked files in Git fall into two categories. They are either files that have just been added to the project but not yet committed, or they are compiled binaries like .pyc, .obj, .exe, and so on.

While it is very beneficial to include the former in the git status output, the latter can make it hard to see what’s actually going on in your repository. You don’t want that, you want to be able to see clean and clear what exactly is going on.

To deal with this issue Git, allows you to ignore files completely by placing paths in a special file called .gitignore. Any files that you would like to ignore should be included on a separate line, and the * symbol can be used as a wildcard.

For example, adding the following to a .gitignore file in your project root will prevent compiled Python modules from appearing in git status:

*.pyc

For example, you always want to inspect the overall state of your repository before committing changes so that you don’t accidentally commit something you don’t mean to. This displays the repository status before and after staging and committing a snapshot:

# Edit hello.py
git status
# hello.py is listed under "Changes not staged for commit"
git add hello.py
git status
# hello.py is listed under "Changes to be committed"
git commit
git status
# nothing to commit (working directory clean)

Using Git Log Command

The git log command displays committed snapshots. The command will allow you to list the project history, filter it, and search for specific changes.

So while git status allows you to inspect the working directory and the staging area, git log only operates on the committed history.

There are many ways to customize log output. Here are some of the most common configurations of git log:

git log

This displays the entire commit history using the default formatting. If the output takes up more than one screen, you can use Space to scroll and q to exit.

git log -n <limit>

Limit the number of commits by <limit>. For example, git log -n 4 will display only 4 commits.

git log --oneline

Condense each commit to a single line. This is useful for getting a high-level overview of the project history.

git log --stat

Along with the ordinary git log information, this will include which files were altered and the relative number of lines that were added or deleted from each of them.

More Git Log Configurations

git log -p

This shows the full difference of each commit, which is the most detailed view you can have of your project history.

git log --author="<pattern>"

This allows you to search for commits by a particular author. The <pattern> argument can be a plain string or a regular expression.

git log --gprep="<pattern>"

This allows you to search for commits with a commit message that matches <pattern>, which can be a plain string or a regular expression.

git log <since>..<until>

This will only show commits that occur between <since> and <until>. Both arguments can be either a commit ID, a branch name, HEAD, or any other kind of revision reference.

git log <file>

This will only display commits that include the specified file. This is an easy way to see the history of a particular file.

git log --graph --decorate --oneline

These are a few more useful options you may want to consider. The –graph flag that will draw a text-based graph of the commits on the left-hand side of the commit messages. –decorate adds the names of branches or tags of the commits that are shown. –oneline shows the commit information on a single line making it easier to browse through commits at-a-glance.

Final Thoughts

I hope this has shown you how to properly inspect a Git repository. By using the git status and git log commands and combining them with different configurations, you can successfully navigate and inspect any Git repository. Therefore, improving your efficiency when working on projects.

Learn as much as you can about Git and it will make using it easier in the long run.

The post How To Inspect a Git Repository on GitHub appeared first on GreenGeeks.

What is a Commit?

A “commit” is in fact, the Git version of saving. Traditional saving is thought of as a system operation used to overwrite an existing file or to write a new file. Git operates differently, as saving changes in Git involves committing an operation that in turn, acts on a collection of files and directories.

Git also has an additional saving mechanism known as “the stash.” Essentially, the stash is a storage area for changes that are not ready to be committed. The stash operates on the working directory and provides extensive options.

Furthermore, a Git repository can be configured for certain files and directories. This will prevent Git from saving changes to ignored content. Let’s take a look at how to save changes in Git.

Save Changes in Git

The git add and git commit commands compose the fundamental Git workflow. These are two commands that every Git user should know and understand. Essentially, these commands are the means to record versions of a project into the repository’s history.

See, developing a project on Git involves the basic edit/stage/commit pattern. So in simpler terms, it lays out like this:

Step 1: Edit Files in the Working Directory.

Edit all the files you have been working on and get them ready to “commit.”

Step 2: Use Git Add Comand

When you are satisfied, or ready, to save a copy of the current project as it is, then you stage changes with git add.

Step 3: Commit to Project History

Once you are happy with the staged snapshot that is provided you commit it to the project history with git commit.

Remember, git commit is saving changes in Git. You can also use the git reset command to undo a commit or staged snapshot when/if needed. There are some samples below so you can see what this would all look like.

In addition to git add and git commit, a third command called git push is essential for a complete and collaborative Git workflow. What git push does is send committed changes to remote repositories for collaboration. This allows other team members to access a set of saved changes.

The Staging Area

The main function of the git add command is to promote pending changes in the working directory, to the git staging area. See, the staging area is one of Git’s more unique features. If you are having a hard time understanding the staging area think of it like this:

The staging area is considered one of the three trees of Git. The other two trees are the working directory and the commit history. Instead of having to commit (save) all of the changes you have made since the last commit, the staging area lets you group related changes into highly focused snapshots before actually committing it to the project history.

This means you can make a bunch of edits to unrelated files, then go back and split them all up into logical commits by adding related changes to the stage and commit them piece-by-piece, instead of all together.

As is the case with any revision control system, it is important to create multiple commits so that it is easier to track down bugs and revert changes when necessary, without having a huge impact on the rest of the project.

Common Options

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git add <file>[/ht_message]

Stage all changes in <file> for the next commit.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git add <directory>[/ht_message]

Stage all changes in <directory> for the next commit.

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git add -p[/ht_message]

Begin an interactive staging session that lets you choose portions of a file to add to the next commit. This will present you with a chunk of changes and prompt you for a command. Here are some commands to choose from and what they mean:

• y: Use the y command to stage the chunk.
• n: Use the n command to ignore the chunk.
• s: Use the s command to split it into smaller chunks.
• e: Use the e command to manually edit the chunk.
• q: Use the q command to exit.

Other Examples

When you start a new project remember that git add serves the same function as svn import. To create an initial commit of the current directory, you will want to use the following two commands:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git add .
git commit[/ht_message]

Once you have your new project up and running you can then add new files by passing the path to git add:

[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git add hello.py
git commit[/ht_message]

Use the commands above to record changes to existing files. Remember, Git does not differentiate between staging changes in new files vs. changes in files that have already been added to the repository.

Quick Review of Saving Changes

Git can be complicated unless you really start to work with it and understand the ins and outs of the program. Let’s do a quick review of saving changes in Git and how it works.

1. The git add command is the first command to use in a chain of operations. This command directs Git to “save” a snapshot of the current project state, into the commit history. When it is used on its own, git add will promote pending changes from the working directory to the staging area, as described above.
2. A git status command is used to examine the current state of your repository and can be used to confirm a git add promotion.
3. The git reset command can be used to undo changes, essentially undo a git add command.
4. The git commit command (also known as the save command) is then used to commit a snapshot of the staging directory (once you are happy with the snapshot) to the repositories commit history.

Final Thoughts

Saving changes in Git is a much different process than saving changes in other file editing applications. However, with a little practice and patience, you will have your Git project running smoothly in no time at all.

Keep practicing with Git and performing commits. You can also check out other Git commands as well. The system is vast, but like anything else, once you learn it then it can be very useful.

The post How to Save Changes in Git appeared first on GreenGeeks.