[doc] Version Control Exercise #2
Conversation
Version_Control_Exercise.md
Outdated
|
|
||
| Everyone run `git status`. We'll run this frequently, and you should make a habit of it - it's a | ||
| good way to check the state of your local repository. You should see that you are up-to-date with | ||
| `origin/main` (the "origin" refers to the remote repository on gitlab). |
There was a problem hiding this comment.
References to GitLab can be deleted
|
Do you guys think it'd be a good idea to add some diagrams to how the commits/workflow occurs? I'm fine either way, but what we already have is a lot so I understand if not |
I personally never found those diagrams useful when I was trying to learn Git (because they are usually too "complicated" for the basics). The most useful image I've ever came across about was this one since it helped me understand the difference between local and remote: Having diagrams for merging and pull requests is quite messy and complicated, and if you do add a diagram for that, I would keep it to one (I was looking for a good diagram as an example but gave up since all of them would probably just create confusion). |
|
Honestly, at that point, I think we'd be fine to leave it out. I think for the wiki it may be a good idea for one of us to make some illustration or diagram of how MRover workflow works since this is merely a tutorial/intro. I think leaving it as is without a diagram is fine. |
|
I imagine some whiteboarding sessions during meetings will still be in order, even when we front load the teaching effort with great resources like this. I hope everyone has been practicing drawing git trees 😆 |
|
Ok, last set of changes. Mostly grammatical, some smaller things with boldening and me leaving in "lab staff." I also added a note that rebasing should not be an option almost never. Feel free to peek quickly and once @CameronTressler reviews and approves, we can merge |
Version_Control_Exercise.md
Outdated
| Everyone in the group should sign into their GitHub account they plan to use with the MRover team, if they have not done already. | ||
|
|
||
| **Person 1** should create a new repository on GitHub. From here, Person 1 should ensure the following when creating the new project: | ||
| * Name it `mrover-vc-exercise` |
There was a problem hiding this comment.
Maybe it would be good to explain the 'vc' acronym, people may not realize what this is. Within this, could say that svn is an alternative to git
There was a problem hiding this comment.
Alternatively I guess I could talk about this in the workflow-intros readme, but I think it would make a little more sense here? That other one is really just about pull requests
There was a problem hiding this comment.
I'll put something in the beginning that talks about VCS and Git vs. SVM; I didn't feel like it would be necessary, but it would be good for members to know
Version_Control_Exercise.md
Outdated
|
|
||
| To actually work on the code, you will need to **clone** the remote repository to create a **local repository** on your own computer. | ||
| 1. Open a terminal and navigate to a folder. We recommend making one called `mrover` to store all the work you will be doing with us. | ||
| 2. Run the following command (replace `zwgold` with the username of the person who had created the remote repository): `git clone [email protected]:zwgold/mrover-vc-exercise.git` (Note: This command will only work if you have SSH Keys set up. Please follow the steps in the first tutorial to do so!) |
There was a problem hiding this comment.
Could this be changed to describe how to find the link from the browser page? Personally, I very rarely just type the link directly, usually I copy it from the 'code' drop down
Version_Control_Exercise.md
Outdated
| This should create a new folder called `mrover-vc-exercise`. That is your **local repository**. | ||
|
|
||
| ## Making a basic change | ||
| At this point, everyone should have a new directory for the **local repository** called `mrover-vc-exercise`. Navigate your terminals into that folder using `cd`. You can check that you are in the right place with the command `pwd`. |
There was a problem hiding this comment.
Might be a little pedantic but I would recommend explicitly saying 'using cd mrover-vs-exercise'
Version_Control_Exercise.md
Outdated
| `origin/main` (the "origin" refers to the remote repository on github). | ||
|
|
||
| Run the command `ls`. You should see the default `README.md` file that GitHub created automatically with the project. Feel free to go ahead and open the file in your IDE. (You could also just open the | ||
| whole folder in your IDE.) |
There was a problem hiding this comment.
Looks like a newline accidentally got into this line
Version_Control_Exercise.md
Outdated
| **Person 2** should continue to lead for this section. Others should follow along. | ||
|
|
||
| 1. Run `git add README.md`. This **stages** the changes so they can be committed. | ||
| 2. Run `git status`. That file is now staged and ready to be committed. |
There was a problem hiding this comment.
Just for clarity, I would say "This shows that the file is now staged..." to be clear that git status doesn't do anything
Version_Control_Exercise.md
Outdated
| 1. Run `git add README.md`. This **stages** the changes so they can be committed. | ||
| 2. Run `git status`. That file is now staged and ready to be committed. | ||
| 3. Run `git commit -m "modify readme"`. This **commits** the changes to your **local repository**. You can think of each commit in the repository as a step along the version history of your code. The `-m` adds a note about what the commit does. | ||
| 4. Run `git status`. Your **local repository** is a step ahead of the **remote repository**. |
There was a problem hiding this comment.
Same comment as above
Version_Control_Exercise.md
Outdated
| 2. Run `git status`. That file is now staged and ready to be committed. | ||
| 3. Run `git commit -m "modify readme"`. This **commits** the changes to your **local repository**. You can think of each commit in the repository as a step along the version history of your code. The `-m` adds a note about what the commit does. | ||
| 4. Run `git status`. Your **local repository** is a step ahead of the **remote repository**. | ||
| 5. Run `git push`. From here, you may need to configure your upstream, which if needed, a message will pop up with the corresponding command to do so. Additionally, you may need to enter your GitHub username/password. |
There was a problem hiding this comment.
I'm tempted to just say we should describe what 'upstream' here means, but that might be pretty challenging for a novice git user to understand, and not completely necessary for now. Alternatively, we could just tell them to run git push origin main
There was a problem hiding this comment.
I thought about it, I'm going to change the command, but additionally, explain what upstream means. I'll send what I had in mind and if it's too much we can just use the command git push origin main with a very brief explanation
There was a problem hiding this comment.
I think this is good
Version_Control_Exercise.md
Outdated
|
|
||
| Note that the `-A` flag will stage all files that have been modified. | ||
|
|
||
| Now, **Person 1** should make one change to their copy of `README.md`. |
There was a problem hiding this comment.
Hopefully they get the point, but just in case, probably good to specify this should happen before pulling
|
Looks good! I added a few small comments that should be pretty straight-forward to address. Sorry for taking a few days |
…nal information on VCS and upstream
resolves umrover/mrover-ros#41
Adapted the EECS 280 Lab 0 Version Control Exercises into a markdown for new members to work through to gain experience handling changes across different local repositories.