version control - I want to commit but also create branch in git. Is this the correct way? -

i have 3 files unstaged.
want commit , push 2 of them , save 3rd in private branch.
if git add/git commit 2 of them, git checkout branch name , git checkout master , git pull followed git push correct?

for concreteness, on master, , have 3 files:

.../file1 .../file2 .../file3 

where ... parts path within repo, , i'll leave them out below.

the first 2 files new (you created them) or existing (you modified them), doesn't matter in case.

meanwhile file3 either new or modified, may make difference below.

the first part right: git add file1 file2; git commit make new commit containing 2 new-or-modified files (and other files in repo), not containing file3 (if it's new), or not containing changes file3 (if exists).

as commit file1 , file2 done, can push new master:

git push origin master 

it doesn't matter have not done file3 yet, or branch on when above; specifying want push local branch master origin's master, can @ least try push time. (that's 2 arguments for. origin part "where it's going", , master part means same master:master, means "push local master -> remote master".) or, can delay if like, , we'll in moment. more importantly, might fail "rejected" message, in case you'll pretty have delay while commit file3 somewhere.

now, file3, situation little more complicated. want "save in private branch", ok, can that, but: new file, or did exist? if new things easy. if existed, there's 1 or 2 more questions: private branch new branch, or existing (private) branch? if it's existing branch, file differ between "whatever branch you're on now" , "that other branch want on"?

for new branch or new file, there won't issues here. do:

git checkout -b new_private_branch    # create new private branch git add file3 git commit 

or:

git checkout existing_private_branch git add file3 git commit 

if there's no change between whatever branch you're on now, , existing private branch, second command work. but, if file3 in current branch, , in existing_private_branch, , different between two, you'll get:

error: ... overwritten checkout:     file3 

when try move existing private branch. because git needs overwrite work-tree version of file3 in order move branch.

if that's case, you'll need save modified file3 (or changes file3) somewhere git checkout won't overwrite, , make working-directory file3 either clean, or non-existent. there number of ways (e.g., mv file3 another_name versus git stash), various different advantages , disadvantages.

i'm guessing file3 new, and/or private branch new, there's no point in going more details here. anyway, let's assume you've saved away file3 on private_branch. means did git commit on private branch , git status shows clean.

git pull, git fetch, git merge, and/or git rebase

everything's cleaned locally , can do:

git checkout master 

to on master.

if else has beaten git push, , try git push origin master (instead of earlier), you'll error:

 ! [rejected]        master -> master (non-fast-forward) 

this means, beat it. put master don't have yet. need it, , how git fetch.

if don't rejected, nobody beat , you're in great shape , done! don't need pull or fetch-then-merge or anything. you're more beat other guy if git push origin master earlier, above. if tried earlier , failed, or try , fails, time something.

git pull

the git pull command means git fetch followed git merge (unless configure rebase). prefer not use git pull much—i separate fetch-then-decide steps. if use git pull anyway, let's break down fetch , merge parts.

git fetch

i type origin part here too:

git fetch origin 

unless you've configured git bunch, fetch assume origin anyway, can leave out origin part; explicit.

this ascii diagrams of commits come in handy. after first git push attempt fails (is "rejected") , git fetch, wind with. each letter represents commit. commits a , b started with. commit c 1 you made file1 , file2. commit d 1 "they" (whoever beat it) made. private branch "coming off b", won't bother drawing here.

... - - b - d       <-- origin/master             \               c        <-- master, head=master 

the push gets "rejected" because you're asking remote move origin/master point c. c, history goes b, , git follows these lines "up and/or backwards" there's no link b d. leave commit d lonely , forgotten.

at point have 2 easy(ish) options. can git merge. since you're on master now, , master tracks origin/master, mean same long form:

git merge origin/master 

that tells git merge your current branch (i.e., master) 1 "fetch"-ed, origin/master. if merge goes automatically git commit-s merge , have remote happy with. diagram-wise, makes new commit e:

... - - b - d        <-- origin/master             \   \               c - e    <-- master, head=master 

now git push origin master succeed. making origin/master point e ok, because e points up-and-back both c and d. but, mean you've made merge-commit have avoided. whether should avoid policy decision, more technical 1 (so nobody boss can tell 1 way or :-) ).

your other option use git rebase instead of git merge:

git rebase origin/master 

(as git merge, can leave out origin/master part, because master tracking origin/master.)

what take commit made earlier—the 1 adding file1 , file2—and "figure out changed" in process (i.e., changed in files), , make same change origin/master. if goes well, leaves old commit behind (it's still in there, git saves long time) , makes new commit. result this:

... - - b - d        <-- origin/master            \    \             \     c2   <-- master, head=master              \               c        [no label] 

the changes in old-commit-c (file1 , file2) in new-commit-c2. unlike c though, c2 "on top of" origin/master. git push origin master succeed, , (including you) forget c , use c2 , history a - b - d - c2. it's not "better" merge version, it's simpler @ , (sometimes) think about.