Difference between revisions of "Git How-To"

From RoboJackets Wiki
Jump to navigation Jump to search
m
 
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==SSH Accounts==
+
==Windows Users==
Before using Git, you will need to have an ssh account on our server to get access. Contact the robojackets network manager to create an account. The username is the one used for the robojackets account, and should be typed '''without''' brackets. Verify this account as follows in a terminal:
+
You'll need to download and install git from [http://git-scm.com/ git.com]. Use all of the default choices in the installer. Once you've done this, you can run all of the commands below in Git Bash.
<pre>
+
Access Git Bash by right-clicking on your desktop and selecting "Git Bash".
ssh [username]@robojackets.org
+
 
</pre>
+
== Public Key ==
You should be asked for a password, and then will have logged in. Because git uses ssh as its primary means of communication, and you'll need to log in a lot, you'll want to set up passwordless login from your own system.  You'll do this by creating an RSA public key with the steps as follows in a terminal on your machine.
+
 
<pre>
+
Before using Git, you have to get access to our repos. The software we use to manage Git access requires your "public key."
ssh-keygen
+
 
[press enter at each prompt for defaults]
+
To generate your public key:
ssh-copy-id -i ~/.ssh/id_rsa.pub [username]@robojackets.org
+
 
ssh [username]@robojackets.org
+
#Create the .ssh directory
</pre>
+
#*Linux users:
At the last step, you should have been able to log into the server without a password.
+
#**<pre>mkdir ~/.ssh<br/>chmod 700 ~/.ssh</pre>
 +
#*Windows users:
 +
#**The directory already exists at C:/Users/[username]/.ssh/
 +
#Generate your ssh key
 +
#*<pre>ssh-keygen -t rsa</pre>
 +
 
 +
This process will produce a public key file (id_rsa.pub) in the directory you created. You should send or copy this file to your project manager, who will add it to the Git system and grant you appropriate permissions.
 +
 
 +
== Getting Code from the Server ==
  
==Getting Code from the Server==
+
Our code, electronics designs, design report, and data sheets are stored in Git repositories. To get access to these, you need to "clone" the correct repository to your machine.
Currently, the software team uses Git, so you will need to clone your team's repository to your machine as follows in the folder of your choice:
 
  
: Robocup
+
:Software
<pre>
+
<pre>git clone git@robojackets.org:igvc/software.git igvc/software
git clone ssh://[username]@robojackets.org/git/robocup/software software
+
</pre>
 +
:Electrical
 +
<pre>git clone git@robojackets.org:igvc/electrical.git igvc/electrical
 
</pre>
 
</pre>
: IGVC
+
:Documents
<pre>
+
<pre>git clone git@robojackets.org:igvc/docs.git igvc/docs
git clone ssh://[username]@robojackets.org/git/igvc igvc
 
 
</pre>
 
</pre>
This will check out a copy of the repository.  For those of you that have used SVN before, remember that committing only commits to the local (on your machine) repository, and you need to "push" to put something on a different machine.
+
== Changing Remote to the Server ==
  
==Changing Remote to the Server==
 
 
If you got the code off of a flash drive, you will need to reset your local copy of the git repository to use the server instead. Go into your software folder and execute:
 
If you got the code off of a flash drive, you will need to reset your local copy of the git repository to use the server instead. Go into your software folder and execute:
<pre>
+
<pre>git remote rm origin
git remote rm origin
+
git remote add -t master -m master origin git@robojackets.org:igvc/software.git
git remote add -t master -m master origin ssh://[username]@robojackets.org/git/robocup/software
 
 
</pre>
 
</pre>
 +
== Committing Local Changes ==
  
==Committing Local Changes==
+
As you add changes and make something work, you should commit your changes to your local repository. This will allow you to manage changes by making use of git, if you want to go back. Once you have something working, execute the following command:
As you add changes and make something work, you should commit your changes to your local repository. This will allow you to manage changes by making use of git, if you want to go back. Once you have something working, execute the following command:
+
<pre>git commit -a
<pre>
 
git commit -a
 
 
</pre>
 
