From f6829a461bbb8801eeb8f32fa6acdf8c5afa5249 Mon Sep 17 00:00:00 2001 From: NataliaLKB Date: Wed, 1 Apr 2015 08:08:51 +0100 Subject: [PATCH 1/4] replacing PR with Pull request to make it more consistent --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index e1eb9e3..a66a5d8 100644 --- a/README.md +++ b/README.md @@ -224,7 +224,7 @@ Go to your browser and open up this repository in github. Press the branches but ![branches button in gitub](./img/github-branch.png) -And then make a Pull Request to master +And then make a pull request to master ![viewing all your branches on github](./img/view-github-branches.png) @@ -263,7 +263,7 @@ Merge with master. You should have a git conflict that looks something like this ![git merge conflict example](./img/merge-conflict.png) Do you see the lines at the top. The first section is labelled `HEAD` those are from this branch. The next section is from master. Delete the lines, and any other code you want until the cheatsheet looks like how you want it to look. -Afterwards git status, add the files in red, commit, and push. Then make a PR to master like before and merge. Don't forget to update your local master branch, and delete the merged branch in Github and in your local repo. It is good to keep your working environments clean and organised. +Afterwards git status, add the files in red, commit, and push. Then make a pull request to master like before and merge. Don't forget to update your local master branch, and delete the merged branch in Github and in your local repo. It is good to keep your working environments clean and organised. @@ -344,7 +344,7 @@ Next, we should go back to the future. The quickest and easiest way is to checko ![git reflog example](./img/git-reflog.png) Find the commit name of the last commit you did (the third time that you recorded) and copy the short hash in yellow. Checkout back to that commit, and `git diff timeline-practise` there should be no difference. -Checkout back to `timeline-practise` and push up to Github to make a PR to master. Make sure you first check that +Checkout back to `timeline-practise` and push up to Github to make a pull request to master. Make sure you first check that it is up to date with master locally. @@ -365,7 +365,7 @@ The second method is you work through your task and complete it before adding or Through my research I have come across many different methodologies, and ultimately you should try to do what seems the most natural to you. I use both of these methodologies depending on the extend of the task before me. The best thing is to always keep in mind that you and your colleagues will inevitably need to go back to your commits and it will help everyone if commits are aptly named. -Likewise, even in Pull Requests, you must aim to make your commits a clear and concise summary of what tasks where completed on that branch. That way the person reviewing your PR understands what they will be reviewing before looking at the code itself. +Likewise, even in pull requests, you must aim to make your commits a clear and concise summary of what tasks where completed on that branch. That way the person reviewing your pull request understands what they will be reviewing before looking at the code itself. From eacc347dfa7805ed03def80a901ddcb797831a5d Mon Sep 17 00:00:00 2001 From: NataliaLKB Date: Wed, 1 Apr 2015 08:19:39 +0100 Subject: [PATCH 2/4] adding further description of `origin` --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index a66a5d8..6e118e8 100644 --- a/README.md +++ b/README.md @@ -220,6 +220,8 @@ After you merge with master you have to push your changes to the remote repo (Gi git push origin update-cheatsheet ``` +When you pull or push you you are usually referring to your remote repo, or origin. In the example of `git push origin ` you are pushing your local changes to a remote branch that you are specifying. It is best practise, and makes things much simpler if you use the same name for your remote branch, as your local one. + Go to your browser and open up this repository in github. Press the branches button ![branches button in gitub](./img/github-branch.png) From c281ead8f83e79a24d1e8f34ee5cbbb889cdf54d Mon Sep 17 00:00:00 2001 From: NataliaLKB Date: Wed, 1 Apr 2015 08:37:01 +0100 Subject: [PATCH 3/4] embelishing the message section about commits to include how you get out of vim --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 6e118e8..db0ecff 100644 --- a/README.md +++ b/README.md @@ -195,7 +195,7 @@ git commit -m 'adding new command in the cheatsheet' git status ``` -The message could be anything, but it is best to make it something that describes what you just did. +The message could be anything, but it is best to make it something that describes what you just did. You can also use the command `git commit` without `-m ' @@ -220,7 +220,9 @@ After you merge with master you have to push your changes to the remote repo (Gi git push origin update-cheatsheet ``` -When you pull or push you you are usually referring to your remote repo, or origin. In the example of `git push origin ` you are pushing your local changes to a remote branch that you are specifying. It is best practise, and makes things much simpler if you use the same name for your remote branch, as your local one. +When you pull or push you you are usually referring to your remote repo, or origin. In the example of `git push origin ` you are pushing your local changes to a remote branch that you are both creating, and naming. Since you are creating this branch from your local one it makes things much simpler if you use the same name for your remote branch, as your local one. + +For more information on pushing, see [here](https://help.github.com/articles/pushing-to-a-remote/) Go to your browser and open up this repository in github. Press the branches button From 1e1d465e465e5dff4938280723e6760ea559b77c Mon Sep 17 00:00:00 2001 From: NataliaLKB Date: Wed, 1 Apr 2015 08:44:28 +0100 Subject: [PATCH 4/4] describing more clearly what happens on a git push based on #2 --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index db0ecff..cd11dfc 100644 --- a/README.md +++ b/README.md @@ -195,12 +195,12 @@ git commit -m 'adding new command in the cheatsheet' git status ``` -The message could be anything, but it is best to make it something that describes what you just did. You can also use the command `git commit` without `-m ' ### Merging Changes with Master -Now that you have made and committed your changes, it is time to merge your branch with master. Even though you are not working with anyone else on this repository, it is always good practice to make sure your current branch is completely up to date with master. Checkout back onto master and pull down. This command looks like this: +Now that you have made and committed your changes, it is time to merge your branch with master. Even though you are not working with anyone else on this repository, it is always good practice to make sure your current branch is completely up to date with master. Imagine if you were working with a team. Someone else has already pushed up changes to master. If that someone else and yourself have changed the same file, it is quite likely that your changes will not be compatible with theirs. To avoid this, you want to merge your changes with theirs to avoid future problems. Checkout back onto master and pull down. These commands look like this: ``` git checkout master @@ -220,7 +220,7 @@ After you merge with master you have to push your changes to the remote repo (Gi git push origin update-cheatsheet ``` -When you pull or push you you are usually referring to your remote repo, or origin. In the example of `git push origin ` you are pushing your local changes to a remote branch that you are both creating, and naming. Since you are creating this branch from your local one it makes things much simpler if you use the same name for your remote branch, as your local one. +When you pull or push you are referring to your remote repo, or origin. In the example of `git push origin ` you are pushing your local changes to a remote branch that you are both creating, and naming. Since you are creating this branch from your local one it makes things much simpler if you use the same name for your remote branch, as your local one. For more information on pushing, see [here](https://help.github.com/articles/pushing-to-a-remote/) @@ -232,7 +232,7 @@ And then make a pull request to master ![viewing all your branches on github](./img/view-github-branches.png) -Now merge, and delete your branch. +Now merge, and delete your branch. Now your remote branch master is completely up to date with your latest changes. Return to your terminal and navigate to your local master branch. Pull down. You will see your branch update (fast-forward). Delete the branch `update-cheatsheet`.