5 ms·
If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you ha
by ekidd 15y ago
If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble.
It's possible to build a very successful git workflow using only the following commands:
git clone git:...
git add path/to/new_file
git commit -a
git pull
git push
(Yes, commit before pulling, rather than vice versa.)
If you want to use branches, you need to add:
# Showing branches.
git branch -a
gitk --all
# Checking out branches.
git checkout some_branch
# Creating and pushing a new branch.
git checkout -b new_branch_name
git push -u origin new_branch_name
# Checking out an existing branch.
git checkout -b some_branch origin/some_branch
# Merging a branch into your current branch.
git pull origin some_branch
This workflow is extremely safe. At worst, you might need to resolve a merge conflict.
But if you start digging around under the hood, and you start editing your commit history, you'd better be prepared to understand what you're trying to do.
- nicky0 15y agoWhy the -u on push?
- _ikke_ 15y agoIt creates a tracking branch, and so git knows how far a branch is relative to a remote branch.
- deleted 15y ago[deleted]
- Kwpolska 15y ago-u, --set-upstream For every branch that is up to date or successfully pushed, add upstr eam (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge in git-config (1). --man git-push
- shennyg 15y agoIt allows you to use `git pull/push' without specifying the remote. see: http://mislav.uniqpath.com/2010/07/git-tips/ http://mislav.uniqpath.com/2010/07/git-tips/ Section "Push a branch and automatically set tracking"
- Pewpewarrows 15y agoA thousand times this. For my first year to year and a half of using git, I didn't even know that you could re-write your history. I just started out with a personal repo on my own machine, where I'd init, add, rm, commit, and look at logs. Then I learned how to start working with someone else's repo, which introduced me to cloning, pulling, pushing, fetching, and all that jazz. As the project sizes grew, I realized how useful branches were, so I became more familiar with tracking things upstream, merging, and some more advanced workflows. Finally I started poking around in the git object model, and learning how I can clean up my local history before a push. It was baby steps all the way. Trying to use rebase the same week or month that you learn git (or version control period), while doable for some, is just crazy for everyone else. You don't jump into riding a bike before you learn to walk.
- hardtke 15y agoIf I follow your workflow, my coworkers go ballistic. The problem is that the "git pull" messes up the revision history. I finally learned to use "git pull --rebase".
- rictic 15y agoTechnically speaking it doesn't "mess up" the revision history, it preserves it. Rebasing instead of merging creates a linear revision history, which is simpler and more similar to centralized version control, but at the cost of losing information about the actual path of development.
- ajross 15y agoAll true. Certainly nothing is "messed up". That said, reading through a bunch of fine-grained and uninformative merge commits when looking at a log is really annoying. Serious projects expect submissions to be in the form of clean patch sets that apply in series and "look like" an instantaneous change. No one cares about per-developer histories. If you look at the kernel history, for example, the only merge commits you see are Linus's and the subsystem maintainers'.
- mainguy 15y agoRight, because the kernel patches are emailed and never pushed to a public location. In essence, the "committers" of the kernel are the only ones who do rebases (either explicitly or implicitly). Frankly, git was not designed for a lot of the use cases it's finding itself in. Medium sized agile teams (5-10 devs) with multiple people mucking around in the same files will be removing bullets from their feet repeatedly for a few weeks when first switching.... OR they will have an incomprensible tangle of branches and merge commits that no person will ever be able to figure out.
- ajross 15y agoThat may be overstating things. The incomprehensible tangle is really just an annoyance. Look at it with "git log --no-merges" and it looks exactly like the tangle you'd get with CVS or subversion: lots of independent unsequenced changes by different developers. Git by default shows this stuff, which in the kernel's use case is useful data. But in this case it's just useless chaff, and an annoyance. But hardly a serious problem.
- garydevenay 15y agoCouldn't agree more! I have lead quite a successful 'git life' without using any complex commands and therefore have never found git hard!
- ph0rque 15y agoGood advice. I would add the following use case: # Oh no! Those changes should have been on their own branch, not dev... git stash git checkout -b changes_on_their_own_branch git stash apply git commit -a
- fr0sty 15y agoThat is overly verbose. Try this: git checkout -b changes_on_their_own_branch git commit -a You can always create a new branch at HEAD (where you are currently) and switch to it without having to stash. On the other hand, stashing may be required if you wanted your branch to start elsewhere: git checkout -b changes_branch start_point
- Timothee 15y agoBut doesn't git stop you from switching to another branch when there are uncommitted changes?
- skimbrel 15y agoAs GP said, not if you're creating a new branch. There's no history in the new branch to potentially overwrite your uncommitted changes in the working tree, so nothing for it to object to.
- eridius 15y agoGit only prevents switching branches if the act of switching branches would modify the files you have uncommitted changes to. In the case of fr0sty's suggestion, the new branch cannot have any changes because it's being created from the current HEAD. But even if you're switching to a pre-existing branch, it may still work depending on what files git will need to touch. In other words, no harm in trying the `git checkout other_branch` first, and only stashing if that fails.
- rjh29 15y agoTo checkout an existing branch, you need only do 'git checkout new_branch_name' - if the branch exists on the remote, git will automatically create a local version and set it to track the upstream version.
- dave1010uk 15y agoI really don't like "git commit -a". I've seen people new to git add every file in the project directory without checking what files are there. This includes merge conflicts, SQL dumps and random backups. If you do a "git status" immediately before then "git commit -a" can be a slight time saver; though It's better to use "git add -u", which stages all files that are in the repo and ignores any new files. Personally, I like adding files either 1 or 2 at a time or even with "git add -p". While I'm at it, lots of people seem to have poor (single line) commit messages, stemming from the use of "git commit -m". Whilst this is OK on some occasions, commit messages are often better thought of as an email with a subject and a body. (Yes, I know sometimes a single line commit is all you need and you can write multi-line commits directly on your shell but some people don't know this and it limits their ability to write a good commit message.) Feel better getting that out my system. Now I need to tell my co-workers.
- donaq 15y ago"git commit -a" actually does not add every file in the directory. It only adds those that are already in the repo.
- dave1010uk 15y agoThat's embarrassing. I meant "git add -A" or "git add .". I guess "git add -a" or "git commit -a" isn't so bad but I still think care should be taken when adding files to the index, especially with newcomers to git, who pick up habbits from tutorials like this.
- skrebbel 15y agoYou're kindly assuming people never enter the wrong command by accident. Undoing a commit, for example, is very common and necessary, especially for beginners.
- ekidd 15y agoThe easiest way to undo a commit is to treat git just like you would Subversion or Mercurial: Use 'git revert $COMMIT_ID' to reverse the generated commit, or simply fix things by hand and commit again. Sure, you can edit the broken commit, if you value a pretty commit history. But again, this requires understanding git well enough to predict the effects. What happens if you run 'git commit --amend -a' after pushing the original commit? What if another user already pulled? How will you fix the resulting mess? If you can answer these questions, then you'll have no problems editing history. If you can't, then you may be signing up for a lot of pain.