User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
cs:git:start [2017/09/11 15:47] Sean Kallaher [Rebase/Integration Method] |
cs:git:start [2017/09/11 15:48] Sean Kallaher [Quick reference] |
||
|---|---|---|---|
| Line 47: | Line 47: | ||
| Users often go long periods without commiting their work, because they feel like small changes are not worth committing. They wait until a substantial amount of changes have occurred, which can range from a few days to a few weeks. This is bad! This results in others not being aware of work that the user is doing, and also risks work getting lost. Users should at a **minimum** commit whatever they have done at the end of their current work session that day. | Users often go long periods without commiting their work, because they feel like small changes are not worth committing. They wait until a substantial amount of changes have occurred, which can range from a few days to a few weeks. This is bad! This results in others not being aware of work that the user is doing, and also risks work getting lost. Users should at a **minimum** commit whatever they have done at the end of their current work session that day. | ||
| - | Some may complain that this will result in a cluttered git history, however the solution for this is simple. When code is ready to be put into an integration branch, the user should perform an interactive rebase, and at that time they can squash together multiple commits into a single commit. By doing this a user can have 15 commits on their own branch (useful when they are developing), but when they believe their added feature is good and stable they can squash-rebase onto dev, and have single commit representing all the changes for the added feature. This results in a very clean and descriptive history when looking at the dev branch. | + | Some may complain that this will result in a cluttered git history, however the solution for this is simple. When code is ready to be put into an integration branch, the user should perform an interactive rebase, and at that time they can squash together multiple commits into a single commit. By doing this a user can have 15 commits on their own branch (useful when they are developing), but when they believe their added feature is good and stable they can squash-rebase onto master, and have single commit representing all the changes for the added feature. This results in a very clean and descriptive history when looking at the master branch. |
| ===== What Files to Commit? ===== | ===== What Files to Commit? ===== | ||
| Line 54: | Line 54: | ||
| ===== Quick reference ===== | ===== Quick reference ===== | ||
| * ''git fetch'' retrieve the latest changes from the server | * ''git fetch'' retrieve the latest changes from the server | ||
| - | * ''git rebase <other branch>'' rebase your current branch on top of <other branch>, which typically should be dev. | + | * ''git rebase <other branch>'' rebase your current branch on top of <other branch>, which typically should be master. |
| * ''git checkout <file/directory name>'' reset all unstaged changes to <file/directory name> | * ''git checkout <file/directory name>'' reset all unstaged changes to <file/directory name> | ||