</pre>
'''You will add a meaningful commit message to say what you did.''' This is important so that other people can understand what you are doing. After committing, you can check that you have committed things by running status:
+
'''You will add a meaningful commit message to say what you did.''' This is important so that other people can understand what you are doing. After committing, you can check that you have committed things by running status:
<pre>
+
<pre>git status
git status
 
 
</pre>
 
</pre>
 +
== Updating Your Local Repository ==
  
==Updating Your Local Repository==
+
Because other people are making changes to the repository on the server, you will need to update your local repository from time to time to get these new changes. You should do this just before any commits to a server so that you don't break the build on the server.
Because other people are making changes to the repository on the server, you will need to update your local repository from time to time to get these new changes. You should do this just before any commits to a server so that you don't break the build on the server.
+
<pre>git pull
<pre>
 
git pull
 
 
</pre>
 
</pre>
 
You may need to jump through some hoops to merge things properly if there are conflicts.
 
You may need to jump through some hoops to merge things properly if there are conflicts.
  
 
You can set up an alias to automatically update multiple repositories. For example, if you have the software, electronics, documentation, and mechanical repositories inside a folder called robocup, you can add the following line to your .bashrc file located in your home folder.
 
You can set up an alias to automatically update multiple repositories. For example, if you have the software, electronics, documentation, and mechanical repositories inside a folder called robocup, you can add the following line to your .bashrc file located in your home folder.
<pre>
+
<pre>alias update_robocup='echo "Checking..."; cd /home/UserName/robocup/electrical; echo "Electrical: "; git pull; cd ../mechanical;  
alias update_robocup='echo "Checking..."; cd /home/UserName/robocup/electrical; echo "Electrical: "; git pull; cd ../mechanical;  
 
 
echo "Mechanical: "; git pull; cd ../robocup_docs; echo "Documentation: "; git pull; cd ../software; echo "Software: "; git pull; cd ../; echo "Done!";'
 
echo "Mechanical: "; git pull; cd ../robocup_docs; echo "Documentation: "; git pull; cd ../software; echo "Software: "; git pull; cd ../; echo "Done!";'
 
</pre>
 
</pre>
 +
You'll probably have to edit that to work with the exact file structure you are using.
  
You'll probably have to edit that to work with the exact file structure you are using.
+
== Committing Changes to the Server ==
  
==Committing Changes to the Server==
 
 
Once you think you have something that should go on the server, you should first check to make sure it works, because if your code breaks the build no one will like you any more and all of the cool kids won't invite you to cool things and everyone will point fingers at you when you walk around campus. Commit all of the changes to your local repository and then push:
 
Once you think you have something that should go on the server, you should first check to make sure it works, because if your code breaks the build no one will like you any more and all of the cool kids won't invite you to cool things and everyone will point fingers at you when you walk around campus. Commit all of the changes to your local repository and then push:
<pre>
+
<pre>git push
git push
+
</pre>
 +
== Branching ==
 +
 
 +
Branches allow us to keep separate instances of the code base for work on individual features. You will often create a branch of the code while you work on fixing a bug or adding a feature, then merge the changes from your branch to the "master" branch when you are done. Here is a summary of the branching workflow:
 +
 
 +
*Create a new branch with this command. Our branch names follow the convention "usrname-taskname". This naming scheme allows us to quickly see who's working on what.
 +
<pre>git branch branchname
 +
</pre>
 +
*Write your code, and commit your changes.
 +
*Use ''PULL'' to update and merge in changes from the master branch. You need to do this to make sure your changes still work with any new changes on the master branch.
 +
**If you want to save yourself some trouble, commit and pull often.
 +
**This command needs to be run while you are on your feature branch for the changes to be merged into your feature branch.
 +
<pre>git pull origin master
 +
</pre>
 +
*Once you've fixed any merge conflicts and tested that the code works with all of the combined changes, checkout the master branch to merge the changes from your branch.
 +
<pre>git checkout master
 +
git merge branchname
 +
</pre>
 +
*Finally, push your merge to the remote server
 +
<pre>git push
 +
</pre>
 +
<br/>If you ever want to see all of the branches in the system, use the following command.
 +
<pre>git branch -a
 
