Would you like a coworker without experience with git to use your git repository? Or are you that coworker who hasn’t used git before? Here’s what you need to know.
1. Set up git
♦ You’ll need to perform this step only once
$ git config user.name “<your name>” # Tell git who you are
$ git config user.email “<your email address>” # Tell git who you are
2. Connect to your colleague’s repository
♦ This will download the remote repository and establish a link between it and the local copy (working directory) on your system. You’ll need to perform this step once per repository/project
$ cd <path where you want the git repository as a subdirectory>
$ git clone firstname.lastname@example.org:repo.git # make sure you use the address your colleague gave you
3. Working cycle
$ git pull # download the latest changes from the server, if any
< do the actual work: make your changes, and check whether everything works >
$ git pull # download the latest changes from the server, if any, and merge them with yours
$ git commit -a -m ‘<message>’ # tell git about your changes
$ git push # upload your changes to the server, for others to use
4. Changes to make
- edit existing files
- add newly created files to the repository:
$ git add <file1> <file2> …
- before committing and/or pushing, make sure everything works/compiles
- before committing and/or pushing, verify the changes and status:
$ git diff # shows a diff of the changes you made
$ git status # shows a status of the repository: which files were changed/added?
$ git log # shows previous commits and the last version that was synced with the server by push/pull
- Make sure you work in the git directory created in step 2. Do not copy the files elsewhere, edit them there, and copy them back.
- Git can merge different changes made by different users, even to the same files in the repository. However, this only works if you edit different lines withing the same file. If you’re editing the same lines as your colleague (without full cycles of committing, pushing and pulling for both you and your coworker in between), git receives one set of changes from you and a conflicting set of changes from your colleague and no longer knows what to do. This is known as a conflict.
- Avoid conflicts by pulling, committing and pushing often, even for relatively minor (but always complete) (sets of) changes.
- Another way of avoiding conflicts is by using many short lines, separated by hard returns, instead of a few long ones, if possible (e.g. in LaTeX). Remember that conflicts arise when multiple people are editing the same lines. Having your content divided over more lines reduces the risk.