I think this adds only files relative to the current path?
One I use from time to time is git add -p (-p stands for patch) , useful if you have a large set of changes, you keep forgetting to commit incrementally upfront, and you want to split your changes into one or more commits.
git checkout -b BRANCH_NAME will create a new branch locally.
Also, if you have time, look at pre-commit hook for your project :-) tired of running your favorite test harness plugin for your project manually or waiting for your Jenkins server to get the job?
Last, is git fetch vs git pull still a debate? I always use git fetch because that seems to be most preferable, fetch then rebase is the right path, most clean way to merge changes with some upstream / branch.
Thanks. I love git but can only be generously considered as a casual user. There are still many things that confuse me (e.g. Tags) and as such there is a ton of functionality I still don't understand. These types of posts help. It's appreciated.
Another one: git pull --rebase. If you've made a commit or two but others have pushed before you've had a change to pull, you can do a rebase to avoid the separate branch and merge that a regular git pull will attempt to do. I don't know if I'd trust it on very out of date branches though.
Recently found out about the usefulness of this command -- was amazed at how much simpler it made integrating changes. It can get tricky with conflicts, but now the commits in my pull requests aren't getting polluted with commits that are just "Pulling in changes" full of other people's code.
Yes. I'd highly recommend making `git pull --rebase` the default behavior of your `git pull` operation. I'd thought that the Git folks were going to make this the default behavior at some point. It really ought to be.
`git pull --rebase` is a much better conceptual way to integrate changes from your upstream when working together collaboratively. The rationale is this: a newly released change should be, in the ideal case, simply an incremental diff against the head of the branch. It may have been developed by forking off at some point in the past, and incorporating changes over time, but those are implementation details of how the diff has been constructed. Once the diff is ready to go, ready to be committed, it's just an incremental change to the head.
By working in a branch and using `git pull --rebase` to incorporate upstream changes, you keep your code in a constant state of being "an incremental addition" to the primary branch. Indeed, it's very similar to what happens with Perforce when one runs `p4 sync ...`, by comparison - your local code is updated to account for the new remote contents. Finally when you submit, your change looks like a single incremental commit, or series of commits. The resulting history is simple and linear.
Sometimes people object to this because they claim that source history should be the "true history of what happened", whatever that means. I believe those arguments miss the point of source history. Source code history is always an abstraction over what really happened. Imagine an extreme example: an IDE that generates a single source commit for every keypress you type while editing a file. That's the true history of what really happened. But is it useful to commit that history to a repository? Of course not - that history is kept locally in your IDE as undo buffer. Similarly, it's often not useful to pollute the commit history with implementation details of how you developed the change (sometimes, but not often).
When you develop changes locally and push them upstream, you rightfully make a judgment call about what level of detail about the development process should be exposed in the history, and what level of detail should be hidden. For example, you might hide detail by combining many keypresses into one commit, as is conventional, or by squashing multiple related commits into a single commit. You might hide the detail about how your change was developed over time by using rebase to make it appear as if it's an incremental change to the head, even if it was developed over time and involved several integrations from the upstream. Sometimes these history-abstracting changes are not appropriate, such as if you truly need to develop a branch in parallel with the main branch, that many people are collaborating on. In that case, a branch may be appropriate. Most of the time, it's ideal to develop changes directly on the master branch, as an incremental change to it, using `git pull --rebase` to keep local changes up to date, which will result in a simple, linear history.
Thank you. I work in a very old-fashioned research lab that we managed to drag to git recently. I haven't been able to convince the team to read the git book. This could be more helpful.
As an aerospace engineer who codes rather than a software engineer, is there a cheatsheet that talks about how to use git from a "when do I commit/merge/etc" rather than a "this the command to perform commit/merge/etc"? Basically, an "Idiot's Guide to Making My Life Easier with Git"
I've tried to use git a few times at work, but I always end up forgetting to use it for awhile when deadlines start creeping up so it becomes "well, the code works in it's current state and it's been 2 months since I committed, so I should probably update the repo" which doesn't seem much better than periodically backing up the folder.
Once you made any noticeable change, it's time to commit. Bonus points for only including files / chunks related to the completed change and not other changes in-flight. This ggives you a nice, annotated history and a way to step back to known state. Many commits a day is the norm.
I have found the tutorials and references on git-scm.com to be effective. http://git-scm.com/doc
Learning and adopting Git was definitely worth it for me and organizations I've worked with. It provides advantages that are difficult to describe in words and best experienced first hand [1]. Once you understand it, it's like a swiss army knife, or a power tool capable of manipulating source code commits any way one desires. The user experience might not be simple, but the semantics are simple in a way that makes operations easy to perform in Git that are challenging in other source control systems.
You can probably take better advantage of source control than checking in on a monthly basis. Personally, I recommend checking in about every 30 minutes to folks I work with. However, we're used to quick release cycles where code might reach production hours after we submit it, not years. I personally favor frequent commits also because it acts as an additional layer of protection against data loss, as well as facilitating frequent code reviews and visibility by coworkers, frequent integration testing, etc. These benefits support developing code as a team, and support a quick release process.
If you'd like to learn Git, then I'd recommend integrating it into your daily habits such that you're committing regularly, perhaps every 30 minutes to an hour. It will be difficult to learn the tool effectively if you use it only once per month.
[1] I'm happy to try if anyone wishes, but there are plenty of arguments out there. I would summarize by saying that Git simply works better than anything else I've used, including CVS, Subversion, Perforce, etc. Upon familiarizing myself with Git, it feels like those tools, through lack of capability, create a lot of problems and friction that Git avoids.
I've had this same problem for a time, but then I realized that forcing myself to commit a lot of times and keep commits meaningful (commits must have a message, and so the committed changes must all be related to that message) also forced me to work in a more focused way: one feature/fix at a time. That is very very good.
The main point is to make your commits small and incremental, with a single commit adding a single feature (or fixing a bug, etc). If you are reading the commit log, there shouldn't be any surprises as to what a particular commit actually changes when applied. If you have a lot of uncommitted changes, remember that you don't have to add them all at once -- use 'git add file1 file2' and make descriptive messages for each change. Also remember that you can 'rebase --interactive' to fix up your commits locally if you want (don't rebase shared/pushed history, though).
like "git stash" it stashes away all the untracked modifications you have, but it puts them onto another branch. i often end up making partial progress on things that should be conceptually in different branches at once - this way, you can stash unrelated changes into different branches, and then merge each branch as you finish.
20 comments
[ 3.0 ms ] story [ 20.4 ms ] threadhttp://zrusin.blogspot.com/2007/09/git-cheat-sheet.html
In nice printable format with a sort of "state diagram" for commits (workspace <-> index <-> local commit <-> remote commit)
https://github.com/trufa/git-cheatsheet
One I use from time to time is git add -p (-p stands for patch) , useful if you have a large set of changes, you keep forgetting to commit incrementally upfront, and you want to split your changes into one or more commits.
git checkout -b BRANCH_NAME will create a new branch locally.
Also, if you have time, look at pre-commit hook for your project :-) tired of running your favorite test harness plugin for your project manually or waiting for your Jenkins server to get the job?
Last, is git fetch vs git pull still a debate? I always use git fetch because that seems to be most preferable, fetch then rebase is the right path, most clean way to merge changes with some upstream / branch.
`git pull --rebase` is a much better conceptual way to integrate changes from your upstream when working together collaboratively. The rationale is this: a newly released change should be, in the ideal case, simply an incremental diff against the head of the branch. It may have been developed by forking off at some point in the past, and incorporating changes over time, but those are implementation details of how the diff has been constructed. Once the diff is ready to go, ready to be committed, it's just an incremental change to the head.
By working in a branch and using `git pull --rebase` to incorporate upstream changes, you keep your code in a constant state of being "an incremental addition" to the primary branch. Indeed, it's very similar to what happens with Perforce when one runs `p4 sync ...`, by comparison - your local code is updated to account for the new remote contents. Finally when you submit, your change looks like a single incremental commit, or series of commits. The resulting history is simple and linear.
Sometimes people object to this because they claim that source history should be the "true history of what happened", whatever that means. I believe those arguments miss the point of source history. Source code history is always an abstraction over what really happened. Imagine an extreme example: an IDE that generates a single source commit for every keypress you type while editing a file. That's the true history of what really happened. But is it useful to commit that history to a repository? Of course not - that history is kept locally in your IDE as undo buffer. Similarly, it's often not useful to pollute the commit history with implementation details of how you developed the change (sometimes, but not often).
When you develop changes locally and push them upstream, you rightfully make a judgment call about what level of detail about the development process should be exposed in the history, and what level of detail should be hidden. For example, you might hide detail by combining many keypresses into one commit, as is conventional, or by squashing multiple related commits into a single commit. You might hide the detail about how your change was developed over time by using rebase to make it appear as if it's an incremental change to the head, even if it was developed over time and involved several integrations from the upstream. Sometimes these history-abstracting changes are not appropriate, such as if you truly need to develop a branch in parallel with the main branch, that many people are collaborating on. In that case, a branch may be appropriate. Most of the time, it's ideal to develop changes directly on the master branch, as an incremental change to it, using `git pull --rebase` to keep local changes up to date, which will result in a simple, linear history.
https://docs.google.com/presentation/d/1t8grwHN0SB7HGgD9Jv9g...
I've tried to use git a few times at work, but I always end up forgetting to use it for awhile when deadlines start creeping up so it becomes "well, the code works in it's current state and it's been 2 months since I committed, so I should probably update the repo" which doesn't seem much better than periodically backing up the folder.
Learning and adopting Git was definitely worth it for me and organizations I've worked with. It provides advantages that are difficult to describe in words and best experienced first hand [1]. Once you understand it, it's like a swiss army knife, or a power tool capable of manipulating source code commits any way one desires. The user experience might not be simple, but the semantics are simple in a way that makes operations easy to perform in Git that are challenging in other source control systems.
You can probably take better advantage of source control than checking in on a monthly basis. Personally, I recommend checking in about every 30 minutes to folks I work with. However, we're used to quick release cycles where code might reach production hours after we submit it, not years. I personally favor frequent commits also because it acts as an additional layer of protection against data loss, as well as facilitating frequent code reviews and visibility by coworkers, frequent integration testing, etc. These benefits support developing code as a team, and support a quick release process.
If you'd like to learn Git, then I'd recommend integrating it into your daily habits such that you're committing regularly, perhaps every 30 minutes to an hour. It will be difficult to learn the tool effectively if you use it only once per month.
[1] I'm happy to try if anyone wishes, but there are plenty of arguments out there. I would summarize by saying that Git simply works better than anything else I've used, including CVS, Subversion, Perforce, etc. Upon familiarizing myself with Git, it feels like those tools, through lack of capability, create a lot of problems and friction that Git avoids.
1 - Clone the repo (only need do this once)
2 - git checkout branchname
3 - Make some file changes
4 - git add filenames
5 - git commit
6 - git pull (make sure you are up to date BEFORE you push to remote repo)
7 - Build and TEST
8 - git push
That's 90% of what I do.
Merging branches is simple.
1 - git checkout destinationBranch
2 - git pull
3 - git merge sourceBranch
4 - build and test
5 - git push
Cheers!
The main point is to make your commits small and incremental, with a single commit adding a single feature (or fixing a bug, etc). If you are reading the commit log, there shouldn't be any surprises as to what a particular commit actually changes when applied. If you have a lot of uncommitted changes, remember that you don't have to add them all at once -- use 'git add file1 file2' and make descriptive messages for each change. Also remember that you can 'rebase --interactive' to fix up your commits locally if you want (don't rebase shared/pushed history, though).
"git stash branch <branchname>"
like "git stash" it stashes away all the untracked modifications you have, but it puts them onto another branch. i often end up making partial progress on things that should be conceptually in different branches at once - this way, you can stash unrelated changes into different branches, and then merge each branch as you finish.