Git is a free and open source distributed version control system – which just means that when you do a git clone (+url of your repository) what you are actually getting is a complete copy of your entire history of that project. This means all your commits! Woot!
Git has a staging area. This just means that if you made 100 new changes to your code, you can break these 100 changes into 10 or 20 or more commits each with their own comments and their own detailed explanation of what just happened!
Some claim Git is better than SVN because it works well even for developers who aren’t always connected to the master repository, as it is available offline.
Branching and merging support are thought to be superior with Git, but it is not as efficient at compressing and storing binary files as other versioning systems.
To see a list of git configuration settings, run:
git config --list
Returns something like:
core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true core.ignorecase=true core.precomposeunicode=true
To see a list of git configuration settings, and where the files they are set in live, run:
git config --list --show-origin
The first thing to do after installing Git is to set the user name and email address. This is important because every Git commit uses this information, and it’s immutably baked into commits.
- Set the global git user with:
git config --global user.name "John Doe" git config --global user.email email@example.com
Git can be configured to work with different user accounts per-repository.
- From within an existing git repository, use the same commands, minus
--globalto set the user for just that repo:
cd /path/to/my/git/repo git config user.name "Jane Doe" git config user.email firstname.lastname@example.org
Make a New Local Repo
Create a new git repo on a local file system by changing into what will become the new repos root directory and enter:
cd /path/to/my/local/git/repo git init
After this, add and commit files as normal.
Make a .gitignore File
Create the file
.gitignore in the root directory of the repo.
See the (.gitignore example file)[/gitignore-example-file/]
cd /path/to/repo/root touch .gitignore git add .gitignore git commit -m "Added a .gitignore file."
Add a Local Project to Github
- Create a new repository on GitHub. To avoid errors, do not initialize the new repository with README, license, or gitignore files. These files can be added after the project has been pushed to GitHub.
- Copy the GitHub remote repository URL from the “Quick setup” section from the repo homepage.
- In Terminal change to the repository root directory.
- Add the local repo to the remote repository and make it the origin:
git remote add origin https://github.com/path/to/my/repo.git
- Verify it by running:
git remote -v
- Push the local repository content to the remote repo:
git push --set-upstream origin master
MacOS Credentials Management
If you are prompted to enter your username and password before each remote commit, then you are not using stored credentials. Git itself cannot store passwords, but it can use external apps like Keychain to store passwords for it.
Keychain for MacOS
git config --listto see the git configurations.
- If this line is present:
credential.helper=osxkeychain, then Keychain has already been setup to hold the actual credentials.
- Open the Keychain app. Go-to the “Login” tab. You should be able to find a
Make Keychain Manage Git Accounts
- From the git repos root directory run:
git config --global credential.helper osxkeychain
- On the next action taken in the repo, you will be prompted to enter your credentials again, which will be saved to Keychain.
Reset the Password in Keychain
- Simply delete the
github.comentry from the Keychain app, then re-set the credentials.
On the next action taken in the repo, you will be prompted to enter your credentials again, which will be saved to Keychain.
Use Multiple Github Accounts
brew install git-flow
Start a New Feature Branch
- Make sure you checkout the
developbranch so your feature is created from the current dev branch.
git checkout develop
developin order to get the most recent version.
Make the Branch
The GitFlow command to start a new branch is
git flow feature start followed by the name of your new feature. Be sure to name your feature something useful (no spaces allowed). For this example we will name our feature
Ticket-001_My_New_Feature. The ticket number is to demonstrate that you can use numbers and dashes.
git flow feature start Ticket-001_My_New_Feature
The new feature branch should now be created and you should be on it. To confirm, simply type
You can now freely work, add files, and commit changes to the feature branch like usual.
You can switch back to a feature branch from another branch by typing
git checkout feature/ followed by the name of your feature branch.
A version-controlled collection of files and directories grouped under a name.
A clone is a copy of a repository. And not just the current iteration, a clone contains the entire repo complete with its entire history.
The origin is the original copy of a repository from which all clones are copied. Developers pull and push to this central copy and use it as the system-of-record for the repository.
A branch is a copy of the repository…inside the repository. The files in a branch are kept separate from all other branches, but all branches are kept in one repository.
The master branch is the default branch name given to the repository when creating it with
To combine two branches together in git is called merging. The process is the same as a commit, where files are compared and combined together. Unresolvable combination failures result in a conflict which must be manually resolved before the merge will complete.
A merge conflict or simply a conflict.
Git Version Number
Check Where Git is installed
Clone a remote origin
Clone a remote repository (origin) located at
https://github.com/my-account/example.git into the directory
/path/to/local/gitrepo/dir on the local machine:
git clone https://github.com/my-account/example.git /path/to/local/gitrepo/dir
Status of the local repo
From within a repository directory:
git status will display the current branch, its relationship to the origin, any files to be committed and any untracked files.
Create a new branch
Create a new branch in the repo named
git branch develop
Switch from the current branch to the
git checkout develop
Create and switch to a new branch
Create a branch and switch to it in one line:
git checkout -b develop
Push a new local branch to the origin
Push the new
develop branch to the origin:
git push -u origin develop
Add (stage) untracked files
Add newly created or edited files to the staging area in preparation for a commit.
Add one file at a time:
git add my_file.js
Or add all untracked files:
git add --all
Pull updates from the origin
Make sure you are working with the latest version of the origin by pulling-down any changes from it often, and before committing.
Commit staged files
Commit all staged files to the local repo:
svn commit -m "A short message about the commit."
Commit message examples:
Fix failing CompositePropertySourceTests Rework @PropertySource early parsing logic Add tests for ImportSelector meta-data Update docbook dependency and generate epub Polish mockito usage
The following is a valid commit message containing tips for writing good git commit messages:
Short (50 chars or less) summary of changes More detailed explanatory text, if necessary, describing the _what_ and _why_, not the _how_. Wrap lines at about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely). Further paragraphs come after blank lines. Write everything in the imperative mood, as if you were commanding someone. Start the line with "Fix", "Add", "Change" instead of "Fixed", "Added", "Changed". - Bullet points are okay, too. - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary. If you use an issue tracker, put references to them at the bottom, like this: Resolves: #123 See also: #456, #789
Push local commits to the origin
Move Current Work to a Feature Branch
Sometime you start down the road on your develop branch, then notice part-way through that this should really be on it’s own feature branch. Stash your current work, create a new branch, then apply the stash to that branch:
git stash git flow feature start my_new_feature_branch_name git stash apply