Git: special operations for add, commit, or push when lots of changes exist?

My understanding of git add is that you’re basically saying to your local git repo “Yes, I’m sure I want to make these changes.”

My understanding of git commit is to actually save the changes to your local HEAD branch. At this point they are actually in version control, but are only local to your instance of git.

  • specify directory for git pull (not current directory)
  • How can I place my Meteor apps version number in the UI?
  • npm install private git repository with .git folder and .gitignore file
  • Git remote for testing
  • Can git tell me if a rebase will conflict without actually rebasing?
  • Can git automatically switch between spaces and tabs?
  • My understanding of git push is to propagate your saved (committed) changes to the master repo, so other developers (or perhaps a CI build) can pull them down for themselves.

    If anything that I have said so far is wrong or is misleading, please begin by correcting me. Assuming I’m correct in my understandings, I originally had a package in my Java project that looked like this:

    com.myapp.server.servlets
        FizzServlet
        BuzzServlet
    

    But then I decided to refactor the names and of a few things, as well as both adding & deleting some new files/packages:

    com.myapp.server.servlet
        FizzesServlet
        WidgetServlet
        com.myapp.server.servlet.impl
            FizzesServletImpl
            WidgetServletImpl
    

    Overall, I account for 5 changes to this directory:

    1. Changed the name from “com.myapp.server.servlets” to “com.myapp.server.servlet
    2. Changed the name from “FizzServlet” to “FizzesServlet
    3. Deleted the BuzzServlet altogether
    4. Added a new WidgetServlet
    5. Added a new com.myapp.server.servlet.impl package with two child files

    Do I have to do any sort of special command magic here, because I did so much refactoring, or can I just run something like git push * to push everything to GitHub? In the SVN Eclipse plugin, if I renamed a package or source file, and then tried committing that change, I would often lose the file altogether (locally) and have to restore from local history. Even then, I got burned far too many times to count and lost a lot of work. I’m hoping not to get the same experience with Git.

  • Proxy issues on git and ssh - Arch linux
  • Intellij (Android Studio) git integration: Where is .git?
  • Can I just copy a git repository to Windows?
  • Moving git branch to another local repo
  • Ensure coding-style during a git commit
  • Git repo not updating github.io content
  • One Solution collect form web for “Git: special operations for add, commit, or push when lots of changes exist?”

    From the way you’re very careful about pushing, your understanding of git push is not quite complete. push will literally only push your commits to your remote — that means, it will copy the exact state that you saved in the commit(s) you have made since last pushing. In Git, every commit is a snapshot of all the files in a repository (it does in fact record all files, and not just the changes). So what you see locally after committing will be exactly what’s copied onto the remote when pushing.

    When you push, one of two things can happen:

    1. The push succeeds, in which case all is well and the state of the remote mirrors the state of your local repo (to emphasize this, remember that git commits are identified by their SHA hash — if the commit were different, so would the hash be)
    2. The push gets rejected, because it is not fast forward. This happens when someone else has pushed commits onto your remote since your last pull/fetch, and it is the equivalent of the nasty and oft-feared conflict when trying to commit in SVN. However, your local state is not affected by this. You will have to resolve the conflict (a) dropping your commits and accepting the state of the remote (git reset is used for this) or by fetching from the remote and (b) merging your local changes, thereby creating a merge commit which will indicate the diverging and re-converging of your history, or alternatively (c) rebasing onto the remote, to produce linear history.

    The conflict resolution case will take a bit more looking into, but the actions required are well-described in the Pro Git book (chapters Branching, Merging, Rebasing).

    A conflict can only happen if someone else can push to your remote, or if you push to your remote from another computer. If you are working in a single-user single-computer scenario (at least for now), there will be no conflict when pushing.

    Git Baby is a git and github fan, let's start git clone.