</pre>
 
</pre>
 +
The branch you are currently on will be marked with an asterisk(*).
  
[[Category: How to Guides]]
+
[[Category:How to Guides: Technical]]

Latest revision as of 20:50, 5 February 2020

Windows Users

You'll need to download and install git from git.com. Use all of the default choices in the installer. Once you've done this, you can run all of the commands below in Git Bash. Access Git Bash by right-clicking on your desktop and selecting "Git Bash".

Public Key

Before using Git, you have to get access to our repos. The software we use to manage Git access requires your "public key."

To generate your public key:

  1. Create the .ssh directory
    • Linux users:
      • mkdir ~/.ssh<br/>chmod 700 ~/.ssh
    • Windows users:
      • The directory already exists at C:/Users/[username]/.ssh/
  2. Generate your ssh key
    • ssh-keygen -t rsa

This process will produce a public key file (id_rsa.pub) in the directory you created. You should send or copy this file to your project manager, who will add it to the Git system and grant you appropriate permissions.

Getting Code from the Server

Our code, electronics designs, design report, and data sheets are stored in Git repositories. To get access to these, you need to "clone" the correct repository to your machine.

Software
git clone git@robojackets.org:igvc/software.git igvc/software
Electrical
git clone git@robojackets.org:igvc/electrical.git igvc/electrical
Documents
git clone git@robojackets.org:igvc/docs.git igvc/docs

Changing Remote to the Server

If you got the code off of a flash drive, you will need to reset your local copy of the git repository to use the server instead. Go into your software folder and execute:

git remote rm origin
git remote add -t master -m master origin git@robojackets.org:igvc/software.git

Committing Local Changes

As you add changes and make something work, you should commit your changes to your local repository. This will allow you to manage changes by making use of git, if you want to go back. Once you have something working, execute the following command:

git commit -a

You will add a meaningful commit message to say what you did. This is important so that other people can understand what you are doing. After committing, you can check that you have committed things by running status:

git status

Updating Your Local Repository

Because other people are making changes to the repository on the server, you will need to update your local repository from time to time to get these new changes. You should do this just before any commits to a server so that you don't break the build on the server.

git pull

You may need to jump through some hoops to merge things properly if there are conflicts.

You can set up an alias to automatically update multiple repositories. For example, if you have the software, electronics, documentation, and mechanical repositories inside a folder called robocup, you can add the following line to your .bashrc file located in your home folder.

alias update_robocup='echo "Checking..."; cd /home/UserName/robocup/electrical; echo "Electrical: "; git pull; cd ../mechanical; 
echo "Mechanical: "; git pull; cd ../robocup_docs; echo "Documentation: "; git pull; cd ../software; echo "Software: "; git pull; cd ../; echo "Done!";'

You'll probably have to edit that to work with the exact file structure you are using.

Committing Changes to the Server

Once you think you have something that should go on the server, you should first check to make sure it works, because if your code breaks the build no one will like you any more and all of the cool kids won't invite you to cool things and everyone will point fingers at you when you walk around campus. Commit all of the changes to your local repository and then push:

git push

Branching

Branches allow us to keep separate instances of the code base for work on individual features. You will often create a branch of the code while you work on fixing a bug or adding a feature, then merge the changes from your branch to the "master" branch when you are done. Here is a summary of the branching workflow:

  • Create a new branch with this command. Our branch names follow the convention "usrname-taskname". This naming scheme allows us to quickly see who's working on what.
git branch branchname
  • Write your code, and commit your changes.
  • Use PULL to update and merge in changes from the master branch. You need to do this to make sure your changes still work with any new changes on the master branch.
    • If you want to save yourself some trouble, commit and pull often.
    • This command needs to be run while you are on your feature branch for the changes to be merged into your feature branch.
git pull origin master
  • Once you've fixed any merge conflicts and tested that the code works with all of the combined changes, checkout the master branch to merge the changes from your branch.
git checkout master
git merge branchname
  • Finally, push your merge to the remote server
git push


If you ever want to see all of the branches in the system, use the following command.

git branch -a

The branch you are currently on will be marked with an asterisk(*).