Difference between revisions of "Git How-To"
(→Getting Code from the Server) |
Athrasher7 (talk | contribs) m |
||
(13 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
− | == | + | ==Windows Users== |
− | Before using Git, you | + | 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". |
− | + | ||
+ | == 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: | ||
+ | |||
+ | #Create the .ssh directory | ||
+ | #*Linux users: | ||
+ | #**<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 == | ||
+ | |||
+ | 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 | ||
+ | <pre>git clone git@robojackets.org:igvc/software.git igvc/software | ||
</pre> | </pre> | ||
− | + | :Electrical | |
− | + | <pre>git clone git@robojackets.org:igvc/electrical.git igvc/electrical | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | <pre> | ||
− | git clone | ||
</pre> | </pre> | ||
− | <pre> | + | :Documents |
− | git clone | + | <pre>git clone git@robojackets.org:igvc/docs.git igvc/docs |
</pre> | </pre> | ||
− | + | == 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 | ||
</pre> | </pre> | ||
+ | == 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. | + | <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. | + | '''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 == | ||
− | + | 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. | + | <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. | ||
− | + | == 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 | + | </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> | </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> | ||
+ | The branch you are currently on will be marked with an asterisk(*). | ||
+ | |||
+ | [[Category:How to Guides: Technical]] |
Latest revision as of 20:50, 5 February 2020
Contents
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:
- Create the .ssh directory
- Linux users:
mkdir ~/.ssh<br/>chmod 700 ~/.ssh
- Windows users:
- The directory already exists at C:/Users/[username]/.ssh/
- Linux users:
- 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(*).