Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
training:everyday_git_usage [2016/09/21 05:58]
kluong [Steps]
training:everyday_git_usage [2021/09/19 21:59] (current)
Line 10: Line 10:
 **Create a branch**\\ **Create a branch**\\
 git checkout -b branch_name\\ git checkout -b branch_name\\
 +-//Name your branch something descriptive:​ test-sampler,​ add-ga-comments//​\\
 +
  
 **Update from the remote master**\\ **Update from the remote master**\\
Line 15: Line 17:
 //git fetch\\ //git fetch\\
 git rebase origin/​master\\ git rebase origin/​master\\
- 
  
  
Line 22: Line 23:
 git commit\\ git commit\\
  
-**In case you forgot to add something to your commit**+**In case you forgot to add something to your commit**\\
 git add filenames.c \\ git add filenames.c \\
 git commit --amend\\ git commit --amend\\
Line 45: Line 46:
 **git add ** - Add file contents to the index [[https://​git-scm.com/​docs/​git-add | Details ]] \\ **git add ** - Add file contents to the index [[https://​git-scm.com/​docs/​git-add | Details ]] \\
 **git commit** - Record changes to the repository. [[https://​git-scm.com/​docs/​git-commit | Details ]] \\ **git commit** - Record changes to the repository. [[https://​git-scm.com/​docs/​git-commit | Details ]] \\
-**git push ** - Update remote refs along with associated objects. [[https://​git-scm.com/​docs/​git-push | Details ]]+**git push ** - Update remote refs along with associated objects. [[https://​git-scm.com/​docs/​git-push | Details ]]\\ 
 + 
 + 
 +===== Notes ===== 
 + 
 +[0] Read the git output - it's normally pretty useful and will tell you what to do. If you get stuck in a state where you have no idea what is happening, try to think about what you did last and how that affects the git data model. If all fails, ask a teammate. 
 + 
 +[1] We use rebasing to keep the history linear and clean. By doing this, we can make sure that every commit is well documented; this also has the added advantage of making code reviews easier as well. 
 + 
 +[2] Branching, especially if you're only working on a one or two person team, is not really necessary. As long as you manually communicate with everyone then it's fine. However, on bigger teams you often will need branches to keep things organized and to do proper code reviews. 
 + 
 +[3] //Pull requests//, a github specific term, give us a mechanism that allows us to easily review code. Other systems (such as Gerrit Code review) also impose different workflows on top of git. 
 + 
 +===== Further Reading =====
  
 +[[ https://​git-scm.com/​book/​en/​v2/​Getting-Started-Git-Basics | Git Basics ]] provides a fantastic technical explanation of how git works in the back.
  
  • training/everyday_git_usage.1474437485.txt.gz
  • Last modified: 2021/09/19 21:59
  • (external edit)