2. Always commit to correct branch.
3. Leave useful, and comprehensible commit messages.
4. Do not work on shared (development, master, etc) branches.
5. Rebase your feature branches to development branch.
6. Diligently handle conflicts.
7. Do not track environment dependent files (Eg. conf.php).
8. Track "templates" of environment dependent files (Eg. conf.php.tmp).
9. Do not track end-user-manipulated files and directories (Eg. "uploads" folder).
10. Do not track "crap files" (Eg. "error.log", "thumbs.db").
11. Remember to track needed but currently empty directories.
A few that come to mind:
- Prefer small, self contained, atomic commits to large ones
- This makes it much easier to understand what you did later
- This allows you to revert specific things if you made a mistake without having to revert a bunch of unrelated stuff and recommit it.
- A useful feature for this is the ability to stage only specific changes within a file and not the whole file so even if you did not plan ahead, and made big changes you can still break them down into separate commits easily. This is possible in the command line but is much easier using a GUI client such as smart git or gitg.
- Write descriptive commit messages - this will help you in the future and your team mates in the present.
- Set git to rebase after pull instead of merging. This will make your history much clearer and makes more sense. To set git to do this automatically run the following in the command line:
- git config --global pull.rebase true
- Don't work too long without commiting - this relates to the first point. I usually make a few commits a day. If you work for a number of days without commiting anything something isn't right - you are not breaking your changes into small enough chunks and you risk loosing your work. One of the nice things in git is that once something is commited you can always recover it. (This by the way doesn't mean you should commit things that don't compile or are half done, just break down you changes into small chunks of working code)
- Make formatting changes in separate commits from actual changes. Formatting a changes make it hard to see what you really changed.
Some of the other answers convolute multiple topics such as revision control and software methodology (to good effect, mind you). For purely git practices, I would recommend the following:
1. Read (or at least skim through) Pro Git: Git - Book
2. Make your commits as small as possible, and group them logically. It is easy to combine 2 commits, but harder to break 1 into pieces.
3. Use descriptive and concise commit messages. If you are having a hard time doing this, your commit is probably too big or it changes more than one thing. Remember the phrase "commits are cheap," and the classic UNIX philosophy, "do one thing, and do it well."
4. "Feature branches" are common; use them! They allow you to work on different additions/changes to a project from the same starting point without affecting each other. Using them correctly tends to cause your master/head branch to only ever contain merge commits which makes identifying problematic changes easier.
5. Decide on a project's "workflow" before you dive into coding. For small projects where you are the only contributor, it is not a problem to use feature branches in the main repo (or even commit straight to master for a linear history). For anything larger, I would recommend the fork-and-pull model. With this model, contributors maintain their own "fork" (clone) of a repo. When they have made changes to their fork that they want others to have, they "upstream" those changes by sending a "pull request" to the original repo. If the developers of the original repo like your changes, they will merge them in with the rest of their code. If not, they will tell you why or suggest revisions.
When you get into developing software, release cycles come into play. Determining what goes into a release and how to coordinate getting everything done begs the use of planning and a proper software methodology (e.g. lean/agile/etc.) which can define such things as epics, stories, and sprints. But that is all a different topic...
No comments:
Post a Comment