<p>From a high level, why do you have both jenkins and developers pushing to the branch? If you have enough CI testing for jenkins to force-push to the branch, then you have enough CI testing to revoke push access from the developers. At first it sounds scary to only have robots pushing to branches (and you should also have a small core team with push access which is only used in the direst of situations), but once you take the plunge into branches gated by CI -- meaning CI must pass before merges are allowed -- operational confidence in the code will quickly increase.</p>

CC BY-SA 3.0
2017-06-01T23:42:56.947Z
2017-06-01T23:42:56.947Z
Jesusaur
<p>It really depends on your situation, but I'll go with the generic/naive approach and say do exactly what your developers do in the same situation: I pulled an hour ago, I made some changes, now I want to push my changes, but other changes have been pushed in the meantime. I commit, pull/rebase, then push. Assuming that whatever Jenkins is committing isn't tied to the commit it built from, this is the same process it should follow to get the same result.</p>

CC BY-SA 3.0
2017-05-19T20:37:42.477Z
This sounds right in theory, but I'm unclear on the actual git commands that should be used. Can you elaborate with the commands? (Junior devops here, my git-fu is weak)
Alex
CC BY-SA 3.0
2017-05-19T20:41:34.450Z
The steps I gave are the commands: `git commit`, `git pull` or `git pull --rebase`, and `git push`.
Adrian
CC BY-SA 3.0
2017-05-19T19:10:55.750Z
2017-05-19T19:10:55.750Z
Adrian
<p>A while ago I had written about how commits were being merged (successfully) into our develop branch in Git, but would later go missing, with no evidence of the missing code other than all the Bitbucket logs proving the merge happened. </p>

<p>We just figured out yesterday that what's happening is Jenkins clones our repo, then holds it for up to 40+ minutes while jobs run, then pushes back with <code>git push origin +develop</code>. This is essentially overwriting any commits we've made in that 40+ minutes as Jenkins pushes back the branch exactly as it saw it on the clone, and minus our additions. </p>

<p>We thought the solution would be to change to </p>

<pre><code>git pull --rebase origin
git push origin develop
</code></pre>

<p>but that's returning </p>

<pre><code>+ git pull --rebase origin
error: Cannot pull with rebase: You have unstaged changes.
</code></pre>

<p>To clarify, Jenkins' "branch" has files on it that we do need merged into the repo. The ideal situation is to find the right way to do a fresh pull of develop into Jenkins' copy before pushing back.</p>

<p>What's the correct git procedure to avoid this issue?</p>

<p><strong>Note</strong>: My original post was deleted for being too vague, and rightfully so since at the time I had zero idea why things weren't working. In this case what happens is Jenkins checks out the repo, runs a script that makes parameter files needed for a second job, then checks it back in so the files (and associated logs) exist in the repo for use/auditing. Not having Jenkins do the process isn't an option.</p>

CC BY-SA 3.0
2017-05-19T19:53:57.590Z
I'd suggest adding a link to the earlier post you mentioned for context. I remember seeing it, but I can't find it anymore. Just a thought. I was wondering why you'd need jenkins to pull at all?
Dan Cornilescu
<jenkins><git>
Jenkins pushing to branch overwrites commits made in interim
Alex
# Jenkins pushing to branch overwrites commits made in interim

(Asked by: username_0 on 2017-05-19)

A while ago I had written about how commits were being merged (successfully) into our develop branch in Git, but would later go missing, with no evidence of the missing code other than all the Bitbucket logs proving the merge happened. 
We just figured out yesterday that what's happening is Jenkins clones our repo, then holds it for up to 40+ minutes while jobs run, then pushes back with git push origin +develop. This is essentially overwriting any commits we've made in that 40+ minutes as Jenkins pushes back the branch exactly as it saw it on the clone, and minus our additions. 
We thought the solution would be to change to 
git pull --rebase origin
git push origin develop

but that's returning 
+ git pull --rebase origin
error: Cannot pull with rebase: You have unstaged changes.

To clarify, Jenkins' "branch" has files on it that we do need merged into the repo. The ideal situation is to find the right way to do a fresh pull of develop into Jenkins' copy before pushing back.
What's the correct git procedure to avoid this issue?
Note: My original post was deleted for being too vague, and rightfully so since at the time I had zero idea why things weren't working. In this case what happens is Jenkins checks out the repo, runs a script that makes parameter files needed for a second job, then checks it back in so the files (and associated logs) exist in the repo for use/auditing. Not having Jenkins do the process isn't an option.

**Tags:** jenkins, git

> **Comments:**
> **username_1**: I'd suggest adding a link to the earlier post you mentioned for context. I remember seeing it, but I can't find it anymore. Just a thought. I was wondering why you'd need jenkins to pull at all?  

---

## 2 answers

### Answer by username_3 on 2017-05-19. Score: 3 | Accepted answer

It really depends on your situation, but I'll go with the generic/naive approach and say do exactly what your developers do in the same situation: I pulled an hour ago, I made some changes, now I want to push my changes, but other changes have been pushed in the meantime. I commit, pull/rebase, then push. Assuming that whatever Jenkins is committing isn't tied to the commit it built from, this is the same process it should follow to get the same result.

> **Comments:**
> **username_0**: This sounds right in theory, but I'm unclear on the actual git commands that should be used. Can you elaborate with the commands? (Junior devops here, my git-fu is weak)  
> **username_3**: The steps I gave are the commands: `git commit`, `git pull` or `git pull --rebase`, and `git push`.  

---

### Answer by username_2 on 2017-06-01. Score: 1

From a high level, why do you have both jenkins and developers pushing to the branch? If you have enough CI testing for jenkins to force-push to the branch, then you have enough CI testing to revoke push access from the developers. At first it sounds scary to only have robots pushing to branches (and you should also have a small core team with push access which is only used in the direst of situations), but once you take the plunge into branches gated by CI -- meaning CI must pass before merges are allowed -- operational confidence in the code will quickly increase.


---

