Sysop:Git

Aus immerda
Zur Navigation springen Zur Suche springen

Using Git

Online documentation

Eclipse Git Plugin

Usage

Workflow

A normal workflow of editing things in git repository might be the following:

  • clone respository, if you don't have it yet on the disk
  • pull repository, if you have already cloned it.
  • work on your things
  • commit your things
  • work on more things
  • commit them and again and again
  • push your changes. This can be to a remote shared repository or your own public repository

This workflow can vary depending on your needs and things you are working on. Please refer to the various documents linked above, describing possible workflows.

In the following command overview we normally describe a very simple workflow, which is adequate for most users which might use git instead of CVS or subversionand don't (yet) use the advanced features of git and the workflows you can describe with.

Authorname etc.

Each commit has an author and a committer field, which record who and when created the change and who committed it (Git is designed to work well with patches coming by mail - in that case, the author and the committer will be different). Git will try to guess your realname and email, but especially with email it is likely to get it wrong. You can check it using git config -l and set them globally with: 

git config --global user.name "Your Name Comes Here"
git config --global user.email you@yourdomain.example.com

You can still distinguish by each repository if you simply do the follwoing in the adequate repository. 

git config user.name "My other name"
git config user.email myself@mydomain.example.com

Colors

Git can produce colorful output with some commands; since some people hate colors way more than the rest likes them, by default the colors are turned off. If you would like to have colors in your output: 

git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto

clone

With clone I clone a remote repository to my location, so I can use and work on it. It's possible to clone from various access possiblities, we present the 2 most common from here:

daemon/git-protocol

I can clone from a git-daemon with the so called git-protocol: 

git clone git://git.foobar.com/myrepository.git

This command will clone the remote git repository into a folder myrepository.

Host and repository location is depending on the remote setup. Please refer to the appropriate information you get on the website or from the developer.

ssh

Using git over ssh, will provide secure authentication and transmission of the data. For usability it's recommended to have an ssh-agent session running, while working.

Command: 

git clone $user@git.foobar.com:/myrepository.git

or 

git clone ssh://$user@git.foobar.com:/path/to/myrepository.git

Depending on the setup of the ssh access the clone url can vary. Please refer to the appropriate information you get on website or from the developer.

pull

pull will help you to update your local repository against the remote one. In short: pull will first fetch your remote repository and then merge a remote branch (usually the master branch) with your adequate local one.

So the simplest thing is that you do the following on a repository which doesn't have any outstanding changes to commit: 

git pull

You can also just update (fetch) the reference to your remote repository and the manually merge it: 

git fetch
git merge origin/master

The last command will merge the changes in the remote repository into your current branch.

If you'd like to see the changes between the fetched remote repository and your local branch you can use the following command after fetching the remote repository: 

git diff origin/master

origin/master is always referring here to the appropriate remote branch, where origin is the identifier of your remote repository and master the remote branch. This can vary according to your workflow or needs.

commit

You normally commit changes grouped together in one commit, for one changed feature or part. So for example if you change two parts or add 2 new features, you do 2 commits and only committing the thins changed for the feature you'd like to commit.

new files

If you have created new files, you first have to add them to your upcoming commit: 

git add path/to/new/file

preparing a commit

With git add you can also add already existing files to the upcoming commit: 

git add path/to/changed/file

show status

With 

git status

you can see your not yet committed changes. It shows you changes you:

  • new or changed files added to the upcoming commit
  • changed but not yet added files
  • new but not yet added files

committing

With one of the following two commands 

git commit
git commit -m "some message"

you commit the changes you added to the upcoming commit.

The first command (git commit) will open an editor where you can enter the commit message, and if you save and quit, the commit will occur with this message.

The second command (git commit -m "some message") will commit the files with the message "some message"

Please: always use good commit messages, which describes what you have changed, added or removed!

If you have changed only a few files and don't want to split into different commits, you don't need to add changed files (but sill new ones!) to the upcoming commit and you can use one of the following two commands: 

git commit -a
git commit -a -m "some message"

which will commit all changed files. So you don't have to add them manually.

push

Commits are always local, hence if you'd like to share your changes with other people or the rest of the world, you have to push them to a repository everybody or your developer team can read from. This can either be your own public repository or a shared repository you use in a team and you might have cloned from.

Pushing means that you push your changes to this repository. You can do that the following way: 

git push origin

Where origin is your identifier of your remote repository and usually the one you cloned from. For more remote repositories have a look at the remotes section.

If you'd like to push into a new repository, where nobody yet have pushed to you can do it the following way: 

git push origin master:refs/heads/master

Where master is your local branch you'd like to push. See branches for more information about branches.

You can also push one of your branches to another remote branch: 

git push origin master:refs/heads/newbranchname

You can also delete remote branches: 

git push origin :branch_to_delete

Use Subversion repositories with GIT

Remotes

useful aliases

graph

 [alias]
     graph = log --graph --abbrev-commit --date=relative --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(blue)<%an>%Creset'

Ruby and Git

Abgerufen von „https://wiki.immerda.ch/index.php?title=Sysop:Git&oldid=8706“